見積もり精度は「見積もった工数やコストに対して、実績がどれだけ離れたか」で表します。測り方を決めないまま「精度を上げよう」と言っても、改善したかどうかを誰も判定できません。この記事では、予実差の計算方法と評価指標の落とし穴、見積もる段階ごとに到達できる精度の目安、精度が上がらない原因と改善の手順を、Boehmの論文とIPA（情報処理推進機構）の公開データをもとに整理します。
まとめ：見積もり精度の幅と段階別管理
- 見積もり精度は予実比（実績÷見積もり）で測り、「0.8〜1.25に入った割合」のように逆数どうしの範囲で数えると、過大側と過小側を同じ倍率で評価できます。研究で使われるMMREは過小見積もりを甘く評価する性質があります。
- 到達できる精度は見積もる段階で決まります。Boehm（1984）は、構想段階で上下4倍、要求仕様の完成時で1.5倍、詳細設計の完了時で約10%という幅を示しました（主観による80%信頼限界）。
- IPAの分析データ集2022では、コスト実績が計画の±10%未満に収まったプロジェクトは1,308件中998件（76.3%）、50%を超えて超過したものは35件（2.7%）でした。
- 精度を下げる主因は手法の選択より、要求が決まる前の一点見積もり、予算や受注価格に合わせた見積もり、実績を残さない運用です。
- 改善は、幅と前提条件を付けて見積もる、段階ごとに見積もり直す、予実を記録して自社の補正値を作る、複数の方法で突き合わせる、の4つです。あわせて、目標と見積もりを分け、見積もり精度を個人の評価指標にしないことを勧めます。
以下、測り方から順に根拠を示します。
見積もり精度の測り方：予実比・誤差率・MMREの違い
同じプロジェクトでも、どの式で測るかで「精度」の数字は変わります。社内で比べるなら、式と見積もった時点を固定してから集計を始めます。
予実比と誤差率の計算式
実務で使う予実比・誤差率と、研究で使われるMREを比較します。
| 指標 | 計算式 | 見積100人日・実績130人日の例 |
|---|---|---|
| 予実比 | 実績 ÷ 見積もり | 1.30 |
| 誤差率（超過率） | （実績 − 見積もり）÷ 見積もり | +30% |
| MRE | |実績 − 見積もり| ÷ 実績 | 0.23 |
誤差率は見積もりを分母にするため、「計画の何%超過したか」という報告の言葉とそのまま対応します。IPAの分析データ集も実績を「計画の30%以内の超過」「計画の50%を超える超過」のように計画を基準に区分しています。MREは分母が実績なので、見積もり100人日と実績130人日の差30人日は、30÷130で約23%となります。社内で数字を並べるときに分母が混在していると、改善したように見えるだけの比較になります。
MMRE・PRED(25)と過小見積もりを甘く見る偏り
見積もりモデルの研究では、MREの平均（MMRE）と、MREが25%以内に収まった割合（PRED(25)）が長く使われてきました。ただし、Fossら（2003年、IEEE Transactions on Software Engineering 29巻11号）のシミュレーション研究は、MMREが「過小見積もりをするモデルを、真のモデルや過大見積もりをするモデルより優れている」と判定してしまうことを示しています。
MREには構造的な偏りがあります。実績100人日に対して見積もりが4分の1の25人日ならMREは0.75ですが、4倍の400人日ならMREは3.0です。過小見積もりはMREが1を超えないのに、過大見積もりは上限なく大きくなります。MMREが小さい手法やチームを「精度が高い」と評価すると、低めに見積もる習慣を後押ししかねません。
予実比に替えるだけでは偏りは消えません。4倍の過大見積もりは予実比0.25、4倍の過小見積もりは予実比4.0で、1からの差は0.75と3.0です。社内で評価するなら、0.8と1.25のように互いに逆数の関係にある上下限を決め、その範囲に入った案件の割合を数えます。この数え方なら、4倍の過大も4倍の過小も同じ「範囲外」として扱えます。
見積もる段階で決まる到達可能な精度：Boehmの4倍から10%まで
見積もり精度には、手法では超えられない上限があります。Boehmは1984年の論文「Software Engineering Economics」（IEEE Transactions on Software Engineering、Fig. 3と脚注4）で、仕様が定まるまでは「ソフトウェアの範囲」そのものに幅があり、見積もり手法がその欠落を補うことは期待できないと述べ、段階ごとの見積もり幅を次のように示しました。
| 見積もる時点 | 見積もり幅（上下とも） |
|---|---|
| 構想（代替案の検討開始） | 4倍（1/4〜4倍） |
| 実現可能性の検討完了 | 2倍 |
| ソフトウェア要求仕様の完成 | 1.5倍 |
| 製品設計仕様の完成・検証 | 1.25倍 |
| 詳細設計の完了 | 約10% |
脚注には、これらの幅は主観的に定めたもので、「80%の確率で上下4倍以内」という意味の80%信頼限界だと明記されています。精度を保証する数字ではなく、「この段階で±10%を求めるのは無理がある」と判断する目安として使います。
工期についても同じ構図があります。IPAの分析データ集2022（p189）は、工数500人月のプロジェクトの工期を50%信頼区間で見ると約11〜21か月の幅があると示し、回帰式で一点の工期を出すことは「これだけの幅がある中で、工期をピンポイントで当てにいくこと」だと注意しています。
実務での使い方は単純です。見積書や社内稟議に「どの段階の見積もりか」を書き、その段階に見合った幅を併記します。構想段階の数字に±10%の約束を付けないことが、後で「精度が悪い」と言われないための最初の対策になります。
実際のプロジェクトはどれだけ外れているか：IPA 1,308件と海外の調査
IPAの「ソフトウェア開発分析データ集2022」表1-3-7.2（p26）は、プロジェクト実績を計画と比べた自己評価を集計しています。コストの内訳は次のとおりです（N=1,308）。
| コスト実績の区分 | 件数 | 割合 |
|---|---|---|
| 計画より10%以上少ない | 126 | 9.6% |
| 計画通り（±10%未満） | 998 | 76.3% |
| 30%以内の超過 | 125 | 9.6% |
| 50%以内の超過 | 24 | 1.8% |
| 50%を超える超過 | 35 | 2.7% |
工期は1,311件中1,171件（89.3%）が納期通りで、30日以上遅れたのは64件（4.9%）でした。
この数字を「日本のプロジェクトの4分の3は±10%で当たる」と読むのは早計です。比較の基準は「計画」で、計画がどの時点で立てられたか（構想段階か、要件定義後か）は区分されていません。IPA自身も、データは複数企業から集めたもので無作為抽出ではないと断っています（p189）。参照点として使えるのは「コスト超過が30%を超えるプロジェクトは全体の4.5%（59件）」という程度の粒度で、自社の目標値はこの表ではなく自社の予実から作ります。
海外の調査も同じ方向を示しています。Moløkken-ØstvoldとJørgensen（2003年）は工数見積もりに関する調査を横断的にレビューし、プロジェクトの60〜80%が工数またはスケジュールを超過していること、Standish Groupの「Chaos Report」が示す平均コスト超過89%を除く他の調査では平均超過が30〜40%だったことをまとめています。IPAの区分（計画比±10%未満を「計画通り」と数える自己評価）とは集計方法が違うため数字は直接比べられませんが、外れる方向が超過側に偏る点はどちらにも共通します。
見積もり精度が上がらない原因：要求の不確実性・判断の歪み・記録不足
IPAが公開している三菱総合研究所・石谷靖氏の講演資料「ソフトウェア開発見積りの基本的な考え方」（2012年、p11）は、見積もりミスの原因としてCapers Jones（2006年）の指摘を引いています。挙げられているのは、要求が決まる前に正式な見積もりを求められる、過去の実績データがなくキャリブレーション（較正）できない、新しい要求が加わっても見積もりが変わらない、保守的な見積もりが封じられ挑戦的な見積もりに置き換えられる、といった項目です。手法の選び方より、見積もりの扱い方の問題が並んでいます。
要求が決まる前の一点見積もり
Boehmの表に照らすと、構想段階の見積もりは上下4倍の幅を持ちます。その段階で「1,200万円」と一点で答え、その数字が契約や予算に固定されると、後の工程でどれだけ正確に作業しても「精度が悪かった」ことになります。同資料は、開発当初に想定した機能は工程が進むにつれて膨らむとし、数値例として「1か月に2%増加」（Capers Jones『ソフトウェア見積りのすべて 第2版』）を挙げています。見積もり後に増えた要求を再見積もりせずに吸収していれば、見積もり手法がどれだけ精緻でも予実はずれます。
予算や受注価格に合わせた見積もり
Boehmは見積もり手法を7つに分け、そのうち「Price-to-win（受注に必要な価格に見積もりを合わせる）」は「契約は取れることが多いが、一般に大きな超過を生む」、「Parkinson（使える資源に見積もりを合わせる）」は「悪い慣行を強化する」と評価し、この2つは受け入れられないと結論づけています。
IPAの分析データ集2022（p191）も「危うい使い方」として、顧客予算から逆算した要求工数を回帰式に入れて規模を算出し、予算に沿った見積もりを作った例を挙げています。この例で示されている対応は、見積もり工数が同書の規模と工数の関係における50%信頼区間内にあることを確かめ、リスクを洗い出して顧客と共有したうえで工数を調整することです。予算が先に決まっている案件でも、見積もりの数字は予算から逆算せずに出し、差はスコープかリスクの扱いで埋めます。
顧客の期待は、見積もる側が意識しないうちに数字を動かします。JørgensenとGrimstad（2011年、IEEE Transactions on Software Engineering）は、東欧・東アジアのオフショア開発会社46社に報酬を払って同じ開発案件を見積もらせる実験を行いました。「数か月後に着手し、3週間で開発することを顧客が期待している」という情報を加えた群の工数見積もりの中央値は142人時で、情報のない群の209人時を約3割下回りました（片側検定でp=0.02）。開発期間が短いことは本来、工数を減らす理由になりません。
楽観に寄る見積もりと幅の過信
石谷氏の資料は、DeMarco-Glassの法則として「ほとんどのコスト見積りは低すぎる傾向がある」を挙げ、作業項目は余計に足されるより忘れられることのほうが多い、根拠がないと楽観的になりがちだと説明しています。
幅を付けた見積もりにも過信が入ります。JørgensenとSjøberg（2003年、Information and Software Technology）の実験では、ソフトウェア技術者が「90%の確信」で付けた工数の予測区間に実績が収まった割合は、15件の開発タスクの平均で68%でした。幅を出すだけでは足りず、自分の過去の外れ方をもとに幅を広げる必要があるということです。
実績を記録しない運用
見積もり精度を上げるには、過去の見積もりがどちらにどれだけ外れたかを知る必要があります。完了時に実績工数だけを残し、当初の見積もり値・見積もった時点・前提条件を残していない組織では、予実比を計算できません。KKDとは？勘・経験・度胸の意味とKKD法・反対語まで解説で扱っている「経験に頼る見積もり」でも、外れ方を記録して次に反映しなければ、同じ判断ミスを繰り返すおそれがあります。
見積もり精度の改善手順：幅の提示・再見積もり・実績補正・レビュー
石谷氏の資料（p27）は、見積もりの課題への方針として、見積もり手法の確立（前提と算出根拠の明確化）、複数の見積もり方法によるレビュー、モニタリングと再見積もり、目標と見積もりの峻別の4つを挙げています。以下では、幅と前提条件の提示、再見積もり、実績による補正、複数手法でのレビューを説明します。目標と見積もりの切り分けは次章で扱います。
見積もり幅と前提条件の明示
最頻値だけでなく楽観値と悲観値を出し、「この前提が崩れたら見積もり直す」という条件を見積書に書きます。三点見積もりの計算方法はボトムアップ見積もりとは？類推・パラメトリック・三点見積りとの違いと計算例で解説しています。前提条件は「対象画面数」「連携する外部システム」「移行データ件数」のように、後で変わったかどうかを判定できる形で書くと、再見積もりの判断が速くなります。
契約・計画への段階別再見積もりの組み込み
要件定義の完了時、基本設計の完了時など、Boehmの表で幅が狭まる時点を再見積もりの節目にします。IPAが2025年4月の講演で示した「情報システム・モデル取引・契約書」の全体像でも、見積もりは試算・概算・確定と段階を分けて示され、多段階契約と再見積もりの考え方が採られています。受託開発では、要件定義を準委任で切り出し、その成果をもとに開発工程の見積もりを確定させる進め方が、この考え方に沿った形です。
予実記録に基づく自社補正値の作成
完了した案件ごとに、最低限次の項目を残します。
- 見積もった時点（構想・要件定義後・基本設計後など）と見積もり値（幅を出したなら最頻値・楽観値・悲観値）
- 見積もりの前提条件と、実際に変わった前提
- 工程別の実績工数
- 差異の主因（要求追加・作業漏れ・生産性の読み違い・外部要因）
案件を見積もった段階や開発種別で分け、各群の件数・予実比の中央値・ばらつきを確認します。要件定義後の見積もりで予実比の中央値が1.2なら、同じ段階の見積もりにはその補正を掛けて提示する、という使い方です。少数の案件から求めた補正値は暫定値として扱い、件数が増えるたびに更新します。IPAの分析データ集2022（p191）も、同書の回帰式をそのまま使うのではなく、自社のプロジェクトデータから同等の回帰式を作って算出するよう勧めています。工数の計算と単位換算は工数計算のやり方｜人日・人月の計算式と単位換算・見積もりの手順を参照してください。
複数手法・複数人による見積もりの比較
Boehmは、どの手法にも長所と短所があり互いに補い合うので、複数の手法を組み合わせて結果を比べ、食い違う箇所を詰めるべきだとしています。類推法の結果とボトムアップの積み上げが大きく食い違ったら、その差がどの作業から来ているかを確認するのが見積もりレビューの中身です。複数人の見積もりを匿名で集めて収束させる方法はデルファイ法とは？手順と合意の判定基準・ワイドバンドデルファイまで実務目線で解説で扱っています。見積もりの根拠の書き方や妥当性の精査手順は工数見積もりの指針｜手法の選び方と根拠の作り方・妥当性の精査手順にまとめています。
見積もり精度を個人の評価指標にしない理由と、目標との切り分け
精度を上げたい組織ほど、見積もり精度を個人やチームのKPIにしがちです。これは勧めません。予実比が評価に直結すると、見積もる人は多めに見積もり、残った時間で作業を膨らませれば予実比は1.0に近づきます。Boehmが「悪い慣行を強化する」と評したParkinson型の見積もりを、評価制度が作り出す形です。見かけの精度は上がっても、プロジェクトのコストは下がりません。
精度は、組織として見積もりの補正値を作るための材料として集計し、個人の査定には使わないほうが正確なデータが集まります。評価するなら「見積もった時点と前提を記録したか」「前提が変わったときに再見積もりを出したか」という手順の遵守を見ます。
もう1つ切り分けるべきなのが目標です。石谷氏の資料は「目標」を「見積り」としてしまう混同を見積もりを難しくする要因に挙げ、入札額と見積もり額は本来違うものだとしています。経営や顧客が求める金額・納期は目標であり、見積もりとの差は見積もり手法ではなくマネジメントで解決する、というのが同資料の方針です。「見積もりを削って目標に合わせる」運用を続ける限り、どの手法を入れても予実は合いません。
アジャイル開発では、ストーリーポイント単位の精度を追うより、スプリントごとの完了量（ベロシティ）が安定しているかを見るほうが予測に役立ちます。ストーリーポイントの見積もり方はスクラム開発の5つの実践ポイント｜ストーリーポイント見積もりと完成の定義を参照してください。
よくある質問
見積もり精度とは何ですか？
見積もった工数・コスト・工期に対して、実績がどれだけ近かったかを表す度合いです。実務では予実比（実績÷見積もり）か誤差率（（実績−見積もり）÷見積もり）で測ります。研究ではMRE（|実績−見積もり|÷実績）とその平均MMREも使われますが、過小見積もりを甘く評価する性質があります。社内では予実比を使い、0.8〜1.25のように逆数どうしの範囲に入った割合を数えると、過大と過小を同じ倍率で評価できます。式と、どの段階の見積もりを比べるのかを先に決めておかないと、数字を比較できません。
見積もり精度の目安は何%ですか？
見積もった段階で変わります。Boehm（1984）は、構想段階で上下4倍、要求仕様の完成時で1.5倍、製品設計の完成時で1.25倍、詳細設計の完了時で約10%という幅を示しました（主観で定めた80%信頼限界）。IPAの分析データ集2022では、コスト実績が計画の±10%未満に収まったプロジェクトが76.3%（1,308件中998件）でしたが、計画を立てた時点は区分されていません。自社の目安は、同じ段階の見積もりの予実比を集計して作ります。
見積もり精度を上げるには何から始めればよいですか？
最初は記録です。見積もった時点・見積もり値・前提条件・実績工数・差異の主因を、完了した案件ごとに残します。並行して、見積もりを最頻値だけでなく楽観値と悲観値の幅で出し、要件定義後・基本設計後に見積もり直す節目を計画に入れます。手法の入れ替えは、予実の記録で「どこで外れているか」が分かってからで遅くありません。
見積もりが苦手な人・できない人は何を変えればよいですか？
本人の能力だけでなく、見積もりを求められる条件から見直します。要求が決まっていない段階で一点の数字を求められている、過去に自分がどれだけ外したかの記録がない、予算に合わせた数字を求められている、のいずれかに当てはまらないかを確認します。個人で取り組めるのは、例えば作業を半日〜2日程度の単位まで分解して書き出すことと、自分の見積もりと実績の比を記録し続けることです。分解した作業を過去の類似案件の作業一覧と照合すると、テスト・レビュー・移行などの計上漏れに気づけます。
ファンクションポイント法を使えば見積もり精度は上がりますか？
規模を機能の数と複雑さから数えるため、担当者による規模のばらつきは減らせます。ただし、要求がどこまで決まっているかは精度を左右する要因の一つで、要求仕様が固まる前に数えたファンクションポイントにはその段階の幅が残ります。また、規模から工数への換算には生産性の値が必要で、自社の実績で較正していない値を使えば予実はずれます。計算手順はファンクションポイント法とは｜計算方法とIFPUG重み表・工数換算の実例で解説しています。
