2006年7月6日木曜日

プロジェクトの尺度

ソフトウェア・プロジェクトの尺度 (生産性とかコード行数とか欠陥密度) をプロセス改善に使うときの問題点はいろいろあるんだけど, その一つに次のようなものがある. あるひとつの尺度をプロセス改善の目安にすると, その尺度を向上させることはできるのだけれど, 必ずしもプロジェクト全体は良くならない.


例えば, 個人の生産性を尺度にするとひとりひとりの生産性の平均は上がってもプロジェクト全体の生産性は落ちてしまうとか, 生産性を尺度にすると隠れた品質も含めた全体の品質は落ちてしまうとか.


それに対処する方法もいくつかある. その一つは尺度をひとつではなく, 複数にして多面性を持たせる. うまくいくこともあるけど, 結局は尺度が際限なく増えて, ソフトウェアを作っているんだか, 測るのが目的なのか分からなくなることもある.


別 のやり方として, ひとつひとつの尺度ではなく, それらを総合した全体的な尺度を使えばいいという考え方もある. そんな尺度はあるのか? すべての尺度と互換性を持ち, すべての尺度を総合した結果を表すような尺度が. 現代社会ではそれは「貨幣」と呼ばれている. 要するにそのソフトウェアがどれだけ稼げるかを問題にすれば, 「見えざる神の手」がすべての尺度のバランスをとってくれるのではないか, というわけだ.


しかし同時に貨幣という尺度はある規模を超えると非常に不安定で,  それ自身が自律した絶対的な価値になってしまうらしいことも分かっている.  例えば歌には売れた CD の枚数 (= 貨幣価値) とは違う尺度が必要なのだ (本来は).