ソフトウェアの見積もり
https://gyazo.com/9db61943d68ea02b4b100ef92ea0f111
ソフトウェアの工数見積もりは40年以上にわたって研究されてきた古いテーマで、入門書も実践書も数多い。だが現場で広く流布する「常識」の多くは、一次資料まで遡ると実証根拠が確認できない。確率分布が書ける前提で精度を磨いてきた見積もり研究は、確率分布が原理的に書けない領域から来る大幅超過には対応していない。見積もりが大幅に外れる事例の多くは、見積もり研究が前提としてきた範囲の外側で起きている。
ソフトウェア見積もりの手法はどこに分布しているか
見積もり手法は5系統に分かれる。それぞれの内部にも世代差や流派がある。
エキスパート判断系: 経験者の直感と類推で値を出す手法群。現場で最も多く使われており、Jørgensenの系統的レビューでは形式モデルと精度差が系統的に出ない比較対象として位置づけられる
直感見積もり（gut feel）: 単独の経験者が一人で値を出す。最古かつ最普及だが個人バイアスの影響を最も強く受ける
PERT 3点見積もり: 楽観値・最頻値・悲観値の加重平均を取る古典的手法。1950年代の米海軍由来
形式モデル系（パラメトリック）: 入力パラメータと回帰式で工数を算出する手法群
COCOMO (Boehm 1981): KLOCを入力に工数を回帰推定。Basic / Intermediate / Detailed の3レイヤ COCOMO II (Boehm 2000): オブジェクト指向・再利用・COTSを織り込んだ後継版 機械学習ベース（LLM以前）: 統計学習で見積もりを行う手法群
回帰木 / Random Forest: COCOMO/Desharnaisデータセットで多数の研究
Case-Based Reasoning: アナロジーベースの自動化。Shepperdの研究系統
Neural Network (浅層): 1990年代から繰り返し試みられている
Deep-SE (Choetkiertikul et al. 2019): LSTM+RHNでストーリーポイントを推定。LLM時代直前のSOTAとしてベンチマークに繰り返し使われる 確率的見積もり / フロー計測系: 分布で予測する手法群
モンテカルロシミュレーション: 過去スループットを乱数源にして完了確率を出す
ベイズ推定系: 事前分布を持って観測で更新する立場。Kruschke系の応用が散発的にある
LLMベース: 大規模言語モデルでストーリーポイントや工数を推定する手法群
GPT2SP (Fu & Tantithamthavorn 2023): GPT-2の最終層を回帰器に置き換えてストーリーポイントを推定 Few-shot prompting + Search-based最適化: Tawosi 2024が例示選択を探索最適化で行う手法 見積もりに使う「単位」も流派ごとに並立している。
KLOC (Kilo Lines of Code): COCOMO第一世代の単位。実装言語に依存する
Function Point: 機能の規模。実装に依存しないが計測コストが高い
Use Case Point: ユースケース記述から導出
Object Point / Application Point: COCOMO IIで導入された大粒度の規模指標
Ideal Days / Engineering Days: 理想日数。Ron Jeffriesが当初ストーリーポイントとして念頭に置いていたもの
ストーリーポイント: 相対的な作業量。命名者Jeffries自身が後悔を表明 T-shirt Size (S/M/L/XL): ストーリーポイントの更に粗い相対サイズ
Cycle Time / Lead Time: タスクが流れる時間。実測値であり見積もり値ではない点で他と異質
Throughput: 単位時間あたり完了アイテム数。Cycle Timeと対をなす
手法も単位もこれだけ並んでいるが、研究を集計しても この手法がエキスパート判断を系統的に上回る と言える証拠は出てきていない（Jørgensen 2007）。不確実性のコーンのような広く流布した経験則も一次資料まで遡ると経験データが見つからない（Bossavit 2015）。Transformerベースの新しいSOTA手法も再現研究では素朴な中央値ベースラインに対して統計的有意な精度差を示せていない（Tawosi 2022）。確立された手法が存在しないままの分野である。 古典の常識を検証する
見積もりが外れる原因はどこにあるのか、流通している古典の「常識」はどこまで実証されているのか、人間の判断見積もりにはどんな系統的歪みがあるのかを順に見ていく。
なぜ見積もりは外れ続けるか
実際のプロジェクトで大幅超過を引き起こす事象の多くは、見積もり時点で考慮対象に含まれていなかった事象である。
ここで起こり得る事象を事前に列挙でき、各事象に確率が付与できる場合（列挙できる不確実性）と、そもそも事象自体を事前に挙げられない場合（列挙できない不確実性）を分けておきたい。見積もりが対応できるのは前者だけである。前者の予測誤差を吸収するための予備費をコンティンジェンシーバッファ、後者の想定外事象に備える独立した予算枠をマネジメントバッファとして区別するのも、この層の違いに対応している。両者を混ぜると、想定外事象でバッファが枯渇したときに何の保険が機能しなかったのかを説明できなくなる。詳しい層別構造は ソフトウェア開発における不確実性 で扱う。 見積もりが大幅に外れる事象の多くは列挙できない不確実性の層から来る。規制変更、外部API廃止、市場の急変、技術スタックの想定外挙動、組織の方針転換、未知の脆弱性、ブラックスワン級の障害といった、見積もり時点で想定リストに入っていなかった事象である。
ところが見積もり研究の主流は、列挙できる層に閉じて組み立てられている。3点見積もり・モンテカルロシミュレーション・COCOMO・参照クラス予測法はいずれも、起こり得る事象が事前に列挙可能で各事象に確率が付与できる前提の上で精度を高めようとする手法だ。研究が扱ってきた誤差要因も、この列挙可能な範囲の内側に留まる。
これらは研究が扱ってきた誤差要因ではあるが、Flyvbjerg のべき乗則分布が示す447%超過の発生源にはならない。xx%のバッファを乗せれば吸収できる 種類の誤差ではない、ということだ。
精度の向上は、列挙可能な範囲の内側の問題でしかない。列挙できない事象が引き起こす超過は、ソフトウェア開発における不確実性 で挙げた露出・吸収・局所化・遅延に振り分ける必要がある。計画錯誤への対策をどれだけ磨いてもブラックスワンには届かない。マネジメントバッファを独立に持ち、想定外事象を probe で観測可能にする運用と組み合わせるしかない。 古典の「常識」は実証されているか
ソフトウェア見積もりの古典のうち、広く流布した3つの「常識」を取り上げる。不確実性のコーン、形式モデル（COCOMO・SLIM・Function Point）、Chaos Report の数字である。いずれも一次資料まで遡ると実証根拠が確認できない。
不確実性のコーン
McConnell自身は「Coneは自動的に狭まらない、狭めるのは見積もり活動そのものである」と注意を促していた。世間で流通している「プロジェクトが進めば自動的に見積もりが収束する」という解釈はMcConnellの主張ではなく、後続の引用過程で生まれたものである。The Leprechauns of Software Engineering (2015) Chapter 2 が、Boehmの原典まで参照文献を辿った結果、図を支える経験データが存在しないことを示した。Boehmが1981年の本に載せた図は経験データではなく主観的なスケッチで、後続文献が孫引きを繰り返すうちに「実証された普遍則」として扱われるようになった。著者の Laurent Bossavit はこれを telephone game（伝言ゲーム）と呼ぶ。 形式モデル系の古典
形式モデル研究の古典はCOCOMO単独ではなく、1970年代後半から1980年代前半にかけて提案された複数のモデルで構成される。研究を集計しても、形式モデルがエキスパート判断を系統的に上回ったとは言えない。
COCOMO (Boehm 1981): KLOCを入力に工数を回帰式で推定 経験豊富な専門家の判断は、よくチューニングされた回帰モデルより精度で劣らない。COCOMOのようなパラメトリックモデルを導入すれば見積もり精度が系統的に上がる、という前提は研究を集計しても支持されない。
Chaos Report の数字
Standish Group の Chaos Report が流布させた「ITプロジェクトの大半が失敗する」「平均コスト超過189%」という数字も、方法論的根拠を欠く。不確実性のコーン と同じ型の検証が完了している。
広く引用されてきた「権威ある数字」を一次資料まで遡る作業を経ると、根拠が見当たらない。不確実性のコーン、形式モデル、Chaos Report のいずれも同じ経過を辿っている。
エキスパート判断に実証されている系統的バイアス
エキスパート判断系はJørgensenの系統的レビューで形式モデルと精度差が出ない手法として位置づけられている。だがそのことは「エキスパート判断に系統的な歪みがない」を意味しない。判断見積もりの過程で実証されている系統的バイアスは複数あり、Planning Poker や WBS の順序設計に直接関わるものがある。
順序効果 (sequence effects)
Study A（同サイズ3タスク、362人）: 中央値100時間程度の似たサイズのタスクを順序ランダム化して見積もらせると、1番目→2番目で見積もり値が平均10%増加、2番目→3番目でさらに3%増加した。似たサイズが続くと見積もりが大きい方に引っ張られる contrast effect が支配する
Study B（大4・小5タスク混合、104人）: 大タスクを小タスクの直後に見積もると平均24%低くなり、小タスクを大タスクの直後に見積もると平均25%高くなった。最初の2タスクだけ取り出すと、大タスク後の小タスクは+57%、小タスク後の大タスクは-18%でさらに強い。サイズが大きく違うタスクが並ぶと前の値に引きずられる assimilation effect が支配する
熟練度では抜けられない: 自己評価の一般スキルでもタスク特化スキルでも、順序効果の大きさは統計的に変わらなかった。経験で意識的に補正できる種類のバイアスではない
実践的な含意がいくつか出ている。
過小見積もりリスクを抑える順序: 大タスクを小タスクの直後に見積もると assimilation で過小に引っ張られ、コスト超過の温床になる。大タスクを先に見積もる、または小タスクと混ぜずに見積もるのが対策になる
Planning Poker のセッション設計: 1セッションで大小のストーリーを混ぜて連続見積もりすると、混在順序のたびに assimilation バイアスが入る。サイズ帯ごとにバッチ化する、または大きいものから順に見積もる運用に意味がある
相対見積もりのベースライン選択: アジャイルの相対見積もりでベースライン（基準タスク）を選ぶ際、小さすぎるベースラインを採ると assimilation で大タスクが過小に評価され、大きすぎるベースラインだと逆に過大評価される。中〜やや大のベースラインが歪みを最小化する
除去ではなく被害最小化: 順序効果は除去できない。同サイズだけ並べれば contrast、サイズが違えば assimilation のいずれかが必ず働く。意識して被害が小さい順序を選ぶしかない
順序効果は研究設計の側にも返ってくる論点で、見積もり実験で順序をランダム化・カウンターバランスしないと結果が交絡する。先行のソフトウェア工学実験の多くがこの点を扱っていない。
見積もりの加算性問題 (summation fallacy)
数学的には、足し合わせて意味が保たれるのは 期待値（平均値） だけである。
平均値の合計 = 全体の平均値（成立する）
中央値や最頻値の合計 ≠ 全体の中央値・最頻値（右に歪んだ分布では合計の方が小さくなる）
90%信頼区間上限の合計 ≠ 全体の90%上限（合計の方がはるかに大きくなる）
楽観値・悲観値の合計 ≠ 全体の楽観値・悲観値
ソフトウェア開発タスクの実績時間分布は典型的に右に歪んでおり、中央値・最頻値より平均値が大きい。人が「典型的にはどれくらいかかるか」を聞かれて答えるのは中央値や最頻値に近い。それを足し合わせると、全体の平均値より系統的に小さい値が出る。WBS分解 + 合計 が過小見積もりに偏る数学的な構造である。
逆向きも成立する。3点見積もりの悲観値を出してそれを合計すれば全体の悲観値になる、という直感は数学的に間違いで、合計値は全体の悲観値よりはるかに大きい。PERT の加重平均（楽観・最頻・悲観の組み合わせ）にもこの問題が潜む。
Halkjelsvik らは2実験で確認している。学生78人のタイピングタスクと、経験あるソフトウェア開発者20人による5タスクの開発時間見積もりで、要素の合計と全体見積もりが一致しない非整合性が出る。経験者でも回避できない。
ここから運用上の論点が3つ出てくる。
WBS分解の前提を疑う: タスクを細かく分割すれば精度が上がるという直感は、要素見積もりが何を測っているかに依存する。中央値・最頻値を合計すれば過小に、信頼区間上限を合計すれば過大に偏る。分割の細かさを上げても、合計値のバイアスは消えない
加算性が成立するのは期待値だけ: 個別に「平均してどれくらいかかるか」を出してそれを合計するなら、全体の期待値に対応する見積もりが得られる。だが日常的に出される見積もりはほぼ常に中央値・最頻値で、人は自分が何を答えているか意識していない
確率的予測の数理的根拠: モンテカルロシミュレーションが分布から乱数を引いて合計するのは、まさにこの加算性問題を回避するためである。点見積もりの合計ではなく、分布の畳み込みを取れば全体分布の期待値・分布形状とも正しく出る
summation fallacy が示すのは、列挙できる範囲ですら点見積もりの合計は系統バイアスを免れないという事実である。加算性を保ちたければ、要素見積もりを平均値に揃えるか、確率的予測（次節）で分布の畳み込みを取るかしかない。確率的予測は手法選択の問題というより、加算性を保つために選ばれる選択肢でもある。
評価指標 (MMRE) の適切性問題
ソフトウェア工数見積もり研究で最も広く使われる誤差指標 MMRE（|act-est|/act の平均）は、Gneiting の proper scoring rule（適切な採点規則）理論を当てはめると、工数の実績分布が対数正規分布（右に歪んだ分布）で近似できる場合、最頻値の見積もりを出力するモデルだけがその期待値を最小化する。中央値を出す計画モデルも平均値を出す線形回帰や PERT 系も、MMRE で評価すると不当に悪い数値が出る。
ここから研究側の問題が出てくる。LLM・ML・エキスパート判断系を MMRE で比較する論文は大量にあるが、各モデルが分布のどの点を狙っているかが揃っていなければ比較結果は数学的に意味をなさず、最頻値を出すモデルが系統的に有利に見える。Tawosi らの GPT2SP 再現研究が指摘した MAE 計算のバグと評価指標の適切性問題は、同じ「LLM 見積もり研究の評価手続きの杜撰さ」という層に属する。さらに現場側でも、開発者は最頻値を答え、計画担当者は中央値で資源を割り当て、モデルは平均値を出し、評価は MMRE で行う、という不整合が普通に発生する。
Halkjelsvik & Jørgensen の summation fallacy が「点見積もりが分布のどの点なのかを意識しないと加算で系統バイアスが出る」と示したのに対し、MMRE 論文は「評価指標も同じ理由で系統バイアスを生む」と示している。点見積もりが分布のどの点を指しているのかを明示しないと、見積もりも評価も両方が歪む。2022年の Jørgensen らはこれを中核的な問題として論じている。
古典に代わる流れ
古典の常識が支えを失った2010年代以降、確率分布で見積もる運用、見積もりを廃する運動、見積もりという語の用途分け、ライトサイジングといった代替の動きが並行して進んだ。
確率的見積もりは何を解決したか／しなかったか
古典が「単一値の見積もり」を扱っていたのに対し、2010年代には分布として見積もる運用が広がった。スループット（一定期間あたり完了アイテム数）の実測値からモンテカルロシミュレーションで「いつ終わるか」の分布を生成する手法である。
この手法は古典への別経路の代替になっている。不確実性のコーンが個別プロジェクトの「進行に伴う収束」を主張していたのに対し、スループットベース予測は過去実績の分布をそのまま外挿する。プロジェクト固有の収束過程に頼らず、十分なサンプルがあれば即座に予測区間が出る。COCOMOのようなパラメータチューニングも不要である。コーンの主張そのものへの反証は Bossavit と Rothman の批判が担っており、スループットベース予測はコーンの収束過程に依存しない予測手段が成立するという形で側面から支える位置にある。
ただし限界もはっきりしている。「分布の根拠」はあくまで過去のスループット観測である。チーム構成・技術スタック・要件性質が変わると過去分布は外挿できない。組織の方針転換や障害対応の混入を吸収する仕組みは別途必要になる。これはコンティンジェンシーバッファとマネジメントバッファの区別（前述）と直接対応する話で、確率的予測が応えられるのはコンティンジェンシー側だけである。分布で見積もったからといって不確実性が消えるわけではない。
外部参照クラスからの矯正を提案する研究もある。参照クラス予測法 (2008)は、自プロジェクトの内部視点からの見積もりに対し、類似プロジェクト群の実績分布（外部視点）でアンカリングする手法で、もともとは Bent Flyvbjerg が交通インフラの巨大プロジェクト向けに開発した。HBR 2011のWhy Your IT Project May Be Riskier Than You Thinkは1,471件のITプロジェクトを集計し、平均コスト超過27%、6件に1件が200%超過・スケジュール70%超過のブラックスワンだと報告した。裾が重い分布をモデル前提に置けという主張で、Kahneman流の外部視点をソフトウェア開発に適用したものだ。 確率的見積もりの広がりと並行して、別方向の動きとして#NoEstimates運動がある。Woody Zuill、Vasco Duarte、Allen Holubらが推進した立場で、タスク単位の見積もりは結局推測でしかなく、その推測に基づく計画は害が大きい という主張である。推進側の主要テキストにも主張の幅がある。 主張をきちんと見ると、予測まで否定しているわけではない。スループットベース予測は #NoEstimates 陣営の中心人物（DuarteもVacantiも近い圏域にいる）が推している。否定しているのは タスク単位で見積もり数値を生成する活動 であり、組織の予算・契約・ロードマップを否定しているわけでもない。 予測も結局は見積もりの一種だ
契約・予算の現実を無視している
小規模プロダクトには通用しても固定価格契約下では成立しない
両者は「見積もり」という語に込めるものがそもそも違うので、語の意味合わせをしないと議論がすれ違う。
実際に有用なのは、#NoEstimates の問題提起そのものより、タスク見積もりとプロジェクト予測は別のことをしている 計画と見積もりは別のことをしている 用途が違えば形式も違う という気付きの方である。次節でこの用途区分そのものを掘り下げる。
見積もりの用途を分ける
「見積もり」という語の意味を整理するには、見積もりが使われる用途を分ける必要がある。用途ごとに、要求される精度も、単一値か分布かの選択も、誰に対して責任を負うかも違う。以降の節で扱う達成率指標・ライトサイジング・LLM 手法評価・古典に代わる見積もりの組み立ても、すべてこの用途区分の上で意味が変わる。
契約・予算化: 発注側・受注側がやり取りする金額確定の場。単一値が要求される。Flyvbjerg の参照クラス予測法はここに参照クラス分布からの補正を組み合わせる
コミットメント: ステークホルダーへの いつまでに何を出す の宣言。形式上は単一値だが、内部では信頼区間の上限値を単一値に変換する運用もある（SpolskyのEBSが出すのはまさにこの形） 計画立案: 分布で扱える領域だが、現場ではタスク単位の単一値見積もりに置き換わることが多い
進捗予測: スループットベース予測が主に扱う用途。Vacanti と Magennis が最適化した領域
意思決定支援: 桁感を掴むなら単一値、リスク評価をするなら分布
学習・対話: Rothman の estimation useful, estimates not so much が指す場所。数値より過程に価値がある
この区分で読み直すと、#NoEstimates が主に否定しているのは計画立案用途で生成されるタスク単位の単一値見積もりであり、進捗予測用途の分布や対話用途の見積もり過程は否定の対象になっていない。Duarte の中道寄りの主張はこの範囲に収まる。Holub の過激寄りの立場は契約用途の単一値にも踏み込んでおり、Duarte 系より否定の範囲が広い。批判側の InfoQ 書評が 予測も結局は見積もりの一種だ と返したのは、用途の区別なしに「見積もり」を一括りにした反論である。
同じ「見積もり」という語の下で何を測っているかが用途ごとに変わる。契約用途の単一値は信頼区間上限の保守的な値、進捗予測の分布はモンテカルロシミュレーションから出る確率付き区間、計画立案の単一値は現場の最頻値、学習・対話の見積もり過程は数値そのものに用がない。これを混ぜると、契約用途の保守値で進捗予測すると常に余裕がありすぎ、計画立案の最頻値で契約すると常に超過する。次節以降で扱う達成率指標とライトサイジングも、計画立案用途と進捗予測用途は別のことをしている という区分の上に乗っている。
達成率指標とライトサイジング
前節の用途区分に立つと、計画ポイントに対する実績ポイントの達成率 を計画予測可能性の指標にする運用は、計画立案用途の見積もり値を進捗予測用途の指標に流用する典型例になる。Dave Nicolette Software Development Metrics (Manning, 2015) の5章はこの運用が抱える歪みを具体例で示した。Nicolette が原書で挙げた12イテレーションの例では、ストレッチ目標による計画 の達成率が68.8%だったのに対し、同じ実績を 直近3イテレーションの平均 で予測した場合は89.9%になる。デリバリ実績は同じで、ステークホルダーに伝える期待値だけが違う。ゲーミング（見積もりインフレ、ユーザーストーリーでない項目へのポイント付与）と計画値への主観混入（直前イテレーションの結果に応じてストレッチ目標を上下させる調整）が達成率を歪め、外れた見積もりへの罰を避ける動きが起きると実際のデリバリ問題が見えにくくなる。 予測は見積もりと実績の比較を使わず、過去のスループット観測から将来の量を返す。Nicolette が紹介する Yesterday's Weather（昨日の天気）は、直近3〜4イテレーションのスループットだけを使う、対象期間を短期に限定する、休暇など一時的な変動要因を別建てで控除する、という運用で、Magennis / Vacanti のモンテカルロ予測（過去スループット分布から乱数を引いて確率付き区間を返す）の中央値だけを取った簡易版にあたる。SpolskyのEBSも同系統である。 予測精度を下げる要因として重みが大きいのが、作業項目のサイズばらつきである。同じユーザーストーリーでも、銀行口座リストの表示と再突入時の機体安定化制御では必要な工数が大きく異なる。Nicolette の5章では、20ストーリー300ポイントを大きさバラバラのまま流したケースと、30ストーリーに分割して同サイズに近づけたケースを比較し、後者で 次反復で完了する数 の予測精度が上がることを示している。N日以内に終わるサイズに分割する 運用ルールを Vacanti / Singh らがライトサイジング (Right-sizing) として体系化した。サイズ分布の上裾を切り落とすことで、モンテカルロ予測とSLE（サービスレベル期待値）の予測幅が安定する。ライトサイジングはストーリーポイントを置き換える運用でもあり、サイズ見積もり × 個数 でベロシティを算出する代わりに 右サイズに揃った個数 = スループット に切り替える。これは タスク単位の数値見積もりを減らして、観測されたフローで予測する の実装である。実装手順・適用条件・失敗パターンとステアリング系メトリクスとの関係は ソフトウェア開発メトリクス で扱う。 LLMとAIコーディングは見積もりにどう関係するか
LLMの登場は見積もりに二方向から影響している。LLMを見積もり手法そのものに使う研究の系統と、AIコーディングが見積もりの前提条件を変える系統である。前者は2022年以降のTransformer/LLM見積もり研究の流れで、後者は2024年以降の AI コーディング日常化に伴う変化として現れている。
LLM見積もり研究は本当にSOTAなのか
TransformerベースのSOTA手法は、issue タイトル+本文を見て中央値を返すだけのベースラインに対して、統計的有意な精度差を示せていなかった。
論争史を踏まえて読むと、新SOTA論文が出る → 再現研究で結果が覆る という流れが繰り返されている領域である。GPT2SPがTawosiの再現で精度の水増しを指摘された構造は、現在のマルチエージェント手法や Gemini embedding 系手法（GemSP, 2026）にも当てはまる可能性がある。SOTA主張を読むときは毎回以下を確認する必要がある。 本当にベースライン（中央値等）を統計的有意に上回ったか
効果量はどの程度か（無視できる程度から小程度なら実用上の意味は薄い）
プロジェクト内かプロジェクト横断か（同一プロジェクト内でしか効かない手法は実用性が落ちる）
AIコーディング時代に見積もりの前提はどう変わったか
ここまでの議論はすべて「人間がコードを書く」前提の上に乗っていた。AIコーディングが日常化した結果、見積もりという行為の前提条件が二箇所で変わった。自分の作業時間を見積もる能力 と、工数という見積もり対象そのものの内訳 である。
見積もり研究の文脈で受け止めるべきは、体感が間違っていた という生産性側の含意ではない。実測が遅くなっている状況下でも、本人は自分が速くなったと見積もり続けた、という点である。計画錯誤が古典的に扱ってきたのは「楽観バイアスで作業時間を過小評価する」という一方向の歪みだった。METR が観測したのは、自分のリポジトリで自分の作業をしている熟練者が、自分の作業時間を見積もる、すなわち内部視点が最も有利に働くはずの条件下で、見積もりと実測の方向が一致しない事例である。
ただし見積もりの議論として残るのは、どの方向に外れるかが事前に分からない という事実の方である。古典的な計画錯誤なら外部視点（類似プロジェクトの実績分布）でアンカリングできる。だが AI 使用下では、誰のホームグラウンドかで効果の方向まで変わる。外部視点の参照クラスを集めようとしても、自分のチームと同質の参照クラスが過去に存在しない。確率的見積もりが依存していた 過去のスループット分布をそのまま外挿する という運用も、AI 導入の前後でスループット分布の母集団が変わるなら成り立たない。これはスループットベースの予測手法そのものを否定するわけではないが、AI 導入直後の数四半期は過去分布を予測根拠として使えないという意味になる。
LLM の推論複雑性: モデルが要するトークン数・推論ステップ数
コンテキスト・情報の完全性: 与えられた情報がタスク完遂に足りているか
コード変換の影響: 生成コードを既存コードベースに統合する手間
反復推論サイクル: プロンプト→検証→再プロンプトの往復回数
人間の監督工数: レビュー・承認・修正に要する人間の時間
この問題提起はまだ概念枠組みの段階で、実プロジェクトデータでの較正は今後の作業として残っている。それでも、見積もる単位が何を測っていたかという前提の再考が必要だという問題提起そのものは残る。ストーリーポイントの 相対的な作業量の比較 という定義は、LLM が同じユーザーストーリーを30秒で実装するケースと3時間検証で苦戦するケースを混在させた途端、何を測っているのか説明できなくなる。COCOMO の KLOC ベースの工数推定式も、生成コード行数が人間労力に対応しなくなった時点で参照値として機能しない。
ストーリーポイントの妥当性についてはAI登場以前から疑念が出ていた。批判は2方向から来ている。
命名者本人の後悔: Ron Jeffries "Story Points Revisited"（2019）で I may have invented story points, and if I did, I'm sorry now（ストーリーポイントを発明したのは自分かもしれない、そうだとしたら今は後悔している）と書いた。ストーリーポイントは元々 ideal days の言い換えに過ぎなかったのが、velocity比較やチーム評価といった本来意図しない用途に拡張されてしまったという回顧である 命名者本人の後悔と現場側の魔術的思考批判は同じ方向を向いている。Frontiers 2026のLLM時代の批判は、同じ流れの中に そもそも前提が変わった という論点を追加している。
AI 導入は両層に同時に影響する。列挙できる層ではサイクルタイム分布の母集団変化として、また プロンプトインジェクション エージェントの暴走 生成コードの既知の脆弱性パターン といった既知化されたリスクの増加として作用する。列挙できない層では 訓練データに含まれた未知の挙動 モデル更新で突然変わる出力傾向 のような、事前に列挙し得ない事象として作用する。後者の比率がどの程度かは現時点で測れていないが、見積もり対象の前提が変わった上で、列挙できる層と列挙できない層の双方に AI 由来の新規要因が加わっている。
エビデンスの非対称と見積もりの組み立て方
古典が支持されないことは示せても、代替が古典より優れていることまでは同じ密度で示せていない。この非対称を確認した上で、現時点で選べる組み立て方を並べる。
代替手法のエビデンスはどこまで揃っているか
ここまで扱ってきたのは、古典の常識に実証根拠があるか、広く使われている手法に系統バイアスがあるか、という問いだった。古典が支持されない方向の証拠は集まっている。一方、参照クラス予測、確率的予測、コンティンジェンシーバッファとマネジメントバッファの二段構えといった代替手法の有効性となると、同じ密度の証拠は揃っていない。
#NoEstimates の有効性データ: Rothman の概念整理が指す 見積もりなしで価値を出せる場面が存在する という主張は、事例報告ベースの議論で、見積もりを廃止したチームの方が予測可能性が上がった という体系的データセットは存在しない。InfoQ 書評の批判もこの点を突いている コンティンジェンシーバッファとマネジメントバッファの二段構え: PMBOK 系の指針として広く流布しているが、分布のどのパーセンタイルで二段の線を引くか を実プロジェクトデータで較正する研究は限定的である。Flyvbjerg の参照クラス分布と Taleb のブラックスワン的考察を継ぎ合わせた構成で、実証データの裏付けは薄い
AI コーディング時代の見積もり: METR 2025 は 16人・246タスクの観察研究で、本人達も この結果が一般化できると主張するつもりはない と limitations 節で明示している。Frontiers 2026 は概念枠組みで実プロジェクトデータでの較正は今後の作業。AI 時代の見積もり前提変化を語る根拠としては、現時点では仮説段階にある
以降で示す代替手法は 古典が支持されない という知見の上で選ばれる選択肢であって、古典より精度が高いことが実証された手法 ではない。手法ごとに確度の差がある。
見積もりをどう組み立てるか
見積もりを依頼するときに代表値を指定する
開発者に見積もり値を尋ねるとき、これは中央値で答えてほしい 平均値で答えてほしい 90%の確率で収まる上限で答えてほしい のように、どの代表値を求めているのかを必ず明示する。指定の選び方は用途で決まる。
契約・予算化用途: 平均値か信頼区間上限（保守的に出したい）
計画立案用途: 最頻値（典型的なケースを想定）
進捗予測用途: 単一値ではなく分布そのものを返してもらう
学習・対話用途: 数値そのものに用がないので指定不要
「100時間」という同一の数字が、最頻値・中央値・平均値・信頼区間上限のどれを指すかで意味が変わる。Halkjelsvik & Jørgensen は加算が成立するのは平均値だけで、人が日常的に答える最頻値・中央値を合計すると右に歪んだ分布の下で系統的に過小な合計値が出ると示した。同じ著者群の MMRE 論文は、評価指標もまた最頻値モデルだけを有利に評価すると示した。両論文に通底するのは、点見積もりが分布のどの点を指しているかを明示しないと、加算でも評価でも系統バイアスが入るという主張である。指定がなければ、開発者は無意識に最頻値を答え、その値が集計・評価・契約に流れて系統バイアスを発生させる。古典の COCOMO や PERT がどの代表値を出していたかを後から特定するのが難しいのは、この区別が当時の文献に存在しなかったためでもある。
参照クラスで内部見積もりを補正する
スコープを約束する予測型プロジェクトでは、コストの単一値が避けられない。エキスパート判断と形式モデルの精度差が系統的でない（Jørgensen 2007）以上、どちらが精度が高いか を議論しても得るものは少ない。代わりに、内部視点で出した自プロジェクトの見積もり値を、外部の類似プロジェクトの実績分布で補正する。具体的な手順は以下になる。
1. 参照クラスを集める: 同業界・同規模・同技術スタックの類似プロジェクトを10件以上集める
2. 超過率分布を作る: 各プロジェクトの当初見積もりに対する実コスト超過率（実コスト÷見積もりコスト）の分布を作る
3. 自プロジェクトの内部見積もりを補正する: 自プロジェクトのエキスパート判断値に、参照クラス分布の中央値・90パーセンタイル・最悪値を掛けた3点を併記する
10件の参照クラスを集めるところが組織側のコストで、ここを継続的にやれている組織は多くない。だが裾の重い分布を内部視点だけで再現するのは原理的に困難で、外部参照クラスを使う以外に補正経路がない。最初は5件でも始めて、プロジェクトを完了するたびに参照クラスに追加していくのが現実的な始め方になる。
なお、サブタスクの点見積もりを単純合計することは避ける。要素見積もりが平均値でない限り合計値は系統バイアスを免れない（前述の summation fallacy）。点の合計の代わりにサイクルタイム分布からモンテカルロ法で全体分布の畳み込みを取る経路もあるが、運用に組み込めている組織は少ないので、まずは参照クラスでの外部補正を優先する。
判断見積もりの順序を設計する
参照クラスを使うかどうかに関わらず、判断見積もりを残す場面では、見積もりの順序設計を運用に組み込む必要がある。Jørgensen & Halkjelsvik 2019 が示したように、大きいタスクを小タスクの直後に置くと assimilation で過小に引っ張られる。具体的には以下のルールで吸収する。
サイズ帯ごとにバッチ化する（大タスクだけを1セッション、小タスクだけを1セッション）
相対見積もりのベースラインは中〜やや大のものを選ぶ
順序を毎回変える（カウンターバランス）
順序効果は「気をつける」では避けられない実証された系統バイアスで、運用設計の側で吸収するしかない。
バッファは二段で持つ
予算とスケジュールに2種類のバッファを別建てで計上する。前節の参照クラス分布をそのまま金額算定に使う。
コンティンジェンシーバッファ: 平均的な超過を吸収するための予備。参照クラス分布の中央値〜90パーセンタイルの超過率を基準に算定する。例えば中央値の超過率が30%なら、内部見積もりに30%上乗せした額をここに置く
マネジメントバッファ: 列挙できない事象に備える独立予算。想定外への保険 として、コンティンジェンシーとは別の費目で計上する。金額は参照クラスの最悪値、または Flyvbjerg のべき乗則研究が示す P90 超過（IT で200%超え）から決める
両者を混ぜずに別費目で持つのは、ブラックスワン級の事象でバッファが枯渇したときに「何の保険が機能しなかったのか」を説明できるようにするためである。混ぜると、平均的な遅れでバッファを食い潰した場合と、想定外の事象で食い潰した場合の区別が消える。
また、不確実性のコーンを信じて 期間が進めば精度が自動的に上がる と仮定してバッファを縮める運用も避ける。Bossavit と Rothman が示した通り、中間マイルストーン時点も初期と同じ幅で扱う方が安全である。
列挙できない事象は見積もりの仕事ではない
事前に列挙できない事象は、見積もりの精度を磨いても対応できない。代わりに、見積もりと並列で仮説検証 (probe) を走らせて、想定外事象が顕在化する前に挙動を観測する。具体的には以下を見積もりサイクルとは別系統で動かす。
Walking Skeleton: プロジェクト初期に最薄のエンドツーエンド実装を作って、技術スタック・統合点・運用環境の想定外挙動を引き出す
MVP / A/B テスト: 仮説の検証だけを目的にした小さな実装を本番環境に出し、市場・ユーザー行動・規制の想定外を引き出す
スパイク: 不明領域に対して期限を切った調査タスクを置き、24時間で当たって終わり のような枠で未知を既知化する
これらは見積もりの精度を上げる作業ではなく、見積もりが原理的に届かない領域に別の道具を充てる作業である。べき乗則分布の裾、Deep Uncertainty、Cynefin の Complex / Chaotic 領域は、すべて同じ層を指している。Cynefin が Complex 領域への対応として挙げる probe → sense → respond の循環は、見積もりサイクルの外側に置く別系統の活動になる。詳細は ソフトウェア開発における不確実性 と ソフトウェア開発プロジェクトの設計 で扱う。 AI 導入の前後でサイクルタイム分布は別物として扱う
ここまで挙げた選び方は、過去のサイクルタイムが将来にも当てはまることを前提にしている。前段の AI コーディング節で示した通り、AI 導入で生産性母集団も見積もり対象の単位も変わるため、AI 導入後のプロジェクトにはこの前提は適用できない。具体的には以下の運用を採る。
チケットに AI 使用フラグを立てる: AI 導入の前後で記録を分け、混ぜたままモンテカルロシミュレーションや参照クラスに食わせない
AI 後のサイクルタイムが30件溜まるまで予測幅を広める: サンプル不足の期間は、確率付き予測の上限を意識的に高めに出す（85%予測を95%予測と読み替える、など）
参照クラス予測法も別建てにする: 類似プロジェクトを集めるときに、AI 導入前後で参照クラスを分ける