予測と約束は別物である：見積もりの作法【第10回】

この記事を読み終えると、予測と約束を区別して答え、見積もりの4つの技法を使い分け、幅と前提をつけて「いつできるか」を伝えられるようになります。ジュニアエンジニア向け 成果の出し方シリーズ（全12回）の第10回です。

🎯 テーマの主役：「見積もり」

今回の主役は見積もりです。一言で言えば、見積もりとは「未来の予測」です。約束ではありません。予測です。

日常の例えで言うなら、天気予報です。天気予報は「明日は晴れです」とは言いません。「降水確率30%」と言います。そしてそれで十分に役に立ちます。傘を持つかどうかを決められるからです。予報は外れますが、外れることを前提に使われているので、誰も怒りません。そしてもう1つ、天気予報は「確率」と「幅」で語られます。「明日の最高気温は22度から25度」という形です。

ところがソフトウェアの見積もりは、しばしば「晴れです」の形で要求されます。「いつできる？」に対して、「9月30日です」と答える。そして約束として扱われます。約束にした瞬間、予測は機能しなくなります。なぜなら約束を守るために、人は見積もりを歪めるからです。期間を短く申告し、品質を削り、残業し、負債を残す。これが最も高くつく結末です。

この記事の仮説はこうです。見積もりの精度は技術の問題ではなく、扱い方の問題である。予測として扱われている限り見積もりは役に立ち、約束に変換された瞬間に壊れる。したがって身につけるべきは、精度を上げる技術よりも、正確に伝える技術である。もしこれが正しければ、あなたの仕事は「当てること」から「前提と幅を伝えること」に変わります。

なお第6回で扱った進捗報告と、この記事は対になります。第6回は「いまどうなっているか」、第10回は「これからどうなるか」です。そして第9回の価値の見積もりと合わせて、「何を・いつまでに」が言えるようになります。

動機：「いつできる？」に、どう答えればいいのか

ジュニアエンジニアが最も苦手とする質問が、これです。「これ、いつできる？」。

そして最も多い失敗は、「9月30日です」と即答することです。即答したくなる気持ちは分かります。期待に応えたい、できると思われたい、分からないと言いたくない。しかしこの即答が、後で大きな問題になります。前提が変わっても、期限だけが残ります。そして間に合わないと分かったとき、すでに手遅れです（第6回で扱ったとおりです）。

もう1つの失敗は、「分かりません」とだけ答えることです。これも正しくありません。見積もりは、意思決定の材料です。材料を出さないのは、仕事をしていないのと同じです。正解は「幅と前提をつけて、いまの予測を出す」です。

この記事のゴールは、「いつできる？」に対して、相手が判断に使える答えを返せるようになることです。

🔍 検証①：予測と約束は、別のもの

まず、この2つを明確に分けます。混ざっていると、正しく扱えません。

予測（estimate）：現時点の情報に基づく、最も確からしい見通しです。新しい情報が入れば更新されます。確率と幅を持ちます。

約束（commitment）：守る義務を負った合意です。予測が変わっても、約束は残ります。だから約束には、予測とは別の根拠が必要です。

重要なのは、約束が悪いわけではないことです。約束は必要な場面があります。対外的な告知、契約、法規制の期限。変えられない日付は実在します。ただしその場合、守るための条件が必要です。範囲を固定する、人が増える、優先順位が上がる。約束には、セットで資源が必要です。「9/30に出します」と言うなら「そのために、この作業を止めます」と言う必要があります。

🔍 検証②：見積もりが外れる4つの構造的理由

次に、外れる理由を理解します。これは能力の問題ではなく、構造の問題です。理解しておくと、外れたときに落ち込まずに済みます。

①不確実性（未知の未知）：そもそも分からないことが残っている。要件が固まっていない、技術が未検証、外部の反応が不明。この不確実性は、初期ほど大きい。これは不確実性の円錐として知られています（初期段階では見積もりの幅が数倍になる）。

②計画錯誤：人間は自分の作業を楽観的に見積もる。これは性格ではなく、認知の傾向です。過去の類似案件の実績を無視し、「今回はうまくいく」と考えます。

③相関する遅延：遅れは独立に起きません。1つ遅れると、他の遅れが重なります。レビュー待ち、環境の空き待ち、他チームの遅れ。これらは同時に発生しやすく、影響が累積します。

④圧力による歪み：見積もりを求められる文脈が、見積もりを歪めます。これは構造的な問題で、研究でも示されています（後述）。

