結論から述べます。システム開発の見積もりが「高い／安い」の正体は、ほぼ工数（人月）です。 開発費は「人月単価 × 投入人数 × 期間」で決まり、その原価の約8割は人件費だからです。そして、同じ要件で見積もりが数倍違うとき、その差のほとんどは「非機能要件（性能・セキュリティ・運用・保守）を見積もりに含めているかどうか」にあります。安い見積もりが本当に安いのか、それとも「あとで効いてくる費用」が隠れているだけなのか——本記事は、発注者がそれを自分で見抜けるようになるための実務ガイドです。
この記事はシステム開発の発注 完全ガイドの費用編です。発注全体の意思決定はそちらを参照してください。
1. 費用の正体：すべては「人月」に還元される
日本のシステム開発費は、ほぼ例外なく人月（にんげつ）で計算されます。
開発費 ≒ 人月単価 × 投入人数 × 開発期間（月）
「3人のエンジニアが、単価100万円で、4ヶ月」なら、ざっくり 3 × 100万 × 4 = 1,200万円。これが見積もりの骨格です。そして、ここがいちばん大事なのですが——開発費の原価の約8割は人件費です。サーバー代やライセンス代ではなく、人の時間にお金を払っているのです。
このことから、3つの実務的な帰結が出ます。
- 「安くしてほしい」は、本質的には「工数を減らしてほしい」——機能を削るか、品質を削るか、のどちらかになる。
- 見積もりの差は、単価の差か、想定工数の差——同じ要件で倍違うなら、どちらかの前提が違う。
- 「人を増やせば早く終わる」は誤り——人を増やすほど調整コストが増える（ブルックスの法則）。これは小さく速いチームが有利な理由でもあります。
人月単価の目安
| 役割・水準 | 人月単価の目安 |
|---|---|
| 初級〜中堅エンジニア | 60〜100万円 |
| 上級・テックリード級 | 100〜160万円 |
| 大手SIer・コンサル（多重下請け構造を含む） | 150万円以上 |
大手SIerが高いのは、技術力だけの問題ではありません。多重下請け構造により、実際に手を動かすエンジニアの単価に、各層のマージンが乗るためです。発注者が払う150万円のうち、最下層の開発者に届くのは半分以下、ということも珍しくありません。
2. 開発タイプ別・費用レンジの目安
「で、結局いくらかかるのか」に答えます。あくまで一般的な相場で、要件次第で大きく変動しますが、判断の出発点として使ってください。
| 開発タイプ | 費用レンジの目安 | 期間の目安 | 例 |
|---|---|---|---|
| SaaS導入・設定 | 〜10万円程度 | 即日〜数週間 | 会計・勤怠・CRMなど既製ツールの導入・初期設定 |
| カスタマイズ・小規模開発 | 50〜300万円 | 1〜3ヶ月 | 既製品の拡張、社内向けの小規模業務アプリ、LP・コーポレートサイト＋簡易機能 |
| 中規模の業務システム | 300〜1,000万円 | 3〜6ヶ月 | 受発注・在庫・予約などの業務システム、MVP |
| 大規模・スクラッチ（B2B SaaS等） | 1,000万円〜数千万円 | 6ヶ月〜 | 業界特化のB2B SaaS、決済を含むマルチテナント基盤 |
私が手がけた木材流通のB2B SaaS（経済産業大臣賞を受賞）は最後のカテゴリで、221本のAPIエンドポイント、17のTerraformモジュール、12のLambda、4ラウンドのセキュリティ監査——という規模感です。この「何が含まれているか」を知らずに金額だけ比較すると、判断を誤ります。次の章がその核心です。
3. 「相場」を自分で検証する——公的データと突き合わせる
ここまでの相場表を含め、世に出回る費用レンジのほとんどは出典のない目安です。目安は出発点としては役立ちますが、「自分の見積もりが妥当か」の判定には使えません。判定に使えるのは、母集団と件数が明示された公的データだけです。
使えるものが2つあります。
3-1. IPA の実測値——「普通のプロジェクト」の大きさを知る
IPA（情報処理推進機構）は、実際の開発プロジェクトの定量データを収集・公開しています。最新版「ソフトウェア開発分析データ集2022」から、2つの中央値を引きます。
| 指標 | 中央値 | 母数 |
|---|---|---|
| プロジェクトの工数 | 7,395人時 | N=1,444 |
| プロジェクトの工期 | 10.1ヵ月 | N=1,396 |
7,395人時を月160時間で割ると、約46人月。前章の式に戻せば、単価100万円なら4,600万円規模です。「中規模の業務システムで300〜1,000万円」という一般的な目安とは一桁違います。
この差は誤りではなく、母集団の違いです。IPAが集めているのは主に大手SIerが手がけるエンタプライズ案件で、中小企業の小規模案件の代表値ではありません。だからこそ使い方はこうなります。
自分の案件が「IPAの中央値の何分の一か」を考える。
30人月の見積もりが出てきたなら、それはIPA中央値の6〜7割の規模です。10ヶ月の工期を提示されたなら、それは中央値ちょうど。桁が合っているかどうかは、この突き合わせで判定できます。逆に「3人月で基幹システムを作る」という見積もりが、中央値の15分の1であることも即座に分かります。
もうひとつ、同じ資料に発注前に効く数字があります。
b：改修・保守, 761, 51.5% ／ a：新規開発, 430, 29.1% 新規開発が 3 割弱、改修・保守が 5 割強であり、この二つで 8 割弱を占めている。（中略）2016 年度～2021 年度は新規開発が 32.5%から 29.1%に減少し、改修・保守が 45.8%から 51.5%に増加している。
— IPA「ソフトウェア開発分析データ集2022」（件数ベース、N=1,479）
計測対象の半分以上は新規開発ではなく、すでに動いているシステムの改修・保守です。件数の割合であって金額比ではありませんが、「作って終わり」の案件のほうが少数派だ、という事実は見積もりを読む姿勢を変えます。稼働後の費用は総コスト（TCO）の記事で扱っています。
3-2. JUAS の実測値——「そもそもいくら使う会社なのか」を知る
もう一方向から検証できます。日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査報告書2026」（2025年度調査、有効回答957社）は、売上高に対するIT予算の比率を公表しています。
IT 予算比率（全体）でみると、25 年度のトリム平均値は 1.47％で 0.07 ポイント上昇した。
— JUAS「企業IT動向調査報告書2026」（n=703／トリム平均＝上下10%を除いた80%で算出）
売上10億円の会社なら、IT予算の目安は年1,500万円前後ということになります。単年のシステム開発費が、この年間IT予算を大きく超えていないか——これは「高い／安い」ではなく「その会社の体力に合っているか」の検証です。超えているなら、分割発注や段階的導入を検討する根拠になります。
なお、この調査の回答企業は東証上場企業とそれに準じる規模です。中小企業そのものの数字ではないため、比率の考え方を借りる使い方に留めてください。
3-3. 3つの検証を並べる
まとめると、見積もりを受け取ったらこの順で確認できます。
- 桁は合っているか — 提示された人月・工期は、IPA中央値（約46人月／10.1ヶ月）の何分の一か
- 体力に合っているか — 年間の総額は、売上高の1.5%前後という比率から見て無理がないか
- 内訳が読めるか — 次章以降の「抜け」チェック
1と2は5分でできます。そしてこの2つを通らない見積もりは、内訳を読む前に前提から話し直したほうが早いというのが実務上の感覚です。
4. 安い見積もりに潜む「抜け」——非機能要件という落とし穴
発注者が最も損をするパターンは、「安かったから選んだら、運用で破綻した」です。なぜこれが起きるのか。安い見積もりは、たいてい次の非機能要件が抜けているからです。
非機能要件とは、「画面を作る」「ボタンを押すと保存される」といった機能要件ではなく、システムが本番で生き延びるための「品質」に関する要件です。
| 抜けがちな項目 | 抜けると何が起きるか |
|---|---|
| 性能（パフォーマンス） | 利用者が増えると遅くて使えない。後から作り直し |
| セキュリティ | 情報漏洩・不正アクセス。賠償と信用失墜 |
| 可用性・回復性（DR） | 障害で止まる、データが消える。復旧できない |
| 監視・可観測性 | 障害に気づけない。原因がわからない |
| テスト・品質保証 | リリースのたびにバグ。改修が怖くて触れない |
| 運用・保守 | 作って終わり。トラブル対応も改修も追加費用 |
これらは「あれば良い」オプションではなく、本番運用の前提です。たとえば決済を含むシステムで「冪等性（リトライしても二重課金しない仕組み）」が見積もりに入っていなければ、それは「いつか二重課金事故を起こすシステム」を安く買っている、ということです。
見積もりの読み方の鉄則: 2社の見積もりが「機能は同じなのに金額が倍違う」とき、安い方が優れているのではなく、高い方に非機能要件が含まれている可能性を最初に疑ってください。同じ土俵で比較するには、両社に「性能・セキュリティ・テスト・監視・運用・保守を含むか」を明示的に確認します。
運用・保守費という「見えないランニングコスト」
見落とされがちですが、システムは作って終わりではありません。本番リリース後の運用・保守費は、一般に初期開発費の年15%前後が目安です。1,000万円で作ったシステムなら、年150万円前後の保守を想定しておく。これを織り込まずに「初期費用が安い」だけで選ぶと、総保有コスト（TCO）で逆転します。
5. 見積もりの妥当性を見抜く5つのチェック
金額の大小ではなく、見積書の「構造」を見ます。妥当な見積もりは、次の5点を満たしています。
チェックリスト
- 内訳の粒度が適切か——「開発一式 800万円」のような丸めた見積もりは危険信号。要件・工程ごとに工数（人日／人月）が分解されているか。
- 前提条件と除外事項が明記されているか——「〜は別途」「〜は含まない」が書かれているか。曖昧な見積もりは、後から追加費用の温床になる。
- 非機能要件が項目化されているか——性能・セキュリティ・テスト・運用が独立した項目として存在するか。
- 要件定義・設計の工程が含まれているか——いきなり実装から始まる見積もりは、要件の曖昧さを発注者に押し付けている。
- 保守・運用の条件が示されているか——リリース後の対応範囲・費用・SLAが書かれているか。
「不確実性」をどう握るか——固定価格 vs 準委任
要件が固まりきっていない段階で固定価格（請負）を握ると、開発側はリスクを織り込んで高めに見積もるか、安く受けて後で揉めるかのどちらかになります。要件が流動的なら、準委任（時間・工数ベース）で小さく始め、要件が固まった部分から請負に切り替える——というハイブリッドが、双方にとって健全です。「すべて固定価格で安く」は、たいてい幻想です。
6. 一人 × 生成AI は、費用構造をどう変えるか
近年、私のような一人（少人数）× 生成AIの開発スタイルが、費用面で現実的な選択肢になっています。なぜ安くできるのか——その根拠を正直に説明します。
| 安くなる理由 | 内容 |
|---|---|
| 中間マージンがない | 多重下請け構造の各層マージンが乗らない。発注額がそのまま開発に向かう |
| 調整コストが小さい | 会社間・チーム間の調整工数がゼロ。意思決定者と直接対話して要件を高速に回せる |
| 生成AIによる実装の高速化 | コードを書く速度が上がり、同じ工数でより多くを実装できる |
| 一気通貫 | 要件定義からインフラ・運用まで一人で担い、引き継ぎロスがない |
ただし——ここが最も重要です——「安い」は「品質を削った」と同義であってはなりません。生成AIは実装を速くしますが、その出力をそのまま信用しない検証ゲート（型安全な境界検証・自動テスト・静的解析・セキュリティ監査）を通して初めて本番品質になります。
私の場合、木材流通DXでは全221エンドポイントの認証欠落0件を第三者ペネトレーションテストで実証し、決済基盤では本番稼働中の二重課金0件を冪等性という構造で担保しています。「速くて安いが、検証で固めているから安全」——これが、一人×生成AIの見積もりが信頼に足るかどうかの分かれ目です。逆に、検証ゲートを説明できない「安いだけ」の相手は、別の意味で高くつきます。
まとめ：金額ではなく「構造」を見る
システム開発の費用で損をしないために、押さえるべきは次の通りです。
- 費用は「人月単価 × 人数 × 期間」で決まり、原価の8割は人件費——見積もりの差は工数の差。
- 相場の目安はSaaS導入
10万円、カスタマイズ50300万円、スクラッチ300万円~数千万円——非機能要件で大きく変動。 - 安い見積もりは非機能要件（性能・セキュリティ・テスト・運用・保守）が抜けがち——同じ土俵で比較する。
- 妥当性は金額ではなく「内訳の粒度」と「前提・除外事項の明記」で見抜く。
- 一人×生成AIの安さは中間マージン削減が根拠で、品質は検証ゲートで担保する——「安いだけ」とは別物。
見積もりの妥当性に不安がある、あるいは「この金額は適正か」を第三者の視点で確認したい——そうしたご相談も歓迎します。要件の棚卸しから、何にいくらかかるのかの構造化まで、発注者の側に立って整理します。