プロジェクトの見積もりを正確にすることはとても難しい。 色々なテクニックがある、楽観ケース・悲観ケースで算出するなどがよくある。（どうやらこれは米海軍の原子力潜水艦開発で用いられたのが始まりらしい） なぜそもそも見積もりが難しいのかの理由について改めて整理してみる。 見積もりの難しさは、究極は不確実性だと考えている。さらにこの不確実性は大きく2種類に整理できる。
見積もり当人の技術力・経験不足からくる不確実性
これは見積もった結果がそもそも甘くて、後からそれが判明するケース。 技術力・経験不足に関してはすぐに修正できるものではないため、小手先のテクニックを使っても根本的な解決にはならない。
要件そのものの不確実性
これははいざ作ってみてから要件が変わっていくケース。（ウッ、頭がいたい...）開発前に整理していた要件に抜け漏れがあったり、いざ機能を触ってみてからそのことが判明したりするケースだ。プロジェクト当初にはなかった追加の工数が後からどんどん増えていく。
どう対処するか
この不確実性に対処するために、ユーザーが触れるものを作りながら要件・設計を見直しつつ、見積もりを修正していくというアプローチがよく用いられている。そうすることで、どんな技術的要件・制約ががあるか明確にしやすいし、実際に触ることができれば要件も洗練することができる。
例えば「達人プログラマー」という本では、”象を喰らう”という比喩とともに紹介されている。象を食べる時、一度には食べることができないため、小さく食べていくことが必要だということだ。初期機能を開発し、ユーザーと共に検証することで、見積もりをより精度の高いものに修正していくというアプローチだ。これを繰り返すことで、プロジェクト全体の見積もりを徐々に精度高いものにしていく。
「なぜあなたの仕事は終わらないのか」という本では、"界王拳"という表現がなされている。不確実性をなくすためにプロジェクト初期に機能の8割を作成してしまうという力技だ。これも、早い段階でユーザー検証できる形で機能を作ることで、見積もりの確度を高めていくことが目的となっている。