②の対策が最も実用的です。自分の過去の実績を参照する。たとえば「私はこれまで、見積もりの1.8倍の時間を使ってきた」というデータがあれば、次からは1.8を掛けた数字を出す。これを基準クラス予測と呼びます。「今回は特別」を排除するのが目的です。そして「特別」は、ほぼ必ず特別ではありません。

🔍 検証③：圧力は、見積もりを歪める

次に、最も知っておくべき構造を扱います。見積もりは、誰に求めたかで変わります。

これは研究で示されている現象です。「顧客（依頼者）の期待が高い」と知らされた開発者は、実際の作業量が同じでも、より短い見積もりを出す傾向が確認されています。つまり見積もりは、技術的な事実だけでなく、社会的な文脈に左右されます。そして見積もりを出す側は、多くの場合自覚していません。

これはあなたに2つの教訓を与えます。第一に、見積もりを出したあと「もう少し早くできない？」と聞かれたら、警戒することです。その質問は、あなたの見積もりを歪めます。第二に、他の人の見積もりを聞くとき、同じ圧力をかけないことです。あなたが将来、後輩の見積もりを聞く側になったときに効きます。

「もう少し早くできない？」への正しい答えは、「範囲を削るなら可能です」です。期間だけを縮める相談は、品質か範囲を犠牲にする相談です（第6回の三角形）。この言い換えができると、会話が建設的になります。「早くする」ではなく「何を削るか」の議論に変わるからです。

🔍 検証④：見積もりの技法は4つ

次に、具体的な技法です。1つではなく、組み合わせて使います。

①分解：大きいものは見積もれません。小さく分けて、それぞれを見積もり、合計します。分解の粒度は、1つが半日〜2日程度が扱いやすい。分解の過程で「分からない部分」が見つかるのが最大の効用です。

②類推（実績参照）：似た作業の実績から見積もる。「前回の同じ種類の画面は3日だった」。これが最も精度が高い方法です。実績がない場合は、他の人に聞きます。

③三点見積もり：楽観値・最頻値・悲観値の3つを出します。悲観値は「最悪の場合」ではなく「95%の確率で収まる値」と定義します。この3つから、期待値と幅が出せます。幅を出すことが目的です。

④相対見積もり：絶対値ではなく、他の作業との比較で見積もります。「これはあれの2倍くらい」。人間は絶対値より相対比較のほうが正確です。チームでカードを使って相対比較する手法も広く使われています。

迷ったら「分解」と「類推」の組み合わせが最強です。分解して、各部分を過去の実績に当てはめる。そして過去の実績がない部分は、調査タスクとして切り出します。「見積もれない部分」を「調査タスク」として明示するのが、見積もりの最も誠実な形です。「この部分は3日間調査して、その後に見積もります」。これは後回しではなく、正しい手順です。

🔍 検証⑤：幅と前提で答える

次に、答え方です。見積もりは、数字そのものより、伝え方で価値が決まります。

幅で答えます。「9月25日から10月2日の間、8割の確率で」。幅があると、相手はリスクを見込めます。幅が50%を超えるようなら、それは見積もりではなく「不明」です。その場合は、調査の提案をします（第8回の「調べるだけの提案」）。

前提を書きます。「レビュー待ちが2日以内」「仕様変更がない」「この担当者が継続」「外部APIの応答が現状と同じ」。前提は、外れたときに説明する材料になります。そして前提を書くことで、相手が前提を守ってくれます。「レビューを2日以内でお願いします」という依頼にも変わります。これが最大の効用です。

確度を表現します。「確実」「おそらく（8割）」「見込み（5割）」「不明（調査が必要）」。この4段階があれば、日常の会話で困りません。

そして、不確実性の円錐を意識します。プロジェクトの初期は、見積もりの幅が数倍に及ぶことが知られています。「初期に精度の高い見積もりを出す」ことは原理的に不可能です。だから初期には、幅の広い予測と、調査の提案を出します。精度が上がるのは、進んでからです。この事実を知っていると、「まだ正確には言えません」と堂々と言えます。

🔍 検証⑥：見積もりと実績を記録すると、精度が上がる

最後に、精度を上げる唯一の確実な方法です。それは記録です。

見積もりと実績の差を記録する。たとえば「見積もり3日、実績5日、倍率1.7」。これを20件分集めると、自分の傾向が見えます。調査を甘く見る、レビュー待ちを数えていない、環境構築を忘れる。傾向が分かれば、次の見積もりで補正できます。

「待ち時間」の記録が最も効きます。実は、作業時間の大部分は「待ち」です。レビュー待ち、回答待ち、環境待ち、他チーム待ち。これを見積もりに入れていないと、必ず外れます。1週間の自分の時間を記録してみると、実作業が半分以下だったという発見は、多くの人が経験します。そして待ち時間は、あなたの努力では減らせません。だから見積もりに明示的に入れて、前提として共有します。「レビュー待ちが2日入るので、実作業3日＋待ち2日で5営業日です」。この説明ができると、見積もりの説得力が変わります。

