世の中の「IT評論家」やら「コンサル」やらは、どうも「人月見積り」がお嫌いのようだ。IPAまでもが、
と言っている。
確かに運用が下手くそだと、「人月」ってのは「値切り」の口実にされてしまったり、生産性低下の元になったりする。これに依存しきっていれば、社員の給料は上がらない。
とは言え、「工数見積り」というのは、あくまでも「見積り」に過ぎない。だからどんな優れた手法があっても、外れることはある。それを考えると、 「人月」で見積るというのは、「近似計算」としてはそう酷くないと思う。なぜなら、「人月」は「具体的な仕事」との関係が見通しやすいからだ。
人月以外の見積り方法はいくつか提案されている。たとえば「業務改善による経費節約」をパラメータとして見積り金額にする手法がある。確かにこれ は「良いシステムを客観的に評価してそれに似合う報酬にする」という点では間違いはないし、顧客の経営陣も納得しやすい。コンサルする方としても、スマー トである。
しかし、この方法には「システムは人手で作るもの」という部分がまるっきり欠落しているので、実際の開発部隊がどうなるかというのは、別の見積りを必要とする。
他の見積り手法もそうで、たいてい「人手で作る」という部分への配慮が欠落している。だから、見積りに失敗するととんでもないことになるのは、想 像に難くない。「システムは確実に動かなければならない」という前提に立つなら、「動く(使える)ものを完成させる」ことを第一にするべきで、技術力や生産性の評価なんてのは、二の次でいい。
「人月見積り」で重要なのは、
- 「平均生産性」の把握
- システム規模の正当な評価
- ちょっとした商才
である。この３つがちゃんとしていれば、そうそう深刻な事態にはならない。見積りという「近似計算」としては悪くない。
「人月見積り」でダメになる要因は、これらのポイントがちゃんとしていないことで、たとえば、
- 生産性の過大評価
- 顧客予算からのシステム規模の決定
- 馬鹿正直な見積り提出
などである。
特に「馬鹿正直な見積り提出」は、いろんなところに弊害がある。「工数見積り」はあくまでも工数の見積りであって、顧客に要求する金額を「工数 × 単価」にしろというのは違うのだ。生産性も技術も高いと思えば、適当にプラスアルファしてしまえばいいだけのこと。顧客が技術や生産性を理解していれば、「プラスアルファ」でも通らないことはないし、理解が得られていなければ他のどんな見積り手法を持って来ても通るわけがない。
そういったところを間違いさえしなければ、別に「人月見積り」でも悪いことはないし、「生産性を上げても金額が低くなってしまう」なんてこともない。リスクも低く押えられる。
悪いのは、「説明能力のなさ」や「業界の下請け体質」や「馬鹿正直」である。別に「人月見積り」だって運用を間違わなければ、生産性も利益も確保できるはずだ。
PS.
仙石氏が別の観点から「人月」の肯定をしている。
私は見積りは「人間」が行う「予測」であること という観点だったが、彼は「顧客」に「説明」するものだという観点だ。確かに人月でない見積りは説明するのが難しい。