見積もり成熟度 Level 3 への壁 ― なぜ私たちは「幅」で語れないのか
はじめに：Level 3 という「分水嶺」
前回の記事で、システム開発における見積もりの成熟度モデルを整理しました。Level 1（不確実性を認識しない）から Level 4（学習駆動）まで、組織が不確実性をどう扱うかによって、見積もりの形式も運用も根本的に変わります。
その中で、Level 1〜2 と Level 3 の間には、単なる技術的な差ではなく「認識論的な断絶」があります。
Level 3 とは何でしょうか。それは「見積もりを幅で語る」世界です。「5人月です」ではなく「3〜7人月（p10–p90）」と表現します。「6月末に納品します」ではなく「6/15〜7/10 の納期ウィンドウで合意する」という運用です。
これは高度な統計手法の話ではありません。「未来は本質的に不確実である」という当たり前の事実を、見積もりという行為に反映させているだけです。
しかし、この「当たり前」に到達している組織は驚くほど少ないのが現実です。
なぜでしょうか。
本記事の目的は、Level 3 に到達できない構造的理由を 5W（Why・What・Who・When・Where）の観点から解き明かすことにあります。「どう変えるか（How）」の前に、「なぜ変われないのか」を正確に理解することが、変化の第一歩だと考えるからです。
パラダイムシフトの本質：「点」から「幅」への転換が意味するもの
表面的な違い（見積の形式）
Level 1〜2 の見積もりは、次のような形式をとります。
- 「5人月でできます」
- 「6月末に納品します」
- 「2,500万円です」
これらはすべて「点」です。単一の数値で未来を表現しています。
Level 3 の見積もりは、形式が異なります。
- 「p10–p90 で 3〜7人月です」
- 「納期は 6/15〜7/10 のウィンドウで考えています」
- 「確度 80% で 2,800万円以内、最悪ケースで 3,500万円」
これらはすべて「幅」です。未来の不確実性を、数値の範囲として表現しています。
深層の違い（世界観の転換）
しかし、形式の違いは表層にすぎません。Level 3 への移行が困難なのは、その背後にある「世界観」の転換が必要だからです。
因果観の転換
Level 1〜2 では、「正しく見積もれば、正しい数字が出る」と暗黙に信じられています。見積もりとは、隠れた正解を発見する作業です。外れたのは、発見の仕方が間違っていたからです。
Level 3 では、「未来は本質的に分布する」と認識します。正解は存在しません。あるのは確率分布だけです。見積もりとは、その分布の形を推定する作業です。
責任観の転換
Level 1〜2 では、「外れた人が悪い」という責任構造があります。見積もりを外したのは、担当者のスキル不足か、努力不足か、確認不足です。
Level 3 では、「外れ方から学ぶ」という責任構造に変わります。外れたこと自体は問題ではありません。外れた原因が技術なのか、要件なのか、外部依存なのかを分類し、次の見積もりに反映することが重要になります。
計画観の転換
Level 1〜2 では、「計画は守るもの」です。計画を変更することは敗北であり、変更を申請することは面倒であり、変更を報告することは恥です。
Level 3 では、「計画は更新するもの」です。新しい情報が得られたら、計画は更新されるべきです。更新しないことのほうが問題です。
なぜこれが「パラダイムシフト」なのか
ここで重要なのは、Level 3 は Level 2 の延長線上にはない、という点です。
Level 1 から Level 2 への移行は、連続的な改善で可能です。バッファを少し多めに積む、リスクを少し意識する、変更管理を少し整備する。これらは既存の枠組みの中での改善です。
しかし、Level 2 から Level 3 への移行は、枠組み自体の書き換えを必要とします。「点で当てる」という前提を捨て、「幅で扱う」という前提に移行しなければなりません。これは改善ではなく、変革です。
だからこそ、多くの組織が Level 2 で停滞します。改善を続けても、Level 3 には到達しません。
Level 1・2 を維持する合理性 ― 変わらない理由にも理がある
Level 3 に到達できない組織を批判する前に、Level 1・2 に留まることの合理性を認識しておく必要があります。変わらないのは、変わらないなりの理由があるからです。
発注側の合理性
予算制度との整合
多くの企業では、IT投資は年度予算として申請されます。予算申請には「確定額」が必要です。「3,000〜5,000万円の幅で申請します」は、予算制度上、受け入れられません。経理部門は「で、いくらなの？」と聞き返します。
説明責任の簡素化
経営会議で「このシステムはいくらで、いつまでにできるのか」と聞かれたとき、「p80 で 6月末ですが、10% の確率で 7月中旬になります」と答えるのは難しいです。「6月末です」と答えるほうが、説明は簡単です。
比較可能性の確保
複数のベンダーから見積もりを取るとき、「A社は 2,500万円、B社は 2,800万円」と並べれば比較できます。「A社は 2,000〜3,000万円、B社は 2,500〜3,200万円」では、どちらが安いのかわかりません。調達部門は比較可能な数字を求めます。
リスクの外部化
確定見積もりを取るということは、不確実性のリスクをベンダーに移転することを意味します。発注側は「この金額で、この納期で」と約束させることで、自らのリスクを減らせます。これは合理的なリスク管理です。
受注側の合理性
受注競争での優位性
「5,000万円で 6月末に納品します」と言い切るベンダーと、「4,000〜6,000万円で、6月中旬〜7月中旬の間に納品します」と言うベンダー。どちらが受注しやすいでしょうか。多くの場合、前者です。「幅で出す」は「自信がない」と解釈されるリスクがあります。
スコープ防衛
固定見積もりは、固定スコープとセットです。「この金額でこの範囲」と決めることで、追加の作業要求を断る根拠になります。幅見積もりでは、この防衛線が曖昧になります。
社内調整の簡素化
受注側でも、社内の見積もり承認プロセスは「確定額」を前提としていることが多いです。「幅で出したい」と言っても、上長や経営層が理解しなければ、社内承認が下りません。
既存プロセスとの親和性
WBS を作り、工数を積み上げ、単価を掛けて総額を出す。このプロセスは、確定見積もりと相性がいいです。幅見積もりを出すには、プロセス自体の見直しが必要になります。
双方にとっての「安定」
確定見積もりは、不確実性を「見ないふり」することで、短期的な心理的安定を提供します。
発注側は「この金額で収まる」と安心できます。受注側は「この範囲をやればいい」と安心できます。双方が「決まった」という感覚を得られます。
もちろん、この安定は幻想です。不確実性は消えたわけではなく、後工程に先送りされただけです。しかし、「今この瞬間の安心」には価値があります。
これは「悪意」ではなく「適応」です。現在の制度・文化・市場環境に対する、合理的な適応なのです。
Level 3 に到達できない構造的理由 ― 5W で解剖する
Level 1・2 に留まる合理性を理解したうえで、Level 3 に到達できない構造的理由を 5W の観点から分析します。
Why（なぜ変われないのか）― 動機構造の問題
変化には動機が必要です。しかし、Level 3 への移行には、動機を阻む構造があります。
発注側の動機障壁
リスク負担の増加
幅見積もりを受け入れるということは、不確実性の一部を発注側も負担することを意味します。「3,000〜5,000万円」の見積もりを受け入れれば、5,000万円になる可能性も自分の責任範囲に入ります。これを避けたい心理は自然です。
社内説明コストの増加
「なぜ幅で契約したのか」「なぜ上振れしたのか」を説明する負担が増えます。確定見積もりなら「ベンダーの見積もりどおりです」で済みます。
「任せたい」という心理
システム開発の不確実性を理解し、それを自分も負担するのは、認知的にも心理的にも負荷が高いです。「専門家であるベンダーに任せたい」という欲求は、人間として自然なものです。
受注側の動機障壁
弱さの表明に見えるリスク
「幅で出す」ことは、「確実なことが言えない」と告白することでもあります。競合が「確定で出します」と言っている中で、自社だけ幅で出せば、「自信がない」「能力が低い」と解釈されるリスクがあります。
競争上の不利
市場全体が確定見積もり文化で動いている限り、幅見積もりを出すベンダーは競争上不利になります。「正しいこと」をしても、受注できなければ意味がありません。
既存の成功体験
「今までも確定見積もりで何とかやってきた」という成功体験があります。デスマーチになっても、最終的には納品してきました。その成功体験が、変化の必要性を見えにくくします。
共通の動機障壁
コストと便益の時間差
Level 3 への移行には、短期的なコストがかかります。プロセスの変更、教育、契約交渉の手間。しかし、便益（手戻りの減少、品質の向上、関係性の改善）は、中長期的にしか現れません。人間は、短期のコストを過大評価し、長期の便益を過小評価する傾向があります。
「何とかなっている」という現状
Level 2 でも、プロジェクトは（苦労しながらも）完了します。品質問題や燃え尽きは起きますが、致命的な破綻は避けられていることが多いです。「何とかなっている」状況では、変化の緊急性が感じられません。
What（何が障壁なのか）― 具体的な障壁の正体
動機の問題に加えて、具体的な障壁が存在します。
認知的障壁
「当てるもの」という信念
「見積もりは当てるものだ」という信念は、深く内面化されています。この信念を持っている限り、「幅で出す」ことは「当てることの放棄」に見えます。信念の書き換えは、知識の習得よりも難しいです。
確率・分布で考える訓練の欠如
多くのエンジニアやマネージャーは、確率や分布で物事を考える訓練を受けていません。p10・p50・p90 という概念を説明されても、直感的に使いこなせるようになるには時間がかかります。
「不確実性」概念の曖昧さ
「不確実性がある」とは、具体的に何を意味するのでしょうか。技術的な難しさなのか、要件の曖昧さなのか、外部依存なのか。この区別ができないと、不確実性は漠然とした「不安」にしかなりません。
制度的障壁
契約書のフォーマット
契約書のテンプレートは、「確定金額」「確定納期」を前提に設計されています。幅を持った契約を結ぶには、テンプレートの改訂が必要です。法務部門の工数がかかります。
会計制度・予算制度
年度予算、四半期決算、費用計上のタイミング。これらの会計制度は、「いくらかかるか確定している」ことを前提としています。幅見積もりは、会計処理を複雑にします。
調達規程
特に大企業や公共機関では、調達規程が「最低価格での比較」を強制することがあります。幅見積もり同士の比較方法が、規程に定められていません。
組織的障壁
意思決定者の理解不足
見積もりの意思決定に関わる経営層や管理職が、技術的不確実性を理解していないことが多いです。「なぜ正確に見積もれないのか」という素朴な疑問に対して、説明するコストがかかります。
評価制度との不整合
「見積もり精度」が評価指標になっている場合、外れることは評価の低下につながります。幅で見積もっても、結果が幅の中に収まったかどうかではなく、最初の p50 と実績の差で評価されてしまうことがあります。
部門間の断絶
調達部門、法務部門、技術部門、経営企画部門。それぞれが異なる論理で動いています。幅見積もりへの移行には、これらの部門の連携が必要ですが、その連携自体がハードルになります。
市場的障壁
業界全体の文化
日本の IT 業界は、人月単価 × 工数 = 見積もり、という文化が深く根付いています。この文化の中で一社だけ変えても、取引先が対応できません。
囚人のジレンマ
全員が幅見積もりに移行すれば、全員が得をします。しかし、自分だけ移行すると損をします。他社が確定見積もりを出す限り、自社も確定見積もりを出さざるを得ません。
Who（誰が関与するのか）― プレイヤーの力学
Level 3 への移行には、複数のプレイヤーが関与します。それぞれの立場と利害を理解する必要があります。
変化を阻むアクター
調達部門
調達部門のミッションは、必要なものを適正な価格で調達することです。「比較可能性」と「コスト管理」が重要な指標になります。幅見積もりは、この両方を難しくします。調達部門が変化を阻むのは、悪意ではなく職務上の論理です。
経営層
経営層は、予算の予測可能性を重視します。「IT投資にいくらかかるか」を株主や取締役会に説明する必要があります。「3,000〜5,000万円の幅です」では、説明責任を果たせません。
法務部門
法務部門は、契約リスクの明確化を求めます。「幅で契約する」ということは、リスクの所在が曖昧になることを意味します。紛争時にどう扱うか、判例も少ないです。慎重になるのは当然です。
営業部門
受注側の営業部門は、受注することが最優先です。顧客が確定見積もりを求める限り、それに応えようとします。「幅で出しましょう」と提案しても、「それでは受注できない」と却下されることが多いです。
変化を望むアクター（しかし声が小さい）
現場エンジニア
デスマーチの当事者です。見積もりの構造的問題を肌で感じています。しかし、見積もりプロセスへの発言権は限られています。
プロジェクトマネージャー
発注側と受注側の板挟みになる当事者です。「確定見積もり」と「現実の不確実性」の間で苦しんでいます。しかし、制度を変える権限は持っていないことが多いです。
品質管理部門
品質が犠牲になった結果を見ています。「なぜ毎回テストフェーズが圧縮されるのか」を知っています。しかし、上流の見積もりプロセスには関与しにくいです。
不在のアクター
見積もり方法の専門部門
多くの組織では、「見積もり方法」を専門に扱う部門や役割が存在しません。見積もりは各プロジェクトで個別に行われ、組織としての学習が蓄積されません。
変化の推進者
Level 3 への移行を推進する責任者が、組織内で明確に定義されていません。誰の仕事でもないので、誰もやりません。
When（いつ変わるべきか／変わりうるか）― タイミングの問題
変化には適切なタイミングがあります。しかし、Level 3 への移行には、タイミングに関する逆説があります。
変化が起きにくいタイミング
プロジェクト進行中
プロジェクトが進行している最中に、見積もり方法を変えることは難しいです。「今さら変えられない」という慣性が働きます。
成功直後
プロジェクトが（苦労しながらも）成功した直後は、「今のやり方で問題ない」という認識が強まります。変化の必要性が見えにくくなります。
通常業務中
日常の業務に追われている中で、見積もりプロセスの改革に時間を割くことは難しいです。「余裕ができたらやろう」と先送りされます。
変化が起きうるタイミング
大規模な失敗の直後
プロジェクトが大きく失敗した直後は、変化のエネルギーが生まれやすいです。「何かを変えなければ」という機運が高まります。しかし、多くの場合、原因分析は「担当者の問題」で終わり、構造的な見直しには至りません。
経営層の交代
新しい経営層が、新しい方針を打ち出すタイミングは、変化のチャンスになりえます。ただし、見積もり方法の改革が経営アジェンダに上がるかどうかは、その経営者次第です。
外部からの強制
規制の変化、主要顧客の要求変化、業界標準の変化など、外部から強制されるケースです。これは変化の強い契機になりますが、自分たちでコントロールできません。
業界全体のトレンド変化
業界全体が幅見積もりに移行すれば、個社も追随しやすくなります。しかし、業界全体が変わるのを待っていては、いつまでも変わりません。
タイミングの逆説
変化に関する逆説があります。
「痛み」がないと変わりません。しかし、「痛み」の最中は変える余裕がありません。
プロジェクトが順調なときは、変化の必要性を感じません。プロジェクトが炎上しているときは、変化に取り組む余裕がありません。
変革の最適タイミングは、常に「少し前」だったのです。
Where（どこで変化が必要か）― 変化の所在
Level 3 への移行には、複数の場所での変化が必要です。
変化が必要な場所（発注側）
予算申請プロセス
「確定額」でしか申請できない予算制度を、「幅を持った申請」も許容する形に変えます。例えば、「基準額 + 上振れ上限」という形式の導入です。
調達規程
価格だけでなく、リスク分担方法、変更時の対応方針なども評価軸に加えます。幅見積もり同士の比較方法を規程に定めます。
契約テンプレート
固定価格契約だけでなく、可変条項を含む契約テンプレートを整備します。法務部門との連携が必要です。
経営報告フォーマット
IT投資の進捗を報告する際に、不確実性を可視化する形式を導入します。「予定どおり」「遅延」の二択ではなく、「p80 で 6月末」のような表現です。
変化が必要な場所（受注側）
見積プロセス
参照クラス（過去の類似案件の実績分布）を活用します。幅見積もり（p10–p90）を標準フォーマットにします。
提案書フォーマット
前提条件、リスク要因、幅の根拠を明示する欄を設けます。「確定額」だけでなく、「条件付き見積もり」を提示できる形式です。
進捗報告
「7割完了」のような曖昧な報告ではなく、分布ベースの報告を行います。残作業の p10–p90 を提示します。
社内評価制度
「予実一致」ではなく、「校正精度（Calibration）」を評価指標にします。幅の中に実績が収まったか、幅の設定は適切だったかを評価します。
変化が必要な場所（両者の間）
契約形態
固定価格契約だけでなく、T&M（タイム・アンド・マテリアル）、上限付き T&M、可変スコープ・固定予算など、複数の契約形態を選択肢に持ちます。
コミュニケーションプロトコル
変更要求の扱い方、影響評価の方法、合意形成のプロセスを、両者で事前に合意しておきます。
リスク分担の合意方法
「不確実性をどう分担するか」を、契約前に明示的に議論する場を設けます。
構造的ジレンマ ― なぜ「正しいこと」が実行されないのか
5W の分析を通じて見えてくるのは、Level 3 への移行を阻む構造的なジレンマです。
囚人のジレンマとしての見積もり
見積もり文化には、囚人のジレンマの構造があります。
全員が幅見積もりに移行すれば、全員が得をします。不確実性が明示されることで、現実的な計画が立てられ、デスマーチが減り、品質が向上し、関係者全員の負担が減ります。
しかし、一社だけ移行すると損をします。競合が確定見積もりを出す中で、自社だけ幅で出せば、「自信がない」と見なされ、受注を逃します。
結果、全員が確定見積もりに留まります。全員が「本当は幅で出したい」と思っていても、最初に動くインセンティブがありません。
情報の非対称性
受注側は、不確実性の存在を知っています。過去の経験から、どこにリスクがあるか、どれくらいブレる可能性があるかを、ある程度わかっています。
しかし、その情報を開示するインセンティブがありません。「リスクがあります」と言えば、「ではリスクを減らしてください」と言われるか、「リスクのないベンダーを選びます」と言われます。
発注側は、不確実性を知らされません。しかし、知りたくもない側面があります。不確実性を知れば、それを自分も管理しなければならなくなります。「ベンダーに任せた」と言えなくなります。
こうして、不確実性は両者の間で「見て見ぬふり」をされます。
短期最適と長期最適の乖離
確定見積もりは、短期的には取引コストを下げます。
交渉がシンプルになります。比較が容易になります。責任の所在が明確になります。契約がすぐに結べます。
しかし、長期的には、品質低下、燃え尽き、信頼毀損を招きます。見積もりが現実と乖離し、それを無理に達成しようとして、人が壊れます。何度も繰り返せば、「この業界はそういうものだ」という諦めが広がります。
短期の意思決定が、長期の悪化を生んでいます。しかし、短期の意思決定を行う人と、長期の結果を引き受ける人は、しばしば異なります。
問題の所在を正しく認識する ― Level 3 への第一歩
「誰が悪いか」ではなく「何が構造か」
ここまでの分析で明らかになったのは、Level 3 に到達できないのは、誰かが悪いからではない、ということです。
発注側も、受注側も、それぞれの立場で合理的に行動しています。調達部門は比較可能性を求め、経営層は予測可能性を求め、営業部門は受注率を求め、エンジニアは現実的な計画を求めています。それぞれが、自分の責任範囲で最適化しようとしています。
問題は、個人ではなく、インセンティブ構造とゲームのルールにあります。
確定見積もりを求めることが合理的になる構造、幅見積もりを出すと不利になる構造、不確実性を隠すほうが得になる構造。この構造自体が問題なのです。
構造を理解せずに、「発注側が悪い」「受注側が悪い」と言っても、何も変わりません。構造の中で、それぞれが適応しているだけなのですから。
変化の前提条件
構造を変えるためには、いくつかの前提条件が必要です。
双方が「現状の代償」を認識すること
確定見積もり文化の代償は、誰が払っているのでしょうか。デスマーチで消耗するエンジニア、品質問題で苦しむ運用チーム、信頼を失う業界全体。この代償を、発注側も受注側も、経営層も現場も、正確に認識することが出発点になります。
変化の「実験」を許容する関係性があること
いきなり全面的に変えることはできません。小さな実験から始める必要があります。「このプロジェクトだけ、幅見積もりを試してみよう」「この契約だけ、可変条項を入れてみよう」。そうした実験を許容する関係性が、発注側と受注側の間にあるかどうかです。
小さく始める場所があること
全社的な制度改革は時間がかかります。まずは、特定のプロジェクト、特定の顧客、特定のチームで始められる場所があるかどうか。そこで成功事例を作り、徐々に広げていくしかありません。
本記事の位置づけ
本記事は、「How（どう変えるか）」の前に、「Why/What/Who/When/Where」を整理することを目的としました。
問題の構造を共有言語化することが、変化の第一歩です。
「見積もりがうまくいかない」という漠然とした不満を、「なぜ幅で語れないのか」という具体的な問いに変換します。その問いに対して、動機の問題、制度の問題、組織の問題、市場の問題、タイミングの問題を区別します。どこに障壁があるのかを、関係者全員が共通認識として持ちます。
この共通認識なしに、「幅見積もりを導入しよう」と言っても、うまくいきません。「なぜ今のやり方ではダメなのか」「何がハードルなのか」を、全員が理解している必要があります。
おわりに：「幅で語る」ことの意味
「幅で語る」とは、「わからない」と言う勇気を持つことです。
「5人月でできます」と言い切るほうが、自信があるように見えます。「3〜7人月です」と言うのは、自信がないように見えます。
しかし、本当に自信があるのはどちらでしょうか。
未来が不確実であることを知りながら、「5人月です」と言い切るのは、知っていて嘘をついているか、知らないふりをしているかのどちらかです。
「3〜7人月です」と言うのは、未来が不確実であることを認め、その不確実性の幅を正直に伝えることです。これは弱さではなく、現実への誠実さです。
Level 3 への移行は、技術の問題ではなく、文化と制度の問題です。p10–p90 の計算方法を学ぶことは、それほど難しくありません。難しいのは、「幅で語ってもいい」という文化を作ること、「幅で契約できる」という制度を作ることです。
そして、その文化と制度を変えるためには、まず構造を理解しなければなりません。
構造を理解した者だけが、構造を変える起点になれるのです。
Discussion