システム開発の費用相場を調べると、数百万円から数千万円までの幅広い数字が並びます。しかし、その一覧を眺めても、自社が受け取った見積もりが妥当かどうかは判断できません。同じ五百万円でも、含まれる工程も成果物もまったく異なるためです。

この記事では、システム開発の費用が決まる仕組みと、種類別および工程別の相場観を整理します。そのうえで、相場表からは読み取れない見積もりの見方と、費用を適正化するための具体的な手順までを、発注する側の視点でまとめます。

この記事を読むと理解できること

• システム開発の費用が人月単価と工数で決まる仕組み

• システムの種類別に見た費用相場のレンジと変動要因

• 要件定義から運用保守までの工程別の費用配分の目安

• 相場表を見ても発注判断ができない構造的な理由

• 見積書で金額よりも先に確認すべき内訳の粒度

• 安い見積もりが結果的に高くつく典型的なパターン

• 作る範囲を絞ることで費用を下げる優先順位の付け方

• 見積もり依頼の前に発注側が用意しておくべき情報

システム開発の費用相場が一覧表だけでは判断材料にならない理由

システム開発の費用相場をまとめた記事は数多くありますが、そこに並ぶレンジは幅が広く、上限と下限で十倍近く開くことも珍しくありません。これは情報が不正確なのではなく、システム開発という言葉が指す範囲が広すぎることに原因があります。同じ相場表の中に、部門単位の小さな仕組みと全社規模の基幹系が同居しています。

たとえば業務システムを五百万円で作るという同じ条件でも、中身はまったく異なります。既存の業務フローをそのまま画面に落とすだけの開発と、業務そのものを設計し直したうえで画面を作る開発では、必要な工数も成果物の数も別物です。費用相場の表では、この差はどこにも表れません。

さらに、見積もりに含まれる工程の範囲が会社ごとに違います。要件定義を別契約にする会社、デザインを実装に含めてしまう会社、データ移行を追加費用として扱う会社が混在しているため、総額だけを横に並べても比較になりません。

つまり、システム開発の費用相場は自社の予算感を掴む出発点にはなりますが、それ単体では発注判断の根拠になりません。相場を確認したあとに、必ず内訳の構造を見る手順が必要になります。業務システムを対象にした進め方の全体像は業務システム開発の進め方で整理しています。

システム開発の費用を決めるのは人月単価と工数

システム開発の費用相場を正しく読むには、金額が決まる仕組みを先に押さえる必要があります。システム開発の費用は、その大半が人件費で構成されます。サーバー費用やライセンス費用も発生しますが、金額の主要部分は、開発に関わる人が何か月稼働するかで決まります。この構造を人月計算と呼び、人月単価と工数を掛け合わせた金額が見積もりの骨格になります。

人月単価は担当者の役割と経験によって異なります。一般に公表されている水準では、初級のプログラマーで月六十万円から九十万円程度、実装を主導する中堅以上のエンジニアで月八十万円から百二十万円程度とされます。設計を担うシステムエンジニアやリーダー層では月百万円から百五十万円程度、プロジェクトマネージャーやコンサルタントでは月百三十万円から二百万円程度が目安とされることが多い水準です。

この単価差は、同じ機能を作る場合でも総額を大きく動かします。経験の浅い担当者だけで構成された体制は単価が下がる一方、手戻りが増えて工数が膨らむことがあり、結果として総額が下がらないケースもあります。単価の安さと総額の安さは別の話です。

工数の側も同様に幅があります。画面数、外部システム連携の数、権限の種類、扱うデータ量といった条件が増えるほど工数は積み上がるため、要件が固まっていない段階の見積もりは、前提条件次第で大きく振れます。

システム開発の費用相場を種類別に整理する

システムの種類ごとの費用相場は、次のように整理できます。いずれも一般に公表されている水準をまとめたもので、要件次第でレンジの外側に出ることもあります。

この費用相場の表で注目すべきは、種類による違い以上に、同じ種類の中でのレンジの広さです。小規模な業務システムでも、下限と上限で二倍以上の開きがあります。

レンジの中でどこに着地するかを決めるのは、機能の数そのものよりも、業務の複雑さと例外処理の多さです。承認ルートが部門ごとに違う、締め日の処理に特例がある、過去データの形式が揃っていないといった条件は、画面数に表れないまま工数を押し上げます。

基幹システムのように対象業務が広い領域では、金額の桁が変わります。業務システムと基幹システムのどちらの話をしているのかが曖昧なまま費用相場を比べると、議論が噛み合いません。両者の違いは基幹システムと業務システムの違いで解説しています。

