工数見積もりの根拠の出し方｜発注者が確認すべき3つの指標と交渉ポイント

システム開発のベンダーから見積書を受け取り、「要件定義 20人日、設計 30人日、開発 80人日……合計◯人月、金額◯◯万円」と書かれた数字を前に、手が止まっていないでしょうか。金額を見て「なんとなく高い気がする」と感じても、その工数が適正なのか、それとも水増しされているのかを判断する物差しがないと、次の一歩が踏み出せません。

困るのは、ここから先の板挟みです。根拠もなく「高いので下げてください」と言えば、ベンダーとの信頼関係を損ねかねません。かといって提示された数字を鵜呑みにすれば、限られた予算が一気に崩れてしまいます。さらに上司や経営層からは「この金額で妥当なのか、根拠を示してくれ」と言われ、その根拠を自分の言葉で説明できないまま、社内承認も取れず意思決定が止まってしまう。これは、社内に開発の専門家がいない発注担当者が必ずと言っていいほど直面する壁です。

実は、工数見積もりの妥当性は、専門家でなくても「3つの指標」を当てはめることでかなりの精度で読み解けます。工程別の工数比率、画面・機能あたりの工数、人月単価とロール構成。この3つを物差しにすれば、合計値の裏にある算出ロジックが見えてきて、「この数字はなぜこうなっているのか」を自分で検証できるようになります。

本記事では、工数見積もりの根拠の出し方と標準的な目安を整理したうえで、発注者が工数の妥当性を確認するための3つの指標と、その検証結果を建設的な交渉につなげる切り口、そして社内承認を得るための材料の整え方までを順を追って解説します。読み終えるころには、手元の見積書を開いて「ここが標準的、ここは確認が必要」と自分の言葉で語れるようになっているはずです。

工数見積もりの根拠とは何か｜「合計◯人月」だけでは判断できない理由

まずは、工数見積もりの妥当性を検証する前提として、工数とは何か、なぜ合計値だけでは判断できないのかを押さえておきましょう。ここが揃っていないと、3つの指標を当てはめても意味が読み取れません。

工数（人月・人日）の基本と「工数×単価＝金額」の構造

工数とは、その作業にどれだけの人的リソースと時間がかかるかを表した単位です。システム開発では「人月（にんげつ）」と「人日（にんにち）」がよく使われます。

• 1人月 ＝ 1人のエンジニアが1か月（実働でおおむね20日前後）フルタイムで稼働する作業量
• 1人日 ＝ 1人のエンジニアが1日稼働する作業量

つまり「合計5人月」とは、1人なら5か月、5人なら1か月かかる作業量を意味します。1人月をおおよそ20人日と換算すると、5人月は約100人日です。工数・人月の数え方や計算方法をより詳しく確認したい場合は、工数・人月とは？発注者が知るべき計算方法と見積もりの読み方も併せてご覧ください。

そして、システム開発の見積金額は基本的に次の式で決まります。

金額 ＝ 工数（人月）× 人月単価

たとえば合計10人月のプロジェクトで、人月単価が100万円なら、開発費はおおよそ1,000万円になります。ここで重要なのは、金額は「工数」と「単価」という2つの要素の掛け算でしかないという点です。金額が高いと感じたとき、その原因は「工数が多い」のか「単価が高い」のか、あるいはその両方なのかを切り分けないと、どこを検証すればよいのかが分かりません。人月単価の相場については後ほど詳しく触れますが、まずは「金額＝工数×単価」という構造を頭に入れておいてください。

なぜ「合計◯人月」だけでは妥当性を判断できないのか

見積書に「合計15人月」とだけ書かれていても、その数字が妥当かどうかは判断できません。理由は単純で、合計値には算出の根拠（内訳とロジック）が含まれていないからです。

同じ「15人月」でも、その中身が「要件定義に手厚く、テストもしっかり確保された配分」なのか、「開発工程に偏っていてテストがほとんど計上されていない配分」なのかでは、プロジェクトの成否はまったく変わってきます。後者のように見えないところでテスト工数が削られていれば、納品後に不具合が頻発し、結局あとから追加費用が発生することにもなりかねません。

合計値だけを見て交渉に臨むと、「高いか安いか」という水掛け論になりがちです。一方、内訳と算出ロジックが見えていれば、「この工程の比率は標準より厚い／薄い」「この画面数に対してこの工数は妥当か」といった具体的な検証ができ、交渉の土台になります。だからこそ、発注者がまず確認すべきは合計値ではなく、工数がどう積み上げられているかという根拠なのです。

