■ 1. 概要と背景
- ソフトウェア工数見積もりは40年以上研究されてきた古いテーマだが、現場で流布する「常識」の多くは一次資料まで遡ると実証根拠が確認できない
- 確率分布を前提とした見積もり研究は、確率分布が原理的に書けない領域から来る大幅超過には対応していない
- 見積もりが大幅に外れる事例の多くは、見積もり研究が前提としてきた範囲の外側で起きている
■ 2. 見積もり手法の分類
- エキスパート判断系:
- 直感見積もり、アナロジーベース見積もり、Wideband Delphi、Planning Poker、PERT 3点見積もりで構成される
- 現場で最も広く使われており、Jørgensenの系統的レビューでは形式モデルと精度差が系統的に出ない
- 形式モデル系（パラメトリック）:
- COCOMO、COCOMO II、SLIM、Function Point、COSMIC Function Point、Use Case Points、商用モデル（SEER-SEM等）で構成される
- 入力パラメータと回帰式で工数を算出する
- 機械学習ベース（LLM以前）:
- 回帰木/Random Forest、Case-Based Reasoning、浅層ニューラルネットワーク、Deep-SE（LSTM+RHN）で構成される
- 確率的見積もり / フロー計測系:
- モンテカルロシミュレーション、Evidence Based Scheduling、スループット / サイクルタイムベース予測、参照クラス予測法、ベイズ推定、#NoEstimatesで構成される
- LLMベース:
- GPT2SP、Few-shot prompting + Search-based最適化、比較学習、マルチエージェント合議、Embeddingベースで構成される
- 見積もり単位の並立:
- KLOC、Function Point、ストーリーポイント、サイクルタイム、スループット等が流派ごとに並立している
- ストーリーポイントの命名者Jeffries自身が2019年に後悔を表明している
- 手法・単位が多数並立しているにもかかわらず、「特定の手法がエキスパート判断を系統的に上回る」証拠は集計結果として出ていない（Jørgensen 2007）
■ 3. 見積もりが外れ続ける理由
- コスト超過の分布はガウス分布ではなくべき乗則分布に従う:
- 5,392件分析（Flyvbjerg 2022）で18%のプロジェクトが50%以上超過、その平均超過率は447%
- 「Double Whammy（2013）」は1,471件のICT累積分布に2つの転換点を見出し、第2転換点以降を「Black Swan Blindness」と命名した
- 超過の発生源は「分布の前提に入っていない事象」であり、確率分布が原理的に書けない「深い不確実性（Deep Uncertainty）」の領域に属する
- Cynefin frameworkは、因果関係が事前に分からない「Complex」領域および秩序が存在しない「Chaotic」領域では予測そのものが意味を持たないと論じる
- 列挙できる不確実性と列挙できない不確実性の区別:
- 列挙できる不確実性: 事前に事象を挙げられ確率を付与できる。見積もりが対応できるのはこの層のみ
- 列挙できない不確実性: 規制変更、外部API廃止、市場急変、組織方針転換等、見積もり時点で想定リストに入らない事象
- コンティンジェンシーバッファとマネジメントバッファは別建てで計上する必要がある:
- コンティンジェンシーバッファ: 列挙できる不確実性の予測誤差を吸収する予備
- マネジメントバッファ: 列挙できない事象に備える独立した予算枠
- 計画錯誤、アンカリング、戦略的虚偽表明、スコープクリープ等は研究が扱ってきた誤差要因だが、447%超過の発生源にはならない
■ 4. 古典の「常識」の実証検証
- 不確実性のコーン:
- McConnell（2006）が広く流布させた「プロジェクト初期±4倍の幅が進行に伴い自動的に収束する」という経験則
- 一次資料を辿ると収束を支える経験データは存在しない
- Bossavit（2015）がBoehmの原典まで遡り、1981年の図は経験データではなく主観的スケッチであることを示した
- Rothmanの現場データでは、小さい仕事が大きい仕事と同等かそれ以上に外れることを報告している
- 形式モデル系（COCOMO、SLIM、Function Point）:
- Jørgensen（2007）の系統的レビューにより、形式モデルがエキスパート判断を系統的に上回ったとは言えないと結論された
- 「パラメトリックモデルを導入すれば精度が系統的に上がる」という前提は研究集計で支持されない
- Chaos Report:
- 「ITプロジェクトの大半が失敗する」「平均コスト超過189%」という数字は方法論的根拠を欠く
- サンプリングが失敗プロジェクトに偏っている疑いがあり、他の独立調査の平均30〜40%と桁が違う
■ 5. エキスパート判断の系統的バイアス
- 順序効果（Jørgensen & Halkjelsvik 2019）:
- 似たサイズのタスクが続くと後の見積もりが大きい方に引っ張られるコントラスト効果が生じる
- サイズが大きく異なるタスクが並ぶと前の値に引きずられるアシミレーション効果が生じる
- 大タスクを小タスクの直後に見積もると平均24%過小評価、小タスクを大タスクの直後に見積もると平均25%過大評価される
- 熟練度では抜けられない（スキルレベルで統計的差異なし）
- Planning Pokerセッションでは大小ストーリーを混ぜず、サイズ帯ごとにバッチ化することが対策となる
- 見積もりの加算性問題（Halkjelsvik & Jørgensen 2022）:
- 加算が数学的に成立するのは期待値（平均値）のみ
- 開発者が「典型的にはどれくらいか」と答えるのは中央値・最頻値に近く、合計すると系統的に過小になる
- WBS分解＋合計は過小見積もりに偏る数学的な構造を持つ
- モンテカルロシミュレーションは分布の畳み込みを取ることでこの問題を回避する
- MMRE（平均絶対相対誤差）の適切性問題（Jørgensen et al. 2022）:
- MMREは最頻値を出すモデルだけを有利に評価する特性を持つ
- 各モデルが分布のどの点を狙っているかが揃っていなければ比較結果は数学的に無意味になる
- 開発者は最頻値を答え、計画担当者は中央値で資源配分し、モデルは平均値を出し、評価はMMREで行うという不整合が発生している
■ 6. 古典に代わる潮流
- 確率的見積もり（スループットベース予測）:
- 過去スループット分布をモンテカルロ法で外挿し「85%の確率でN営業日以内に完了」等の確率付き予測を返す
- Evidence Based Scheduling（Spolsky 2007）、Actionable Agile Metrics（Vacanti 2015）、Forecasting and Simulating Software Development Projects（Magennis 2011）が代表的
- コーンの収束過程に依存せず、COCOMOのようなパラメータチューニングも不要
- 限界: 過去スループットが外挿の根拠であるため、チーム構成・技術スタック・要件性質が変わると適用できない
- 参照クラス予測法（Flyvbjerg 2008）:
- 内部視点の見積もりを類似プロジェクト群の実績分布（外部視点）で補正する
- 元はインフラ建設の巨大プロジェクト向けに開発された手法
- 1,471件のITプロジェクト集計（HBR 2011）で平均コスト超過27%、6件に1件が200%超過のブラックスワンを報告
- #NoEstimates運動:
- Zuill、Duarte、Holubらが推進した「タスク単位の見積もりは推測に過ぎず害が大きい」という立場
- Duarte（中道）: ストーリーポイントをやめ最近のスループットだけで予測する
- Holub（過激）: 見積もりに使う時間で実装すべきと論じる
- 予測そのものを否定しているわけではなく、タスク単位で見積もり数値を生成する活動を否定している
- Rothmanの整理:
- 見積もりの行為は有用だが見積もり値はそうでもない（estimation useful, estimates not so much）
- 計画は常に必要だが見積もりが必要なのは「学びを得る / 期日合意を要する場面」だけ
- 計画と見積もりは別の活動として区別する
■ 7. 見積もりの用途区分
- 見積もりの用途ごとに要求される精度、単一値か分布か、責任の所在が異なる:
- 契約・予算化: 発注側・受注側間の金額確定。単一値が要求され、参照クラス分布での補正を組み合わせる
- コミットメント: ステークホルダーへの宣言。形式上は単一値だが内部では信頼区間上限を変換する運用もある
- 計画立案: 分布で扱える領域だが現場では単一値に置き換わることが多い
- 進捗予測: スループットベース予測が主に扱う用途
- 意思決定支援: 桁感を掴む場合は単一値、リスク評価は分布
- 学習・対話: 数値より過程に価値がある
- #NoEstimatesが否定しているのは主に計画立案用途で生成されるタスク単位の単一値見積もりであり、進捗予測の分布や対話用途の見積もり過程は否定の対象ではない
- 用途を混ぜると系統バイアスが発生する:
- 契約用途の保守値で進捗予測すると常に余裕がありすぎる
- 計画立案の最頻値で契約すると常に超過する
■ 8. 達成率指標とライトサイジング
- 計画ポイントに対する実績ポイントの達成率を計画予測可能性の指標にする運用は、計画立案用途の見積もり値を進捗予測用途の指標に流用する典型例となる
- 達成率を歪める要因:
- ゲーミング: 見積もりインフレ、ユーザーストーリー以外の項目へのポイント付与
- 計画値への主観混入: 直前イテレーションの結果に応じてストレッチ目標を上下させる調整
- Yesterday's Weather:
- 直近3〜4イテレーションのスループットのみを使う簡易予測
- モンテカルロ予測の中央値だけを取った簡易版にあたる
- ライトサイジング（Right-sizing）:
- 作業項目を「N日以内に終わるサイズ」に分割してサイズ分布の上裾を切り落とす運用
- サイズのばらつきが予測精度を下げる主要因であり、均一化することでモンテカルロ予測とSLEの予測幅が安定する
- ストーリーポイントを置き換える運用でもあり、「揃った個数=スループット」として扱う
■ 9. LLMとAIコーディングの影響
- LLM見積もり研究の現状:
- GPT2SP（IEEE TSE 2023）はDeep-SE比6〜47%の精度向上を報告したが、Tawosiらの再現研究（2022）でMAE計算バグによる精度水増しが指摘された
- 再現研究では、GPT2SPが中央値ベースラインを統計的有意に上回るのは16プロジェクト中3件のみで、効果量も無視できる程度から小程度にとどまる
- Çalıklıら（FSE 2025）はGPT-4等が人間と同じアンカリングバイアスを示すことを実験で確認した
- プロジェクト横断での汎化の壁は依然として残っている
- 「新SOTA論文が出る→再現研究で結果が覆る」という流れが繰り返されている
- AIコーディング時代の見積もり前提の変化:
- METR（2025）のRCTにより、AI使用下で開発者は24%の高速化を予測したが、実測では完了時間が19%増加した
- 見積もりの方向性そのものが予測と逆転した事例であり、外部参照クラスで補正できない状況を意味する
- Microsoft/Accenture（2024）やGoogle（2024）のRCTでは26%・21%の効率改善が報告されており、AIの効果は対象集団・指標・タスク性質で方向が変わる
- Frontiers AI（2026）は既存手法（COCOMO、ストーリーポイント等）が「人間のコーディング労力が支配的」という前提に乗っており、LLM支援開発下では工数の内訳がプロンプト設計・生成結果の検証・統合・往復に移ると主張する
- 同論文はHybrid Intelligence Effortとして5次元（LLMの推論複雑性、コンテキスト完全性、コード変換の影響、反復推論サイクル、人間の監督工数）での見積もり枠組みを提案しているが、概念枠組みの段階にとどまる
- AI導入の前後でサイクルタイム分布の母集団が変わるため、スループットベース予測の過去分布外挿は成立しない
■ 10. エビデンスの非対称と見積もりの組み立て方
- エビデンスの非対称:
- 古典が支持されないことは示せても、代替が古典より優れていることまでは同じ密度で示せていない
- 「古典に根拠なし」を示す作業は一次資料の追跡で可能だが、「代替が古典より良い」を示すにはRCT級の介入実験が必要で現実的に困難
- 見積もりを依頼するときに代表値を指定する:
- 契約・予算化用途は平均値か信頼区間上限、計画立案用途は最頻値、進捗予測用途は分布を指定する
- 指定がなければ開発者は無意識に最頻値を答え、集計・評価・契約に系統バイアスが発生する
- 参照クラスで内部見積もりを補正する:
- 同業界・同規模・同技術スタックの類似プロジェクトを10件以上集める
- 各プロジェクトの超過率分布を作成し、中央値・90パーセンタイル・最悪値を内部見積もりに掛けた3点を併記する
- サブタスクの点見積もりを単純合計することは加算性問題により避ける
- 判断見積もりの順序を設計する:
- サイズ帯ごとにバッチ化する
- 相対見積もりのベースラインは中〜やや大のものを選ぶ
- 順序効果は「気をつける」では避けられないため運用設計で吸収する
- バッファは二段で持つ:
- コンティンジェンシーバッファ: 参照クラス分布の中央値〜90パーセンタイルの超過率を基準に算定する
- マネジメントバッファ: 参照クラスの最悪値またはFlyvbjergのP90超過を基準に算定し、別費目で計上する
- 不確実性のコーンを信じて「期間が進めば精度が自動的に上がる」と仮定してバッファを縮める運用は避ける
- 列挙できない事象は見積もりの仕事ではない:
- Walking Skeleton: プロジェクト初期に最薄のエンドツーエンド実装を作り想定外挙動を引き出す
- MVP / A/Bテスト: 仮説検証だけを目的にした小さな実装を本番環境に出す
- スパイク: 不明領域に期限を切った調査タスクを置き未知を既知化する
- これらはCynefinの「probe → sense → respond」循環に対応し、見積もりサイクルの外側に置く別系統の活動となる
- AI導入の前後でサイクルタイム分布は別物として扱う:
- チケットにAI使用フラグを立て、AI導入前後で記録を分けてモンテカルロシミュレーションや参照クラスに混ぜない
- AI後のサイクルタイムが30件溜まるまで予測幅を広める
- 参照クラス予測法もAI導入前後で別建てにする