IPA（情報処理推進機構）「ソフトウェア開発分析データ集2024」によると、システム開発プロジェクトの約44%が当初見積りを超過して完了している（IPA、2024年10月公表）。また、追加費用が発生するケースは少なくない（※発生率はプロジェクトの規模・契約形態により異なる）。見積書の段階で「何にいくらかかるのか」を見抜けなければ、追加請求のリスクは自社が負うことになる。
システム開発の見積書の見方｜基本項目一覧
見積書に並ぶ項目は、開発会社によって粒度が異なる。ここでは一般的な見積書に含まれる主要項目を整理する。
横にスクロールして確認できます
| 項目 | 内容 | 費用目安（構成比） |
|---|---|---|
| 要件定義 | 業務分析、要件の文書化、画面設計の前段階 | 全体の10-15% |
| 基本設計（外部設計） | 画面設計、DB設計、システム構成設計 | 全体の10-15% |
| 詳細設計（内部設計） | プログラム仕様書の作成 | 全体の5-10% |
| 開発（プログラミング） | コーディング、単体テスト | 全体の30-40% |
| テスト | 結合テスト、総合テスト、受入テスト支援 | 全体の15-20% |
| プロジェクト管理（PM費） | 進捗管理、会議、報告書作成 | 全体の10-15% |
| 環境構築 | サーバー構築、デプロイ設定 | 全体の3-5% |
| 保守・運用（初年度） | 障害対応、小規模改修、監視 | 別途月額 |
※ 上記構成比はIPA「ソフトウェア開発分析データ集」の中規模案件（1,000-5,000万円帯）のデータに基づく目安。案件規模や開発手法（ウォーターフォール/アジャイル）により変動する。
費用相場の全体像については中小企業のためのシステム開発費用ガイドも併せて参照されたい。
要件定義とは、「このシステムで何を実現したいか」を開発会社と一緒に文書にまとめる工程だ。基本設計は画面の見た目やデータベースの構造を決める工程。テストは作ったシステムが正しく動くかを検証する工程を指す。
RESTAURANT DX
店長の経験と勘を、仕組みで再現できる店舗にしませんか？
発注／シフト／予約／FLコストを標準化する多店舗飲食特化のDX。食材ロス削減・インバウンド対応まで概算費用をその場で示します。
失敗しないための7つのチェック項目
1. 人月単価の相場感を確認する
「人月単価」とは、エンジニア1名が1ヶ月稼働した場合の費用のこと。JISA（情報サービス産業協会）の業界統計を参考にした一般的な相場として、SE（システムエンジニア）の人月単価は80-120万円、PG（プログラマー）は60-90万円が国内相場だ。見積書の人月単価がこの範囲から大きく外れている場合は、その理由を確認すべきだ。単価が極端に安い場合、経験の浅いエンジニアが配置されるリスクがある。
2. 要件定義費用が計上されているか
要件定義の工程が見積りに含まれていない場合、2つの可能性がある。1つは「要件定義なしで開発を進める（=手戻りリスク大）」、もう1つは「後から追加費用として請求される」だ。IPA「ソフトウェア開発分析データ集」でも、要件定義の不備がコスト超過の最大要因と分析されている。要件定義費用が明記されていることを確認しよう。
3. テスト工数の妥当性を見る
テスト工程は全体の15-20%が目安だ。テスト工数が全体の10%未満であれば、品質リスクが高い。逆に、テスト工程の記載が「テスト一式」のように曖昧な場合も注意が必要だ。結合テスト、総合テスト、受入テスト支援がそれぞれ分かれて記載されているかを確認する。
4. プロジェクト管理費の割合を確認する
PM（プロジェクトマネージャー）の管理費は全体の10-15%が相場だ。0%の場合は管理費が他の項目に上乗せされている可能性がある。逆に20%を超える場合は、管理コストが過大ではないか根拠を確認したい。管理費には進捗報告、会議体の運営、課題管理などが含まれる。
5. 保守・運用費用が明記されているか
システムは「作って終わり」ではない。リリース後の保守・運用費用が見積書に含まれているか、別途契約なのかを確認する。業界慣行として開発費の15〜20%程度が年間保守費用の目安とされている。保守の範囲（障害対応のみか、機能追加を含むか）も重要なチェックポイントになる。
6. 追加費用の発生条件を確認する
「仕様変更が発生した場合の費用はどうなるか」を事前に確認する。見積書または契約書に、追加費用の算定方法（時間単価制、都度見積り等）と、変更管理のプロセスが記載されているかをチェックする。この記載がない見積書は、後から「言った・言わない」のトラブルになりやすい。
7. 支払い条件とマイルストーンを確認する
一括前払いを求められる見積書には注意が必要だ。一般的には、着手金（30%）、中間金（30-40%）、検収完了時（30-40%）のように分割払いとし、各段階で成果物を確認してから支払う形が望ましい。マイルストーン（中間の区切り）ごとに成果物が定義されていれば、進捗の可視化にもなる。
見積書で「危ない」サイン3つ
以下のいずれかに該当する見積書は、追加費用やトラブルのリスクが高い。
1. 「一式」が多すぎる見積書 「開発一式 500万円」のように、作業内容が分解されていない見積書は、何にいくらかかっているのか判断できない。工程ごと、機能ごとに分解された見積書を依頼すべきだ。
2. テスト工程の記載がない、または極端に少ない見積書 テスト工程を省略してコストを下げている見積書は、リリース後の不具合対応で結局コストが膨らむ。
3. 保守費用に一切触れていない見積書 開発費だけを安く見せて受注し、保守契約で回収するビジネスモデルの可能性がある。開発費と保守費用の合計で比較することが重要だ。
見積書の内容、妥当かどうか確認しませんか？
見積シミュレーションでは、業務内容と規模をもとに開発費用の概算を確認できます。他社の見積書との比較材料としてもご活用いただけます。開発事例はこちらをご参照ください。
※ 営業電話はしません | オンライン対応可 | 相談だけでもOK
適正価格を知るためのアクション
見積書を受け取ったら、以下の3つのアクションで適正価格を判断する。
1. 複数社から見積りを取る 最低3社から見積りを取得し、項目ごとに比較する。総額だけでなく、人月単価、テスト工数比率、PM費比率を横並びで比較することで、各社の見積りの妥当性が見えてくる。
2. RFP（提案依頼書）を作成する 同じ条件で比較するために、自社の要件を文書化したRFP（提案依頼書）を作成する。RFPとは「こんなシステムを作りたい」という要望をまとめた書類だ。これがあると各社が同じ前提で見積りを出せるため、比較精度が上がる。
3. 工程別の相場を把握する 本記事の項目一覧と構成比を参照し、受け取った見積書の各項目が相場範囲内かを確認する。大きく外れている項目があれば、開発会社にその理由を質問する。
費用の全体像を把握するなら
システム開発の費用相場、発注の流れ、予算の組み方については、中小企業のためのシステム開発費用ガイドで体系的に解説している。見積書の確認と併せて参考にしていただきたい。
また、会社概要では開発体制や対応領域を確認できる。
まとめ
見積書は「総額」ではなく「項目ごとの内訳」で読む。7つのチェック項目（人月単価、要件定義、テスト工数、PM費、保守費用、追加費用条件、支払い条件）を確認すれば、不透明な見積りを見抜ける。複数社から見積りを取り、同じ条件で比較することが、適正価格で発注するための最も確実な方法だ。
受け取った見積書の妥当性を確認しませんか？
見積シミュレーションでは、業務内容と規模をもとに開発費用の概算を確認できます。受け取った見積書が適正かどうかの判断材料としてご活用ください。開発事例はこちらもご参照ください。
※ 営業電話はしません | オンライン対応可 | 相談だけでもOK
GXOの見解
システム開発の成否は開発会社選びの前に、業務要件、既存データ、運用責任、段階移行をどこまで整理できるかで決まる。
GXOは見積比較だけでなく、発注前の論点整理とRFP設計が手戻りと追加費用を減らすと見る。
GXOは、業務整理、要件定義、RFP、開発、保守、レガシー刷新まで接続できる形で支援します。
実務判断のポイント
この記事を読むべきなのは、経営者、情シス、業務責任者、発注担当です。単に情報を把握するだけでなく、要件定義、RFP作成、見積比較、レガシー刷新、業務システム再構築の相談に進めるべきかを判断するための材料として整理する必要があります。
GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。システム開発の見積書の見方｜失敗しないための7つのチェック項目【テンプレート付き】に関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。
放置した場合と整備した場合の違い
横にスクロールして確認できます
| 観点 | 放置した場合 | 整備した場合 |
|---|---|---|
| 業務影響 | 属人的な判断が増え、対応の優先順位がぶれやすい | 影響範囲、期限、責任者を決めて進められる |
| 投資判断 | ツール導入や外注費だけが先行し、効果測定が曖昧になる | 売上、工数削減、リスク低減の指標にひも付けられる |
| 現場運用 | 例外処理や承認フローが残り、定着しにくい | 権限、ログ、教育、改善サイクルまで設計できる |
| 経営報告 | 問題が発生してから説明資料を作ることになる | 月次で状況、課題、次の打ち手を説明できる |
導入・改善前のチェックリスト
- 対象業務、対象部門、対象データを明文化しているか
- 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
- 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
- 例外処理、承認、差し戻し、監査証跡まで確認しているか
- 社内で判断できる範囲と外部支援が必要な範囲を分けているか
- 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
- 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
- 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
- セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
- 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
- 経営判断に必要な資料を1枚で説明できる状態にしているか
- 次の90日で検証する範囲と、やらない範囲を明確にしているか
GXOの実務補足
システム開発の成否は開発会社選びの前に、業務要件、既存データ、運用責任、段階移行をどこまで整理できるかで決まる。
GXOは見積比較だけでなく、発注前の論点整理とRFP設計が手戻りと追加費用を減らすと見る。
GXOは、業務整理、要件定義、RFP、開発、保守、レガシー刷新まで接続できる形で支援します。記事のテーマを単なる情報収集で終わらせず、相談、診断、要件定義、実装、運用改善に接続することで、要件整理から開発、保守、段階移行ロードマップへ接続。さらに、標準ヒアリングと既存診断を使い、発注前相談から開発案件へ展開。
相談につながる進め方
- 現在の業務、データ、ツール、担当者を棚卸しする
- 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
- 初期対応、90日以内の改善、半年以上の投資を分ける
- 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
- 小さく検証し、効果測定後に本番化や横展開を判断する
FAQ
Q1. 見積書の金額が会社によって大きく違うのはなぜ？
開発会社ごとに、エンジニアの単価水準、開発手法（ウォーターフォール/アジャイル）、見積りに含める工程の範囲が異なるためだ。例えば、要件定義やテストを含む見積りと、開発工程のみの見積りでは総額が大きく変わる。比較する際は「何が含まれていて、何が含まれていないか」を確認することが重要になる。
Q2. 見積書をもらった後、何を質問すればいい？
まず「一式」と記載されている項目の内訳を聞くこと。次に、仕様変更が発生した場合の追加費用の算定方法を確認する。そして、保守・運用の範囲と費用を聞く。この3点を質問するだけで、見積書の透明性は大きく向上する。
Q3. 安い見積りを選べばコストは抑えられる？
必ずしもそうではない。テスト工程を省略した安い見積りでは、リリース後の不具合対応に追加費用がかかる可能性がある。IPA「ソフトウェア開発分析データ集」でも、テスト工程の不足がプロジェクトの手戻りコストを増大させると報告されている。初期費用だけでなく、保守費用を含めた総コストで比較することを推奨する。
参考資料
- IPA（情報処理推進機構）「ソフトウェア開発分析データ集2024」 https://www.ipa.go.jp/digital/chousa/metrics/publish-data.html
- IPA「IT人材白書2024」 https://www.ipa.go.jp/jinzai/chousa/itjinzai_hakusho.html
- 経済産業省「IT人材需給に関する調査」 https://www.meti.go.jp/policy/it_policy/jinzai/
- JISA（情報サービス産業協会）「情報サービス産業 基本統計調査 2024年版」（2024年6月公表） https://www.jisa.or.jp/Portals/0/resource/statistics/
参考情報
- 制度、価格、仕様、脆弱性、法務、セキュリティに関する判断は、公開時点の公式情報と一次情報を確認したうえで更新してください。
