見積もりはなぜ失敗するのか（そして、なぜそれでも必要なのか）

• ソフトウェア開発における作業見積もりは 複雑系（Complex）領域 に属しており、どれほど熟練したチームであっても本質的に正確な見積もりは不可能
• #NoEstimates 運動は、見積もりが 成果目標として誤用 される現実への正当な反発だったが、見積もり自体を拒否すると組織の調整能力が失われる
• 見積もりの核心的な価値は未来予測ではなく、不確実性の下でのコミュニケーションと調整 にあり、外部契約・チーム間依存・ROI 判断に不可欠
• Steve McConnell の 不確実性の円錐（Cone of Uncertainty） によれば、プロジェクト初期には見積もり誤差が 4 倍まで発生しうるが、学習を通じてのみその幅は狭まる
• 見積もりを約束に変えてしまう組織的習慣を改め、スコープベース・前提明示・段階的補正 の見積もり方式を採用すべき

---

#NoEstimates 運動が実際に解決した問題

• チームが問題についてほとんど何も分かっていない状態で見積もりを求められ、その数字がロードマップに反映されて顧客への約束になる、というパターンが繰り返される
• 現実が見積もりと乖離すると、チームは「納期を守れなかった」と非難されるが、そもそもその納期は合意したものではなかった
• 見積もりが予測ではなく 約束（commitment） に変質することが、核心的な病理現象
• 「見積もりをやめよう」という解決策は、壊れた温度計への反応として 温度という概念そのものを否定 するのに等しい
• Maarten Dalmijn の表現を借りれば、見積もりは実際の作業量を変えず、機能開発は必要なだけ時間がかかる
  • 見積もりが影響を与えるのは作業そのものではなく、その周辺にある 期待値（expectations）
  • 期待値を正直かつ明確に管理することには十分な価値がある

組織が実際に見積もりを必要とする理由

• #NoEstimates の議論でほとんど抜け落ちている点: 見積もりは作業を行うチームのためではなく、その周囲にある組織のためのもの

• 見積もりが避けられない状況は 3 つある

• 外部への約束（External commitments）: 顧客契約、マーケティングキャンペーンと連動したリリース、規制対応の締切などでは、実現可能性を判断するために作業所要時間のモデルが不可欠

  • 「私たちは見積もりをしません」は顧客に返せる答えではなく、契約終了につながりうる

• チーム間依存（Inter-team dependencies）: チーム B がチーム A の完了を待たなければならないとき、チーム A が何の予測も出さなければ、チーム B は計画できない

  • おおまかなシグナル（「たぶん 6 週間、長くても 8 週間」）は沈黙よりはるかに有用であり、これは統制ではなく 下流チームのメンバーに対する敬意 である

• ROI 計算: 機能 X と機能 Y のどちらを作るかを決めるには、相対的なコストモデルが必要

  • すべてが不可知なら合理的なトレードオフはできず、どうせ推測するなら 前提を明示した構造化された推測 の方がよい

Joseph Pelrine が示した見積もりの本質的な難しさ

• Joseph Pelrine はヨーロッパ初の Certified Scrum Trainer であり、社会的複雑性科学のレンズを通じてソフトウェアアジャイルを研究している
• アジャイルソフトウェア開発に従事する 300 人以上 を対象に、日常業務の活動を Cynefin フレームワーク（Dave Snowden のセンスメイキングモデル）の領域に配置する実験を実施
  • Cynefin は問題を Clear、Complicated、Complex、Chaotic の 4 領域に分類する
• 作業見積もりは一貫して反復的に Complex 領域 に配置された
• Complicated と Complex の違い が核心:
  • Complicated 領域では因果関係を把握でき、専門家が追跡でき、専門知識が信頼できる予測を生み出す
  • Complex 領域では因果関係は 事後にしか把握できず、システムはあまりに絡み合っていて文脈依存的であり、小さな変化にも敏感
• ソフトウェア開発が製造業ではない理由: ほとんど常に、以前存在しなかったものを固有のコードベースと固有のチームダイナミクスの上に構築しているから
  • 大工の比喩が機能しない理由: キャビネットは他のキャビネットとおおむね似ているが、機能は他の機能とおおむね似ていない
• 優れたチームであっても 平均的なレベルの見積もりしかできない が、それは能力不足ではなく、Complex 領域における精度に本質的限界があるため
• 目標は見積もりを当てることではなく、本質的な不正確さにもかかわらず有用な意思決定を行うこと

不確実性の円錐（Cone of Uncertainty）が示すこと

