2026.06.07 システム発注システム開発失敗相場・見積もり

システム開発の見積もりは適正か｜5つの判断ポイント

システム開発の見積もりが「適正かどうか」判断しにくい3つの構造的な理由

システム開発の見積もりを受け取ったとき、「高いのか、安いのか、妥当なのか」が分からず困る企業は少なくありません。家電やオフィス家具のように定価が明確な商材と違い、システム開発は要件・品質・体制・開発方式によって価格が大きく変わるためです。

しかも、同じ「受発注管理システム」でも、どこまでを作るのか、どの品質水準を求めるのか、将来の拡張を見込むのかによって、見積もりは数倍変わることがあります。まずは、なぜ比較が難しいのかを理解しておくことが大切です。

1. 同じ要件に見えても、各社で前提条件が違う

複数社に同じ相談をしても、返ってくる見積もりが大きく異なるのは珍しくありません。これは一概に「高い会社が不当」「安い会社が良心的」という話ではなく、各社が想定している前提が違うからです。

スクラッチ開発か、SaaS・パッケージ活用か
要件定義をどこまで含めるか
セキュリティ・バックアップ・監視の水準
将来の機能追加を見越した設計にするか
UI/UXデザインにどこまで工数をかけるか
国内中心の体制か、オフショアを含む体制か

見積もり比較で最初に見るべきなのは金額ではなく、「何が含まれているか」です。前提条件が揃っていない相見積もりは、正確な比較になりません。

2. 「人月」という業界特有の考え方が分かりにくい

システム開発では、費用算出の考え方として「人月」が使われることが多くあります。人月とは、1人が1か月稼働した場合の作業量・費用の目安です。ただし、実務では単純に「人数×月数」で品質や生産性を比較できるわけではありません。

たとえば、同じ2人月でも、経験豊富なエンジニア2人月と、経験の浅いエンジニア2人月では成果が異なることがあります。また、PM、設計者、テスターの工数が含まれているかどうかでも総額は変わります。

見積もりの見方	確認ポイント
人月単価	役割ごとの単価差があるか、PMや設計者の単価が分かれているか
工数	なぜその工数になるのか、機能別・工程別の根拠があるか
体制	誰が担当するのか、専任PMやレビュー体制があるか
成果物	設計書、テスト仕様書、マニュアルなどが含まれるか

そのため、「人月単価が安いからお得」とは限りません。単価だけでなく、工数の根拠と体制まで確認する必要があります。

3. 発注側の要件が曖昧だと、見積もり精度が下がる

見積もりがぶれやすい大きな理由の一つが、発注側の要件整理不足です。要件が曖昧な状態では、開発会社はリスクを見込んで高めに見積もるか、逆に最低限だけを想定して安く見せるかのどちらかになりやすくなります。

現状業務フローが整理されているか
必要機能の一覧があるか
外部連携の有無が明確か
利用人数・同時接続数・データ量の想定があるか
PC・スマホなど対応デバイスが決まっているか
希望納期と優先順位が整理されているか

これらが未整理のまま依頼した見積もりは、基本的に「概算」と考えるべきです。概算見積もりと詳細見積もりでは、金額が大きく変わることがあります。

【判断ポイント①】費用の内訳が工程別・機能別に明示されているか

見積もりの適正さを判断する第一歩は、費用の内訳が十分に開示されているかを見ることです。内訳が細かいほど、比較・質問・調整がしやすくなります。

「一式見積もり」は比較しづらく、追加費用の温床になりやすい

「システム開発一式 500万円」のような見積もりは、一見するとシンプルですが、発注側にとっては判断材料が不足しています。何が含まれ、何が含まれないのかが不明確だからです。

スコープ外の機能が後から追加費用になる
設計やテストが十分に確保されているか分からない
他社見積もりと横並びで比較できない

特に注意したいのは、安い一式見積もりです。安く見えても、実際には必要な機能や保守が含まれていない場合があります。

工程別に分かれているかを確認する

最低でも、次のような工程別の内訳があると比較しやすくなります。なお、下表の比率は案件規模や契約形態で変わるため、あくまで一般的な目安です。

工程	費用比率の目安	確認したい内容
要件定義	10〜20%	ヒアリング回数、要件定義書の有無、業務整理支援の範囲
設計	15〜25%	画面設計、DB設計、API仕様、権限設計など
開発・実装	30〜50%	機能別工数、フロント・バックエンドの分担
テスト	10〜25%	単体・結合・受入支援の範囲、テスト観点
移行・導入	5〜15%	データ移行、初期設定、教育、リリース支援
保守・運用	別建てが多い	問い合わせ対応、障害対応、更新作業の範囲

テストや設計の比率が極端に低い場合は、品質面のリスクを疑ったほうがよいでしょう。

人月単価と工数をセルフチェックするコツ

