_ 見積もりは難しい

しばらく前のことですが、 久々にソフトウェア関連の書籍を読んでました。 有名な本らしいですが、まだ読んだことがなかった「55の真実と10のウソ」です。

感想を一言でいうと、とても面白かったです。 一つ一つのネタについて、著者の考えを述べて、反論を紹介して、 最後にはちゃんと参考文献を載せてくれるという、懇切丁寧な構成。 一個ずつ読みながら、「うんうん、そうだよなあ」とか「それはちょっと違うんじゃない？」とか、一人で思わずツッコミなら読める本です。 考える材料として、とっても刺激的で、良書です。 ソフトウェア開発に何らかの形で関与する人なら、一度は手に取って、 思考の源泉として利用していただきたい出来栄えです。

たくさん読みながら考えたことはあったのですが、 そのうち、本書でかなりの割合を占めている見積もりのことについて、 自分なりの考えを少し書き留めておきます。

まず、見積もりは誰にとっても難しいらしいということがよくわかります。 正確に見積もることはどうやっても無理で、 なのに見積もりミスがプロジェクトの失敗に繋がる危険が最も大きい、 という困った代物です。

本書では「これは駄目」「こんな宣伝文句は嘘」とか、否定的な見解は大量に示されているわけですが、 「じゃあどうすればいいのよ？」ってのがありません。 銀の弾丸はないから自分で考えて何とかしろってことなのかもしれませんが、 やらないというのも無理な話ですから、精度が悪くてもマシな方法を採用する以外にやりようがないですよね。

その中で、何を基準にして必要なお金の量を決定するか、 サービスをいくらで売るか何を数えるのか、という問題があります。 伝統的に、人月がよく使われている領域です。 人の数に時間をかけて、全体コストを見積もるわけです。

人月に対して否定的な意見というのは昔からあるわけですが、 実は私自身は否定的ではありません。 それはなぜかというと、それなりに合理性があって、 他に大した手段は存在しないからです。

他にどういう意見があるのか、ネットで検索して調べたりもしたんですが、 例えば、プロジェクトのパフォーマンスに基づいて（作るものの価値に基づいて）決めればよいというものがありました（元ネタは失念）。 アイデアとしては、あるプロジェクトを遂行し、その結果として、 お客さんのビジネスがもっとうまくいくようになる、 その結果としていくら儲かるのか、 あるいは、いくらコストを削減できるのか、 そういう観点から決める方がいいということでした。

これは一見魅力のある考え方です。 お客さんにとってより役に立つものを作れば、それだけ自分たちも報われる、そう考えれば、やる気も出てきそうではありませんか。

ところが、この方法には落とし穴があります。 まず、そのプロジェクトをやらない、あるいは、失敗したときにどうなるかを実演することはできない（したくない）ので、実測値として差額がはじき出せないってことです。 効果が目に見えるまで何年もかかる領域もあるわけですし、 現実問題、測定不可能です。 しかも、仮にそういうことができたとしても、見積もりはやる前になされねばならないのですから、それでは間に合いません。

さらに、本書で示されているように、見積もりのとても難しいところは、 本当にどうなるかはやってみるまで誰にもよくわからない、 それぐらいソフトウェアは複雑だということです。 ということは、プロジェクトが成功した場合のシミュレーションができないんですね。 仕様さえ（完全には）固めようがない段階で、プロジェクト成功後にどうなるかを精度良く予見できるならば、見積もりの問題なんて初めから生じないはずです。

だから、パフォーマンスに基づいた計算というのは、 コストに基づいた計算（＝人月）と結局同じぐらい当てにならないというか、ある意味もっと酷い結果になると思います。 プロジェクトのコストが最低いくらかかるかは、 人件費などを元にすれば、ある程度の精度で計算可能ですが、 パフォーマンスについてはそれがありません。 計算の仕方次第では、下手すると、マイナスにさえなりかねません。 それではプログラマは安心して生活できません。

私が思うに、人月がよく槍玉にあげられる最大の理由は、 人月単価を固定することに起因します。 例えば、あるベンダでは一人月100万だとか、そういう「人の差」が掻き消えているところです。

プログラマの能力差云々がよく語られますが、 経営の観点から見ても、これはかなり変なんです。 プログラマがみんな同じ役職や身分なら同じだけの給料をもらっているのなら、納得できます。 しかし現実はそうでないはずです。 みんな大なり小なりもらっている金額が異なるはずです。 なのに、みんな同じ単価にしてしまうと、 会社にとってはあんまり給料が高くない人を割り当てた方が得になるという、奇妙奇天烈な状況になります。

プログラマが必ずしも能力に基づいて賃金が査定されているわけではありませんから、絶対的にそうだとはいえませんが、 同じ会社の中では大体、給料が多いほど経験が豊富になって、 プロジェクトに貢献する確率が高まる傾向があると思います。 その方がお客さんにとっても品質が向上したり、納期が短くなったりして、得することも多いはずです。 しかし単価が固定されると、ちっとも能力の差が考慮されなくなって、 社内で安い方が得になってしまって、「安かろう悪かろう」が横行するという哀しい状況に陥ってしまうのではないでしょうか。

逆に、単価が人によって変動するシステムであれば、 私は人月計算でも構わないのではないかと思います。 もっともその次にはある人にある仕事を任せて、どれぐらい時間が必要になるのかを見積もるという難関にぶち当たっていくことになるわけですが...