スティーブ・マコネル

ソフトウェア技術者ならず、見積りをする全ての人にオススメしたい本。

見積もりにはアート(技法)としての見積もりとサイエンスとしての見積もりがあり、本書ではアートとしての見積もりに重きを置く、と書かれており、実際さまざまな見積もり技法について説明している。

その技法は、恐らく多くの見積もりをする人にとって、十分に役に立つものだと思う。
本書の188ページにある例を引用する。

例えば、6ヶ月のスケジュールがあったとしよう。あなたは、最初のマイルストーンを4週間で達成する計画を立てた。しかし、実際には6週間かかってしまった。この場合、あなたなら次のうちどれを選ぶだろうか。

• 失った2週間は、スケジュールの後の方で埋め合わせられると考える。
• スケジュールの合計の2週間を追加する。
• 誤差の大きさ(この場合は50%)をスケジュール全体に掛け合わせる。

もっともありがちなのは、1番目の選択肢だろう。通常は次のような論法になる。「要求にかける時間が予定より少し長かった。だが、もう要求は固まった。残りの時間を切り詰めよう。コーディングとテストの間で不足分を埋め合わせられるはずだ」。しかし、1991年に300以上のプロジェクトについて調査した結果によると、プロジェクトが一度失った時間を埋め合わせることは、まず不可能であることが分かっている。それどころか、遅れはさらに広がる傾向にある。したがって、この選択肢がベストチョイスなることは、ほとんどないと思ってよい。
(中略)
よほどの例外を除いて、実際の結果が見積もり通りにならない場合の正しい選択肢は、3番目ということになる。

これを読んで思わずにやりとしたり、あるいは過去の見積もりを思い出す人も多いだろう。
そういう人にもオススメしたい。

実際本書には小難しい(サイエンスよりの)議論も存在するが、最初にアート(技法)に重きを置くと書かれている通り、すぐに役に立つ技法が沢山のっている、いわば見積もり技法のカタログ集と言える。
第9章の1例を挙げると、1点見積もりは実際には「最良ケース」に近くなってしまうことから、次のような公式を提案している。

期待ケース = [最良ケース + (4 * 最有力ケース) + 最悪ケース] / 6

例えば自分で以下のように機能追加の見積もりをしてみる。

• 最良ケース=5人日
• 最悪ケース=20人日
• 最有力ケース=10人日

この場合、より確度の高い1点見積もりを出すために期待ケースの見積もりを出すとすれば、
期待ケース = [5 + (4 * 10) + 20] / 6 = 65/6 = 約11人日
となる。
なお実際にありがちなのは、最良ケース=5人日をそのまま採用してしまうケースだと思う。

※この辺りの「公式」をより正確に理解しようとすると、統計学的知識が必要になるようである。(分散とか標準偏差とか)
※下記はよい本らしい。

・見積もりとターゲットとコミットメントは違うものだ。
　・見積もりは分析的なプロセスであり、確率論的な考え方をする。
　・ターゲットは、実現したいビジネス上の目標。
　・コミットメントは、定義された機能を特定の品質レベルを確保しながら期日までに納品するという約束。
　・よって、コミットメントが見積もりよりも挑戦的だったり、保守的だったりすることが当然ある。
・見積もりと計画の関係
　・見積もりのゴールは正確性であり、特定の結果を追求することではない。
　・計画のコールは特定の結果の追求。
・見積もりがシングルポイントで示される(例: 14週間)場合、それは現実的なものではない。
　実際は見積もりの皮を被ったターゲットである。
・あらゆる見積もりは、確率が含まれている。確率を明示した見積もりは良い見積もり。
　16週以内で完成する確率は0%
　18週以内で完成する確率は10%
　20週以内で完成する確率は50%
　22週以内で完成する確率は75%
　24週以内で完成する確率は90%
・自分のコミットメントが幅のある見積もりの中のどこに位置するのかを把握し、それに応じた計画を立てる。
・見積もりは予言ではない。
・よい見積もりとは、プロジェクトの責任者がターゲットを達成するためのコントロールを行ううえで、適正な意志決定ができる明確な視点を提供する見積もり。
・常人が直感的なセンスで考える「90%確か」は、実際には「30%確か」にほぼ近い。
・見積もりの幅を狭くするプレッシャーを感じたら、それが本当に存在するのか確認すべし。
・多くのビジネスでは、見積もりの予測可能性を重視する。(短かったり、安かったり、というのは結果)
・ソフトウェア業界には過少見積もりの問題がある。まず見積もりを多くすることから始める必要がある。
・優れたプロジェクトマネージャーは、見積もり誤差が実際の20%以内にあれば、プロジェクト完了に向けてナビゲートできる。がそれを超えれば難しい。
・即興の見積もりは止めよう。
・見積もりに必要なのは過去のプロジェクトの見積もりと実績。
・開発者の見積もりは既に十分に楽観的に短くなっているため、削ってはいけない。
・アクティビティの見落としも考慮する。
・ソフトウェア開発では、多くの問題について何千もの意志決定をする必要があるプロセスである。そのためそれぞれの意志決定の不確実性がプロジェクトの不確実性を引き起こす。よって、プロジェクトの見積もりは、プロセスの進行に応じて「不確実性のコーン(円錐)」を形成することになる。
・コーンはひとりでには狭くならない。狭くするためにはプロジェクトコントロールが必要。
・ソフトウェア開発は規模の不経済が適用される。プロジェクトが大きくなればなるほど、効率は悪くなる。(失敗プロジェクトになる可能性も高い)
・1点見積もりは、最悪ケースの見積もりと最良ケースの見積もりのうちの最良ケースの見積もりに近い。

・その他多数…