【ソフトウェア】あなたの見積もり能力チェック

早速ですが、あなたの見積もりスキルをテストする問題を出します。次の説明を呼んで表の質問に答えてみてください。

（説明）
それぞれの問題について、答えが90%の確度でこの範囲内にあると自分が考える範囲の上限と下限を見積もってください。範囲の幅が大きすぎたり、逆に小さすぎたりしないように気をつけること。自分の最善の判断として、正解が含まれることが90%は確かだと思える幅を記入すること。答えを調べたりしてはいけません。空欄は誤答として扱います。回答時間は10分以内。

答えは下記のチェックボックスをONにすると表示されます。

今回は少し古い書籍ですが「ソフトウェア見積り-人月の暗黙知を解き明かす」という書籍の内容を踏まえて記事にしました。見積もりをする上での参考にしてもらえればと思います。

「90%確か」はどのくらい確かなのか？

この質問の作成者であるスティーブ・マコネル氏が、実際に答えてもらった人のうち直近の600人の平均正解数は2.8問だったそうです。90%の確かさは30%程度の確かさ程度になっています。

このような90%確かさを裏付けようと思うと、統計的な分析の裏付けがない限り、意味がないと氏は言っていますが、全くその通りだと思います。この質問で、8割以上の正解の人も全体の2%ほどいたそうです。その人たちは大きめの幅をとっていたそうですが、90%に対して80%の正解なので、それでも不十分な幅の取り方だと氏は付け加えています。

見積もりに幅を持たせることに対する心理的プレッシャー

例えば、あなたが知人に「エッフェル塔のアンテナの先までの高さを正確に教えて」と質問したとします。下記の回答のうち、どれが正確だと思いますか？

1. 300mくらいだよ
2. 200〜300mくらいだよ
3. 200〜400mくらいだよ

おそらく多くの方が1の「300mくらいだよ」が正確だと感じたのではないでしょうか。
エッフェル塔のアンテナの先端までの高さは324m（Wikipedia）とされています。1と2の答えでは最も近い数字から24mも外しています。今回は3の「200〜400m」が最も正確に高さを言い当てたことになるのです。

逆に、もしあなたがエッフェル塔の高さを知らない建築家だったとして、同じ質問をされると如何でしょう？「200〜400m」と答えるのは、正確ではないような気がして答えづらくありませんか？
200mと300mだと100mだけの差ですが、200mと400mでは2倍の差があるので不正確と感じる方は多いそうです。スティーブ・マコネル氏によると、これは個人の勝手な思い込みから来ていると結論づけています。この思い込みの原因はプロフェッショナルとしてのプライドと、不必要に幅の狭い見積もりを要求するマネージャーや顧客とのやり取りの経験からきているそうです。これが自分自身にプレッシャーを与え、幅の狭い見積もりを提示しなければならないと思い込ましているようです。
このように言われると、私自身には思い当たる節がいくつもありました^^;

マネージャーのジレンマ

ここまでで見積もりに幅を広く持たせることで正確さが増すことが理解いただけたと思います。では、不必要に幅の狭い見積もりを要求するマネージャーはどうして生まれるのでしょうか。個人的な考えになりますが、これには2つのジレンマが存在していると思います。

1つは過大見積もりだった場合の学生症候群の発生、もう一つは過小見積もりだった場合のスケジュール遅延などの問題です。
エッフェル塔の例ではわかりづらいので、ここからは5〜10ヶ月という期間の見積もりを前提に考えてみます。

過大見積もりだったら、のジレンマ

5〜10ヶ月の見積もりが提示された場合、仮に上限である10ヶ月をもとに計画を作成したとしましょう。
この場合に懸念されるのが「学生症候群」と言われるものです。夏休みの宿題を休みの終わりになって慌てて追い込むアレのことですね。

スケジュール前半は比較的余裕があるのでゆったりと進み、納期が近づくと大慌てでなんとか終わらせる現場を見たことがある方もいるのではないでしょうか。
この時、スケジュールに余裕がありすぎたことが問題視されると、もっと期間を短くして最後に詰め込むことがないようにしたほうが良かった、とマネージャーは思うかもしれません。

過小見積もりだったら、のジレンマ

今度は5〜10ヶ月の見積もりの下限である5ヶ月をもとに計画を作成したとしましょう。この場合に懸念されるのは、スケジュールの遅延リスクです。少ない見積もりを前提としてスケジュールを立てたことで、何か問題が生じた場合に遅延リスクを抱えることになります。一度遅延すると、リカバリのため他のプロジェクトの開始を遅らせたり、他の動いているプロジェクトから人員を移してきてリカバリさせるなど、被害はどんどん大きくなります。
見積もりが少なすぎたことが問題視されると、もっと余裕のある見積もりを採用すれば良かった、とマネージャーは思うかもしれません。

幅の狭さはマネージャーの安心感なのかもしれない

マネージャーとしては過大見積もりでもなく、過小見積もりでもない、幅の狭い見積もりを望むようになります。 それは5〜10ヶ月というものではなく、7〜8ヶ月というものかもしれません。過大見積もりだったとしても、過小見積もりだったとしても実態とのブレ幅が小さく、上述のジレンマが発生しない、程よい見積もりを得ることでマネージャーはマネジメントの安心感を得ているのかもしれません。

最後に

エッフェル塔の高さの例で、300〜400mという見積もりと、300〜350mと幅の狭い見積もりがあったとします。前者と後者はいずれも正確ですが、後者はより精度が高い見積もりと考えるのが適切だと思います。また、正解を知らないことに対して正確な見積もりを出す場合、幅をできる限り広く取ることで正確さを増すことができますが、精度をあげることはヤマカンではできません。何らかの方法で計測あるいは算出する必要がでてきます。

ソフトウェア開発における見積もりも同じで、過去に類似する開発をやったことがない場合に精度高く見積もることは不可能に近いです。精度を上げるには過去の類似する何かと比較するとか、少し調べて知見を得てから見積もるとか、何か基準を作って比較、算出しないと精度の高い見積もりを出すことは不可能です。見積もりをする際は、幅を持たせる、実際に計測するを念頭において提示するのが良いでしょう。

ソフトウェア開発に限った話ではないと思いますが、見積もり一つをとっても奥が深くて楽しいですね。それでは、また。