工数の根拠の出し方には型がある

ベンダーが工数を算出する方法には、大きく分けて3つのアプローチがあります。専門的に細かく理解する必要はありませんが、「根拠を説明できる見積もりかどうか」を見極めるために、発注者目線で概要を知っておくと役立ちます。

• 積み上げ式（WBS方式）: 開発に必要な作業を「機能」「画面」「工程」といった細かい単位に分解し、それぞれの工数を積み上げて合計する方法。最も根拠を説明しやすく、内訳が細かいほど検証もしやすくなります。
• 類推式: 過去に手がけた類似プロジェクトの実績工数を基に、規模の違いを補正して見積もる方法。「以前◯◯業界向けに作った同規模のシステムが◯人月だった」という説明ができれば、一定の妥当性があります。
• 係数式（パラメトリック方式）: 画面数・機能数・処理件数などの規模指標に、経験則による係数を掛けて算出する方法。「画面1枚あたり◯人日」のように、ある程度ざっくりと規模から逆算します。

ここで見極めたいのは、ベンダーが**「なぜこの工数になるのか」を説明できるかどうか**です。「だいたいこのくらいです」としか答えられない見積もりは、根拠が積み上げられていない可能性が高く、注意が必要です。逆に、内訳を分解して根拠を示せる見積もりは、たとえ金額が高くてもどこにコストがかかっているかが透明で、検証も交渉もしやすくなります。

工数見積もりの根拠を読み解く3つの指標

ここからが本記事の核心です。発注者が工数の妥当性を検証するための物差しとして、次の3つの指標を使います。

1. 工程別の工数比率
2. 画面・機能あたりの工数
3. 人月単価とロール構成

それぞれについて「標準の目安 → 自分の見積もりへの当てはめ方 → ベンダーへの確認質問」の順で解説します。3つすべてが完璧に当てはまる見積もりは多くありませんが、3つの視点から見ることで、どこに違和感があるのかを具体的に特定できるようになります。

指標①｜工程別の工数比率

システム開発は、おおまかに「要件定義 → 設計 → 開発（製造） → テスト」という工程を経て進みます。各工程にどれくらいの工数を配分するかには、業界で共有されている標準的な目安があります。

各種の解説や公的データを総合すると、一般的な工程別の工数配分の目安は次のとおりです（Y's｜システム開発の工程比率とは）。

特に注目したいのがテスト工程です。情報処理推進機構（IPA）の調査では、結合テストと総合テストにかかる実績工数の中央値が合計で約32%に達するというデータもあり、テストは品質を担保するうえで決して軽視できない工程です（IPA ソフトウェア開発分析データ集 2022）。

自分の見積もりへの当てはめ方は単純です。見積書の各工程の人日（または人月）を合計工数で割り、それぞれの比率を計算してみてください。たとえば合計100人日のうちテストが5人日（5%）しか計上されていなければ、標準の15〜25%と比べて極端に薄いことが分かります。これは「テストを十分にやらない＝品質リスク」というサインかもしれませんし、「テストを別契約として切り出している」だけかもしれません。いずれにせよ、確認すべきポイントとして浮かび上がります。

逆に、要件定義の比率が極端に薄い場合も要注意です。要件定義が甘いまま開発に進むと、後工程で手戻りが発生し、結果的に総工数が膨らむことが少なくありません。

ベンダーへの確認質問例 「各工程の工数配分を拝見すると、テスト工程が全体の◯%となっています。一般的な目安より少し低いように見えるのですが、この比率にされた理由を教えていただけますか。テストの範囲はどこまで含まれていますか？」

指標②｜画面・機能あたりの工数

2つ目の指標は、開発する画面や機能の数から工数を逆算する見方です。多くの業務システムは「画面」や「機能」の集合体なので、「画面1枚あたり何人日か」「1機能あたり何人日か」を見ると、工数の妥当性をざっくり検証できます。

ただし、ここで強調しておきたいのは、画面・機能あたりの工数は規模や複雑度によって大きく幅があるという点です。単純な一覧表示の画面と、複雑な検索条件・帳票出力・外部システム連携を伴う画面とでは、必要な工数がまったく異なります。そのため「1画面◯人日が正解」という固定値は存在せず、あくまで「桁が大きくずれていないか」を確認するための目安として使います。

