「この工数の根拠は何ですか」。自分で作った見積もりを提出した直後、上司や顧客からこう聞かれて、言葉に詰まってしまった経験はないでしょうか。設計に1ヶ月、開発に2ヶ月、テストに2週間。エクセルに工程と日数を並べてみたものの、いざ「なぜその数字なのか」を問われると、はっきり答えられない。そんな不安を抱えたまま見積書を出している方は少なくありません。
困るのは、根拠を説明できないと「見積もりが甘いのでは」と疑われたり、値切られたときに守れなかったりすることです。さらに厄介なのは、自分自身でも「本当にこの工数で足りるのか」と確信が持てないことです。なんとなく置いた数字は、後から少し前提が変わっただけで簡単に崩れてしまいます。
実は、根拠のある工数見積もりとは、特別な才能や長年の勘で出すものではありません。「作業を細かく分解し、分解した一つひとつに、なぜこの工数なのかという理由を添える」という、地道な手順の積み重ねです。やり方さえ押さえれば、経験の浅い方でも「説明できる見積もり」を作れるようになります。
本記事では、見積もりを作る側の視点に立って、作業をWBS（作業分解構造）で分解し、各タスクに工数と一行の根拠を置き、前提条件とバッファを明示して、聞かれてもすぐ答えられる見積書に仕上げるまでの手順を解説します。手元の見積もりに筋の通った理由を持たせたい方は、ぜひ最後まで読み進めてください。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
工数見積もりの「根拠」とは｜説明できる見積もりとできない見積もりの差
まず押さえておきたいのは、「根拠のある工数」とはどういう状態を指すのか、という定義です。ここがあいまいなまま手を動かすと、結局また「なんとなくの数字」に戻ってしまいます。
「根拠がある工数」とは、なぜその数字かを一行で説明できる工数のこと
根拠のある工数とは、ひとことで言えば「なぜこの数字なのかを、一行で言葉にできる工数」です。
たとえば「ログイン画面の実装に3人日」という数字があったとき、「過去に同じような認証付き画面を3人日で作った実績があるから」と即答できれば、それは根拠のある工数です。逆に「だいたいそのくらいかな、と思ったから」しか出てこなければ、根拠のない工数ということになります。
この違いは、見積もりの正確さそのものよりも、「説明できるかどうか」にあります。多少ずれていても、「画面が3つあって、1画面あたり1人日で見積もったので3人日です」と説明できれば、相手は数字の妥当性を判断できますし、認識がずれていればその場で擦り合わせられます。説明できる工数は、議論のテーブルに乗せられる工数なのです。
工数や人月といった単位そのものの考え方に不安がある場合は、工数・人月とはを先に確認しておくと、本記事の内容がより理解しやすくなります。
なんとなく置いた工数が後で崩れる理由
なんとなく置いた工数が後で崩れるのは、その数字の「前提」が言語化されていないからです。
「開発に2ヶ月」とだけ置いた見積もりを考えてみます。この2ヶ月には、本来なら「画面が10枚で、外部システム連携はなし、テストデータは先方支給」といった前提が含まれているはずです。ところが、その前提が頭の中だけにあって書き出されていないと、後から「画面は15枚だった」「連携が1本あった」と判明したときに、なぜ工数が増えるのかを説明できません。相手から見れば「最初の見積もりが甘かった」としか映らないのです。
根拠のない工数は、前提が変わったときに守れない工数です。逆に言えば、各工数がどんな前提・どんな作業の積み上げで成り立っているかを書き残しておけば、状況が変わっても「ここの前提がこう変わったので、この分だけ工数が増えます」と筋を通して説明できます。これが、説明できる見積もりとできない見積もりの分かれ道です。
根拠を持って工数を積み上げる手順｜作業分解（WBS）から始める
ここからが本記事の中心です。根拠のある工数を組み立てる手順を、作業分解（WBS）を起点に解説します。流れはシンプルで、「作業を分解する → 分解した各タスクに工数を置く → その工数に根拠を一行添える」の3ステップです。
WBS（Work Breakdown Structure＝作業分解構造）とは、やるべき作業を細かく分解して構造的に整理したものです（WBS法【見積もり】とは）。難しく考える必要はなく、「大きな仕事を、見積もれる大きさの小さな仕事に割っていく」作業だと捉えてください。
まず作業を分解する
最初にやるのは、開発全体を機能単位・工程単位の小さなタスクに割っていくことです。
たとえば「会員管理機能」を一気に見積もろうとすると、大きすぎて勘に頼るしかありません。そこで、次のように分解します。
- 会員登録画面（入力フォーム・バリデーション・登録処理）
- 会員一覧画面（検索・一覧表示・ページング）
- 会員詳細・編集画面（表示・更新処理）
- 会員削除処理（論理削除・確認ダイアログ）
ここまで割ると、一つひとつが「だいたいこのくらい」と見積もれる大きさになります。大きな塊のままだと根拠を持てないのは、その中に無数の作業が隠れていて把握しきれないからです。「見積もれる大きさ」になるまで割る、というのが分解の目的です。
工程単位（要件定義・設計・開発・テスト）で割る軸と、機能単位（会員管理・商品管理・注文管理）で割る軸を組み合わせると、抜け漏れに気づきやすくなります。実務では、機能ごとに設計・開発・テストの工数をそれぞれ置く形がよく使われます。
分解したタスクごとに工数を置く
作業を分解したら、一つひとつのタスクに工数を置いていきます。このとき頼りにするのが、「過去の類似作業」と「標準的な作業量」です。
過去に似た作業をした実績があれば、それが一番強い根拠になります。「前のプロジェクトで似た検索画面を2人日で作った」のであれば、今回の検索画面も2人日を起点に、条件の複雑さで微調整すればよいわけです。実績がない場合は、「単純なCRUD画面なら1画面あたり1人日」といった、自分やチームの標準的な作業量を基準にします。
タスクごとに工数を積み上げて全体を出すこの方法は、ボトムアップ見積もり（積み上げ法）と呼ばれます。一つひとつの根拠が明確になるため、全体の計画も見通しやすくなるのが利点です（失敗しない工数見積の手法やポイント）。
このとき注意したいのは、設計・開発だけでなく、レビュー・単体テスト・結合テスト・ドキュメント作成・打ち合わせといった「開発以外の作業」も忘れずにタスクとして置くことです。これらが抜けると、後から「思ったより時間がかかった」という形で工数が崩れます。
各工数に「なぜこの数字か」を一行で添える
分解とタスクごとの工数づけができたら、それぞれの工数に「なぜこの数字か」という一行の根拠を添えます。これが、説明できる見積もりにするための最も大事な一手間です。
たとえば、こう書き添えます。
- 会員登録画面：3人日（類似の入力フォームを過去2人日で実装、今回はバリデーションが多めのため+1人日）
- 会員一覧画面：2人日（単純な検索・一覧のため標準工数1人日×2、ページング込み）
- 外部API連携：5人日（実装経験のない決済APIのため、調査込みで幅をもって設定）
この一行があるだけで、見積もりの説明力はまったく変わります。相手から「会員登録だけで3人日もかかるの？」と聞かれても、「バリデーションが多いので通常より1人日積んでいます。要件を絞れば2人日に圧縮できます」と即答できます。根拠を一行残しておくことが、「聞かれて答えに詰まる」状態から抜け出す近道です。
分解が粗いと根拠も粗くなる｜どこまで細かく割るかの目安
ここで多くの人が迷うのが、「どこまで細かく割ればいいのか」という点です。
目安としては、1タスクが「数時間〜2、3人日程度で完了する大きさ」まで割るのが扱いやすいとされています。1タスクが1週間を超えるようだと、まだ中に複数の作業が隠れている可能性が高く、根拠も粗くなりがちです。逆に、30分単位まで割ると今度は数が膨大になって管理しきれません。
分解が粗いと根拠も粗くなる、というのは覚えておきたい原則です。「開発：30人日」とだけ置いた見積もりは、なぜ30人日なのかを説明できません。しかし、それを15個のタスクに割り、それぞれに1〜3人日の根拠を添えれば、合計の30人日には15個分の説明が裏付けとして付いてきます。分解の細かさが、そのまま根拠の強さに直結するのです。
ただし、要件がまだ固まっていない段階では、無理に細かく割っても精度は上がりません。その場合は「この機能群でおおよそ◯人日（要件確定後に再見積もり）」と粒度を粗いまま正直に示し、再見積もりの前提を明記しておくほうが誠実です。
工数の根拠を強くする3つの要素｜前提・バッファ・難易度の織り込み方
作業を分解して工数を積み上げたら、次はその工数を「説明に耐える」レベルまで強くしていきます。鍵になるのは、前提条件・バッファ・難易度という3つの要素です。
前提条件を明示する
工数は、必ず何らかの前提の上に成り立っています。その前提を見積もりに書き出しておくことが、根拠を守るための土台になります。
書いておきたい前提は、たとえば次のようなものです。
- スコープ：何を含み、何を含まないか（例：管理画面は対象外、データ移行は別途）
- 体制：何人で、どのスキルレベルの人が担当するか
- 環境：開発環境・テストデータ・既存システムの仕様書は誰が用意するか
- 進め方：仕様確定の期限、レビューや承認のサイクル
前提を明示する最大の効果は、「前提が変われば工数が変わる」と相手に伝えられることです。「テストデータは先方支給という前提で、その作成工数は含んでいません」と書いておけば、後から「テストデータも作って」と言われたときに、追加工数を正当に主張できます。前提条件は、見積もりを後から守るための盾になるのです。
バッファは「隠す」のではなく「根拠とともに見せる」
不確実な作業に対しては、バッファ（余裕）を持たせることが欠かせません。どれだけ正確に見積もっても、不測の事態は必ず起こるからです（工数見積もりに失敗しないコツ）。
ここで大事なのは、バッファを各タスクにこっそり水増しして隠してしまわないことです。隠したバッファは、後から「ここは盛っているのでは」と疑われたとき、何も説明できません。代わりに、「不確実な箇所にいくら積んだか」を根拠とともに見せる形をおすすめします。
たとえば「外部API連携は実装経験がないため、調査と試行錯誤の分として2人日のバッファを別建てで計上」と書いておけば、バッファそのものが根拠を持った工数になります。どこに、なぜ、いくら積んだかが明確なので、相手も納得しやすく、リスクが解消されればバッファを減らす交渉にも応じられます。
不確実性の高いタスクには、三点見積もりという考え方も有効です。これは、各タスクについて「うまくいった場合（楽観値）」「通常かかる時間（最頻値）」「最悪の場合（悲観値）」の3つを見積もり、(楽観値 + 最頻値×4 + 悲観値) ÷ 6 という式で期待値を出す方法です（三点見積り法とは）。たとえば楽観値2人日・最頻値5人日・悲観値10人日なら、(2 + 5×4 + 10) ÷ 6 ≒ 5.3人日となります。最悪のケースも織り込んだうえで一つの数字に落とせるため、バッファの根拠を数値で示しやすくなります。
難易度・未経験要素を工数に織り込む
同じ「画面1枚」でも、何度も作ったことのある画面と、初めて扱う技術を使う画面とでは、必要な工数がまったく違います。この難易度の差を工数に反映させることも、根拠の一部です。
過去に実績のある作業は、その実績値をそのまま使えるため、工数を一点で置けます。一方、過去実績がない作業（新しいフレームワーク、未経験の外部サービス連携、複雑なアルゴリズムなど）は、調査や試行錯誤の時間が読みにくいため、幅を持って見積もるのが現実的です。
「この作業は経験がないため、最短3人日・最長6人日。間を取って5人日で計上し、調査の結果次第で見直し」というように、難易度の高さを工数の幅として表現します。一点で「5人日」とだけ置くより、「なぜ幅があるのか」「どういう条件で上下するのか」まで示すほうが、はるかに説明力のある根拠になります。
根拠を残す見積書のまとめ方｜聞かれてもすぐ答えられる形にする
ここまでで、作業を分解し、工数を積み上げ、前提・バッファ・難易度で根拠を厚くしてきました。最後は、それらを相手に提出できる見積書の形に落とし込み、「聞かれてもすぐ答えられる」状態に仕上げます。
工程・作業単位で工数を並べ、合計人月は「結果」として示す
見積書では、合計人月をいきなり大きな数字として出すのではなく、工程・作業単位の工数を並べ、その合計として総工数を示す形にします。
具体的には、機能や工程ごとに行を立て、それぞれの工数を並べます。
工程・作業 | 工数 |
|---|---|
要件定義 | 5人日 |
基本設計 | 8人日 |
会員管理機能（設計・開発・テスト） | 12人日 |
商品管理機能（設計・開発・テスト） | 10人日 |
結合テスト | 6人日 |
不確実性バッファ（外部連携の調査分） | 3人日 |
合計 | 44人日（約2.2人月） |
このように内訳から積み上げて合計を示すと、「なぜ合計2.2人月なのか」が一目で伝わります。合計人月は最初に決める数字ではなく、各作業の積み上げの「結果」として出てくる数字だ、という考え方が根拠のある見積もりの基本です。
前提条件は見積書に必ず添える
見積書には、本体の工数表とは別に、前提条件をまとめた欄を必ず設けます。口頭で「これは含んでいません」と補足しても、記録に残らなければ後で「言った・言わない」になってしまいます。
前提条件の欄には、先ほど整理したスコープ・体制・環境・進め方の前提を箇条書きで記載します。たとえば「本見積もりは画面10枚を前提とし、追加画面は別途見積もり」「データ移行・既存システム改修は範囲外」「テスト環境は貴社にてご用意いただく前提」といった具合です。前提を書面に残しておくことが、提出後の認識ずれを防ぎ、自分の工数を守る最大の防御になります。
根拠メモを手元に残す
見積書本体には書ききれない細かい根拠は、自分の手元に「根拠メモ」として残しておきます。これは相手に提出するものではなく、自分が説明に詰まらないための備えです。
根拠メモには、各タスクの工数の横に「なぜこの数字か」を一行ずつ書いておきます。先ほど作業分解のステップで添えた一行の根拠を、そのまま手元に保管しておくイメージです。「会員登録3人日＝過去実績2人日＋バリデーション多めで+1」のようなメモが残っていれば、提出から数週間後に「あの工数の根拠は？」と聞かれても、メモを見れば即座に答えられます。
人の記憶は驚くほど早く薄れます。見積もりを出した瞬間は根拠を覚えていても、別の仕事を挟むと「なぜこの数字にしたんだっけ」と分からなくなるものです。根拠メモは、未来の自分を助けるための保険だと考えてください。
提示後に発注者がどう見るかを知っておく
最後に、自分の見積もりが相手にどう見られるかを知っておくと、より説得力のある見積書を作れます。
発注者の側は、提示された工数を「工程別の比率は妥当か」「画面・機能あたりの工数は適正か」「見落とされている作業はないか」といった視点で読み解き、必要に応じて検証や交渉を行います。発注者がどんな観点で工数をチェックし、どう交渉してくるかについては、工数見積もりの根拠の確認方法で発注者側の視点から詳しく解説しています。相手の見方を先回りして知っておくと、「ここは突っ込まれそうだから根拠を厚くしておこう」と備えられ、結果として崩れにくい見積もりになります。
まとめ｜作業を分解し根拠を添えれば、工数見積もりは説明できるようになる
ここまで、根拠のある工数見積もりの作り方を順番に見てきました。最後に流れを整理します。
- 根拠のある工数とは、「なぜこの数字かを一行で説明できる工数」のこと
- まず作業をWBSで分解し、「見積もれる大きさ」の小さなタスクに割る
- 各タスクに、過去実績や標準作業量を基準に工数を置き、「なぜこの数字か」を一行添える
- 前提条件・バッファ・難易度の3要素で、工数の根拠を説明に耐えるレベルまで厚くする
- 工程・作業単位で工数を並べ、合計人月は積み上げの結果として示し、前提条件と根拠メモを残す
これらは特別な才能を必要とする作業ではありません。「大きな仕事を小さく割り、一つひとつに理由を添える」という地道な手順の積み重ねです。
まずは、手元にある見積もりを一つ取り出して、作業を分解してみてください。そして、各工数の横に「なぜこの数字か」を一行ずつ書き添えてみましょう。それだけで、次に「この工数の根拠は？」と聞かれたとき、落ち着いて答えられる自分に近づいているはずです。根拠を持って説明できる見積もりは、あなた自身の仕事への信頼にもつながっていきます。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 工数の根拠を一行添えるとき、過去実績がまったくない作業はどう書けばよいですか？
「未経験のため幅をもって設定」と正直に書き、最短・最長の幅と前提を残します。たとえば「決済API連携：最短3人日・最長6人日、調査込みで5人日計上、結果次第で見直し」と書けば、一点で置くより説明力のある根拠になります。
- 根拠を添えた工数を「もっと安くできないか」と値切られたら、どう守ればよいですか？
工数そのものを削るのではなく、前提や範囲を動かして交渉します。「バリデーションを絞れば2人日に圧縮できます」「外部連携を外せば調査分3人日は不要です」と、何を諦めれば何人日減るかを根拠とセットで示せば、値切り交渉を範囲の調整に置き換えられ、理由のない安売りを避けられます。
- 前提条件を見積書に明記したのに、後から「そんな前提は聞いていない」と覆されたらどうすればよいですか？
口頭ではなく、見積書に書いた前提条件の欄を根拠に立ち返ります。「本見積もりはテストデータ先方支給を前提と明記しています」と書面を示し、前提が変わるなら追加工数が発生する旨を改めて提示します。前提を書面に残しておくことが、こうした蒸し返しに対して工数を守る唯一の盾になります。
- 次の見積もりの精度を上げるために、日頃からどんな記録を残しておけばよいですか？
見積工数だけでなく、実際にかかった工数と差が出た理由を作業単位で残しておくのが効果的です。「会員登録は3人日見積もりで実績4人日、バリデーション仕様の変更が原因」のように記録すれば、次回似た作業の見積もり根拠になり、自分なりの標準工数の精度も少しずつ上がっていきます。
- 積み上げた工数の合計が、相手の予算や希望納期にどうしても収まらないときは、どう調整すればよいですか？
全タスクを一律に削るのではなく、優先度の低い機能やバッファを根拠付きで外して調整します。「会員削除は今回見送れば3人日減らせます」と、どのタスクを削れば何人日縮むかを示せば、相手も納得して取捨選択できます。根拠が一行ずつ残っていれば、削る判断もその場で説明できます。