結果：「いつできる？」への答え方テンプレート

【質問】いつできますか

■ NG：即答の一点日付
　「9月30日です」
　→ 約束として扱われ、前提が変わっても残る

■ OK：幅と前提と確度
　「いまの情報では、8割の確率で 9月25日〜10月2日です」
　「確度を上げるには、Aの調査に3日必要です」

【その後の会話で必ず添えること】
　・前提：レビュー待ち2日以内／仕様変更なし／担当者継続
　・交換条件：「9月25日に固定したい場合、Bの機能を次回に回します」
　・次の更新：「9月18日時点で、精度を上げて再提示します」

【見積もれないと言うとき】
　「この部分は未知なので、見積もれません。
　　3日間の調査をください。その時点で全体の見積もりを出します」
　→ 見積もれないことを隠さず、調査を提案する（第8回）

【根拠を聞かれたとき】
　・分解した結果（半日〜2日の単位の積み上げ）
　・類推した実績（前回の類似作業は3日）
　・待ち時間（レビュー待ち2日を別枠で計上）

この形で答えると、何が変わりますか。第一に、相手がリスクを見込めます。第二に、前提が守られます（相手が前提を知るので、レビューを早く回してくれます）。第三に、外れたときに説明できます。「前提のAが崩れました」と言える。これが最も大きい。予測が外れることは、失敗ではありません。説明できないことが失敗です。

考察：見積もりが下手なのではなく、扱いが下手

ここまでを踏まえて、1つ踏み込んだ話をします。日本を含む多くの現場で、「見積もりは外すもの」という前提が共有されていません。だから見積もりを外すことが、能力の低さとして扱われます。そしてその結果、人は見積もりを守るために、本来削ってはいけないものを削ります。テスト、レビュー、ドキュメント、休息。

そしてこの構造が、より大きな事故を生みます。2013年、ある国の公的医療保険のWebサイトが、公開初日に利用不能になりました。期限に合わせて開発が進められた結果、公開時に想定された負荷に耐えられず、修復に数週間を要しました。教訓は「期日に合わせて品質を削ると、期日も守れない」です。品質を削った分は、後で必ず返済が必要になります。そして返済は、元本より大きい（第2回・第5回で扱ったとおりです）。

だからこそ、見積もりを「予測」として扱う文化を作ることは、安全の基盤になります。そしてその文化は、あなたの1回の答え方から変わります。あなたが「幅と前提」で答えると、周りもそう答えるようになります。特に、あなたが後輩の見積もりを聞く立場になったとき、圧力をかけないことが重要です。「もっと早くできない？」は、見積もりを歪める質問です。代わりに「この範囲を削れば早くなる？」と聞きます。

もう1つの考察は、見積もりの価値は精度だけではないということです。見積もりの過程で、分からないことが見つかります。分解すると、知らない部分が見えてきます。これが最大の効用です。精度の高い見積もりより、見積もりの過程で見つかったリスクのほうが価値があります。だから「見積もりは外れたから無意味」ではありません。外れたこと自体が、学びです。

📌 注目ポイント

核心は4点です。第一に、予測と約束は別物であり、混ぜると両方壊れること。第二に、見積もりが外れるのは能力ではなく構造（不確実性・計画錯誤・相関する遅延・圧力）であること。第三に、見積もりは「幅・前提・確度」で伝えること。第四に、見積もりと実績の記録が、精度を上げる唯一の確実な方法であること。

特に第三点の「前提」が最も実用的です。前提を書くと、相手が前提を守るようになります。「レビュー待ちが2日以内」と書けば、レビューが遅れたときに状況が変わったことが共有されます。前提は、見積もりを守る盾ではなく、協力の依頼です。

💡 活用事例：不確実性の円錐という事実

見積もりの難しさは、ソフトウェア工学の初期から研究されています。1981年の古典的な研究では、プロジェクトの進行に応じて見積もりの不確実性が減少することが示され、その形が円錐（コーン・オブ・アンサーティ）として表現されました。初期段階では、見積もりは数倍の幅を持ちます。設計が進むにつれて幅が狭まり、実装が進むとさらに狭まります。

この事実を知っていると、会話が変わります。初期段階で「9月30日」と即答することは、原理的に不可能です。幅を出すか、調査を提案するのが正解です。そして「精度を上げるには、調査期間が必要」という提案は、正当な要求です。見積もりの精度は、情報量に比例します。情報を増やすには時間がかかる。この当たり前の事実を、数字で説明できるのが強みです。

