--- title: "工数見積もりの指針｜手法の選び方と根拠の作り方・妥当性の精査手順" url: "https://www.issoh.co.jp/column/details/11019/" published: 2026-02-17 updated: 2026-09-27 categories: ["ビジネス理論・用語"] publisher: "株式会社一創" --- # 工数見積もりの指針｜手法の選び方と根拠の作り方・妥当性の精査手順 工数見積もりで行き詰まるのは、計算そのものより「なぜその数字なのか」を説明する段階です。IPAの「ソフトウェア開発分析データ集2022」では、コスト計画について「算定の根拠が明確で実行可能性を検討済み」と自己評価したプロジェクトが1,303件中1,211件（92.9%）にのぼり、別集計の実績評価では回答1,308件中184件（14.1%）が超過区分に分類されています。この記事では、IPAが公開する資料が示す見積りの指針にそって、手順・手法の選び方・根拠の組み立て方・妥当性の精査までを順に整理します。数字そのものより、数字を支える前提をどう書き残すかに軸を置きます。 ## まとめ：工数見積もりの4つの指針 IPAが公開する解説資料「ソフトウェア開発見積りの基本的な考え方」（三菱総合研究所 石谷靖、2012年4月20日、CoBRA研究会）は、見積りの課題に対する方針を次の4つに整理しています。 - 見積り手法の確立：前提（インプット）とアウトプットを明確にし、算出根拠の明確化と再現性を確保する - 見積りの妥当性の確保：複数の視点から確認し、複数の見積り方法でレビューする - モニタリングとコントロールと再見積り：前提とインプットの変化を監視し、変わったら見積り直す - 目標と見積りの峻別：目標と見積りの差は見積り手法ではなくマネジメントで解決する 同資料はこのうち「見積り手法の確立」に「すべての対策の出発点」と注記しています。妥当性の確認も再見積りも、前提と算出根拠が書かれていなければ実行できないためです。取引の枠組み側にも同じ発想があり、IPAが公開する「情報システム・モデル取引・契約書」の解説資料は、契約プロセスの例として見積り①（試算）、見積り②（概算）、見積り③（確定）という多段階を図示しています。この例は、要件の具体化に合わせて段階的に見積りを更新する進め方を示しています。 以下では、この4つの方針に沿って実務での組み立て方を見ていきます。手法そのものの定義や違いは[ボトムアップ見積もりとは？パラメトリック・類推・三点見積りとの違いをわかりやすく解説](/column/details/2783/)にまとめてあるため、本記事では選び方と使い方に絞ります。 ## 工数見積もりにおける算出根拠と前提条件の確認 ### コスト計画・実績の自己評価と集計上の限界 IPAの分析データ集2022には、プロジェクト自身による計画と実績の自己評価が載っています。計画側（表1-3-7.1）では、コスト算定について「根拠が明確で実行可能性を検討済み」が1,211件、「根拠が不明確、または実行可能性を未検討」が71件、「計画なし」が21件で、母数は1,303件です。9割を超えるプロジェクトが、着手時点では根拠を持っていると答えています。 一方の実績側（表1-3-7.2）は次のとおりです。 | コスト実績の自己評価 | 件数 | 構成比 | | ------------------ | ----- | ----- | | 計画より10%以上少ないコストで達成 | 126 | 9.6% | | 計画通り（±10%未満） | 998 | 76.3% | | 計画の30%以内の超過 | 125 | 9.6% | | 計画の50%以内の超過 | 24 | 1.8% | | 計画の50%を超える超過 | 35 | 2.7% | | 合計（N） | 1,308 | 100% | 超過した184件のうち、30%以内に収まったものが125件で、大きく崩れた50%超の超過は35件（2.7%）です。同資料の本文も「コストはほぼ計画以内（aとb）が約86%」と記しています。工期側（N=1,311）はさらに安定していて、納期前倒し20件と納期通り1,171件を合わせた1,191件（90.8%）が計画内です。つまり大半の案件は見積りどおりに終わり、崩れるときは一部が大きく崩れる、という分布になっています。ただし、この集計だけでは、超過の原因が見積り手法にあるのか、前提条件の変化にあるのかは判断できません。 ### 見積りミスにつながる算出根拠の説明不足 先のIPA資料は、見積りミスを引き起こす原因を10項目挙げています（出典はCapers Jones、2006年およびLinda M. Laird・M. Carol Brennan、2006年）。そのなかに「見積りに関して根拠をきちんと説明できない場合」と「期間と工数に関して、『望み』と『見積り』が混同されている場合」が並んでいます。精度を上げる技法の話ではなく、説明できるかどうかが独立した失敗要因として扱われている点が要注意です。 同資料はさらに、ソフトウェア工学の経験則としてDeMarco-Glassの法則「ほとんどのコスト見積りは低すぎる傾向がある」を引き、「データ等の根拠がない場合は『楽観的に』なりがちである」と補足しています。根拠を書き出す作業は、説明のためだけではなく、自分の楽観を検出する手続きでもあります。勘と経験に寄りかかった見積りの構造は[KKDとは？勘・経験・度胸の意味とKKD法・反対語まで解説](/column/details/10224/)で詳しく扱っています。 ### 目標と見積りの区別：算出値と提示値の分離 同資料は「目標と見積りの峻別」を4つの方針のひとつに置き、その例として「入札額と見積り額は本来違うもの」と明記しています。予算の上限や希望納期は目標であり、前提とインプットから算出した数字が見積りです。両者が一致しないとき、見積りの側を削って辻褄を合わせると、根拠と数字が切り離されて説明できない見積りになります。 実務上は、見積書に至る前の内部資料で「算出値」と「提示値」を別の行に持ち、差分に調整理由を書いておく形が扱いやすくなります。差分が埋まらない場合は、予算差ならスコープや予算の調整、納期差なら工程や体制の見直しを検討します。期間の延長や増員については、追加費用と調整工数も再算定します。これが同資料の言う「見積り（手法）で解決するのではなく、マネジメントで解決」の実装です。 ## 見積りの手順はスコープ設定から工期算出までの5段階 ### 規模を起点とした工数・工期の算定 IPA資料が示す見積りフローは、対象（スコープ）の設定、要件の洗い出し、規模の見積り、工数の見積り、工期の見積りという並びです。規模から工数を求める場合、生産性をFP／人時などの「規模÷工数」で定義するなら、工数は規模を生産性で割って算出します。逆数の原単位（人時／FP）を使う場合は掛け算です。工期は作業の依存関係と体制も踏まえて見積もります。 規模の指標として同資料が挙げるのは、ソースコード行数、ファンクションポイント、オブジェクトポイント、ユースケースポイントです。あわせて、規模のスコープを新規量・変更量・削除量・母体規模に分けて数えることも示されています。改修案件で新規追加分だけを見積もると、既存部分の影響調査や回帰テストを過少に見積もるおそれがあります。母体規模に加えて、調査対象とテスト範囲を確認します。ファンクションポイントの数え方は[ファンクションポイント法とは｜計算方法とIFPUG重み表・工数換算の実例](/column/details/2781/)、人日・人月への換算と計算式は[工数計算のやり方｜人日・人月の計算式と単位換算・見積もりの手順](/column/details/2382/)にあります。 ### 要件未確定段階の見積り幅と数値例の適用限界 石谷氏の資料は、細部が決まっていない段階の規模見積りについて「部分的な情報から、推測するしかない」「実際とぶれがでることは避けられない」と述べ、数値例として4倍から4分の1という幅を示しています。出典として挙げられているのはB. Boehm「Software Engineering Economics」（1984年）で、その原論文はコスト見積りの幅を段階ごとに書き分けています。人と機械の接点をどう作るかなど不確実な点が残る初期構想の段階では4倍、実現可能性の検討を終えて運用構想が定まると2倍、ソフトウェア要求仕様書ができた時点で1.5倍が、それぞれ上下いずれの方向にも生じうる幅とされています。 この数値には原論文自身が注記を付けています。これらの範囲は主観的に決めたもので、80パーセントの信頼限界を表すことを意図している、つまり「上下いずれかに4倍以内が10回のうち8回」という意味だ、という但し書きです。1984年時点の経験則であり、すべての案件に当てはまる精度保証ではありません。段階が進めば幅が狭くなるという順序を借りる材料であって、自社の見積り幅として転用する数値ではない、と押さえておくのが安全です。 したがって企画段階の数字は、単一の値ではなく幅で出し、どの段階の見積りかをラベルとして必ず添えます。概算であることや算定時点を明記しないと、後から確定見積りと誤解されるおそれがあります。 この段階分けは、IPAが公開する「情報システム・モデル取引・契約書」の解説資料（IPAデジタル基盤センター専門委員による2025年4月24日の講演資料、p23）でも契約プロセスの例として図示されています。そこではRFIの後にRFP①と見積り①（試算）、次にRFP②と見積り②（概算）、そして見積り③（確定）が並び、同じ資料の契約プロセス・手続き規定に「多段階契約と再見積りの考え方を採用」と明記されています。見積書の表題には試算・概算・確定の別を示し、算定時点、対象範囲、未確定事項、金額や工数を見直す条件も併記します。 ### Web開発・インフラ構築の見積り対象範囲 2012年の石谷靖氏の資料は、システム開発のコスト構成要素を、開発・運用、付帯作業、機器などの3つに分けています。付帯作業にはインフラ構築、開発環境整備、検証支援作業（テスト環境整備など）、個人情報管理、セキュリティ管理、ユーザ教育が含まれ、機器などにはハードウェア、ネットワーク、ミドルウェア、パッケージソフトウェア、OSが入ります。 Webアプリケーションでは設計・実装に加えてテスト・移行・運用準備を、インフラ構築では構成設計・設定・検証・切替作業を確認します。機器費用は作業工数と分けて整理します。同じ「見積り」でも対象範囲が違うため、比較や流用の前に、どの構成要素まで含んだ数字かを確認する必要があります。見積書の1行目に対象範囲を書く、という単純な運用がここで効きます。 ## 要件の確定度と過去データに応じた見積り手法の選定 手法は優劣ではなく、手元にある情報で決まります。要件がどこまで固まっているかと、参照できる実績データがあるかの2軸で整理すると次のようになります。 | 段階 | 要件の状態 | 取りうる手法 | 必要な前提 | | ----- | ----- | --------------- | -------- | | 企画・提案 | 方向性のみ | 類推法、三点見積り | 類似案件の実績値 | | 要件定義中 | 一部確定 | パラメトリック法と積上げの併用 | 生産性の基準値 | | 要件定義後 | 機能が確定 | ボトムアップ（WBS積上げ） | WBSの分解粒度 | 各手法の中身と使い分けは[ボトムアップ見積もりとは？パラメトリック・類推・三点見積りとの違いをわかりやすく解説](/column/details/2783/)に譲ります。積上げの前提になるWBSの作り方は[WBSとは？作り方5ステップとガントチャートとの違いを具体例で解説](/column/details/2345/)、人時・人日・人月の扱いは[工数の単位とは？人時・人日・人月の換算早見表と1人月160時間の根拠](/column/details/11021/)を参照してください。 ### 見積りモデルの適用条件と過去実績による較正 先のIPA資料が挙げる見積りミスの原因の2番目は「過去の実績データがなく見積りのキャリブレーション（較正）ができない場合が多い」です。パラメトリック法も見積りツールも、自社の実績で係数を較正して初めて自社の数字になります。較正していないモデルは、自社の開発条件でどの程度の精度が得られるか未確認です。採用前に、モデルの適用範囲と自社案件での誤差を確認します。 同資料は手法の歴史も整理しており、1990年代に機械学習アルゴリズム、ニューラルネットワーク、CART、アナロジー方式が次々に適用された後、1990年代後半から2000年代にかけて熟練者の判断を活用する方向が再認識されたと記しています。1997年のCoBRA法（Briandら、1998年）は、熟練者の知識を定量化してモデルに組み込む型でした。データが足りないなら、モデルを増やすより、熟練者の判断を変数として書き出して見えるようにするほうが筋が通ります。 ## 見積り根拠の記載項目：前提・内訳・バッファ ### 算出の前に書き出す前提条件 IPA資料の対策①は「前提（インプット）とアウトプットの明確化」と「アウトプットの算出根拠の明確化と再現性の確保」です。再現性とは、同じ前提を与えれば別の担当者でも同じ数字に辿り着けることを指します。ここを満たすには、対象範囲、想定する要件の確定度、使用技術、体制と稼働率、前提として置いた外部依存（他社システムの仕様確定時期など）を、数字より前に書き出す必要があります。 前提を書き切ると、後から前提が崩れたときに再見積りの根拠がそのまま手に入ります。前提の記載がないと、当初の範囲と追加要件の境界を説明しにくくなり、増加分の交渉に必要な根拠が不足します。 ### バッファの算定根拠とリスク別の内訳 バッファを基本工数に混ぜ込むと、削減要求が来たときにどこを削るかの議論ができません。不確実性の要因ごとに項目を立て、それぞれに工数を割り当てて明細にしておきます。項目が立っていれば、その不確実性が消えた時点でバッファを落とす判断もできます。 なお、本記事で参照したIPA資料からは、一律に適用できるバッファ率を示せません。分析データ集2022にもバッファ比率の統計は収録されていないため、この資料を根拠に「業界標準は何%」とは説明できません。前述の段階別のぶれ幅も、バッファ率の代わりに使える数値ではありません。見積り幅は情報がどこまで確定しているかを表すもので、バッファは起きたら追加作業が要るリスクへの備えです。企画段階では未確定要件を明示して条件別の見積り幅を示し、バッファはそれとは別に、想定するリスク、発生時に必要な追加作業、既存の見積りとの重複を確認して算定します。管理側の工数比率については[管理工数の比率は何％が妥当か｜10％の根拠をIPA原典と実証研究で検証](/column/details/11036/)に一次資料ベースの数字をまとめています。 ### 自動見積りツールの再現性と算出根拠の検証 見積りの自動化ツールやAIによる算出が入ると、根拠の所在が変わります。判断軸はひとつで、同じインプットを与えたときに同じ数字が再現されるか、そして数字を動かしている説明変数が開示されているかです。IPA資料が対策①に「再現性の確保」を置いているのは、ここが崩れると妥当性の確認も再見積りもできなくなるためです。 説明変数や算出過程を確認できないツールの出力だけでは、見積りの根拠を十分に説明できません。社内や発注者への説明では、入力条件、対象範囲、過去案件での誤差、別手法との比較を補う必要があります。このようなツールは、算出済みの見積りに対する妥当性チェック（第2の見積りとしてのクロスチェック）に用途を限るのが現実的な使い方になります。CoBRA法のように影響要因と係数を明示する場合も、出力値に加えて、入力条件、係数の設定根拠、実績による検証結果を提示します。 ## 見積りの精査：クロスチェックと再見積り ### 複数手法による見積り結果の比較と差分分析 IPA資料の対策②は「見積りの妥当性の確保」で、内容は「複数の視点からのチェック」と「複数の見積り方法によるレビュー」です。とくに「見積りの前提が曖昧な場合は様々な立場・可能性からのチェック／シミュレーション」が必要だと書かれています。前提が曖昧なほど、単一手法の数字を信じてはいけないという順序になっています。 実務では、積上げで出した数字と、類似案件からの類推で出した数字を並べます。ここで見るべきは一致することではなく、差分を説明できることです。差分の理由が「今回は移行対象データが3倍ある」のように言語化できれば、それ自体が見積り根拠の一部になります。説明できない差分が残る場合は、対象範囲、作業の抜け・重複、生産性の設定、参照案件との条件差を順に確認します。 ### 要件追加に伴う規模の変化と再見積り IPA資料は、開発当初の想定機能は工程が進むにしたがって一般に膨張するとし、数値例として1か月に2%増加を挙げています（出典はCapers Jones「ソフトウェア見積りのすべて 第2版」共立出版、2009年）。見えていなかった要件が後から見えてくる以上、初回の見積りとのぶれは構造的に発生します。 そのため対策③は「モニタリングとコントロールと再見積り」となっており、前提とインプットの変化を監視して、明確になった時点で見直すことを求めています。工程の区切りで前提条件を点検し、工程途中でも要件や体制などの前提が変わった場合は再見積りを検討します。前提条件を最初に書き出しておけば、そのどれかが崩れた日が再見積りの日になります。 ### 変更管理の書面と未決事項の確定期限 再見積りを実行に移す手続きは、契約のひな型側に用意されています。IPAの解説資料が整理する「情報システム・モデル取引・契約書」の構成では、関連ドキュメントモデルとして変更提案書・変更管理書が第34条から第37条に置かれ、各フェーズ共通事項として「変更管理手続の詳細化（第37条）」が挙げられています。さらに責任関係の論点に「未決事項の確定手続・時期の明確化（第36条）」があり、決まっていないことをいつまでに決めるかを契約時点で扱う建て付けになっています。 実務で効くのは、この「未決事項」の扱いです。前提条件として書き出した未確定項目に確定期限を付けておけば、期限を過ぎた時点が再見積りと変更管理の起点になります。期限のない未決事項は、いつまでも初回見積りの前提として残り続け、崩れたときに誰の責任かの議論だけが残ります。工数の実績側の管理は[管理工数の比率は何％が妥当か｜10％の根拠をIPA原典と実証研究で検証](/column/details/11036/)とあわせて設計してください。 ## よくある質問 ### 工数の見積もりはどのように進めればよいですか？ IPA公開資料の見積りフローに従うと、対象（スコープ）の設定、要件の洗い出し、規模の見積り、工数の見積り、工期の見積りの順になります。規模ベースの見積りでは、規模を見積もり、生産性をFP／人時などで定義する場合は規模を生産性で割って工数を算出します。要件が未確定なら、規模にも仮定や幅を持たせます。着手前に、付帯作業（インフラ構築、開発環境整備、ユーザ教育など）の工数を対象に含むか決めておきます。機器購入費やライセンス費は工数とは分け、費用見積りに計上します。 ### 工数見積もりができない原因は何ですか？ IPA資料は原因として、要求が完全に決定される前に正式な見積りが求められること、過去の実績データが無く較正できないこと、新しい要求が加わっても見積りが変更されないこと、根拠をきちんと説明できないことなどを挙げています。手法を知らないことより、前提と実績データが揃っていないことが先に効いている構造です。 ### 見積りの根拠として何を示せばよいですか？ 対象範囲、要件の確定度、使用技術、体制と稼働率、外部依存の前提を先に書き、そのうえで規模の算出方法、規模から工数への換算に使った生産性、不確実性ごとのバッファ内訳を示します。判断基準は、別の担当者が前提と算定過程を追えるかです。例えば仮の案件なら、「対象150FP、生産性0.15FP／人時（自社実績から設定）、基本工数1,000人時、移行作業は別計上」のように、数量・単位・生産性の出どころ・除外範囲を併記します。 ### バッファはどのくらい積むのが標準ですか？ 本記事で参照した資料からは、一律の標準値を示せません。IPAのソフトウェア開発分析データ集2022にはバッファ比率の統計がなく、同資料を根拠に「業界標準は何%」とは説明できません。代わりに、未確定要件による見積り幅と、リスクに備えるバッファを分けて示します。バッファの根拠には、想定リスクと発生時の追加作業、参照できる過去実績を用います。 ### 見積りの教科書にあたる公的資料はありますか？ IPA/SEC編「ソフトウェア開発見積りガイドブック」（オーム社、2006年4月25日発行、A5判240ページ、ISBN 4-274-50068-3）が該当します。ただし本資料の著作権は2013年4月1日に一般社団法人情報サービス産業協会（JISA）へ譲渡され、書籍販売は終了しています。IPAのサイトには[アーカイブ扱いの書誌情報ページ](https://www.ipa.go.jp/archive/publish/secbooks20060425.html)が残っています。本記事で数値と方針を引いたのは、いずれもIPAが公開している次の3点です。統計は[ソフトウェア開発分析データ集2022](https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html)の本編PDF、4つの方針と見積りフローは[「ソフトウェア開発見積りの基本的な考え方」（2012年、PDF）](https://www.ipa.go.jp/archive/files/000005394.pdf)、契約プロセスと変更管理は[情報システム・モデル取引・契約書（第二版）](https://www.ipa.go.jp/digital/model/model20201222.html)とその解説資料です。原表と原文にあたって確認できます。 ## 関連記事 - [ボトムアップ見積もりとは？パラメトリック・類推・三点見積りとの違いをわかりやすく解説](/column/details/2783/) - [工数計算のやり方｜人日・人月の計算式と単位換算・見積もりの手順](/column/details/2382/) - [WBSとは？作り方5ステップとガントチャートとの違いを具体例で解説](/column/details/2345/) - [ファンクションポイント法とは｜計算方法とIFPUG重み表・工数換算の実例](/column/details/2781/) - [管理工数の比率は何％が妥当か｜10％の根拠をIPA原典と実証研究で検証](/column/details/11036/) --- 出典: [工数見積もりの指針｜手法の選び方と根拠の作り方・妥当性の精査手順]()（株式会社一創）