2015年5月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
無料ブログはココログ

« 2010年7月 | トップページ | 2010年9月 »

2010年8月

2010年8月31日 (火)

【システムと経営】経営とコンピュータシステムは切り離せないとは

「経営とコンピュータシステムは切り離せない」とよく言われる。

しかし、ここでいうコンピュータシステムとは何のことであろう。


1.経営のためのツール

2.業務運営のためのツール

両者は別物である。
しかし、1も2も合わせて「経営とコンピュータシステムは切り離せない」の文脈で語られることも多いのではないだろうか。

この混同は、大抵の場合困ることもないだろうが、「ビジネスアナリシス」とか「超上流」とかを考える場合、この区別は重要ではないか。

つまり、経営のためのツールと業務運営のためのツールでは、目的、目標の立て方が違う。
そして、目的、目標のレベルも違う。

一番意識すべきは、ユーザと経営目標との関係である。

「経営のため」と「業務運営のため」ではユーザが違う。

ユーザ企業のシステム部門やSIerは、業務運営のためのツールの要求定義以上の部分を行うことは可能であるが、経営のためのツールのそれは、現状の多くの組織において無理ではないだろうか。

なぜならそれは経営そのものであるから。

この部分は、結局戦略系のコンサルに頼らざるを得ないのであろうか。
それでは悲しい。

ここを自前で出来てこそ、「経営とコンピュータシステムは切り離せない」と言えるのではないだろうか。

2010年8月27日 (金)

【定量的管理】上手なプロジェクト管理と上手なメトリクス管理

ソフトウェア開発において、上手なプロジェクト管理と上手な品質メトリクス管理はどのような関係にあるのだろうか。

品質メトリクス管理は、プロジェクト管理の1項目ではあるが、敢えて分けて考えみる。

プロジェクト管理では、メトリクスを含め様々な情報を元にプロジェクトを計画通りに進めることを目的とする。
計画から外れそうになったら、できるだけ早くその芽を摘み取り、軌道修正する。
そこにプロジェクトマネジャーの手腕が発揮される。

これはある意味職人芸。

この職人芸を前提としたプロジェクト管理に対し、客観的に数値を以って管理しようというのがメトリクス管理である。
メトリクス管理においては、誰がプロジェクトマネジャーとなるかでデータが変わることは前提としづらい。
誰が実施しても同じ傾向が見られるということが前提となっている。

以上を考えると、プロジェクトマネジャーが、想定される以上の能力を持っていると、プロジェクトは、定性的には成功するが、メトリクス管理においては、異常値を生じさせることとなるかもしれない。

メトリクス管理は、着目する管理項目以外についてはプロジェクト間のばらつきはない、もしくは無視できると仮定している。

プロジェクトマネジャーの能力にプロジェクトの成否がかかっているというようなことが一方で言われ、一方で人によるばらつきを前提としないメトリクス管理を言われる。

上手なプロジェクト管理と上手なメトリクス管理とはどのような関係になるのだろうか。

2010年8月24日 (火)

【ソフトウェアの生産性】固定値・変動値

財務における固定費・変動費のような考え方を、ソフトウェアの定量管理においても取り入れて良いのではないか。

つまり、規模や時間の多少に応じて変化する変動値と、規模や時間の多少によってはあまり変化せず、1つの案件を取り組めば固定的に必要となる固定値を分ける考え方。

具体例としては、工数の内、PM工数は比較的開発規模に依存しないように見積もることや、改定すれば必ず実施するテストを決めることが挙げられよう。

実際、このような固定的な考え方を行っている組織も多いだろう。

しかし、このような考えは見積もり時に行われることが多く、プロジェクトが進んで、生産性やバグ摘出密度等を考える際には、せっかく採用した固定的考え方を捨ててしまっていることが多いのではないか。

固定的な考え方を採用せねばならないとは言わないが、一方で見積もり等では取り組んでいるのに、定量管理においてはこの考えを無視して進めてしまうのは、何かもったいない感じもする。

ただし、見積もりは、多少複雑でも算出方法を定義して後からでも追跡可能ならばそれで良いが、実績管理においてはわかりやすくという現場の要請により、できるだけシンプルなものにすべきという考えはあるだろう。

2010年8月20日 (金)

【定量的管理】信頼度の錯覚

【お断り】信頼度といってもSRGM(ここでそのものズバリの名前を書くと余計に検索にヒットしそうなので4文字語で・・・)の話ではありません。

ここに次の2つのデータがある。
あなたはどちらを取るか。

1.自分が担当したシステムの直近5プロジェクトのデータ

2.権威があるとされている団体が集めた3000件を超えるプロジェクトデータ

胸を張って1.と言えるだろうか。

2.はデータの数は多い。手にした数字をハンドリングすれば統計的処理もできよう。しかし、データの素性が全く分からない。業種、システムに対する要求レベルも様々な組織が提供していると、工数1人月と言ったところで三者三様の計上方法であろう。仮に、団体がデータの正規化をしているかもしれないが、それでも諸々のブレは生じよう。

一方、1.はデータの素性を自分自身がしっかり理解している。
数は少ないが、5つのプロジェクトデータがどのような背景下で収集されたかも知っている。次のプロジェクトでも、5つそれぞれの状況をイメージして数字のコントロールができよう。

