不確実性のコーン: 初期の見積もりが外れる理由

著者: Tara Minh · 更新日: 2026年10月10日

不確実性のコーンとは、プロジェクトの見積もりは開始時点で最も信頼性が低く、未知の要素が解消されるにつれて初めて信頼性が高まることを示すモデルです。Steve McConnell のバージョンでは、ソフトウェアの初期見積もりは最終結果の0.25倍から4倍の範囲に収まるとされ、意思決定が進むにつれて1.0倍へと収束していきます。

重要な事実

• 上下どちらにも4倍: 初期コンセプト段階の見積もりは、高い側にも低い側（0.25倍）にも4倍ずれる可能性があり、最小値から最大値までの幅は16倍に及びます（Construx の不確実性のコーンに関するホワイトペーパーによる）。
• 約束ではなく最良のケース: コーンが示すのは、熟練した見積もり担当者が到達できる最良の精度です。これより悪くなるのは簡単で、これより正確になるには運に恵まれるしかありません（同じ Construx のホワイトペーパー）。
• 主観的な出自: Barry Boehm は1981年の著書 Software Engineering Economics で最初のバージョンを描きました。その範囲は80%の信頼限界として判断で設定されたもので、プロジェクトデータから測定されたものではありません（Bossavit, The Leprechauns of Software Engineering）。
• 狭めるのは作業: 狭まりの大半は暦上の時間のおよそ最初の20〜30%で起こり、それはチームがばらつきを取り除く意思決定を行うからこそ起こります（Construx）。

不確実性のコーンとは

横に倒した漏斗を思い浮かべてください。プロジェクトの開始時点にあたる左側は幅が広く、納品が近い右側では先端に収束します。縦軸は、工数、コスト、スケジュール、スコープの見積もりが、最終的な成果からどれだけ離れうるかを表します。横軸は時間で、初期コンセプト、承認された製品定義、要件の完了、設計の完了、完成といったマイルストーンで区切られています。

考え方はシンプルです。プロジェクトの初期には、何を作るのか、誰が作るのか、どのリスクが顕在化するのか、どの要件が変わるのかを正確には把握できていません。こうした未知の要素の一つひとつが、見積もりにばらつきを加えます。それぞれが明確になるにつれて、起こりうる結果の範囲は狭まっていきます。

ここまでは、よく引用される部分です。見落とされがちなのは、McConnell がすぐ隣で述べていることです。不確実性は時間が経つから減るのではなく、誰かが意思決定を行ったから減るのです。Construx のホワイトペーパーは、見積もりのばらつきを減らす唯一の方法は、プロジェクト自体のばらつきを減らすことだとはっきり述べています。その1週間にプロジェクトの何も定義されないのであれば、チームに「見積もりを精緻化するためにもう1週間」を与えても意味がありません。

コーンの由来

最も古いバージョンを描いたのは、Software Engineering Economics（1981年）の Barry Boehm で、彼はこれを漏斗曲線と呼びました。最も初期の段階では、見積もりは上下どちらにも4倍ずれる可能性があります。McConnell の Construx ホワイトペーパーは、初期コンセプトの範囲を高い側4倍から低い側0.25倍、つまり16倍の幅としています。

その後 Steve McConnell が「不確実性のコーン」と名付け、Software Estimation: Demystifying the Black Art（Microsoft Press、2006年）をはじめとする見積もりに関する著書に取り入れました。彼が創業した Construx は、現在もこのモデルをホワイトペーパーとして公開しています。

ここで正直な注意点があります。Laurent Bossavit によるコーンの歴史の分析によれば、Boehm の範囲は測定されたデータセットではなく判断に基づくものでした。Bossavit はまた、IEEE Software に掲載された Todd Little の2006年のデータ（実際のプロジェクトのステータスレポートに基づく）が、左右対称の漏斗とは一致しなかったことも指摘しています。実際のプロジェクトは、前倒しになるよりはるかに頻繁に遅延し、多くが長期間「90%完了」のまま止まっています。

