複数のベンダーから受託開発の見積書を受け取ったものの、金額に大きな幅があり、どれが妥当なのか判断できずに困っていないでしょうか。数百万円から数千万円という規模になると、「この金額は高いのか、それとも安いのか」を自力で見極められないまま、上司への説明にも窮してしまうことがあります。
相場を扱った記事は世の中に数多くあります。しかし、そのほとんどは「小規模なら○○万円、中規模なら○○万円」という総額レンジを示すだけで終わってしまいます。総額の目安が分かっても、手元の見積書が「設計費に偏っているのか」「テスト費が薄すぎるのか」までは判定できません。発注経験がなければ、ベンダーの言い値を検算する物差しそのものを持っていないのが実情です。
この記事で提案するのは、相場表を眺めるのをやめて「配分比率の物差し」を持つという発想の転換です。受託開発の費用は、規模に応じて工程ごとの配分比率がおおよそ決まっています。その比率を早見表として手元に置き、受け取った見積書を工程ごとに逆算して突き合わせれば、「どこが膨らんでいるのか」「どこが薄すぎるのか」を自分の目で確認できます。
本記事では、まず規模別の総額目安を出発点として確認したうえで、規模別×工程別の費用配分比率の早見表を提示します。そのうえで、受け取った見積書を逆算して妥当性を検算する5つのステップを計算例つきで解説し、最後に検算結果を社内承認の説明材料に変える方法までを順を追って説明します。読み終えるころには、見積書の金額を自分の言葉で評価できるようになっているはずです。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
受託開発の費用相場を「規模別の総額目安」でつかむ
検算を始める前に、まず自分の案件がどの規模帯に属するのかを把握しておく必要があります。配分比率の早見表は規模帯ごとに数値が変わるため、規模の特定が検算の出発点になります。ここでは総額レンジを「答え」としてではなく「当てはめる枠を決めるための起点」として確認していきましょう。
受託開発の費用は「人月単価 × 工数」で決まる
受託開発の費用は、突き詰めれば「人月単価 × 工数（人月）」というシンプルな式で計算されます。人月単価とは、エンジニア1人が1ヶ月（通常160時間程度）稼働した場合の費用のことです。工数とは、その作業に何人月かかるかという見積もりです。たとえば人月単価100万円のエンジニアが5人月分の作業をすれば、500万円という計算になります。
見積書の金額が一見複雑に見えても、その根っこにあるのはこの掛け算です。人件費が開発費用全体の60〜70%を占めることが多く（ICD「システム開発の費用相場とは？」）、受託開発の費用は基本的に人にかかるコストの集積だと理解しておくと、後の検算が腹落ちしやすくなります。
人月単価のレンジそのものや、エンジニアの職種・スキルによる単価差については、見積書の妥当性を見抜くチェック項目とあわせてシステム開発費用の妥当性を見抜く見積書チェックで詳しく整理しています。本記事では人月単価の詳細には深入りせず、「費用は人月の積み上げである」という前提だけ押さえて先に進みます。
規模別の総額目安と、その「幅」が生まれる理由
2026年時点の受託開発の総額目安は、おおむね次のように整理できます。これはあくまで枠を決めるための参考値であり、案件によって上下に振れる点に注意してください。
規模帯 | 総額の目安 | 想定される内容 |
|---|---|---|
小規模 | 100万〜500万円 | シンプルなWebシステム、機能を絞った業務ツール |
中規模 | 500万〜2,000万円 | 予約システム、社内基幹の一部、マッチング機能を含むアプリ |
大規模 | 2,000万円〜数億円 | 基幹システム全体、大規模な業務システム、複数システム連携 |
（参考: ICD「システム開発の費用相場とは？」、シースリーインデックス「基幹システムの費用相場2026年版」）
同じ「中規模」でも500万円と2,000万円では4倍の開きがあります。この幅が生まれる主な理由は、画面数・機能数、外部システムとの連携の有無、非機能要件（性能・セキュリティ・可用性）の厳しさ、そして要件の固まり具合です。要件が曖昧なまま発注すると、後から仕様が膨らんで上限に近づきやすくなります。
相場表を鵜呑みにすると危険な理由——同規模でも倍違う
ここで強調しておきたいのは、総額レンジだけを見ても見積書の妥当性は判断できないということです。たとえば「中規模で1,200万円」という見積書が2社から出てきたとしても、片方は設計に厚く実装に薄い、もう片方はテストをほとんど見込んでいない、ということが起こり得ます。総額が同じでも中身の配分が違えば、完成するシステムの品質は大きく変わります。
つまり、相場表が答えてくれるのは「総額が常識的な範囲か」までです。「その内訳が健全か」までは答えてくれません。発注担当者が本当に知りたいのは後者のはずです。次章では、その内訳を判定するための物差し——規模別×工程別の費用配分比率の早見表を提示します。
規模別×工程別の費用配分比率「早見表」
ここからが本記事の中核です。受託開発の費用は、要件定義・設計・実装・テスト・プロジェクト管理といった工程に分かれており、それぞれが総額の何%を占めるかにはおおよその目安があります。この比率を物差しとして持っておけば、受け取った見積書が健全な配分になっているかを判定できます。
工程別配分比率の早見表（規模帯別）
工程別の工数比率については、独立行政法人情報処理推進機構（IPA）が多数の開発プロジェクトの実績データを集計・公開しています。IPAのソフトウェア開発データ白書によれば、新規開発プロジェクトにおける工程別の工数比率は、基本設計18%・詳細設計18%・製造（実装）31%・結合テスト20%・総合テスト13%が一つの目安とされています（IPA ソフトウェア開発データ白書）。結合テストと総合テストを合わせると約32%がテスト工程に充てられている計算です。
この公的データを土台に、要件定義とプロジェクト管理を加え、規模帯ごとの実務的な傾向を反映して整理したのが次の早見表です。あくまで目安であり、案件の特性によって前後する点は前提としてください。
工程 | 小規模 | 中規模 | 大規模 |
|---|---|---|---|
要件定義 | 10% | 13% | 15% |
基本設計・詳細設計 | 20% | 25% | 27% |
実装（製造） | 45% | 35% | 28% |
テスト（結合・総合） | 20% | 22% | 25% |
プロジェクト管理 | 5% | 5% | 5% |
※ IPAの工数比率（基本設計18%・詳細設計18%・製造31%・結合テスト20%・総合テスト13%）を基準に、要件定義・プロジェクト管理を加え、規模による傾向差を反映した実務目安です。
この表の使い方は単純です。手元の見積書の総額にこの比率を掛ければ、各工程の「理論上いくらかかるはずか」という金額が求められます。たとえば中規模1,200万円なら、要件定義は約156万円（13%）、設計は約300万円（25%）が理論値になります。
なぜ規模が大きいほどPM・テストの比率が上がるのか
早見表を見ると、規模が大きくなるほど実装の比率が下がり、設計とテストの比率が上がっていることに気づきます。これには明確な理由があります。
大規模なシステムでは、関係者やシステム連携が増えるため、作りはじめる前に「何を・どう作るか」を固める設計の重みが増します。設計が甘いまま実装に入ると、後工程での手戻りが膨大になるからです。テストも同様で、システムが大きくなるほど機能間の組み合わせが爆発的に増え、結合テスト・総合テストにかかる工数が膨らみます。テスト工程が開発全体の3割前後を占めることは、IPAのデータでも裏付けられています（freshet「テスト工数は開発全体の32%」）。プロジェクト管理の比率自体は規模によらず一定程度に見えますが、総額が大きいぶん絶対額としての管理コストは増えていきます。
逆に小規模案件では、機能がシンプルで設計の負荷が軽いため、実装そのものに費用が集中します。早見表で小規模の実装比率が45%と高いのはこのためです。
要件定義・設計の比率が極端に低い見積もりが危険信号な理由
検算の観点で特に注意してほしいのが、要件定義と設計の比率です。この2工程の比率が早見表より極端に低い見積書は、危険信号と考えてください。
要件定義と設計は、システムの土台を決める工程です。ここを薄く見積もっているということは、「要件を固めずに走り出す」「設計を省いていきなり作る」という進め方を意味します。一見すると安く見えますが、開発が進んでから仕様の認識違いが発覚し、大きな手戻りや追加費用につながりやすいのです。実際、追加費用が発生する原因の多くは上流工程の詰めの甘さにあります。この構造についてはシステム開発で追加費用が発生する原因と回避策で詳しく解説しています。
「安い見積もり=お得」ではなく、「安い見積もりはどこかを削っている」という前提で内訳を見ることが、検算の出発点になります。次章では、この早見表を使って実際に見積書を逆算する手順を見ていきましょう。
受け取った見積書を「逆算」して妥当性を検算する手順
早見表は、ただ眺めるだけでは物差しになりません。手元の見積書に当てはめてはじめて意味を持ちます。ここでは「相場を読む」から「自分の見積もりを検算する」へと一歩踏み込み、受け取った見積書を逆算して妥当性を判定する具体的な手順を説明します。
検算5ステップの全体像
検算は次の5つのステップで進めます。電卓があればその場でできる単純な作業です。
- 合計額を確認する — 見積書の税抜合計額を把握します。
- 規模帯を判定する — 先ほどの総額目安テーブルに照らし、小規模/中規模/大規模のどれに当たるかを決めます。
- 各工程の理論値を逆算する — 合計額に早見表の比率を掛け、工程ごとの「あるべき金額」を算出します。
- 受領見積もりの工程別金額と突き合わせる — 見積書に記載された工程別の金額と、理論値を並べて比較します。
- 差分を読む — 理論値より大きく過小・過大な工程を見つけ、その意味を解釈します。
ポイントは、理論値はあくまで「健全な配分の目安」だということです。差分があること自体は問題ではなく、「なぜその差分があるのか」を説明できるかどうかが本質です。
計算例で1件通して検算する（中規模・1,200万円のケース）
実際に1件、通して検算してみましょう。中規模で税抜合計1,200万円の見積書を受け取ったと仮定します。
まず規模帯は「中規模」と判定できます。次に、中規模の早見表比率を1,200万円に掛けて理論値を算出します。
工程 | 中規模の比率 | 理論値 |
|---|---|---|
要件定義 | 13% | 156万円 |
基本設計・詳細設計 | 25% | 300万円 |
実装 | 35% | 420万円 |
テスト | 22% | 264万円 |
プロジェクト管理 | 5% | 60万円 |
合計 | 100% | 1,200万円 |
ここに、受け取った見積書の工程別金額を並べて突き合わせます。仮に見積書が次のようだったとします。
工程 | 理論値 | 受領見積もり | 差分 |
|---|---|---|---|
要件定義 | 156万円 | 60万円 | −96万円（過小） |
基本設計・詳細設計 | 300万円 | 240万円 | −60万円（やや過小） |
実装 | 420万円 | 600万円 | +180万円（過大） |
テスト | 264万円 | 200万円 | −64万円（やや過小） |
プロジェクト管理 | 60万円 | 100万円 | +40万円（過大） |
この比較から、いくつかの差分が見えてきます。要件定義が理論値の4割弱しかなく、上流が大きく薄いことが分かります。一方で実装は理論値を180万円上回っています。これは「要件を十分に固めないまま実装に費用を寄せている」という配分であり、先ほど述べた危険信号のパターンに当てはまります。総額1,200万円は中規模として常識的な範囲ですが、内訳を見ると上流が薄く、手戻りリスクを抱えた構成だと判定できるわけです。
このように、総額だけでは見えない「配分の偏り」を、逆算によって数字で可視化できます。これが配分比率を物差しに持つことの威力です。
「一式」表記を工程に割り戻せないときの質問テンプレート
ここで多くの発注担当者が直面する壁が、「一式」表記です。見積書が「開発一式 1,200万円」とだけ書かれていて、工程別に分かれていなければ、そもそも突き合わせができません。
このときは、遠慮せずベンダーに内訳を求めてください。次のような質問テンプレートを使うと、角を立てずに必要な情報を引き出せます。
- 「御見積もりの内訳を、要件定義・設計・実装・テスト・プロジェクト管理の工程別に分けてご提示いただけますでしょうか。社内承認の際に内訳の説明を求められるためです」
- 「各工程の想定工数（人月）と、適用される人月単価をあわせてお教えいただけますか」
- 「テスト工程として、結合テストと総合テストはそれぞれどの程度の工数を見込んでいらっしゃいますか」
工程別の内訳を出せないベンダー、あるいは出し渋るベンダーには注意が必要です。健全な見積もりであれば、内訳は当然に積算されているはずだからです。内訳の提示を求めること自体が、ベンダーの見積もりの確からしさを測る一つの判断材料にもなります。
契約形態（請負/準委任）で検算の前提がどう変わるか
ここまでの検算は「総額が固定されている」ことを暗黙の前提にしてきました。しかし受託開発では、契約形態によって費用の出方が変わり、検算の当てはめ方も変わります。社内説明の場で前提を取り違えると説明が破綻するため、最小限おさえておきましょう。
請負＝総額固定、準委任＝月額×期間——検算の基準が違う
受託開発の契約形態は、大きく請負と準委任に分かれます。請負は成果物（完成したシステム）の納品に対して総額が固定される契約です。この場合、早見表による逆算検算はそのまま適用できます。総額に比率を掛けて理論値を出し、見積書と突き合わせれば済みます。
一方、準委任は稼働（作業時間）に対して月額で費用が発生する契約です。「月額○○万円 × ○ヶ月」という形で費用が積み上がるため、検算の基準が変わります。準委任では、まず想定期間全体の総額を「月額 × 月数」で算出し、その総額に早見表の比率を当てはめて検算します。期間が延びれば総額も増えるため、「何ヶ月で完了する想定か」という前提条件を必ず確認したうえで検算する必要があります。
つまり、請負は「固定された総額の内訳が健全か」を、準委任は「月額と期間の積み上げが妥当か」を検算する、という違いがあります。同じ早見表を使うにしても、入口の総額の作り方が異なる点を意識してください。
上流準委任・下流請負の組み合わせ時の検算の注意点
実務では、要件定義など不確実性の高い上流工程を準委任、仕様が固まった下流の実装・テストを請負、というように工程ごとに契約形態を分ける進め方もよく採られます。この組み合わせ型では、見積書が一本の総額にならず、契約形態の異なる複数の見積もりに分かれることがあります。
この場合の検算は、上流（準委任部分）と下流（請負部分）を分けて評価するのが基本です。上流は「期間と月額が妥当か」、下流は「固定総額の内訳が健全か」を別々に見ます。準委任は稼働時間に対して月額で費用が発生し、請負は成果物に対して総額が固定されるため、追加費用が生じる条件も両者で異なります。組み合わせ型の見積もりを検算するときは、どの工程がどちらの契約形態なのかを最初に確認し、その工程の総額がどう作られているかを押さえたうえで、それぞれに合った物差しを当てることが重要です。なお、要件が固まりきっていない段階で一括の固定総額を提示された場合は、まず不確実性の高い上流を準委任で切り出し、仕様が固まってから下流を請負に切り替えられないか検討すると、コストの膨張を抑えやすくなります。
検算結果を社内承認の説明材料に変える
検算で差分を数字にできても、それを社内の稟議や上長説明でそのまま使える言葉に変換できなければ、承認は取れません。最後のこの章では、検算で得た差分を「説明ロジック」に落とし込む方法を示します。検索後の理想状態——金額の根拠を自分の言葉で説明し、承認を取る——への着地点です。
差分を「リスク」と「妥当」に仕分ける判断軸
検算で見つかった差分は、すべてが問題というわけではありません。差分には「リスクを示す差分」と「合理的に説明できる差分」の2種類があります。社内説明では、この仕分けが要になります。
リスクを示す差分の典型は、要件定義・設計・テストが理論値より大きく過小なケースです。これらは品質の土台を削っている可能性が高く、「設計費が理論値より3割少ないため、仕様の固め込みが不十分で手戻りリスクがある」というように、リスクとして言語化できます。
一方、妥当と説明できる差分もあります。たとえば「テスト費が相場より2割高いが、本システムは決済を扱うため品質保証に手厚く工数を割いている」「実装費が理論値より高いのは、既存システムとの連携が複雑なため」といったように、案件固有の事情で説明がつくものです。差分を見つけたら、まずベンダーにその理由を確認し、納得できる説明があれば「妥当な差分」として整理します。
ポイントは、差分の有無で機械的に良し悪しを決めないことです。「差分がある→理由を確認する→リスクか妥当かを判断する」という流れで一つずつ仕分けていけば、説明に筋が通ります。
そのまま使える社内説明の3点セット
検算結果を社内で説明するときは、次の3点をセットで提示すると説得力が出ます。稟議書や説明資料にそのまま落とし込める型です。
- 規模帯の特定 — 「本案件は機能数・連携範囲から中規模に該当し、総額1,200万円は相場の範囲内です」
- 理論配分との突き合わせ — 「IPAの工程別工数比率を基準に逆算すると、要件定義は156万円が目安ですが、本見積もりは60万円で約6割少なくなっています」
- 差分の解釈と対応 — 「上流が薄いため手戻りリスクを確認したところ、要件は社内で確定済みとの回答を得たため、リスクは限定的と判断します」
この3点セットがあれば、「なぜこの金額で妥当なのか」「どこにリスクがあり、どう対処したのか」を、自分の言葉で一貫して説明できます。上司から「この金額の根拠は？」と問われても、相場表を見せるのではなく、検算のプロセスそのものを根拠として示せるようになります。これが、相場記事を何本読んでも得られなかった「判断する力」です。
まとめ——相場表ではなく「配分比率の物差し」を持つ
受託開発の見積書を前にしたとき、相場表が教えてくれるのは「総額が常識的な範囲か」までです。本当に知りたい「その内訳が健全か」に答えるには、規模別×工程別の費用配分比率という物差しが必要でした。
本記事で整理した流れを振り返ります。まず自分の案件の規模帯を特定し、要件定義・設計・実装・テスト・プロジェクト管理の配分比率の早見表を物差しとして用意します。次に、受け取った見積書の総額に比率を掛けて各工程の理論値を逆算し、受領金額と突き合わせて差分を読み取ります。差分は「リスク」と「妥当」に仕分け、規模帯・理論配分・差分の解釈という3点セットで社内説明に落とし込みます。
この検算ができるようになれば、ベンダーの言い値に振り回されることはなくなります。「設計費が薄い」「テスト費が手厚い理由は何か」を自分の目で確認し、金額の妥当性を自分の言葉で説明できる——それが、相場記事を何本読んでも届かなかったゴールです。次に見積書を受け取ったら、ぜひ早見表を手元に置いて逆算検算を試してみてください。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 工程別の内訳を出してもらえましたが、さらに人月単価を確認する意味はありますか？
意味はあります。工程別の金額と人月数が分かれば「単価 × 工数 = 金額」が成り立つか検算でき、単価が相場から大きく外れていないか、工数が過大・過小でないかをそれぞれ独立して確認できます。見積もりの根拠をより立体的に把握でき、社内承認の説明材料としても有効です。
- 早見表の配分比率はあくまで目安とのことですが、差分があった場合にどう判断すればよいですか？
差分の大小より「合理的な説明ができるか」が判断の核心です。案件固有の事情（外部システム連携の複雑さ・セキュリティ要件の厳しさ等）があれば差分は妥当と判断できますが、説明が得られない場合はリスクと判断してください。「差分がある→理由を確認する→リスクか妥当かを判断する」という流れで仕分けてください。
- 検算の結果、設計費が明らかに少ないと分かりました。ベンダーにどう伝えればよいですか？
「IPAの工程比率と比較すると設計工程が想定より少なく見えます。要件定義・設計の工数をどのように算出されたか教えていただけますか」と事実確認の形で伝えるのが自然です。責める表現を避け、根拠を共有する姿勢で問い合わせると建設的な対話につながります。
- 複数社から見積もりを取った場合、この早見表を使ってどう比較すればよいですか？
各社の見積書を同じ工程区分（要件定義・設計・実装・テスト・PM）に揃えて並べ、各工程の金額と比率を横並びにしてください。総額よりも工程ごとの配分の差が比較の核心で、品質リスクを可視化できます。
- 契約が準委任の場合、早見表はそのまま使えますか？
準委任は「月額×期間」で総額が変動するため、まず想定期間の総額を算出してから早見表を当てはめます。「何ヶ月で完了する想定か」と「月額」を必ずベンダーに確認したうえで検算してください。期間が延びると総額も増えるため、完了目安の根拠も併せて確認しておくとリスクを抑えられます。