自分の見積もりへの当てはめ方としては、まず見積もりの対象となる画面数・機能数をベンダーに確認し、開発工程の工数を画面数で割ってみます。たとえば開発工程が80人日で画面が40枚なら、1画面あたり平均2人日という計算になります。この数字を見て、「シンプルな画面が多いのに1画面あたりの工数が大きい」あるいは「複雑な処理が多いのに工数が小さすぎる」といった違和感がないかをチェックします。

重要なのは、平均値だけでなく画面ごとの難易度のばらつきを意識することです。すべての画面を一律の工数で見積もっている場合、複雑な画面の工数が不足していて後から膨らむ、あるいは単純な画面に過剰な工数が乗っている、というケースが起こり得ます。

ベンダーへの確認質問例 「今回の開発対象は◯画面とのことですが、開発工数を画面数で割ると1画面あたり平均◯人日になります。画面ごとに難易度の差は大きいと思うのですが、特に工数が大きい画面・小さい画面はどれで、その理由は何でしょうか？」

指標③｜人月単価とロール構成

3つ目の指標は、工数そのものではなく「1人月あたりいくらか（人月単価）」と「どんな役割（ロール）の人材が何人月分積まれているか」という単価側の視点です。冒頭で触れた「金額＝工数×単価」のうち、単価の妥当性を検証する指標です。

人月単価は、担当するエンジニアの役割・スキルレベルによって大きく変わります。各種の相場情報を総合すると、ロール別の人月単価の目安はおおむね次のような幅です（発注ラウンジ｜人月単価とは、セラク｜エンジニアの単価相場）。

このうち、PM・システムアナリスト・プログラマーの単価は発注ラウンジの掲載値を、上級・中堅システムエンジニアの単価はセラクのスキルレベル別（経験年数別）の相場を参照しています。これらの単価は、スキル・経験年数・地域（首都圏か地方か）・プロジェクトの内容によって変動します。あくまで目安として捉えてください。

自分の見積もりへの当てはめ方として確認したいのは、単価の高いロールが何人月分積まれているかです。たとえば、比較的単純な開発であるにもかかわらず、PMや上級SEといった高単価人材の工数が大きく計上されていると、その分だけ金額が押し上げられます。もちろん難易度の高いプロジェクトでは上級人材の関与が必要ですが、「なぜこの規模でPMが◯人月も必要なのか」を確認する余地はあります。

見積書にロール別の内訳（誰がどの工程に何人月）が記載されていない場合は、その内訳の提示を求めましょう。ロール構成が見えると、単価のどこにコストがかかっているかが透明になります。

ベンダーへの確認質問例 「工数の内訳を、担当ロール別（PM・SE・PGなど）に分けて教えていただけますか。特にPM・上級SEの工数が全体に占める割合と、その役割を担っていただく理由を伺いたいです。」

提示された工数見積もりを発注者がチェックする手順

3つの指標を理解したら、次は実際の見積書に当てはめる手順に落とし込みます。順番に進めることで、抜け漏れなく工数の根拠を読み解けます。

チェックの前提｜「対象範囲（スコープ）」が明記されているか

指標を当てはめる前に、必ず確認すべき前提があります。それは、その見積もりがどこまでの範囲（スコープ）を対象にしているかです。

工数の妥当性は、対象範囲が定まって初めて評価できます。たとえば「画面30枚分」と「画面50枚分」では当然工数が変わりますし、「テストは結合テストまで」なのか「本番運用を見据えた総合テストまで」なのかでも大きく異なります。スコープが曖昧なまま「合計◯人月」だけを比較しても意味がありません。

見積書や提案書に、次のような前提条件が明記されているかを確認してください。

• 開発対象の機能・画面の範囲（一覧があるか）
• 含まれる工程（要件定義から運用テストまでのどこからどこまでか）
• 前提となる技術・環境（既存システムとの連携の有無など）
• 含まれないもの（スコープ外として明示されている項目）

これらが曖昧な場合は、指標の検証に入る前に、まずスコープの明確化をベンダーに依頼しましょう。

3つの指標を当てはめる手順

スコープが確認できたら、先ほどの3つの指標を次の順番で当てはめていきます。

1. 工程比率を見る: 各工程の工数を合計で割り、要件定義・設計・開発・テストの比率を算出する。標準の目安と比べて極端に厚い／薄い工程がないかを確認する。
2. 画面・機能あたりの工数を見る: 開発工程の工数を画面数・機能数で割り、1画面（1機能）あたりの平均工数を出す。桁が大きくずれていないか、難易度のばらつきが反映されているかを確認する。
3. 人月単価とロール構成を見る: 人月単価が相場の幅に収まっているか、高単価ロールの工数配分に納得できるかを確認する。