• Steve McConnell の 不確実性の円錐 という概念: プロジェクト初期には見積もり誤差が両方向に 4 倍（合計 16 倍のレンジ）まで発生しうる
• プロジェクトが進み、未知の要素が解消されると（要件の明確化、アーキテクチャの確定、難しい問題の発見と解決）、円錐は狭まる
• 皮肉なのは、見積もりが 最も正確になる時点は完了直前 であり、そのときこそ見積もりの必要性が最も低いということ
  • 最も有用な初期段階（まだ方向転換やプロジェクト中止が可能なとき）にこそ、私たちは最も情報を持っていない
  • そして多くの組織は まさにその初期段階で最も強い約束 をしてしまう
• 追加の示唆は 2 つある:
  • この円錐は 熟練した見積もり担当者における最良ケース を示しており、ほとんどのチームはこれより精度が低い
  • 初期コンセプト段階で日付を確定するのは計画ではなく、願望を立ててそれに合わせて日程を引くこと だ
  • 円錐は 時間ではなく不確実性を取り除く決定 によってのみ狭まる
  • スコープ定義、アーキテクチャ上の未知の解消、実際のコード作成と難所の発見が円錐を狭めるのであり、3 週間会議だけをしていても狭まらない
• ステークホルダーには「見積もりの品質は、円錐のどこに私たちがいるかに依存する」と明示的に伝えるべき
  • 1 週目に 2 週間ぴったりの数字は出せないが、レンジを示し、それを狭めるために何を確認する必要があるかは説明できる
  • ほとんどのステークホルダーは円錐を説明すれば受け入れる。単に、レンジを求めてもよいと誰も教えてこなかっただけ なのだ

フィボナッチスケールを使う理由

• フィボナッチスケール（1, 2, 3, 5, 8, 13, 21）の 非線形性が認識論的な役割 を果たす
• 2 と 3 の差は「おおよその違いを感じ取れる」程度だが、8 から 13 へのジャンプは 不確実性の帯域が見積もり値そのものより広い ことを符号化している
  • 13 ポイントのストーリーは「正確に 13」ではなく、「8 より明らかに不確実で、21 ほどではないカテゴリ」を意味する
• フィボナッチ数の間隔は 複雑性が実際に拡大する仕方 を反映している
  • 小さいものはおおよそ見積もれるが、大きいものは未知の要素・統合ポイント・予期しない事態が多く、幾何級数的に予測が難しくなる
  • 21（または 13）以上のストーリーは、「まだ作業を理解できていないので 分割すべきだ」ことを意味する
• フィボナッチ見積もりのもう 1 つの過小評価されがちな機能は、見積もりの会話の中で起こること
  • ある人が 3、別の人が 13 と言ったなら、数字そのものはほとんど重要ではなく、同じチームが同じストーリーをなぜそんなに違って見ているのかが重要
  • 片方が依存関係を見つけていたり、チケットには書かれていない技術的制約を知っていたりする可能性がある
• 見積もりの最大の価値は数字ではなく、共通理解が形成されたかを確認すること にある
  • この強制装置を取り除くと、共有理解は誰かが作業 3 日目に隠れた複雑さにぶつかるまで形成されないことが多い
• 「見積もり会議は無駄だ」という #NoEstimates の主張に同意しにくい理由: うまく運営すれば、その会話の中で アラインメント が生まれる
  • 運営の悪い会議への答えは、会議そのものを廃止することではない

約束の罠（Commitment Trap）とその回避方法

• #NoEstimates 運動が反応した最も深い機能不全は、見積もりが論理ではなく社会的圧力によって約束へと変換されること だった
• 関連する失敗モード: 作業をしない人たちがタイムラインを作ってチームに投げ込むと、不正確な見積もり + 数字への当事者意識のないチーム という最悪の組み合わせが生まれる
  • 現実が乖離したとき、誰の責任か分からないため、全員が全員を責める
  • 作業を実行する人たちが常に見積もりを所有すべきであり、他人に見積もりを押し付けるのは楽観主義ではなく 責任転嫁ゲームの前兆 である
• 納期への執着が定着すると、すべての会話が「どうやって納期に間に合わせるか？」へと収束し、そもそも正しいものを作っているのか という問いが視界から消える
• ほとんどの組織が混同している 3 つを分ける必要がある:
  1. 見積もり（Estimate）: 現在の不確実性レベルにおける確率的予測であり、レンジと前提の明示的な表明を伴う必要がある
     • 例: 「要件変更がなく、次の金曜日までに API に関する質問への回答を得られる前提なら、4〜6 週間と見ています」
  2. 計画（Plan）: 結果ではなく プロセスに対する約束
     • 例: 「2 週間作業した後に進捗をレビューし、更新された予測を提示する」
  3. 約束（Commitment）: 結果を伴う約束であり、円錐が十分に狭まったときにのみ、まれに慎重に行うべきもの
     • 初期コンセプト段階での約束は大胆さではなく 無謀さ である
     • 約束を強いられたときは、タイムラインではなく 優先順位への約束 を試み、それも無理なら 信頼度レベルを約束の一部 として含める