システム開発の費用相場を工程別の配分と運用保守で読み解く

総額よりも参考になるのが、工程別の費用配分です。一般的な受託開発では、おおむね次のような割合になるとされます。

工程別の配分は、総額の相場よりも見積もりの健全性を映します。この配分から外れている見積もりは、必ずしも不当ではありませんが、理由を確認する価値があります。実装が七割を占めるような構成であれば、要件定義や設計の工数が十分に取られていない可能性があります。

運用保守の費用も合わせて確認しておく必要があります。一般に、システム開発の初期費用の年間十五パーセントから二十パーセント程度が保守費用の目安とされ、五年使えば初期費用と同等の金額が積み上がる計算になります。

保守費用には、障害対応、問い合わせ対応、OSやライブラリの更新、小規模な改修などが含まれます。どこまでが月額に含まれ、どこからが追加費用になるのかを契約時に確認しておかないと、運用開始後に想定外の請求が続くことになります。

見積書は金額ではなく内訳の粒度で読む

複数社から見積もりを取ったとき、多くの発注者はまず総額を比べます。しかし、判断の精度を上げるうえで先に見るべきなのは、内訳がどれだけ細かく分かれているかです。

粒度の細かい見積書は、提案側が自社の要望を具体的な作業に翻訳できている証拠になります。逆に、システム開発一式という一行で金額が提示されている場合、その会社が何を作ろうとしているのかを外から確認する手段がありません。

確認すべきは、要件定義、デザイン、実装、テスト、データ移行、運用保守という主要な行が独立して立っているかどうかです。このうちどれかが欠けている見積もりは、安いのではなく、その工程が範囲に含まれていないだけである可能性が高いと考えられます。

あわせて、前提条件の記載も確認します。画面数の想定、対応ブラウザ、同時利用者数、提供されるデータの形式といった前提が書かれていれば、条件が変わったときにどこが増えるのかを事前に議論できます。

システム開発の費用相場より安い見積もりが高くつく典型パターン

システム開発の費用相場より明らかに安い見積もりが出てきたとき、そこには必ず理由があります。単純に効率が良い場合もありますが、後から費用が増える構造になっているケースも少なくありません。

第一のパターンは、要件定義が薄い、あるいは含まれていない場合です。発注側が仕様を書き切れる前提で見積もられているため、実際には決めきれず、開発途中で仕様変更として追加費用が発生します。

第二のパターンは、デザインと業務設計が工数に入っていない場合です。画面を作る工数はあっても、誰がどの順番で何を入力するかという業務の流れを設計する工数がないと、使われないシステムができあがります。作り直しの費用は、最初から設計するより高くつきます。

第三のパターンは、データ移行とデータ整備が別途扱いになっている場合です。既存のデータは形式が揃っていないことが多く、整備作業は想像以上の工数になります。ここを範囲外にしたまま契約すると、稼働直前に大きな追加が発生します。

第四のパターンは、保守が含まれていない場合です。初期費用だけで比較すると安く見えますが、運用が始まってから年単位で費用が積み上がります。総額で判断するなら、少なくとも三年分の保守費用を含めて比べる必要があります。

システム開発の費用を下げる打ち手は値切りではなく作る範囲を絞ること

システム開発の費用を抑えたいとき、最初に思い浮かぶのは単価の交渉です。しかし、人月単価の値引きで動く金額はせいぜい一割程度で、しかも体制の質が下がる副作用を伴います。効果が大きいのは、作る範囲そのものを絞ることです。

範囲を絞るときは、機能を一律に削るのではなく、優先順位をつけて段階的に作ります。判断の基準になるのは、その機能がないと業務が止まるかどうかです。止まる機能は第一段階に入れ、あると便利な機能は第二段階以降に回します。

二つ目の基準は、利用頻度です。月に一度しか使わない集計機能を自動化するより、毎日発生する入力作業を先に改善したほうが、投資に対する効果が大きくなります。

三つ目の基準は、代替手段の有無です。既存のSaaSや表計算ソフトで当面回せる業務は、無理に作り込まず後回しにできます。こうして第一段階の範囲を絞れば、初期費用は下がり、実際に使ってみてから次の投資判断ができるという利点も生まれます。

このほか、補助金の活用、一部工程の内製化、ニアショアやオフショアの活用も費用を下げる手段になります。ただし、いずれも管理工数が増える側面があるため、範囲を絞る打ち手を先に検討する順序が現実的です。依頼先の選定については業務システム・DXに強い開発会社(SIer)9選も参考になります。

システム開発の費用見積もりを相場に近づけるために発注前に用意する情報