Construx のホワイトペーパーにおける McConnell の答えは、コーンは最良のケースであり、運営の悪いプロジェクトでは決して狭まらない不確実性の「雲」が生じるというものです。したがって、コーンは統計的な法則ではなく、有用な教育用モデルであり計画の規律として扱ってください。実践上の教訓はどちらでも変わりません。初期の数字には広いレンジをつけるべきだということです。

不確実性のコーンとその他の見積もり概念の比較

コーンは見積もり手法ではありません。どの手法の出力についても、その時点でどれだけ信頼してよいかを判断するためのレンズです。だからこそ、以下の手法に取って代わるのではなく、組み合わせて使うことになります。

使える目安があります。コーンの幅に見合った精度の手法を選ぶことです。初期コンセプトの段階で1時間単位のボトムアップ見積もりを行うのは、見せかけの精密さです。逆に、設計が終わりスコープが確定した後に大まかな類推見積もりを行うのは無駄です。

初期の見積もりが外れる理由

見積もり担当者のせいにしたくなりますが、問題は担当者ではないことがほとんどです。初期にコーンを広げる要因は4つあります。

要件が曖昧である。 「顧客ポータルを作る」は、ログインページと請求書の一覧を意味することもあれば、決済を備えたフルセルフサービスのプラットフォームを意味することもあります。どちらも妥当な解釈ですが、両者の工数の差は非常に大きくなります。

スコープが動く標的である。 ステークホルダーは、実際に動くものを目にすると機能を追加したり削除したりします。これは初期段階のスコープクリープであり、そもそもクリープの起点となるベースラインさえまだありません。

依存関係が未知である。 決済チームに6週間の待ち行列があることや、連携する前にレガシーシステムの書き換えが必要なことは、まだ分かっていません。

チームが固まっていない。 スキル、稼働可能性、ベロシティは、メンバーが実際の仕事で一緒に働くまでは推測にすぎません。

さらに、人間的な側面もあります。楽観は初期設定のようなもので、会議で口にした数字は約束になりがちです。初期コンセプトの段階でスポンサーが「約4か月」と聞けば、その数字は計画にも予算にも、ときには顧客との契約にも書き込まれます。それが「1か月から16か月」というレンジとともに示されたことは、誰も覚えていません。

Construx はこれを本当の危険として挙げています。コーンがまだ広い段階でコミットする組織は、同社の言葉を借りれば、予測可能性を損ない、リスクを高めます。初期コンセプトや製品定義の段階でコミットすることは、2倍から4倍の見積もり誤差を受け入れることを意味します。

不確実性のコーンの使い方（ステップ別）

コーンをなくすことはできませんが、意図的に活用することはできます。実際に使える手順を紹介します。

ステップ1: 現在の段階を正直に見極める

プロジェクトが今どこにあるかを判断します。初期のアイデア、スコープ承認済み、要件完了、設計完了、構築中のいずれかです。厳しく見てください。予算が承認済みでも要件定義書が半分しか書かれていないプロジェクトは、依然として広い側にあります。

ステップ2: 点ではなくレンジで示す

最良の見積もりを、下限値と上限値に変換します。初期コンセプトでは Construx のモデルが0.25倍から4倍を認めているため、勘で出した100日の見積もりは25日から400日になります。スライドの上では馬鹿げて見えますが、それが狙いです。この差が人々を不安にさせれば、それを狭めるための作業に合意してもらえます。

タスク単位のレンジについては、三点見積もりが、下限値、最頻値、上限値を導き出すための根拠ある方法を提供します。

ステップ3: 幅を生んでいる未知の要素を洗い出す

見積もりを動かすすべての未解決事項を書き出します。固まっていない要件、未知の連携、未確定の人員、未検証の技術などです。それぞれがレンジにどれだけ幅を加えるかで順位づけします。このリストは、リスク登録簿の出発点にもなります。

ステップ4: 未知の要素を取り除く作業をスケジュールに入れる

