システム開発の費用は、ひとことで言えば「どれだけの作業量（工数）が必要か」と「その作業を誰が担うか（単価）」の掛け算で決まります。そして工数を大きく動かすのは、画面や機能の数だけではありません。外部サービスとの連携の数、性能やセキュリティといった非機能要件の水準、テストや移行の範囲、プロジェクトを回す体制といった、見積書の上では目立たない要素が金額の差を生みます。
そのため「システム開発の費用相場はいくらか」という問いに一つの数字で答えることはできず、相場の数字だけを頼りに判断すると、安すぎる見積もりに飛びついて後から追加費用が膨らんだり、逆に妥当な見積もりを高いと誤解して機会を逃したりします。大切なのは、金額がどの要素から組み立てられているかを分解して理解し、自社の案件ならどこが重くなりそうかを見通すことです。
この記事は、初めてシステム開発を発注する事業責任者や、複数社の見積もりを前に判断に迷っている担当者に向けて書いています。見積もりの内訳の読み方、工数を左右する要因、費用を抑えるための具体的な手順、よくある失敗までを順に整理します。読み終えるころには、提示された金額が「何に対する対価なのか」を自分の言葉で説明できるようになるはずです。
システム開発の費用は「工数×単価」で決まる
受託開発の見積もりの多くは、人月（1人が1か月働く作業量）を単位にした工数と、担当者の役割ごとの単価を掛け合わせて算出されます。式にすると「費用＝工数（人月）×単価＋その他の実費」です。その他の実費には、サーバーやクラウドの利用料、外部サービスのライセンス、デザイン素材などが含まれます。
ここで押さえておきたいのは、単価は役割によって異なるという点です。プロジェクトマネージャー、設計を担うエンジニア、実装を担うエンジニア、デザイナー、テスト担当者では単価が違い、同じ工数でも誰がどれだけ関わるかで総額が変わります。見積書に「開発一式」としか書かれていない場合は、役割別の工数を確認すると比較がしやすくなります。
もう一つは、工数は「作る作業」だけでできていないという点です。要件を固める打ち合わせ、設計書の作成、テスト、修正、リリース作業、プロジェクト管理といった周辺作業が、実装と同じかそれ以上の比重を占めることも珍しくありません。実装部分だけを見て「この機能ならすぐ作れるはず」と考えると、見積もりとの差に戸惑うことになります。
なお、AIを活用した開発や既存のサービス・部品の組み合わせによって、同じ機能をより少ない工数で実現できる場面も増えています。工数は固定的なものではなく、作り方の工夫によって変わるものだと理解しておくと、見積もりの比較で「なぜこの会社は工数が少ないのか」を前向きに質問できます。
見積もり内訳の主な項目と読み方
見積書の項目名は会社によって異なりますが、おおむね次のような工程に分かれています。それぞれに何が含まれ、どこで金額差が出やすいかを把握しておくと、内訳を読むときの視点が定まります。
| 工程 | 主な作業 | 金額差が出やすいポイント |
|---|---|---|
| 要件定義 | 目的・業務範囲・機能・非機能の整理と合意 | 発注側の準備度合い、打ち合わせ回数 |
| 設計 | 画面設計、データ設計、外部連携の設計 | 設計書をどこまで作るか、レビューの回数 |
| 実装 | 画面・機能・管理画面・連携の開発 | 画面数、業務ルールの複雑さ、既製部品の活用度 |
| テスト | 単体・結合・総合テスト、受入テスト支援 | テストの範囲と自動化の有無、対象端末の数 |
| 移行・リリース | データ移行、本番環境構築、公開作業 | 既存データの量と汚れ具合、切り替え方式 |
| プロジェクト管理 | 進捗管理、課題管理、定例会 | 関係者の数、意思決定の速さ |
| 保守・運用 | 不具合対応、監視、軽微な改修 | 対応時間帯、対応範囲、月額か都度か |
内訳を読むときは、各工程の比率に注目します。たとえば実装に対してテストの比率が極端に小さい見積もりは、品質確認の多くを発注側の受入テストに頼る前提かもしれません。要件定義が含まれていない見積もりは、要件が固まっている前提で作られている可能性があります。工程ごとの金額そのものより、「何が含まれていて、何が含まれていないか」を確かめることが重要です。
見積もりの精度にも段階があります。初期の打ち合わせだけで出す概算見積もりと、要件定義を終えてから出す詳細見積もりでは、前提の確かさが大きく違います。両者の違いは概算見積もり・詳細見積もりの解説でも整理しています。概算の段階で金額を確定的に捉えすぎないことが、後の行き違いを防ぎます。
工数を大きく左右する5つの要因
同じ「顧客管理システム」でも、条件によって工数は何倍にも変わります。費用の見通しを立てるうえで特に影響の大きい要因を5つ挙げます。
1. 画面数と業務ルールの複雑さ
画面の数は工数の目安になりますが、より効いてくるのは画面の裏側にある業務ルールです。一覧と詳細を表示するだけの画面と、条件によって承認者が変わる申請画面では、同じ1画面でも作業量がまったく違います。例外処理、入力チェック、権限ごとの表示切り替えが増えるほど工数は膨らみます。
2. 外部連携の数と方式
会計ソフト、決済サービス、メール配信、既存の社内システムなど、連携先が増えるほど設計とテストの負担が増します。連携先がAPIを公開しているか、ファイル連携しかできないか、リアルタイムで同期する必要があるかによっても工数は変わります。連携先の仕様書が手に入らない場合は調査の工数が別途必要になることもあります。
3. 非機能要件の水準
非機能要件とは、性能、可用性、セキュリティ、拡張性など「機能以外に求める品質」のことです。同時に何人が使うか、止まってよい時間はどれくらいか、どの程度のセキュリティ対策が求められるかによって、構成もテストも変わります。取引先からセキュリティチェックシートへの回答を求められる業種では、その対応を前提にした設計が必要です。
4. 対象とする端末と利用環境
PCのブラウザだけで使うのか、スマートフォンにも対応するのか、専用アプリが必要かで工数は大きく変わります。ネイティブアプリならOSごとの対応やストア審査も加わります。対応ブラウザや端末の範囲を広げるほど、テストの組み合わせも増えます。
5. データ移行の有無
既存のExcelや旧システムからデータを移す場合、データの整理・変換・検証に想像以上の工数がかかります。表記ゆれや重複が多いデータほど手間が増えます。移行の工数は見積もりから漏れやすい項目の一つです。
費用感をつかむための見積もり分解の手順
見積もりを受け取る前、または受け取った後に、自社で費用の妥当性を確かめるための手順を示します。専門知識がなくても、この順番で整理すれば判断の材料がそろいます。
- 目的と成果を一文で書く：「何のために作るのか」「完成すると何がどう変わるのか」を書き出します。目的が曖昧なままでは、必要な機能の範囲も決まりません。
- 利用者と業務の流れを洗い出す：誰がどの場面でシステムを使うのかを、役割ごとに書き出します。現場の流れを図にしておくと、抜けている画面や機能に気づけます。
- 機能一覧を作り、優先度を付ける：必要な機能を一覧にし、「初回リリースに必須」「あると便利」「将来」に分けます。詳しくは機能一覧表の作り方で解説しています。
- 連携先と非機能要件を明記する：連携が必要なサービス、想定する利用者数、セキュリティの要求水準を書きます。分からない項目は「未定」と書いて相談材料にします。
- 見積もりを工程別・機能別に受け取る：一式ではなく、工程ごと、可能なら機能ごとの工数を出してもらいます。どの機能が重いかが分かれば、削る判断がしやすくなります。
- 前提条件と除外事項を確認する：見積もりの前提（資料の提供時期、確認の回数、対応端末など）と、含まれていない作業を一覧にして突き合わせます。
- 優先度の低い機能を外した場合の金額を聞く：初回リリースの範囲を絞った場合の見積もりも出してもらうと、投資判断の幅が広がります。
この手順の多くは、見積もり依頼の準備そのものでもあります。依頼前にそろえる資料については開発会社に見積もりを依頼する前に準備する資料も参考になります。
開発費以外にかかる費用を見落とさない
システムの総費用は、開発費だけでは終わりません。公開後も継続的にかかる費用を把握しておかないと、運用段階で予算が足りなくなります。主なものは次のとおりです。
- インフラ費用：サーバーやクラウドの利用料、ドメイン、SSL証明書など。利用者やデータ量の増加に応じて変動します。
- 外部サービスの利用料：決済サービスの手数料、メール配信、地図、認証、生成AIのAPIなど、従量課金のものが多く含まれます。
- 保守費用：不具合への対応、OSやライブラリの更新対応、監視、問い合わせ対応など。範囲と対応時間で金額が変わります。
- 改善・追加開発の費用：公開後に分かった課題への対応や、新しい機能の追加。事業が伸びるほど必要になります。
- 社内の人件費：要件定義への参加、テスト、運用マニュアル作成、利用者への説明など、発注側の担当者が使う時間です。
特に見落とされやすいのが最後の社内人件費です。外注すれば社内の負担はなくなると考えがちですが、要件の確認や受入テストは発注側にしかできない作業です。担当者の工数を確保しないまま進めると、確認待ちでスケジュールが延び、結果的に開発費も膨らみます。
費用を抑えるために発注側ができること
費用を抑える方法は「単価の安い会社に頼む」だけではありません。工数そのものを減らす工夫のほうが、品質を保ちながら効果を出しやすい方法です。
初回リリースの範囲を絞る
最も効果が大きいのは、最初に作る範囲を絞ることです。業務で毎日使う機能、売上に直結する機能から作り、使用頻度の低い機能や例外対応は手作業で補う設計にすると、初期費用を抑えながら早く使い始められます。新規事業であれば、検証したい仮説に必要な機能だけに絞ったMVPから始める考え方が有効です。
既製のサービスや部品を活用する
認証、決済、メール配信、管理画面の土台などは、既存のサービスや部品を使えば一から作る必要がありません。すべてをスクラッチで作るより工数を大きく減らせます。ただし、既製品の制約に業務を合わせる必要が出ることもあるため、どこまで既製品に任せるかは要件とのすり合わせが必要です。
発注側の判断を速くする
確認や承認が遅れると、開発会社は待機や手戻りの工数を見込まざるを得ません。決裁者を明確にし、定例会で決めることと持ち帰ることを分けておくだけでも、全体の工数は変わります。
仕様変更のルールを先に決める
開発途中の仕様変更は費用増加の大きな要因です。変更が出たときにどう判断し、どう費用を見積もるかのルールを契約前に決めておくと、予算の見通しが立てやすくなります。
架空の例：予約管理の業務システムで見積もりが分かれたケース
ここでは、仕組みを理解するための架空の例を紹介します。複数店舗を運営するある会社が、電話と紙で受けていた予約をWebで受け付け、店舗スタッフが管理画面で確認できるシステムを検討したとします。
最初に3社へ相談したところ、金額に大きな開きがありました。内訳を確かめると、A社は会員登録とポイント機能まで含めた見積もり、B社は予約受付と管理画面のみで、既存の顧客データの移行は含まない見積もり、C社は予約受付と管理画面に加えて、店舗ごとの権限設定とデータ移行を含む見積もりでした。金額差の大部分は、作る範囲の解釈の違いから来ていたのです。
この会社は、まず「初回に必須の機能」を予約受付・予約確認・店舗別の権限設定に絞り、ポイント機能は次の段階に回すと決めました。そのうえで、同じ機能一覧を3社に渡して見積もりを出し直してもらいました。条件をそろえたことで差は縮まり、残った差は「テストをどこまで開発会社が担うか」と「公開後の保守体制」の違いだと分かりました。最終的には、金額だけでなく、公開後の改善まで相談できる体制を重視して依頼先を選んでいます。
この例のように、見積もりの差は会社の良し悪しよりも前提の違いで生まれることが多いものです。比較の具体的な方法はシステム開発の見積もり比較のコツで詳しく扱っています。
費用でよくある失敗と、見積もり受領時のチェックリスト
よくある失敗と避け方
費用に関する失敗は、発注側の小さな見落としから始まることがほとんどです。代表的なものを挙げます。
- 「一式」の見積もりをそのまま受け入れる：何が含まれているか分からないため、後から「それは範囲外です」と言われやすくなります。工程別・機能別の内訳を求めましょう。
- 最安値の見積もりを選ぶ：安い理由が範囲の狭さやテストの省略にある場合、後から追加費用がかかり、結果的に高くつきます。安い理由を必ず確認します。
- 要件が固まる前の概算で予算を確定する：概算は幅を持った数字です。予算を組むときは、要件定義後に金額が動く可能性を織り込んでおきます。
- 運用費用を予算に入れない：公開後のインフラ費用や保守費用が想定外になると、改善に回す予算がなくなります。開発費とは別に年単位で見積もっておきます。
- 社内の担当工数を確保しない：確認や受入テストが遅れ、スケジュールと費用の両方に跳ね返ります。担当者の時間をあらかじめ計画に入れます。
- 見積もり後に機能を少しずつ足していく：一つひとつは小さな追加でも、積み重なると当初の範囲を大きく超えます。追加の要望はいったん一覧に記録し、初回リリース後にまとめて優先度を判断する運用にすると、予算の見通しを保てます。
- 予備費を持たない：どれだけ丁寧に要件を固めても、開発中に新たな発見は必ずあります。見積額ぎりぎりで予算を組むと、必要な修正すら判断できなくなります。想定外に備えた余地を予算に残しておくと、判断に余裕が生まれます。
見積もりを受け取ったときのチェックリスト
見積書を受け取ったら、次の項目を確認してから判断に進みます。すべてに答えられない場合は、開発会社に質問して埋めていきましょう。
- 工程別（要件定義・設計・実装・テスト・移行・管理）の内訳が分かるか
- 機能ごとの工数、または重い機能がどれかが分かるか
- 見積もりの前提条件（資料提供の時期、確認回数、対応端末など）が明記されているか
- 含まれていない作業（除外事項）が明記されているか
- テストの範囲と、受入テストで発注側が担う作業が分かるか
- データ移行の有無と範囲が明記されているか
- インフラ費用や外部サービスの利用料の見込みが別途示されているか
- 公開後の保守の範囲と費用の考え方が示されているか
- 仕様変更が発生した場合の扱いが説明されているか
- 契約形態（請負か準委任か）と、それによる責任範囲が分かるか
契約形態によって、完成責任の所在や仕様変更の扱いが変わります。判断に迷う場合は請負契約と準委任契約の選び方も確認してください。
よくある質問
Q. 相場が分からないと予算が組めません。どう考えればよいですか？
一般的な相場の数字より、自社の案件で「何を作るか」を先に決めるほうが予算の精度は上がります。まず目的と必須機能を整理し、その範囲で概算を複数社から取り、要件定義後の詳細見積もりで金額が動く幅を織り込んで予算を組むのが現実的です。
Q. 見積もりが会社によって大きく違うのはなぜですか？
多くの場合、作る範囲の解釈、テストの範囲、リスクの見込み、体制の違いが原因です。同じ機能一覧と前提条件を渡して見積もりを出し直してもらうと、差の理由が見えてきます。
Q. 人月単価が安ければ総額も安くなりますか？
必ずしもそうではありません。単価が安くても工数が多ければ総額は変わりませんし、仕様の伝達や品質確認に発注側の手間が増えることもあります。単価と工数、そして発注側の負担を合わせて比較することが大切です。
Q. 開発後の運用費用はどのくらい見込めばよいですか？
インフラ、外部サービス、保守、改善の4つに分けて見積もるのが基本です。利用者数やデータ量、保守の対応時間によって大きく変わるため、開発会社に前提を伝えて見込みを出してもらい、年単位で予算化しておくと安心です。
Otsumuに相談できること
作りたいものの範囲がはっきりしていて、社内に要件を整理できる担当者がいる場合は、この記事の手順で機能一覧と前提条件をそろえ、複数社から見積もりを取るだけでも十分に妥当な判断ができます。小規模なツールであれば、ノーコードや既製のサービスで足りることもあり、必ずしも外部の開発会社に頼む必要はありません。
一方で、何を作るべきかがまだ定まっていない、見積もりの差の理由が分からない、初回リリースの範囲をどこまで絞ってよいか判断できない、といった状況では、事業側と開発側の両方の視点を持つ相手に相談したほうが早く結論にたどり着けます。範囲の決め方を誤ると、費用だけでなく事業の立ち上がりそのものが遅れるからです。
Otsumuは自らも事業を手がける立場から、目的に照らして必要な機能を絞り込み、AIを活用した少人数・短期間の開発で、構想から開発・運用・改善までを一気通貫で支援しています。システム開発では種類別の進め方を紹介しており、新規事業であれば新規事業の爆速MVPシステム開発として、検証に必要な範囲から形にすることもできます。PoC / MVP Sprint は300万円〜（税別・参考価格、6週間を目安に設計）で、それ以外は範囲に応じて個別にお見積もりします。
お手元の見積もりの読み解きや、初回に作る範囲の整理だけでもご相談いただけます。まずは30分の無料相談で、状況をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01