人月単価の相場は、地域、会社規模、役割、契約形態によって大きく変動します。そのため「全国一律の正解」はありませんが、国内の受託開発では、エンジニアやPMの月額換算単価が数十万円台後半〜百数十万円程度に収まるケースが多く見られます。

ただし、近年は人材不足や物価上昇の影響もあり、2026年時点では単価レンジが上振れする案件も珍しくありません。相場を見るときは「単価の高低」だけでなく、担当者の役割・経験・責任範囲をセットで確認することが重要です。

単価が高い理由：上流工程対応、業務理解、PM力、セキュリティ要件、レビュー体制
単価が低い理由：オフショア活用、若手中心、設計や管理工数が別建て、スコープ限定
確認すべき点：機能別工数、管理工数、レビュー工数、テスト工数の有無

なお、機能ごとの標準工数は開発言語や既存資産の有無で大きく変わるため、単純な相場表だけで断定するのは危険です。見積もりの妥当性は、「過去の類似案件と比べてどうか」を開発会社に説明してもらうのが現実的です。

【判断ポイント②】開発方式の提案が、要件と予算に合っているか

同じ課題を解決する方法でも、スクラッチ開発、パッケージ導入、SaaS活用、ノーコード/ローコードなど複数の選択肢があります。見積もりの適正さは、金額だけでなく「その作り方が本当に妥当か」で判断すべきです。

スクラッチ以外の選択肢も提示されているか

優良な開発会社ほど、最初からスクラッチありきではなく、複数の実現方法を比較してくれます。特に業務システムでは、既存SaaSやパッケージ、ローコード製品で十分な場合もあります。

方式	初期費用の傾向	向いているケース	注意点
スクラッチ開発	高め	独自業務が強い、競争優位を作りたい	開発期間・保守負担が大きくなりやすい
パッケージ/ERPカスタマイズ	中程度	標準業務に近い、早く導入したい	カスタマイズが増えると高額化しやすい
SaaS導入	低〜中	会計、人事、CRM、ワークフローなど標準業務	月額課金、機能制約、ベンダーロックインに注意
ノーコード/ローコード	低〜中	小規模な社内ツール、試作、短納期案件	複雑な処理や大規模運用に限界がある場合がある

なお、2026年時点では「ノーコードだけで何でも作れる」といった表現は誇大です。実際には、業務の複雑さ、外部連携、権限管理、監査要件によって向き不向きがあります。

要件に対してオーバースペックな技術になっていないか

小規模な社内ツールなのに、大規模サービス向けの複雑なアーキテクチャを提案されることがあります。高度な技術そのものが悪いわけではありませんが、要件に対して過剰であれば初期費用も保守費も膨らみます。

利用者数やデータ量に対してインフラ構成が過剰ではないか
技術選定の理由が「流行」ではなく業務要件に基づいているか
将来の保守担当者を確保しやすい技術か
障害時に他社でも引き継ぎやすい構成か

たとえば、Kubernetes、マイクロサービス、イベント駆動設計などは有効な場面もありますが、すべての案件に必要ではありません。「なぜこの技術なのか」をビジネス要件で説明できるかが重要です。

初期費用だけでなく、将来の保守コストまで確認する

技術選定は、将来の保守性に直結します。特定ベンダー独自の仕組みや、利用者の少ない技術を採用すると、将来の改修費が高くなることがあります。

使用言語・フレームワークのサポート状況
クラウドやSaaSの継続利用料金
ドキュメント整備の方針
ソースコードや設計書の引き渡し条件
第三者保守への切り替えやすさ

※フレームワークやランタイムのサポート期限は頻繁に更新されます。PHP、Node.js、Java、各種クラウドサービスのサポート情報は、必ず公式ドキュメントで最新状況をご確認ください。

【判断ポイント③】開発スコープと追加費用の条件が明確か

見積もりトラブルで最も多い原因の一つが、スコープの曖昧さです。契約前に「どこまでが見積もりに含まれるか」を明確にしておかないと、後から追加費用が発生しやすくなります。

追加費用が発生しやすい典型パターン

通知機能、権限管理、CSV出力などの周辺機能が見積もり外だった
外部システム連携の仕様が未確定で、後から工数が増えた
既存データの移行・整形作業が含まれていなかった
スマホ対応や複数ブラウザ対応が別料金だった
受入テスト支援や操作研修が含まれていなかった

こうした項目は「当然入っているはず」と思い込みやすいため、見積書・提案書・要件一覧で明文化しておくことが大切です。

見積もりの根拠として確認したい項目

スコープの妥当性を確認するには、次のような情報が見積もりに紐づいているかを見ます。