ディスカバリーを成果物として扱います。スコープ外の事項を含めて、製品ビジョンを定義します。要件を完成させます。最もリスクの高いインターフェースのプロトタイプを作ります。誰も試したことのない連携について、技術スパイクを実施します。これらはいずれもばらつきを取り除く作業であり、それぞれに担当者と期日を設けるべきです。

ステップ5: 確定的なコミットを遅らせる

McConnell の指針は、コーンの初期の広い部分では意味のあるコミットはできず、効果的な組織はコーンを意図的に狭めてから待つ、というものです。彼のホワイトペーパーは、プロジェクトの約30%が経過した時点でのコミットが可能かつ適切だと述べています。ビジネス側がそれより早く数字を必要とするなら、レンジを示し、それがレンジであることを明記してください。

ステップ6: マイルストーンごとに再見積もりする

カレンダーではなく、主要な未知の要素が解消されるたびに見積もりをやり直します。新しいレンジを前回のものと比較します。狭まっていなければ、それは雲であり、スコープ、人員、アプローチについて話し合う必要があります。

ステップ7: レンジが十分に狭まったらベースラインを設定する

スポンサーが資金を出し、チームがコミットできるほどレンジが狭まったら、それをプロジェクトベースラインとして記録します。以降は、その数字に対する差異を追跡します。

そのままコピーして使えるテンプレート: 見積もりレンジトラッカー

この表をプロジェクト計画にコピーし、マイルストーンごとに更新してください。「幅」の列は上限を下限で割っただけの値で、コーンが狭まっているかどうかを一目で確認できます。

記入方法は次のとおりです。

1. 下限と上限は、作業全体で合計した三点見積もりから、または単一の最良推定値にコーンの倍率を適用して求めます。
2. 解消した未知の要素は、前回の行以降に下した意思決定の単純なリストです。このセルが空で、幅も変わっていないなら、それは想定どおりです。
3. コミット可否は方針の列です。開始時に誰も揉めないよう、スポンサーとあらかじめ合意しておきます。

幅の列が2つのマイルストーン連続で縮まらなければ、エスカレーションしてください。プロジェクトのどこかが収束していません。

ビジネス機能別の例

コーンはソフトウェアに限りません。スコープが未定義で、不慣れな工程を含む仕事なら、どれも同じように振る舞います。以下の数字は、大まかな最初の推測にコーンの初期段階の倍率（0.25倍から4倍）を当てはめた例示的な計算であり、ベンチマークではありません。

マーケティングのローンチを例に取りましょう。「8週間」は、何が含まれるのかを問うまでは妥当に感じられます。ブリーフが承認されておらず、誰がコピーを承認するのかも、法務が主張内容を確認する必要があるのかも決まっていないなら、「8週間」は願望にすぎません。ブリーフ、サイトマップ、承認の流れが固まれば、同じプロジェクトを正直に6〜10週間と見積もれるかもしれません。

オペレーションの導入にも同じ論理が当てはまります。プロセスマッピングの前では、$200,000という数字には$600,000という数字と同程度の根拠しかありません。マッピングとベンダーの候補リストができた後なら、レンジは財務ディレクターが承認できる水準まで絞り込まれるかもしれません。

コーンと Agile チーム

よくある反論があります。「私たちは Agile だから、コーンは当てはまらない」というものです。当てはまらないのではなく、当てはまり方が違います。

Construx 自身のホワイトペーパーによれば、反復型のプロジェクトでは、イテレーションごとに小さなコーンを通過します。イテレーションの要件定義の前は、コーンのうち製品定義が承認された段階にいます。イテレーションが短ければ、チームは数日で要件定義と UI 設計を終え、その部分の作業についてばらつきを4倍から1.6倍に減らせます。スケジュールが固定されている場合、そのばらつきは終了日の不確実性ではなく、どの機能が収まるかという不確実性として現れます。