見積もりの精度は、発注側が渡す情報の質でほぼ決まります。情報が足りなければ、開発会社はリスクを見込んだバッファを積むため、金額は高く出ます。逆に、前提が揃っていれば不確実性が減り、金額も工期も現実的な水準に収まります。

用意しておくと効果が高いのは、次のような情報です。いずれも完璧な資料である必要はなく、現状を説明できる粒度で十分です。

• 対象業務の現在の流れと、関わる部門や担当者の数

• 現在使っているシステムやツールと、その利用範囲

• 移行対象となるデータの種類、件数、保存形式

• 想定する利用者数と、権限の種類

• 解決したい課題と、達成したい状態の優先順位

• 予算の上限と、稼働させたい時期

特に効くのが、データの現状と課題の優先順位です。データの実態が分かれば移行工数の見積もりが安定し、優先順位が示されていれば、予算に合わせて範囲を調整する提案が受けられます。

なお、AI関連の機能を含む開発では、費用の構造がやや異なります。検証工程とデータ整備の比重が大きくなるため、一般的なシステム開発の費用相場をそのまま当てはめられません。詳細はAI開発会社の費用相場で整理しています。

まとめ

システム開発の費用は人月単価と工数で決まり、その大半が人件費です。種類別に整理した費用相場は予算感を掴む出発点になりますが、同じ種類の中でもレンジは二倍以上に開くため、相場表だけで発注判断はできません。

判断の精度を上げる鍵は、総額ではなく内訳の粒度です。要件定義、デザイン、実装、テスト、データ移行、運用保守の行が独立して立っているか、前提条件が明記されているかを確認すれば、安さの理由が範囲の欠落によるものかどうかが見えてきます。

費用を下げる打ち手として最も効果が大きいのは、単価交渉ではなく作る範囲を絞ることです。業務が止まるかどうか、利用頻度、代替手段の有無という三つの基準で優先順位をつけ、第一段階を小さく作る。そのうえで、現状の業務フローとデータの実態を整理して渡せば、システム開発の費用相場との差はおのずと説明可能な範囲に収まります。

システム開発の費用相場に関するよくある質問

システム開発の費用相場はどのくらいが目安ですか

対象によって幅がありますが、一般には部門単位の小規模な業務システムで三百万円から八百万円程度、複数部門にまたがる中規模の業務システムで八百万円から二千万円程度が目安とされます。全社の基幹業務を対象とする基幹システムでは三千万円を超え、一億円規模になることもあります。ただし同じ区分でもレンジは二倍以上に開くため、目安として扱い、実際の判断は見積もりの内訳で行う必要があります。

システム開発の見積もりが会社によって大きく違うのはなぜですか

主な理由は二つあります。一つは人月単価の差で、担当者の役割と経験によって月六十万円程度から二百万円程度まで開きがあります。もう一つは、見積もりに含まれる工程の範囲の違いです。

要件定義を別契約にしたり、データ移行や保守を範囲外にしたりする会社があるため、総額が安く見えても比較対象が揃っていません。システム開発の費用相場と比べる前に、含まれている工程を揃えて並べることが必要です。

システム開発の費用を抑えるには何から始めるべきですか

最初に取り組むべきは、作る範囲を絞ることです。人月単価の交渉で動く金額は限定的ですが、機能の優先順位をつけて段階的に開発すれば、初期費用を大きく下げられます。業務が止まるかどうか、利用頻度が高いかどうか、既存ツールで代替できるかどうかという三つの基準で機能を仕分けると判断しやすくなります。補助金や一部内製化も選択肢ですが、範囲の絞り込みを先に検討する順序が有効です。

システム開発の保守運用にかかる費用の相場はどのくらいですか

一般に、初期の開発費用に対して年間十五パーセントから二十パーセント程度が目安とされます。五年間運用すれば、初期費用と同等の金額が積み上がる計算になります。保守の範囲には障害対応、問い合わせ対応、OSやライブラリの更新、軽微な改修などが含まれますが、どこまでが月額に含まれるかは契約によって異なります。追加費用になる作業の線引きを、契約前に文書で確認しておくことが重要です。

見積もりを依頼する前に何を準備しておけばよいですか

対象業務の現在の流れ、関わる部門と担当者の数、既存システムの利用範囲、移行対象データの種類と件数と形式、想定利用者数と権限の種類、そして解決したい課題の優先順位を整理しておくと精度が上がります。加えて、予算の上限と稼働希望時期を伝えると、範囲を調整した提案を受けられます。資料は完成度より現状を説明できる粒度が重要で、情報が不足するほど開発会社はリスク分のバッファを積むことになります。