■見積もり誤差の発生要因
- プロジェクトに関する不正確な情報
- 開発チームに関する不正確な情報
- プロジェクトの混乱
→ 移動するターゲットの見積もりは困難であるため - 見積りプロセスが適切でない
■ 見積もりの不確実性はプロジェクトの決定事項に依存する
つまり、何も決まっていないプロジェクトについていくら見積もり作業をしても、到達できる確実性には限界があり、不確実性は残る。下記の表にあるように、プロジェクトの初期に不確実性を取り除く決定が行われるので、これらの作業が漏れなく行えれば、見積もりの精度は上がってくる。
このバージョンのコーンからわかるように、見積りの正確性はプロジェクトの期間の最初の30%で急速に改善され、±4倍から±1.25倍に減少する。(Kindleの位置No.1170-1171)
ただし、この表はプロジェクトを進める中で、適宜必要とされる意思決定が確実になされたことが前提になっている。これらの決定が有効でないと、見積もり誤差は以下になる。
■不確実性が高い状況での見積もりの出し方
上記の研究結果を実際のプロジェクトに反映するには、以下のような表が有効である。それは、プロジェクトの置かれた状況に合わせて、最初に出した「一番ありそうな見積もり」に対して、決めておいた係数をかけるという方法である。
この係数は実際のプロジェクトや開発チームによって変わりそうだが、考え方として有効だということだろう。例えば、「新しいECサイトを立ち上げてお茶を販売する」というケースでは、「初期コンセプト」の段階に相当しそうである。この段階で見積もりを出すのは難しいが、上記のやり方に従えば、かなり幅のある見積もりにはなるものの、一応の数字を出せることになる。「何も分かりません」という回答よりずっと良い。
有意義なコミットメントは、プロジェクトの前半（進路のおよそ30%）で行うことが可能であり、適切である。(Kindleの位置No.1221-1222)
それ以前のコミットメントにはあまり意味がないということ。役に立てるには見積もりが荒すぎるのだ。
■プロジェクトの不正確な情報への対策
プロジェクトの情報が不正確である例
- 要求の見落とし→見逃されていた影響箇所の発見
- アクティビティの見落とし→開発環境構築など、必要な作業の計上漏れ
アクティビティの見落としを防ぐには、過去の記録を調べると良い。また、今後のために記録を残すことはもちろん有用である。何にどのぐらいかかったかが分かれば、予測の上で有用である。
■偏見への対策
即興で、つまり直感だけで見積もりをしてはならない。それは不正確で役に立たないのである。そして常に楽観的になってしまう。思い付くアクティビティが少なすぎるのがおそらく原因である。ちゃんと見積もり作業を実施すること。
■見積もり精度
見積もりの正確性と出す数字の有効桁数を一致させる。
日単位でしか意味がないのに、34時間15分～40時間45分などという見積もりを出したら、15分単位の精度で見積もりを出したと勘違いされる。
