【目次】
・なぜ「見積り根拠」がそんなに大事？
・見積り根拠とは何か
・見積り根拠を書くときの基本ルール
・手法別・見積り根拠の書き方サンプル
・見積り根拠カタログ：書くべき項目と例文集
・よくあるNGパターンと改善例
・見積り根拠をレビュー・更新するポイント
・まとめ
なぜ「見積り根拠」がそんなに大事？
システム開発の見積りレビューで、こんなやり取りをしたことはありませんか。
- 上司「この工数の根拠は？」
- PM「えっと、過去の経験から…」
- 顧客「もう少し説明してもらえますか？」
見積りの数字そのものよりも、「なぜその数字になったのか」を説明できるかどうかで、
相手の納得感や信頼度が大きく変わります。
ここで必要になるのが「見積り根拠」です。
本記事では、システム開発のプロジェクトで使いやすい 見積り根拠の書き方 を、テンプレート感覚で使える「カタログ形式」で整理します。
そのまま文章を少し変えて流用できるように、具体例も合わせて紹介します。
見積り根拠とは何か
見積り根拠の定義
見積り根拠とは、見積りの数字（工数・期間・コスト）に対して「なぜその値なのか」を説明するための情報や前提条件のことです。
例えば、以下のような情報が含まれます。
- 前提条件（やらないこと・やることの範囲）
- 使用した見積り手法（類推、ボトムアップ、FP法、ストーリーポイントなど）
- 元になった過去実績や参考資料
- 工数や期間を決める際に使った計算式
- リスクと不確実性を踏まえたバッファの考え方
見積り根拠を書く目的
見積り根拠を書く目的は主に次の3つです。
- 説明責任を果たすため
・顧客・上司・ステークホルダーに対して、「なんとなく」ではなく論理的に説明できる。 - 将来の自分とチームを守るため
・後から「なぜこの工数で合意したのか」を思い出せる。
・手戻りや追加要望が出たときに、「当初の前提と違う」ことを客観的に示せる。 - 見積りの品質を上げるため
・根拠を言語化することで、漏れや矛盾に気づきやすくなる。
・他メンバーのレビューを受けやすくなり、見積り精度が改善される。
見積り根拠を書くときの基本ルール
ここからは、どんなプロジェクトでも共通して使える「書き方の基本」を押さえておきます。
数字とセットで「根拠」を書く
NG例：
- 「実装：80時間」
- 「テスト：40時間」
OK例：
- 「実装：80時間（既存モジュール流用率70％、新規画面4画面×各8時間＋共通部品16時間＋レビュー時間16時間を想定）」
- 「テスト：40時間（単体テストケース約40件、1件あたり0.8時間＋バグ修正レビュー含む）」
数字だけではなく計算の内訳を書くことで、後から見直したときも意味が分かります。
前提条件と範囲を明確にする
見積り根拠は、以下のような前提とセットで書くとブレが減ります。
- 対象スコープ（どこまで含めるか）
- 対象外（やらないこと）
- 役割分担（どこまで自社／相手が担当するか）
- 使う技術・ツールの想定
- 品質レベル（テスト範囲・レビュー回数など）
手法別・見積り根拠の書き方サンプル
ここでは、代表的な見積り手法ごとに、根拠の書き方例を紹介します。
類推見積り（類似プロジェクトから推定）
想定シナリオ
- 過去に似たような案件を経験している
- 大まかな規模感は掴めるが、詳細はこれから
書き方例
本案件は、2023年実施の「在庫管理システム刷新」と機能構成・技術スタックが類似しているため、当該プロジェクトの実績工数（合計1,200時間）をベースとした類推見積りとした。
データ項目数が約1.2倍であることから、実装・テスト工数に1.2倍の係数を適用し、要件定義・設計はほぼ同等とみなして算出している。
ポイントは、
- どの過去案件を参照したか
- どの部分を同じとみなしたか
- どこを何倍・何％で補正したか
を明確に書くことです。
ボトムアップ見積り（WBSベース）
想定シナリオ
- WBSを作成し、タスクごとに工数を積み上げる
書き方例
要件定義〜総合テストまでの工程をWBSに分解し、各タスクに対して担当者1名あたりの標準作業時間を設定して積み上げた。
要件定義は「現行調査」「ToBe整理」「要件定義書作成」「レビュー対応」の4タスクとし、各タスクの工数は過去3案件の平均値（例：現行調査 24時間、要件定義書作成 40時間）をベースに算出している。
ここでは、
- 「WBSで分解した」こと
- 「各タスクの時間の根拠」がどこから来ているか
を書きます。
パラメトリック見積り（規模×係数）
想定シナリオ
- 画面数、帳票数、IF本数などから工数を算出
書き方例
実装・単体テスト工数は、画面数・帳票数・IF本数を基準としたパラメトリック見積りとした。
- 業務画面：15画面 × 10時間／画面 ＝ 150時間
- 参照系帳票：5帳票 × 8時間／帳票 ＝ 40時間
- 外部IF：3本 × 20時間／本 ＝ 60時間
各単価は、直近2案件の実績（平均値）と今回の難易度（中程度）を踏まえ設定している。
「何に対して」「いくらの単価をかけたのか」を、式で見せると相手も納得しやすくなります。
見積り根拠カタログ：書くべき項目と例文集
ここからがメインの「カタログ」部分です。
実際の見積り資料や見積り根拠書に、そのままコピペして調整しやすい形で整理します。
プロジェクト全体の前提条件
項目例
- 対象スコープ
- 対象外
- 役割分担
- 品質条件
- 前提となるインフラ／環境
- 前提となる情報提供
例文
- 「本見積りは、要件定義〜総合テストまでを対象とし、本番移行後の保守・運用は含まない。」
- 「インフラ環境（サーバ、ネットワーク、OS）は顧客側で構築・提供されることを前提とする。」
- 「画面レイアウトのデザイン案は顧客から支給され、当社側では微修正のみを想定する。」
スコープ・機能規模の根拠
項目例
- 画面数・帳票数の想定
- IF本数と難易度
- データ件数・データ量
例文
- 「画面数はヒアリング結果と現行システムのメニュー構成から、業務画面15、マスタ画面5、管理画面3の計23画面と想定している。」
- 「外部IFは、顧客提供のRFPに記載のある『会計システム連携』『人事システム連携』の2本を対象とし、各1日1回のバッチ連携を想定する。」
工数見積りの根拠
項目例
- 使用した見積り手法
- 係数・工数単価
- バッファの考え方
例文
- 「要件定義工数は、ヒアリング対象部署3部門（各2回）＋要件定義書作成・レビューを合計して、1部門あたり24時間×3部門＝72時間と算出した。」
- 「技術的な不確実性（新ミドルウェア導入）を考慮し、設計・実装工程に対して10％のバッファを上乗せしている。」
コスト・期間の根拠
項目例
- 作業人数と期間の関係
- スキルレベル別のアサイン想定
- カレンダー・稼働日数
例文
- 「実装〜単体テストは、SE1名＋PG2名の体制で2ヶ月間（営業日合計40日、1人あたり8時間）を想定している。」
- 「レビューや打ち合わせは週1回1時間を基本とし、1回あたりPM＋SEの2名参加とした。」
リスクと不確実性の扱い
項目例
- リスク一覧
- 影響度と対応方針
- リスクバッファ
例文
- 「要件の確定度合いが低いため、追加・変更発生リスクが高いと判断し、全体工数の10％をリスクバッファとして見込んでいる。」
- 「外部システムとのIF仕様が未確定であることから、IF1本あたり8時間分の調整工数を追加で計上している。」
対象外・別途見積り項目
項目例
- 対象外の機能
- 対象外の業務
- 別途見積りとする項目
例文
- 「現行システムからのデータ移行は、別途見積りとし、本見積りには含まない。」
- 「操作マニュアルの作成は、標準的な画面操作説明のみを対象とし、業務フローの再設計は対象外とする。」
よくあるNGパターンと改善例
経験と勘だけの説明
- 「過去もこれくらいだったので同じくらいです」
- 「この規模なら2ヶ月くらいでしょう」
改善例：
- 「直近の類似案件（顧客A社向け販売管理システム）では、同規模の機能で実装〜単体テストまで合計300時間であったため、本案件も同程度と見込み、画面数の差分（＋20％）を加味し360時間とした。」
前提条件が書かれていない
後から「そんなつもりではなかった」と揉める原因になります。
改善例：
- 「本見積りでは、『現行システムに大きな仕様変更はない』ことを前提としています。現行仕様の見直しや業務プロセス改革が必要な場合は、別途見積りとなります。」
バッファを隠す
バッファを隠していると、「削れませんか？」と言われたときに守り切れません。
改善例：
- 「技術的な不確実性および要件変更リスクに備え、合計工数の10％（80時間）をリスクバッファとして計上しています。バッファの具体的な使用状況は、定例会で共有します。」
見積り根拠をレビュー・更新するポイント
チームレビューで穴を埋める
- 開発メンバーに「この工数で本当に足りるか」をレビューしてもらう
- テスト担当、インフラ担当など、専門視点からもチェックしてもらう
レビューで得られた指摘は、数字だけでなく根拠の文章にも反映することで、見積りの説得力が増します。
見積り根拠は「生きたドキュメント」にする
- 要件変更や追加があれば、その都度根拠も更新する
- プロジェクト完了時に、「実績」と「見積り根拠」を突き合わせ、次回の改善に活かす
こうすることで、見積り根拠が次のプロジェクトの「武器」になっていきます。
まとめ
最後に、この記事の要点を整理します。
- 見積り根拠は、数字の裏側を説明するための前提・計算方法・参照実績のセット。
- 「前提条件」「スコープ」「工数の算出方法」「バッファの考え方」「対象外」を明文化することで、説明責任と将来の自分を守れる。
- 類推見積り・ボトムアップ・パラメトリックなど、手法ごとに「何を根拠にしたか」を書き分ける。
- カタログ形式で文例をストックしておくと、案件ごとに少しアレンジするだけで、短時間で説得力のある見積り根拠が作れる。
- 見積り根拠は作って終わりではなく、レビューと更新を通じて磨き込むことで、組織としての見積り力が向上する。