類推（基準クラス予測）の有効性も、大規模プロジェクトの研究で繰り返し示されています。過去の類似案件の実績分布から見積もるほうが、個別に積み上げるより精度が高いことが報告されています。理由は単純で、人間は「今回は特別」と考えがちだからです。「今回は特別」を排除する仕組みが、実績参照です。あなたの個人のタスクでも同じです。自分の過去20件の倍率を知っていれば、「今回は特別」に騙されません。

✅ 要点まとめ

• 予測と約束は別物。混ぜると両方壊れる
• 約束にするなら、範囲の固定・資源・優先順位が必要
• 見積もりが外れるのは構造：不確実性・計画錯誤・相関する遅延・圧力
• 圧力は見積もりを歪める。「もう少し早く」への答えは「範囲を削るなら可能」
• 技法は4つ：分解・類推（実績参照）・三点見積もり・相対見積もり
• 見積もれない部分は「調査タスク」として切り出す（これが最も誠実）
• 答えは幅・前提・確度の3点セット。前提が最大の効用
• 待ち時間を見積もりに入れる。実作業は全体の一部にすぎない
• 記録が精度を上げる唯一の確実な方法。見積もり・実績・外れた理由
• 不確実性の円錐：初期は幅が数倍。初期に一点の日付は原理的に不可能

🚀 取り込み方：明日から使う3段階

今日（5分でできること）：いま抱えているタスクの見積もりを、「幅・前提・確度」の3点で書き直してください。「3日」ではなく「2〜4日、8割の見込み。前提はレビュー待ち1日以内」。これだけで、あなたの見積もりは意思決定に使える形になります。

今週（小さく試す）：見積もりと実績を記録し始めてください。表は4列で十分です。タスク／見積もり／実績／外れた理由。5件も貯まると、自分の癖が見えます。「調査を1.5倍甘く見る」「レビュー待ちを忘れる」。そして次の見積もりで補正します。自分の倍率を知ることは、最も費用対効果の高い学習です。

今月（業務に組み込む）：チームに「見積もりの答え方」を提案します。幅・前提・確度の3点セットと、「もう少し早く」への対応（範囲を削る交換条件）。あわせて、見積もりを評価対象にしないという合意を提案します。見積もりが評価されると、人は安全側に長く出し、予測として機能しなくなります。予測の精度は、評価と切り離したときに上がります。これは第6回（報告のしやすさ）と同じ構造です。情報が正しく流れる条件を整えることが、最も価値の高い仕事です。

🔥 ハマりポイント：見積もりで失敗する3つの型

その1：「早く答えるほうが有能に見える」と思いがちだが、実は即答は後で高くつく

症状は、即答した日付が独り歩きし、前提が崩れても期限だけ残る。原因は見積もりが予測だと理解されていないことです。対処は、「いまの情報では」を必ず前置きすることです。「いまの情報では、8割でこの範囲です。精度を上げるには調査が必要です」。この前置きがあるだけで、その後の前提変更が自然に扱えます。即答を避けることは、有能さを下げません。むしろ、予測を正確に扱える人として信頼されます。

その2：「見積もりは自分の作業時間のこと」と思いがちだが、実は待ち時間が半分を占める

症状は、実作業3日と見積もって、実際に2週間かかる。原因は待ち時間を計上していないことです。対処は、1週間自分の時間を記録することです。「実作業」「待ち」「割り込み」「会議」の4分類で測ると、自分の作業時間が想像より少ないことに気づきます。そのうえで、見積もりに待ち時間を明示的に入れます。「実作業3日＋レビュー待ち2日＋確認1日＝6営業日」。この分解ができると、見積もりの質が一段上がります。

その3：「見積もりを外すのは失敗」と思いがちだが、実は説明できないことだけが失敗

症状は、外れたときに謝るだけで、原因の分析がない。原因は外れることを想定していないことです。対処は、前提を書いておくことです。前提を書いていれば、外れたときに「どの前提が崩れたか」を説明できます。「レビュー待ちが2日以内という前提が、5日になりました」。これは失敗ではなく、状況の変化の報告です。そして次の見積もりで、その前提を厳しくします。見積もりは改善していくものであり、1回で当てるものではありません。第3回の仮説と検証と、まったく同じ構造です。

🔄 代替アプローチとの比較：見積もりをめぐる立場

「見積もり」には複数の立場があります。どれが正しいかではなく、文脈で選ぶものです。