この3ステップで「標準的に見える部分」と「確認が必要な部分」を仕分けし、確認が必要な部分について先ほど紹介した質問例を使ってベンダーに問い合わせます。

見落としやすい工数

最後に、3つの指標だけでは見えにくく、トラブルの原因になりやすい工数を挙げておきます。これらが過少（または過剰）になっていないかも併せて確認してください。

• テスト工数: 前述のとおり、品質に直結する重要工程です。極端に薄い場合は要確認です。
• バッファ・リスク工数: 想定外の事態に備えた予備工数。ゼロだと無理のある計画になりがちですが、過大すぎても水増しの可能性があります。「どの程度のバッファを、なぜ見込んでいるか」を確認できると安心です。
• 保守・運用工数: 納品後の保守運用が見積もりに含まれるのか、別契約なのかは必ず確認しましょう。含まれていないのに含まれていると思い込むと、後から想定外の費用が発生します。
• プロジェクト管理工数（PM工数）: 進行管理・打ち合わせ・ドキュメント作成などの工数。指標③のロール構成と合わせて、妥当な範囲かを確認します。

工数の根拠を踏まえた交渉ポイント｜値切りではなくスコープを問い直す

3つの指標で検証を終えたら、その結果を交渉につなげます。ここで大切なのは、「高いから下げてください」という値切りではなく、根拠を起点にした建設的な交渉にすることです。値切りはベンダーとの信頼関係を損ない、結果的に品質を削る方向に働きかねません。

交渉の基本姿勢｜「高い／安い」ではなく「根拠を教えてください」から入る

交渉の入り口は、否定ではなく質問です。「この金額は高い」と切り出すのではなく、「この工数の根拠を教えてください」と尋ねるところから始めます。

この姿勢には2つの効果があります。1つは、ベンダーを敵に回さず、対等なパートナーとして議論できること。もう1つは、ベンダー自身に工数を再説明してもらう過程で、過剰に乗っていた工数が自然に見直される余地が生まれることです。根拠を問われて初めて「ここは少し多めに見積もっていました」と調整が入るケースは珍しくありません。

検証で見つけた違和感（テスト比率が薄い、特定の画面の工数が大きい、高単価ロールの比重が高いなど）について、先ほどの質問例を使って一つずつ確認していきましょう。

スコープ調整による工数削減

工数そのものを削るのが難しい場合でも、スコープ（開発範囲）を調整することで工数と金額を抑えられる余地があります。これは値切りとは異なり、「何を作るか」を見直すアプローチなので、品質を犠牲にせずにコストを下げられる可能性があります。

• 優先度の低い機能を後回しにする: すべての機能を初期リリースに詰め込まず、「最初は必須機能だけ」に絞ることで初期工数を削減できます。
• フェーズ分割（段階的リリース）: プロジェクトを複数フェーズに分け、初期投資を抑えながら段階的に開発する方法です。初期工数が下がるだけでなく、第1フェーズの結果を見て次の判断ができる利点もあります。
• 既製品・SaaSの活用: ゼロから開発する予定だった機能の一部を、既存のパッケージやSaaSで代替できないかを検討します。該当すれば、その機能の開発工数をまるごと削減できます。

「予算は◯◯万円が上限なので、その中に収めるとしたら、どの機能を後フェーズに回すのが現実的でしょうか」とベンダーに相談すると、専門家の視点から優先順位の提案を引き出せます。

そのまま使える確認・交渉の質問文例

最後に、3つの指標それぞれに対応する質問文例をまとめておきます。見積書を前に、そのまま使える形にしています。

• 工程比率について: 「各工程の工数配分を拝見しました。テスト工程が全体の◯%ですが、想定しているテストの範囲（単体・結合・総合）はどこまででしょうか。品質面で十分な工数が確保されているか確認したいです。」
• 画面・機能あたりの工数について: 「開発工数を画面数で割ると1画面あたり平均◯人日でした。難易度の高い画面と低い画面で工数にどの程度の差をつけているか、内訳を教えていただけますか。」
• ロール構成について: 「工数をロール別（PM・SE・PG）に分けた内訳をいただけますか。特にPM・上級SEの工数配分の根拠を伺いたいです。」
• スコープ調整について: 「予算の上限が◯◯万円です。この範囲に収めるとしたら、どの機能を後フェーズに回す、あるいは既製品で代替するのが現実的か、ご提案いただけますか。」