確認項目	見るべき内容
機能一覧	対象機能が列挙され、優先順位や対象外も明記されているか
画面一覧	対象画面数、管理画面の有無、レスポンシブ対応の範囲
外部連携	連携先、API数、認証方式、テスト環境の有無
データ移行	移行元データの整備、変換、投入、検証の範囲
非機能要件	性能、可用性、セキュリティ、監査ログ、バックアップ
導入支援	教育、マニュアル、初期設定、問い合わせ対応

「何を作るか」だけでなく、「何を作らないか」まで明記されている見積もりは、トラブルが起きにくい傾向があります。

変更管理ルールを契約前に確認する

システム開発では、途中で仕様変更が発生すること自体は珍しくありません。重要なのは、変更が起きたときの扱いが明確かどうかです。

軽微変更の定義は何か
追加見積もりが必要になる条件は何か
変更時の承認フローはどうなっているか
納期への影響を誰がどう判断するか
不具合修正と仕様変更の線引きは何か

契約形態が請負か準委任かによっても、責任範囲や変更時の扱いは変わります。契約条件に不安がある場合は、法務担当者や弁護士などの専門家に確認するのが安全です。

【判断ポイント④】保守・運用コストを含めたTCOで見ているか

システムは作って終わりではありません。運用開始後には、障害対応、セキュリティ更新、クラウド利用料、機能改善など継続的な費用が発生します。初期費用だけで判断すると、結果的に高くつくことがあります。

TCO（総保有コスト）で比較する

TCOとは、導入から運用まで含めた総コストのことです。少なくとも3年、できれば5年程度で比較すると、見積もりの見え方が変わります。

コスト項目	主な内容
初期開発費	要件定義、設計、実装、テスト、導入
インフラ費	クラウド、CDN、監視、バックアップ、ドメイン、証明書
保守費	障害対応、問い合わせ、アップデート、軽微改修
追加開発費	機能追加、法改正対応、業務変更対応
ライセンス費	SaaS、API、ミドルウェア、外部サービス利用料
教育・運用費	マニュアル、社内教育、運用担当者の工数

たとえば初期費用が安くても、毎月の保守費やクラウド費が高ければ、数年後には別案より総額が高くなることがあります。

保守費の見方とチェックポイント

保守費はシステム規模や対応範囲で大きく変わるため、一律の相場を断定するのは難しいですが、小規模な社内ツールで月数万円台、中規模以上で月10万円以上になるケースは珍しくありません。24時間監視や厳格なSLAが必要なら、さらに高くなります。

重要なのは金額そのものより、何が含まれているかです。

障害・不具合対応の受付時間と対応時間
セキュリティアップデートの範囲
クラウド・サーバー監視の有無
バックアップと復元対応の有無
問い合わせ回数や対応窓口
軽微改修が含まれるかどうか

「保守込み」と書かれていても、実際には問い合わせ窓口だけで、改修や更新は別料金ということもあります。契約前に必ず確認しましょう。

保守が薄い見積もりの長期リスク

保守費が極端に安い、または保守契約がない場合、短期的には安く見えても、長期的にはリスクが高くなります。

脆弱性対応が遅れ、セキュリティ事故につながる
担当者が不在で障害時に復旧が遅れる
ライブラリやOSの更新が止まり、将来の改修費が膨らむ
運用ノウハウが属人化し、引き継ぎが難しくなる

特に受発注、在庫、顧客管理など業務停止の影響が大きいシステムでは、初期費用よりも保守体制の安定性を重視すべき場面があります。

【判断ポイント⑤】開発会社の実績・体制・信頼性が費用に見合っているか

見積もりの適正さは、金額だけでは判断できません。同じ500万円でも、実績豊富なチームが上流設計から保守まで担うのか、経験の浅い少人数チームが最低限の実装だけを行うのかで、価値は大きく変わります。

相場より大幅に安い見積もりで考えられる背景

オフショアやニアショアを活用している
若手中心で単価を抑えている
設計・テスト・保守を薄くしている
受注後の追加開発で利益を確保する前提になっている
実績作りのために低採算で受注している

安いこと自体が悪いわけではありません。ただし、「なぜ安いのか」を説明できるかどうかは必ず確認しましょう。

事前に確認したい会社・チームのポイント

類似業務・類似規模の開発実績があるか
専任PMまたは進行管理責任者がいるか
要件定義、設計、実装、テストの役割分担が明確か
障害時や担当者離脱時のバックアップ体制があるか
情報セキュリティに関する社内ルールや認証があるか
保守や追加開発を継続して依頼できる体制か

なお、PマークやISMSは一定の管理体制を示す参考材料にはなりますが、それだけで開発品質を保証するものではありません。実績、提案内容、体制説明とあわせて総合的に判断しましょう。

比較しやすい見積もりを取るにはRFPが有効

複数社を正しく比較したいなら、RFP（提案依頼書）を用意するのが有効です。各社に同じ前提条件を渡せるため、見積もりのばらつきを抑えやすくなります。