• 見積もりを口にした瞬間から約束として扱う組織慣行こそが機能不全の根源
  • #NoEstimates の政治的解決策（そもそも数字を言わない）は理解できるが、その代償として組織は資源配分・依存関係の順序付け・外部ステークホルダーとの率直な対話能力を失う
• より良い解決策は、円錐を教え、ステークホルダーを教育し、数字を出すたびに見積もりと約束の違いを明示すること
  • 見積もり拒否より難しく時間もかかるが、信頼が壊れうる状況を避けるのではなく、信頼を築く ことにつながる

良い見積もり実践法

• 遅らせて見積もる: 円錐は学習を通じてしか狭まらないため、スパイクの実施・探索的コーディング・統合先チームとの会話を先に進める
  • 意味のある数字を出せるだけの学習がないうちに数字を求める圧力には抵抗すべき
• 着手前の過剰な分解を避ける: 不確実性に直面すると作業をさらに小さく砕きたくなるが、十分に細かく分解しても信頼できる見積もりが得られるとは限らない
  • 精巧な事前計画は 硬直化 し、現実を反映しなくなった後もチームがそれにしがみつく原因となり、結果として乖離はさらに混乱を招く
  • 調整しやすいシンプルな計画 から始めるべきだ
• 点見積もりではなくレンジを示す: 「3〜5 週間」は「4 週間」より正直でありながら、実行可能性はほぼ同じ
  • 単一の数字しか許されないならレンジの中央値を出し、それが中央値であることを伝える
  • ステークホルダーと 不確実性の円錐を使うことに合意 し、見積もりを伝えるたびに参照する
• 前提を可視化する: 見積もりは前提の質に依存するため、スコープ変更がない前提・特定の技術的アプローチを採る前提・別チームが特定日までに引き渡す前提などを明示する
  • 頭の中にしかない前提は、最悪のタイミングで表面化する 誤解 になる
• 精度は追跡するが、罰しない: 目的は非難ではなく補正（calibration）
  • 6 か月間一緒に見積もり、その精度をレビューしたチームは、どこで体系的に過大見積もり・過小見積もりをしているかについての 共有感覚 を育てる
  • 不正確な見積もりを罰すると、チームは防御的に見積もりを膨らませるようになり、膨らませた見積もりは正直だが不確実な見積もりより役に立たない
  • Complex 領域での外れた見積もりは性格上の欠陥ではなく、領域の特性 である
• 8 を超えたら分割する: フィボナッチで 13 や 21 のストーリーは、ほぼ常にまだ表面化していない隠れた複雑さを含んでいる
  • 分割という行為は、実際に何を分かっていて何を分かっていないのかを明確に表現することを強制する
  • しばしば、3 つのサブストーリーのうち 2 つは小さく、1 つに不確実性が集中している ことが分かる

両陣営にとって不都合な真実

• 見積もりは計算ではなく コミュニケーションの一形態 であり、その目的は未来予測ではなく、不確実性の下での 調整と意思決定支援 にある
• 見積もりの失敗モードはランダムではなく 体系的: 早すぎる見積もり、レンジを点として扱うこと、見積もりを約束として扱うこと、不確実性の円錐における認識論的な位置を無視すること、実行者に見積もりを押し付けること
• Dalmijn がいう 複雑な作業見積もりの誤謬（Complex Work Estimation Fallacy）: より頻繁に見積もり、プロセスを改善し、より長く一緒に働けば、やがて正確な見積もりができるようになるという信念
  • Complex 領域における見積もり精度の限界はチーム成熟度の関数ではなく、領域そのものの関数 である
  • 改善はできても正確にはならず、この 2 つを混同すると、組織は本質的にチームの制御外にあることについてチームを罰することになる
• 見積もり拒否は 調整ゲームからの離脱 にすぎない
  • 完全に独立して運営でき、継続的デプロイができ、外部への約束が不要なチームなら可能だが、ほとんどのキャリアではそうした文脈にいない
• 選択肢は「悪い見積もり」対「見積もりなし」ではなく、無意識で低品質な見積もり（組織がどうせあなた抜きでも作る見積もり）対 明示的で謙虚で、レンジベースで、前提が見える見積もり である
• 作業見積もりが Complex 領域にある以上、複雑性マインドセット で向き合う必要がある: 探索し、観察し、対応し、見積もり、追跡し、補正することの反復
• 円錐は待っていれば狭まるのではなく、学習によって狭まる