こう書いてしまうと、当たり前のように聞こえるのだが、「未だ自プロジェクトのデータがほとんど集まっていないので、○○○の発行しているデータ集の数字を元に基準値を策定する」みたいなことを聞くのはなぜだろう。

権威に頼ることはない。
それは信頼度の錯覚である。

先の問には、即答で「1.自分が担当したシステムの直近5プロジェクトのデータ」と言うようにしたい。

2010年8月17日 (火)

【ソフトウェア開発のメトリクス】SI会社の取組み姿勢・・・

【以下は、完全に個人的な考えである】

SI会社におけるソフトウェア開発のメトリクス取組みの意義とは何であろう。

生産性にしろ何にしろ、確立されたメトリクス計測・評価方法と言えるものが無い(※)にも関わらず、取り組むSI会社は多い。

※あるのであれば、グローバルスタンダードとなる定義やIFPUGのような権威あるユーザーズグループのような団体があるはずだが、聞かない。

では、これら会社はなぜメトリクスに取組むのであろうか。
有効有効と言われながら確立された方法がない取り組みを行うのは、収益を指向するSI会社にとってどのようなメリットがあるのだろうか。

なぜか世間では有効と言われている・・・が鍵であろう。
有効と言われていることを行っていないのは、実施していると言う競合他社に対し営業上得策ではない。
よって取り組むこととなる。

これは、裸の王様の家臣のような状態に置かれているというのは言い過ぎか。

しかし、多くのSI会社にとって、外から見た時に「ちゃんとやっているように見える」ということは重要であろう。

それをした方が会社としてペイするのなら私企業の観点からは実施するべきことは当然である。

しかし、さらに個人的な考え方であるが、メトリクスで品質・生産性が管理できるのであれば、プロジェクトマネジメントなど流行らないはずである・・・と考えている。
もちろん、過度に精度や管理に走らずザックリ状況を把握するツールとしての位置づけならば否定はしない。

2010年8月13日 (金)

【メトリクスデータ活用】見積もり用・プロジェクト管理用・報告用

メトリクスデータの活用について。

例えば生産性。
生産性を表現するメトリクスにこれはと言える決定版は存在していない。
それでも各組織で工夫(?)しながらモデルを構築し、測定/評価している。

なぜ?

メトリクスの活用は、用途で見れば、

1.プロジェクトにおける実管理用
2.説明責任用

とに分かれると考えている。

1.は生産性については、かなり厳しいと考える。
方法に決定打がなく各組織で工夫している時点でそれは言えよう。

では、2はどうか。
プロジェクトの節目節目で、状況を報告する際、予め定めた基準に達しているか否かをもって次の工程に行く等の判断を上位管理層や顧客が行う、そのための根拠データという使い方。
これは有効な活用だと考えている。

他にないか。
見積もり用。
見積もりの際も、根拠が必要。
この根拠としてメトリクスデータを基にするという使い方。

こちらも有用であると考える。

以上は、説明責任を果たすためには活用できるが、実際のプロジェクト管理においては使うべきでないというスタンスに立っている。

だからと言って、上位管理層や顧客を騙そうというわけではない。
精度と目的から考えて、活用が妥当か否かということである。

例えば、見積もりは詳細なWBSが作成される前に行われることが多く、精度が実際のプロジェクト管理におけるそれより低くとも有益であると思われる。

以上のように考えるのであるが、実際の運用においては、見積もりも実管理も報告も同じメトリクスでなされていることが多い。

分けろとは言わない、ただし、各メトリクスの特性を考えて使わなければならない・・・と纏めるのも少し違う気がする。

やはり、無理のあるメトリクスを実管理に用いるのは止めるべきであると考える。

2010年8月10日 (火)

【定量的管理はできるのか】ウォーターフォール型開発で要件変更がある開発

ウォーターフォール型開発かつ要件変更を少なくとも設計開始後にも受入れるプロジェクトでは、ソフトウェア開発品質の定量的管理は簡単にはできないと考える。

ならば、複雑な管理をすれば良いかというと、個人的には更に無理だと考えるが・・・。

要件変更があっても、変更に関する変動を正しく追跡すれば良いという考えもあろう。
しかし、変更により何が変わったかということを追跡することは容易なことであろうか。
たとえば、設計中の手戻りがテストにどのような影響を与えるのか読めているであろうか。
W字採用していれば可能?
そうかもしれないけれど・・・。

また、要件変更を正しく管理しておけば、管理しようとしている定量的仮説は維持されるのか。
たとえば、プログラミング中の変更が作りこむバグは、変更のタイミングに因らないと言えるであろうか。

また、過去データの状況から、要件変更による影響を予め見込んで計画や基準値を考えておくなどということも言われるが、要件変更はいつどこでどのようなインパクトのものが何件出てくるかが、定量的に意味があるように分かると考えてよいと言えるだろうか。

では、開発途中の要件変更を受け入れるのであれば、定量的管理はできないというのか・・・と言われるであろう。
そうとまでは言わない。
しかし、精度の観点等、諦めねばならないこともしくは制約が出てくるだろうということ。

やりたいこととできることは違うと考えるべきであるし、定量的管理において屋上屋を架けておかしくなるのは、スパゲッティプログラムと同じで避けるべきである。

« 2010年7月 | トップページ | 2010年9月 »