樋口です。
現実の業務アプリケーションでは
「物を生産するのにどれだけのコストがかかるのか」(費用)
「その物によってどれだけの利益を生み出せるのか」(効果)
を必ず事前に予測します。
いわゆる費用対効果ってやつですね。
これはソフトウェア工学に関わらず
あまりに当然のごとく行われていることです。
これを無視してやっているプロジェクトはどっかおかしいですね。
やればやるほど損しちゃうわけですから。
プログラマとかSEとかには見積もりの詳細は語られないことが多いので、
そういったことが無視されていると
勘違いしてたりするのかもしれません。
(いや、実際大赤字のプロジェクトはいっぱいありますけどね。)
では、どうやって費用を見積もるのでしょうか?
どうやって効果を見積もるのでしょうか?
どうも、根本的にそのあたりで
話がおかしくなっているような気がしてなりません。
ばかばかしいですが、
ありがちな業務アプリケーションを作る時に
1つの画面を作る工数
2つの画面を作る工数
3つの画面を作る工数
4つの...
と画面と工数との対応グラフを書いてみると、
最初の数枚では異様に増大率が高く、
その後次第に正比例するようになってきます。
(すくなくとも log n じゃないのは間違いないですね。)
理由はまぁわざわざ書かなくても分かるでしょう。
(分からなかったら勉強しなおしてください。)
コードの量も、いくらリファクタリングを行ったとしても、
「違う要件」を積み重ねていけば
本来はほぼ正比例の関係になっていくはずです。
それこそ本当に「同じ要件」を繰り返しであれば、
単にサブルーチン化すればよいだけなので、
いくら重ねても「一定」となるはずです。
「常に違う要件なのだから常に違って当然」と
濱井さんは頻繁に言われていますが、
業務アプリケーションのように、
全体的なパターンはよく似ているにもかかわらず、
常に要件が微妙に異なるようなケースは頻繁に現れます。
つまり「違うけど似ている」のです。
だから測定をして、その結果を元に、
次回の予測をすることがある程度可能なのです。
(あくまで「ある程度」です。)
XP でも、最初の見積もりは不正確でも、
次第に精度が上がっていくと言われていますが、
それはいったいなぜ可能なのか、ちょっとは考えて見ましょう。
本当に「何もかもがまったく違う」ということは意外と少ないのです。
一方、「業務アプリケーション」と「ゲームアプリケーション」と
みたいなものとは完全に開発パターンが異なっています。
このように、開発パターンが異なるようなものの見積もりを
直接比較するようなことは
どのソフトウェア工学でも行われていないはずです。
(やっていたら教えてください。)
似ているから測定したものを元に予測できるのです。
一般にソフトウェアの「生産量」を計測する時に認識されているのは、
こういった「正比例」が見込まれる部分のはずであり、
それを元に次回の見積もりの精度を上げるためのものであるはずです。
さて、一方、こういった見積もりのための計測のために
安易に「コード量」を測ったり「時間数」を測ると
「コード量」や「時間数」に単純比例した費用を支払うようなことに
なってしまいます。
つまり、
「無駄なコードを書くこと」や
「無駄に時間を浪費すること」で
開発者が余計に儲かってしまう、というおかしな逆転現象が発生します。
(おそらく誰もがここがおかしいと考えているはずで、
これは今更話題にすることではないですね。)
これは競争原理が働いていないことが大きな原因です。
もし、数社に同じ仕様を提示して見積もらせた場合に、
より安い方を選べば、顧客としては、無駄なコードや無駄な時間浪費による
コスト増大ということは避けられるはずです。
(もちろん、最下層の労働者が相変わらず無駄な作業で賃金をもらえば、
受注した会社が大赤字になることになりますが...
これも、労働者同士の競争原理が働かないことが原因かも。)
(あと、見積もりができるようにするまで
要件を固めるためにかかるコストを、
誰がどう支払うのかという問題があったりするのですが...)
とはいえ、今度は「安かろう悪かろう」という現象も引き起こります。
つまり、ある限度を超えると、
コストを下げるには品質を下げるしかなくなってきます。
要件を減らせば、コストは下がりますし、
テストをサボれば、コストは下がりますし、
文書化をサボれば、コストは下がります。
つまり、単に見積価格を見ているだけでは
「物の品質が低いからコストが低い」のか
「労働者の質が高いから、低コストで十分な品質の物が作れる」のかを
知ることができないのが問題になるわけです。
(これはソフトウェアに限らず生産すべてに起こる問題です。)
濱井さんが盛んに批判されている CMM のような
「品質」重視の測定方法はこういった場面で有効になってくるわけです。
濱井さんは
「違うものを作るのだから、プロセスは繰り返せない」
と何度も書かれていますが
「違うけど似ている」から繰り返せるのです。
素人集団と熟練チームとをどうやって判定するかというのが
CMM が目指すところでしょう。
もしも、これが「業務アプリケーション」と「ゲームアプリケーション」とを
同じチームが開発するのでは、プロセスが違うので繰り返せません。
それは当たり前ですね。
効果についての見積もりは、要件によってあまりに違うので、
それはその都度何らかの方法で見積もるしかないでしょう。
ゲームアプリケーションであれば、
既存の同類のソフトの売り上げや、
アンケートなどの結果から
おおよその販売数を予測するでしょうし、
業務アプリケーションであれば、
人員や労働時間の削減の量とか、
スループットとかで予測するでしょう。
しかし、これはソフトウェア工学とはまた別の問題領域でしょうね。
それを一緒くたにして
「ソフトウェア工学では無視されている」とか
「測定できない」と言ってみたりするのはどうかと思います。
いくら大雑把でも、10円のものを10億円と見積もったり、
逆に100億円のものを100円と見積もるようなことは
常識的に考えて、ふつうはないでしょう。
(1円入札とかはあったりしますけどね。:-P )
あと、リファクタリングや再利用で、
どんどん高速にアプリケーションが作れるようになると
単純に思っているのであれば、ちょっとおめでたい気がします。
「すでにあるミドルウェアをちょっとカスタマイズすれば
すぐにできるようになります。」
と業者に言われて信じてしまい
車輪の再発明しなくて済むわと思っていたら
気が付くとほとんど再構築で莫大な費用を要求される
なんて話もあったりしますしねぇ...
これも「安かろう悪かろう」なのでしょう。
すくなくとも「測定に失敗した」よい事例の一つです。
// 樋口 勝也
// bugbear@....nu