プロジェクトの背景・目的
現状業務の課題
必要機能と優先順位
非機能要件（性能、セキュリティ、可用性など）
外部連携の対象
希望納期
予算感
評価基準（価格、実績、保守体制など）

RFPが難しい場合でも、最低限「機能一覧」「利用人数」「外部連携」「希望時期」の4点は揃えて依頼すると、見積もり精度が上がります。

見積もりの「高すぎ・安すぎ」を判断するための相場感

システム開発費用は案件ごとの差が大きいため、相場はあくまで参考です。特に2024年以降は、エンジニア人材不足、円安、クラウド費用の変動、セキュリティ要件強化などの影響で、従来より高めに出るケースもあります。

その前提で、中小企業向けの一般的な目安を整理すると次のようになります。

システム種別	規模の目安	初期費用の参考レンジ	補足
簡易な社内ツール	少画面・単純業務	50万〜200万円前後	ノーコード/ローコード活用で抑えやすい
小規模な業務システム	10〜20画面程度	200万〜700万円前後	外部連携や権限管理で増額しやすい
中規模の業務システム	複数部門利用・連携あり	500万〜2,000万円前後	要件定義や移行の難易度で差が大きい
ECサイト構築	標準機能中心	150万〜600万円前後	SaaS/パッケージ活用かスクラッチかで大きく変動
独自要件の強いEC/会員サイト	基幹連携・独自機能あり	500万〜3,000万円以上	物流・決済・CRM連携で高額化しやすい
スマホアプリ	iOS/Android対応	300万〜1,500万円前後	ネイティブ、WebView、バックエンド有無で変動

※上記は2026年06月06日時点の一般的な参考レンジです。実際の費用は、要件、品質、体制、地域、契約形態、既存資産の有無で大きく変わります。

3社以上を比較するときの評価シート例

相見積もりでは、価格だけでなく総合点で比較するのがおすすめです。

評価項目	重みの例	確認内容
初期費用	20%	予算内か、内訳が明確か
3〜5年TCO	20%	保守・クラウド・追加開発を含めて比較
スコープの明確さ	15%	対象機能、対象外、変更条件が明確か
技術・開発方式	15%	要件に合っているか、保守しやすいか
実績・信頼性	15%	類似案件、体制、継続支援の有無
PM・コミュニケーション	10%	説明の分かりやすさ、進行管理の安心感
保守・サポート	5%	障害対応、問い合わせ、更新範囲

最安値の会社が、必ずしも最も費用対効果が高いとは限りません。評価軸を決めて比較すると、判断しやすくなります。

値下げ交渉より、スコープ調整のほうが安全なことが多い

予算を超えたときに、単純な値引き交渉だけをすると、見えないところで工数や品質が削られることがあります。より現実的なのは、優先順位をつけてスコープを調整する方法です。

Must / Should / Could で機能を整理する
フェーズ1とフェーズ2に分ける
初期は手作業で代替できる機能を外す
デザインや管理機能を最小限にする
既存SaaSで代替できる部分は置き換える

この方法なら、品質を大きく落とさずに初期費用を抑えやすくなります。

よくある質問（FAQ）

見積もりの「人月」はどう判断すればよいですか？

人月そのものは一般的な見積もり表現ですが、それだけでは妥当性を判断できません。単価、工数、役割、成果物の4点をセットで確認しましょう。

誰の単価か（PM、SE、PG、テスター）
何に何人月かかるのか
設計やテストが十分に含まれているか
過去の類似案件をもとに説明できるか

単価が極端に低い場合は、若手中心、オフショア中心、または管理工数が別建ての可能性があります。逆に高い場合は、上流工程や高い品質保証を含んでいることがあります。

複数社の見積もりが3倍以上違う場合、どちらを信じるべきですか？

まずは「同じものを見積もっているか」を確認してください。多くの場合、スコープ、品質基準、保守範囲、技術選定が違います。

安い会社には「なぜこの金額で可能なのか」、高い会社には「どこにコストがかかっているのか」を具体的に説明してもらうのが有効です。説明の明確さ自体が、会社選びの判断材料になります。

「要件定義後に費用確定」という提案は信頼できますか？

要件が曖昧な段階では、詳細見積もりを確定できないのが通常です。そのため、「まず要件定義を行い、その後に本見積もりを出す」という提案は、むしろ実務的で誠実な場合があります。

ただし、次の点は確認しましょう。

要件定義フェーズの費用と成果物が明確か
要件定義後に本発注しない選択肢があるか
成果物の引き渡しを受けて他社比較できるか
本開発の概算レンジが事前に示されているか

契約条件によって扱いが変わるため、不明点は契約前に必ず確認してください。

見積もり段階でNDA（秘密保持契約）を結ぶのは普通ですか？

はい、一般的です。見積もりのために業務情報や顧客情報、システム構想を共有する場合、NDAを締結するのは自然な流れです。