「見積もりしない」という選択肢も存在します。作業を小さく一定の大きさに揃えて、平均的な処理数を測る。この立場は、反復開発が定着したチームでは有効です。「いつできるか」を個別に予測せず、統計的に予測します（同じ大きさの作業を週に何件処理できるか）。ただし外部に対する約束がある場合は、日付に変換する必要があります。この立場が向かないケースも正直に書きました。重要なのは、どの立場かをチームで合意することです。立場が混ざると、会話が噛み合いません。

📅 今後の展望：見積もりは「統計」と「流れ」へ

見積もりの実践は、この20年で個人の勘から統計へ移りつつあります。過去の実績データから統計的に予測する方法、作業を一定の大きさに揃えて流れを測る方法、サイクルタイムの分布から予測する方法。これらは個別の見積もりより精度が高いことが知られています。理由は単純で、人間の楽観バイアスを排除できるからです。

そしてAIの活用も進んでいます。過去の類似タスクから見積もりを提案する、リスクの高い部分を指摘する。ただしAIの見積もりも、過去のデータの質に依存します。記録がない組織では、AIも良い予測を出せません。つまり記録の価値が、これまで以上に上がります。

もう1つの流れは、「予測を評価に使わない」という合意が広がることです。見積もりの精度を個人評価に使うと、予測は機能しなくなります。この事実は少しずつ認識されつつあります。あなたがチームで見積もりを扱う立場になったとき、最初に決めるべきは「見積もりをどう使うか」です。この合意が、チームの予測精度を決めます。

まとめ

この記事では、見積もりの作法を扱いました。予測と約束は別物であり、混ぜると両方壊れます。見積もりが外れるのは構造的な理由（不確実性・計画錯誤・相関する遅延・圧力）であり、能力の問題ではありません。技法は4つ（分解・類推・三点・相対）で、見積もれない部分は調査タスクとして切り出します。そして答えは幅・前提・確度の3点セット。記録が精度を上げる唯一の確実な方法です。

これを読んだあなたは、「いつできる？」に対して、相手が判断に使える答えを返せるようになりました。次の第11回では、割り込みと優先順位を扱います。忙しさを設計する——それが次のテーマです。見積もりができても、次々に降ってくる割り込みに予定が壊れるなら意味がありません。第10回と第11回は、セットで機能します。

参考文献

1. Barry W. Boehm『Software Engineering Economics』（1981） — ソフトウェア見積もりの基礎と不確実性の円錐。 https://www.computer.org/
2. Steve McConnell『Software Estimation: Demystifying the Black Art』（2006） — 見積もり技法の実務的な整理。 https://www.construx.com/
3. Magne Jørgensen & Dag I. K. Sjøberg（2004）「The impact of customer expectation on software development effort estimates」 — 期待が高いと見積もりが短くなる現象の実証研究。 https://www.sciencedirect.com/
4. Magne Jørgensen（2004）「Realism in assessment of effort estimation uncertainty」 — 見積もりの不確実性の扱いに関する研究。
5. Bent Flyvbjerg（2006）「From Nobel Prize to Project Management: Getting Risks Right」 — 基準クラス予測の提案。 https://arxiv.org/
6. Daniel Kahneman & Amos Tversky（1974）「Judgment under Uncertainty: Heuristics and Biases」 — アンカリングと利用可能性。 https://www.science.org/
7. Roger Buehler, Dale Griffin & Michael Ross（1994）「Exploring the Planning Fallacy」 — 計画錯誤の実証。 https://www.sciencedirect.com/
8. Frederick P. Brooks『The Mythical Man-Month』（1975） — 人月の神話と、進捗の遅れに関する観察。
9. Diane Vaughan『The Challenger Launch Decision』（1996） — スケジュール圧力が判断を歪める過程の詳細な分析。
10. Columbia Accident Investigation Board（CAIB）報告書（2003） — スケジュール圧力と組織要因の分析。 https://www.nasa.gov/
11. Healthcare.gov の公開障害に関する米国政府・議会の報告（2013年10月〜） — 期日優先が招いた公開時の障害。 https://www.gao.gov/
12. The Standish Group CHAOS レポート（1994年以降） — プロジェクトの納期・予算・機能の達成状況（方法論には議論がある点に留意）。 https://www.standishgroup.com/
13. James Grenning（2002）「Planning Poker」 — 相対見積もり手法の原典。
14. Donald G. Reinertsen『The Principles of Product Development Flow』（2009） — 遅延コストと意思決定の経済性。
15. IPA『ソフトウェア開発データ白書』 — 国内プロジェクトの工数・期間データ。 https://www.ipa.go.jp/
16. PMI『PMBOK Guide』／A Guide to the Project Management Body of Knowledge — 見積もりとスケジュール管理の標準。 https://www.pmi.org/