不確実性のコーン

英語名 Cone of Uncertainty
読み方 コーン オブ アンサータンティ
難易度
所要時間 見積もりレビュー時に都度適用
提唱者 Barry Boehm(1981年)/ Steve McConnell『ソフトウェア見積り』
目次

ひとことで言うと
#

プロジェクト初期の見積もりは実際の 0.25倍〜4倍 の幅でブレるが、フェーズが進むにつれ不確実性は収束していく。この「漏斗型の収束パターン」を可視化し、見積もり精度をフェーズごとに管理するための概念モデル。

押さえておきたい用語
#

押さえておきたい用語
不確実性(Uncertainty)
プロジェクトの成果・工数・コストについて現時点ではわからない要素の大きさ。情報が増えるほど不確実性は小さくなる。
見積もりレンジ(Estimate Range)
見積もりの上限と下限の幅。初期段階では 4:1(最良ケースの4倍が最悪ケース)に達することもある。
マイルストーン
プロジェクトの主要な中間地点。要件定義完了・設計完了・テスト開始など、見積もり精度が向上するタイミングと一致する。
コンティンジェンシー(Contingency)
不確実性に備えて予算やスケジュールに上乗せするバッファ。コーンが広い初期ほど大きなバッファが必要になる。

不確実性のコーンの全体像
#

不確実性のコーン:プロジェクト進行に伴い見積もりの幅が収束する
プロジェクト進行 →見積もり誤差実績4x0.25x1.25x0.8x構想要件定義設計完了実装中盤誤差 ±300%誤差 ±100%誤差 ±50%誤差 ±25%※ 各フェーズの通過ごとに見積もりを更新し、レンジを狭めていく
不確実性のコーンの活用フロー
1
初期見積もり
ポイント値ではなくレンジ(幅)で見積もりを提示する
2
フェーズ通過
要件定義や設計完了など情報が増えるたびに再見積もりする
3
レンジ更新
最新情報で上限と下限を狭め関係者に共有する
確定見積もり
実装中盤以降に誤差±25%以内で確定コミットする

こんな悩みに効く
#

  • プロジェクト初期の見積もりが毎回大きく外れる
  • 経営層に「で、いくらかかるの?」と詰められるが正確に答えられない
  • 見積もりの不確実性をチームやステークホルダーに説明するロジックがない
  • コンティンジェンシーバッファの根拠を聞かれても答えられない

基本の使い方
#

現在のフェーズを特定する
プロジェクトが「構想段階」「要件定義中」「設計完了」「実装中盤」のどの位置にあるかを確認する。フェーズによって見積もり精度の期待値が決まるため、まず現在地を明確にする。
レンジ付きの見積もりを作成する
「6か月」ではなく「4〜9か月」のようにレンジで見積もりを出す。構想段階なら0.25x〜4x、要件定義完了なら0.5x〜2x、設計完了なら0.67x〜1.5xが一般的な幅。
ステークホルダーにコーンを共有する
見積もりの幅が大きい理由を「まだ不明な要素が多いため」と図示して説明する。コーンの図を見せることで、「精度が低い=チームの能力不足」ではなく「情報不足の段階ではブレるのが当然」という共通認識をつくる。
フェーズ完了ごとに再見積もりする
要件定義の完了、設計の完了、プロトタイプの完成など、情報が大きく増えるタイミングで見積もりを更新し、レンジを狭める。更新のたびに関係者に共有し、コーンが収束していることを可視化する。
コミットメントの時期を判断する
レンジが±25%以内に収まった段階で初めて「確定見積もり」としてコミットする。それ以前の段階で確定値を約束すると、ほぼ確実にスケジュールかコストがオーバーする。

具体例
#

例1:SaaS開発チームが新機能のリリース時期をレンジで提示する

BtoB SaaSを開発するスタートアップ(エンジニア12名)。CEOから「顧客管理機能はいつリリースできる?」と聞かれた開発リーダーが、不確実性のコーンを使って回答した。

フェーズ時期見積もりレンジ信頼度
構想段階1月3〜12か月±300%
要件定義完了2月4〜8か月±100%
設計完了3月5〜7か月±40%
実装中盤5月6〜7か月±15%

1月時点で「8月リリース」と確約していたら外れていた可能性が高い。レンジで提示し、フェーズごとに更新したことで、CEOも投資家への説明に自信を持てるようになった。最終的にリリースは7月で、設計完了時の見積もりレンジ内に収まっている。

例2:建設会社がマンション建築の概算をコーンで管理する

従業員200名の建設会社。分譲マンション(60戸)の建設プロジェクトで、施主から早い段階での予算確定を求められた。

不確実性のコーンを用いて「現段階ではこの幅です」と明示し、確定見積もりは基本設計完了後に出すと合意を取った。

構想段階の概算は 12〜30億円。基本設計完了後に 18〜22億円 に収束し、実施設計完了後に 19.5億円 で確定した。結果、実績は 20.1億円 で確定値の +3% にとどまった。

初期に「20億円」と言い切っていたら、変更要求のたびに追加請求が発生しトラブルの元になっていたはずだと、プロジェクトマネージャーは振り返る。

例3:自治体がDX推進事業の予算をフェーズ分割で管理する

人口15万人の地方自治体。住民向けオンライン手続きシステムの構築を企画したが、議会での予算承認に「確定金額」が必要だった。

不確実性のコーンの概念を使い、予算を2段階に分割する方式を提案。第1段階で「要件定義・基本設計」の予算(2,000万円)を承認し、設計完了時点で本体開発の確定見積もりを改めて議会に諮る方式にした。

段階承認額精度
第1段階(構想〜設計)2,000万円確定
第2段階(開発〜導入)8,500万〜1.2億円(概算)±30%
第2段階(設計後に再提示)9,800万円(確定)±10%

最終的な事業費は 1.02億円 で、設計後の確定見積もりから +4% の範囲に収まった。議会からも「段階的に精度が上がるプロセスが透明でわかりやすい」と好評を得ている。

やりがちな失敗パターン
#

  1. 初期段階でポイント値の見積もりを出してしまう ─ 「6か月です」と言い切ると、それが「約束」になる。必ずレンジで提示し、精度の限界を明示する
  2. コーンを知っていてもレンジを狭くしすぎる ─ 構想段階で「5〜7か月」と出すのは楽観的すぎる。研究に基づくレンジ幅を守る
  3. フェーズを進めても再見積もりしない ─ コーンの価値はフェーズごとの更新にある。初期見積もりのまま最後まで行くとコーンは収束しない
  4. 見積もりの幅=チームの無能と解釈される ─ ステークホルダーへの説明時にコーンの図を見せ、「フェーズが進めば精度は上がる」と伝える教育が必要

まとめ
#

不確実性のコーンは、プロジェクト初期の見積もりが大きくブレることは避けられないという前提に立ち、フェーズの進行に応じて見積もり精度が収束するパターンを可視化する概念。初期はレンジで提示し、フェーズ完了ごとに幅を狭めていくことで、ステークホルダーとの期待値のズレを防ぐ。確定コミットは十分に情報が揃ってから行うのが鉄則。