ホワイトペーパーが指摘するとおり、代償として失われるのは、数イテレーション先のコスト、スケジュール、機能を合わせた長期的な予測可能性です。多くのチームが折衷案に落ち着いています。要件の大半を事前に定義し、その後は短いイテレーションで構築する方法です。ホワイトペーパーによれば、これによってコーンのばらつきはプラスマイナス25%程度まで下がります。

実際には、Agile チームでもロードマップやリリース日にはレンジが必要であり、ストーリーポイントのような相対的なサイズ評価は、近い将来の作業に最も適しているということです。遠い先の項目には、粗いサイズ評価と、「後でもっと分かる」という正直な姿勢がふさわしいでしょう。

不確実性のコーンの Do と Don't

Do

• 早い段階ではレンジで伝える。 コンセプト段階では「8か月」ではなく「4〜16か月」と言いましょう。レンジはあなたを守り、スポンサーを教育します。
• 狭まりを具体的な意思決定に結びつける。 トラッカーのすべての行に、前回の見積もり以降に何が解消されたかを示してください。
• マイルストーンで再見積もりする。 要件が完了した後の新しい見積もりは、新しい情報のない毎月の更新よりも価値があります。
• レンジを使ってディスカバリーの優先順位を決める。 最も大きな幅を加えている未知の要素から先に取り組みます。
• 見積もりとコミットを分ける。 見積もりは見込みであり、コミットは約束です。同じ文の中で混同してはいけません。
• コーンを定量的な手法と組み合わせる。 モデル化できるだけの詳細が揃ったら、モンテカルロシミュレーションなどを使います。

Don't

• コーンが自動的に狭まると考えない。 時間が経っても狭まりません。狭めるのは意思決定であり、Construx のホワイトペーパーも、プロジェクトの統制が不十分だとコーンは雲になりうると述べています。
• モデルが提供できない精度を約束しない。 熟練した見積もり担当者でも、コーンを上回ることはできません。より大きく外すだけです。
• スポンサーを喜ばせるためにレンジを絞らない。 新しい情報の裏づけがないまま数字を絞っても、リスクが大きくなるだけです。
• 偏りを無視しない。 実際のプロジェクトは前倒しになるより遅延することのほうが多いため、下限と上限が同じ確率だとは考えないでください。レンジは悲観側に重みをつけます。
• 点の見積もりを会議室の外に出さない。 「約4か月」がレンジなしでメールに書かれた時点で、それは約束になります。
• 曖昧な段階で精密な手法を使わない。 1ページのコンセプトに対する時間単位のボトムアップ見積もりは、見せかけにすぎません。

コーンに関するよくある間違い

「初期の見積もりは信頼できない」と聞いて、計画は無意味だと結論づけるチームがあります。そうではありません。コーンが教えるのは、分かっていることに見合った計画を立てること、そして初期の労力は数字を磨くことではなく、最大の未知の要素を解消することに使うことです。

また、左右対称という形を文字どおりに受け取りすぎるチームもいます。Bossavit の批判は、きれいな図が必ずしもきれいな分布の証拠にならないことを思い出させてくれます。倍率は対話の出発点として使い、自社の実績に合わせて調整してください。過去のプロジェクトが平均で40%超過してきたなら、それを織り込みましょう。

3つ目の間違いは、ベースラインを守れなかった言い訳にコーンを使うことです。スコープと設計が安定した時点で、コーンは役目を終えています。その段階でのベースラインからの差異は、不確実性の問題ではなくマネジメントの問題です。スコープ、スケジュール、コストのトレードオフこそが、適切な議論になります。

重要なポイント

不確実性のコーンは、あらゆるスポンサーが尋ねる質問「どれくらいかかるのか」に対して、根拠のある答えを与えてくれます。初期段階での正直な答えはレンジであり、そのレンジの幅自体が情報です。待つのではなく、意思決定を重ねることで狭めましょう。コーンが狭まるまでは確定的なコミットを控えてください。そして、実際の未知の要素が解消されるたびに、数字を見直しましょう。