- システム開発の見積書の基本構成と各項目の意味
- 人月単価・工数の妥当性チェック方法
- 複数社の見積もりを正しく比較する方法
- 見積書でよくある落とし穴と注意点
- 見積もり交渉のポイントとやってはいけないこと
なぜ見積書の「読み方」が重要なのか
システム開発の見積書は、建設の見積書と同じくらい専門的です。「合計金額だけ見て安い方を選ぶ」のは、家を建てるときに坪単価だけで決めるようなもの。含まれている範囲が違えば、安い見積もりが結果的に高くつくことは珍しくありません。
特にシステム開発では「見積もりに含まれていなかった」という追加費用が発生しやすく、最終的なコストが当初見積もりの1.5〜2倍になるケースもあります。
この記事では、IT知識がなくても見積書のポイントを押さえ、適正な価格で発注できるようになることを目指します。
見積書の基本構成
システム開発の見積書は、一般的に以下の構成になっています。
①要件定義・設計フェーズ
- 要件定義 — 何を作るかを整理する工程。全体の10〜15%程度
- 基本設計(外部設計) — 画面・帳票・データベースの設計。全体の10〜15%
- 詳細設計(内部設計) — プログラムの内部構造の設計。全体の10%程度
②開発・実装フェーズ
- プログラミング(実装) — 実際にコードを書く工程。全体の30〜40%
- 単体テスト — 個々のプログラムの動作確認。実装に含まれることも多い
③テストフェーズ
- 結合テスト — プログラム同士を繋げた動作確認。全体の10〜15%
- 総合テスト(システムテスト) — システム全体の動作確認。全体の5〜10%
④その他
- プロジェクト管理(PM費用) — 進捗管理・会議・報告。全体の10〜15%
- 環境構築 — サーバー・開発環境・テスト環境の構築
- データ移行 — 旧システムからのデータ移行。意外とコストがかかる
- マニュアル作成 — 操作マニュアル・管理者マニュアル
- 教育・研修 — ユーザー向けの操作研修
人月単価の読み方
システム開発の見積もりは「人月」(1人が1ヶ月働く量)を基本単位とします。見積金額は「人月単価 × 工数(人月)」で計算されます。
人月単価の相場
| 役割 | 単価相場(月額) | 説明 |
|---|---|---|
| プロジェクトマネージャー | 120〜200万円 | プロジェクト全体の管理 |
| システムエンジニア(上級) | 100〜150万円 | 設計・技術判断 |
| システムエンジニア(中級) | 70〜100万円 | 設計・実装 |
| プログラマー | 50〜80万円 | 実装・テスト |
| デザイナー(UI/UX) | 60〜100万円 | 画面設計・デザイン |
上記は一般的な国内開発会社の相場です。大手SIerはこの1.5〜2倍、オフショア開発は0.3〜0.6倍程度になります。
単価が高い=割高とは限らない
人月単価が安い会社が必ずしも得とは限りません。スキルの低いエンジニアは工数が多くかかるため、「単価50万円 × 10人月 = 500万円」と「単価100万円 × 4人月 = 400万円」を比較すると、単価が高い方が安くなるケースもあります。
重要なのは「単価」ではなく「総額と品質のバランス」です。
工数の妥当性チェック
見積書で最も判断が難しいのが「工数が妥当かどうか」です。以下のポイントでチェックしましょう。
チェックポイント①:工程別の比率
一般的なシステム開発の工程別比率の目安は以下のとおりです。
| 工程 | 比率の目安 | 注意点 |
|---|---|---|
| 要件定義・設計 | 25〜35% | ここが少なすぎると手戻りが増える |
| 実装 | 30〜40% | 主たる開発工程 |
| テスト | 15〜25% | ここを削ると品質リスク |
| PM・管理 | 10〜15% | 全体の10%未満だと管理が手薄 |
テスト工程が全体の10%未満の場合は要注意です。テストを削ってコストを下げている可能性があり、納品後の不具合リスクが高くなります。
チェックポイント②:機能数と工数のバランス
簡易的なチェックとして、画面数や機能数あたりの工数を計算してみましょう。
- 一般的なCRUD画面(一覧・詳細・登録・編集・削除):0.5〜1.5人月/画面
- 複雑な業務ロジックを含む画面:1.5〜3.0人月/画面
- 外部システム連携(API連携):1.0〜3.0人月/連携先
これらの目安と大きく乖離している場合は、理由を確認しましょう。
チェックポイント③:暗黙のコスト
見積書に明記されていないが、実際には発生するコストがあります。
- サーバー・インフラ費用 — クラウド利用料は月額ランニングコスト
- SSL証明書・ドメイン — 年額数千〜数万円
- 外部サービス利用料 — 決済代行、メール配信、地図API等の月額費用
- 保守運用費用 — 開発後の月額保守費用(月額開発費の15〜20%が目安)
- 追加開発の余地 — 「Phase 2」として後回しにされた機能の費用
複数社の見積もりを正しく比較する
システム開発の発注では、2〜3社から見積もりを取るのが一般的です。ただし、各社のフォーマットや前提条件が異なるため、単純な金額比較はできません。
比較表の作り方
以下の項目で横並びの比較表を作成しましょう。
- 見積もり総額(税抜・税込を統一)
- 含まれる範囲(要件定義〜テスト〜導入まで含むか)
- 含まれないもの(サーバー費用、データ移行、教育等)
- 開発期間
- 使用技術(言語、フレームワーク、インフラ)
- 保守費用(月額・年額)
- 体制(PM有無、何名体制か)
- 支払い条件(一括・分割・マイルストーン払い)
安すぎる見積もりに注意
3社中1社だけ極端に安い場合は、以下の可能性を疑いましょう。
- 要件の理解が不十分で工数を見誤っている
- テストやドキュメントを省略している
- 後から「追加費用」で回収する前提
- 経験の浅いエンジニアをアサインする予定
「なぜこの金額で出せるのか」を率直に質問し、納得できる回答が得られるか確認しましょう。
見積書でよくある落とし穴
落とし穴①:「一式」の罠
「システム開発一式:500万円」のような見積もりは要注意です。何が含まれているか分からないため、後から「それは含まれていません」と言われるリスクがあります。最低限、工程別・機能別の内訳を求めましょう。
落とし穴②:テスト費用の圧縮
金額を安く見せるためにテスト工程を最小限にしている見積もりがあります。テストが全体の10%未満の場合、品質リスクが高いと考えてください。
落とし穴③:PM費用の不在
プロジェクト管理の費用が入っていない見積もりは、「管理は誰がやるのか?」を確認しましょう。発注者側で管理する前提になっている場合、発注者に相当な負荷がかかります。
落とし穴④:保守費用の先送り
開発の見積もりだけで、運用保守の費用が記載されていないケースがあります。システムは作った後も保守が必要です。月額保守費用の目安も合わせて確認しましょう。
落とし穴⑤:変更時の追加費用ルール
開発途中で要件が変わった場合の追加費用の計算方法が明記されていないと、金額で揉めます。変更管理のルール(変更見積もりの出し方、承認フロー)を事前に合意しておきましょう。
見積もり交渉のポイント
やるべきこと
- RFP(提案依頼書)を作成する — 各社に同じ条件で見積もりを依頼し、比較しやすくする
- 予算感を伝える — 「予算は○○万円程度」と伝えることで、現実的な提案が出てくる
- 優先順位をつける — 全機能が必須でない場合、「必須」「あれば嬉しい」に分けて柔軟性を持たせる
- 段階的な開発を提案する — Phase 1で最小限を開発、Phase 2で追加機能。初期投資を抑えられる
やってはいけないこと
- 「A社はもっと安い」と値引き交渉 — 品質を落とされるか、後で追加費用で回収される
- テストやPM費用を削る — 最も削ってはいけない項目。品質とプロジェクト成功に直結
- 口頭の約束で進める — 見積もりの前提条件・範囲は必ず書面で確認
あわせて読みたい
- システム開発の契約ガイド|請負・準委任・SESの違いと注意点
- システム開発の検収・納品ガイド|検収基準の決め方とトラブル防止策
- SLA(サービスレベル契約)の決め方|システム運用保守で押さえるべき指標と条項
- 【2026年版】RFP(提案依頼書)の書き方ガイド|失敗しないシステム開発の発注準備
- 【2026年版】システム開発の費用相場まとめ|種類別・規模別に徹底解説
まとめ
- 合計金額だけで判断しない。「何が含まれていて、何が含まれていないか」が最重要
- 人月単価の相場を把握する。PM 120〜200万円、SE 70〜150万円、PG 50〜80万円が目安
- 工程別の比率をチェック。テスト10%未満・PM不在は品質リスク
- 「一式」見積もりは内訳を求める。曖昧な見積もりは後からトラブルになる
- 安すぎる見積もりには理由がある。「なぜこの価格か」を必ず確認
- 保守費用・変更時のルールも事前に確認。開発費だけでなくTCO(総保有コスト)で判断する
見積もりの比較や妥当性の判断でお困りの方は、お問い合わせからご相談ください。FUNBREWでは、透明性の高い見積もりと丁寧な説明を大切にしています。
この記事をシェア