これらの質問は、いずれも「根拠を確認する」スタンスで構成されています。ベンダーにとっても答えやすく、結果として双方が納得できる見積もりに近づけられます。

工数の妥当性を社内に説明し、承認を得るための材料整理

工数を検証し、交渉の方向性が見えても、最後に残る壁が「社内承認」です。上司や経営層に「この工数・金額で妥当だ」と納得してもらえなければ、プロジェクトは前に進みません。ここでは、検証・交渉の結果を社内承認用の材料にまとめる方法を解説します。

社内承認で問われる3つの観点

上司や決裁者が見積もりの承認を判断するとき、突き詰めると次の3つの観点で問われることがほとんどです。あらかじめこの3つに答えられる形で材料を準備しておくと、承認がスムーズに進みます。

1. なぜこの工数なのか（根拠）: 工数がどう積み上げられているか、内訳と算出ロジックを説明できるか。
2. 標準・他社と比べてどうか（妥当性）: 工程比率や人月単価が業界の標準的な目安と比べて妥当な範囲か。
3. 削減余地は検討したか（コスト意識）: 値切りではなく、スコープ調整やフェーズ分割などの削減策を検討したうえでこの金額に至ったか。

この記事で解説してきた3つの指標による検証は、そのまま「1. 根拠」と「2. 妥当性」への回答になります。そして交渉ポイントで紹介したスコープ調整の検討は「3. 削減余地」への回答です。検証の作業がそのまま社内説明の材料になる、という点を意識して進めると効率的です。

検証・交渉の結果を1枚に整理する

社内説明では、詳細な見積書をそのまま見せるよりも、ポイントを1枚（1ページ）に整理した資料のほうが伝わります。次のような構成でまとめると、3つの観点に過不足なく答えられます。

• 工数の概要: 合計工数（人月）と金額、対象スコープを簡潔に。
• 標準目安との対比: 工程比率を標準の目安（要件定義10〜15%、設計20〜30%、開発30〜40%、テスト15〜25%）と並べ、自社の見積もりが標準的な範囲に収まっていることを示す。人月単価も相場の幅と対比する。
• 確認した根拠: ベンダーに質問して得られた回答のうち、妥当性を裏づける重要なものを箇条書きで。
• 検討した削減策と結果: スコープ調整・フェーズ分割などをどう検討し、その結果として最終的な工数・金額がどうなったか。「◯◯機能を後フェーズに回し、初期工数を◯人月削減した」のように、検討した事実を残すことが重要です。

このように整理すれば、決裁者は「担当者が根拠を理解し、標準と照らし合わせ、削減余地まで検討したうえで提示している」と判断でき、承認に踏み切りやすくなります。逆に言えば、合計金額だけを持っていっても「なぜこの金額なのか」を問われて差し戻されるだけです。検証の過程で得た情報を捨てずに1枚にまとめることが、意思決定を前に進める鍵になります。

まとめ｜工数の根拠を3つの指標で読めば、発注の意思決定は前に進む

システム開発の工数見積もりは、「合計◯人月」という数字だけを見ても妥当性を判断できません。判断の物差しになるのは、内訳と算出ロジック、すなわち工数の根拠です。

本記事では、発注者が工数の根拠を読み解くための3つの指標を解説しました。

1. 工程別の工数比率: 要件定義・設計・開発・テストの配分が標準的な目安に収まっているか。特にテスト工程が極端に薄くないか。
2. 画面・機能あたりの工数: 画面数・機能数から逆算した工数に、桁の大きなずれや難易度の無視がないか。
3. 人月単価とロール構成: 人月単価が相場の幅に収まっているか、高単価ロールの工数配分に納得できるか。

これらを実際の見積書に当てはめるときは、まず対象範囲（スコープ）の明記を確認したうえで、3つの指標を順に当てはめ、テスト・バッファ・保守運用といった見落としやすい工数も併せてチェックします。そして検証で見つけた違和感は、「高い」という否定ではなく「根拠を教えてください」という質問から交渉を始め、必要に応じてスコープ調整やフェーズ分割で工数を抑えます。最後に、検証と交渉の結果を1枚に整理すれば、そのまま社内承認の材料になります。

まずは手元の見積書を開き、各工程の工数を合計で割って比率を出すところから始めてみてください。たった一つの計算でも、「この工程は標準より厚い／薄い」という具体的な気づきが得られ、ベンダーへの最初の質問が見えてきます。工数の根拠を自分の言葉で読み解けるようになれば、根拠なく板挟みになっていた状況から抜け出し、発注の意思決定を自信を持って前に進められるようになります。