システム開発の見積もりが会社によって違う理由
同じ "予約システム" でも、含まれる品質・設計・運用範囲で金額は大きく変わる。
この記事の結論
- 見積もりの差は、単価差だけでなく、要件定義・設計・テスト・保守・セキュリティ・運用範囲の差 から生まれます。
- 「同じシステム」に見えても、含まれる品質ライン が違えば見積もりは数倍違います。
- 見積もりの内訳には、工程別の工数・含まれる成果物・含まれない項目・追加費用の計算方法 が明示されているのが正常です。
- 安い見積もりで確認すべき質問は 7 つ。返答内容で、安さの理由が見えます。
- 予算別 (50 / 300 / 1,000 万円以上) でできることのレンジを把握しておくと、相談先が絞れます。
「3 社に見積もりを依頼したら、50 万円・300 万円・1,000 万円が並んだ。何が違うのか分からない」
発注検討中の経営者から、よく届く相談です。同じシステムを発注したつもりが、見積もりが 20 倍違う ことはあります。これは単価差ではなく、含まれる範囲と品質ライン の差です。
OpenAI が公開している Codex の説明でも、「動くものを作る」だけでなく、テストやリンタなど実開発環境に近い構成 で実行することが整理されています (Introducing Codex / OpenAI)。AI でない開発でも、「動かす」と「運用に耐える状態にする」では、必要な工数が違います。
この記事では、見積もりの内訳、安い見積もりで確認すべき質問、予算別にできることを整理します。
なぜ同じ依頼で見積もりが違うのか
主な理由を 5 つに整理します。
1. 含まれる工程の差
- A 社: 実装だけ
- B 社: 要件定義 + 設計 + 実装
- C 社: 要件定義 + 設計 + 実装 + テスト + 保守
同じ「実装」でも、前後の工程がどこまで含まれるかで金額が変わります。
2. 含まれる品質ラインの差
- A 社: 動けば OK、テスト最小限
- B 社: 主要フローのテスト、セキュリティ標準
- C 社: 重要フロー E2E、SOC2 想定、ペネトレーションテスト
「同じ機能」でも、品質ラインで工数が大きく変わります。
3. 含まれる運用範囲の差
- A 社: リリースで終わり
- B 社: リリース後 1 ヶ月のサポート
- C 社: リリース + 月額保守 + 月次レビュー
リリース後のサポートが含まれているかで、月額の見え方が違います。
4. AI 活用の深さの差
- A 社: AI 利用なし、または実装だけ AI
- B 社: 設計、レビュー、テストに AI 活用
- C 社: AI 開発体制が組織として整備されている
AI 活用が深いほど、同じ品質を出すために必要な工数が減ります。
5. チーム編成の差
- A 社: ジュニアエンジニア中心
- B 社: ミドル + ジュニア
- C 社: シニア + ミドル + 専門家 (セキュリティ、AI、UX)
人月単価より、「誰がやるか」 が品質と納期に効きます。
見積もりに含まれる項目
正常な見積もりに含まれているべき項目:
| 項目 | 内容 |
|---|---|
| 要件定義 | ヒアリング、機能整理、優先順位 |
| 設計 | アーキテクチャ、データモデル、画面設計 |
| 実装 | フロント、バックエンド、インフラ |
| テスト | 単体、結合、E2E、受け入れ |
| デプロイ | 本番環境構築、CI/CD、デプロイ手順 |
| ドキュメント | 設計書、運用 Runbook、引き継ぎ資料 |
| 保守 | リリース後の対応期間と内容 |
| プロジェクト管理 | 進捗管理、ミーティング、報告 |
これらが内訳として明示されていれば、安い・高いを判断できます。
見えにくい工数
見落とされやすい工数も含めて確認します。
1. 設計
- データモデル、API、画面遷移の設計
- アーキテクチャ判断
- 技術選定
2. 例外処理
- 異常系の検討
- エラーハンドリング
- 復旧手順
3. テスト
- テストケースの作成
- テストデータの準備
- 受け入れテスト
4. セキュリティ
- 認証・権限の設計
- 入力検証
- 脆弱性スキャン
5. パフォーマンス
- 負荷想定
- データベース最適化
- キャッシュ設計
6. 監視・ログ
- エラー監視
- アクセスログ
- 監査ログ
7. プロジェクト管理
- 週次ミーティング
- 進捗報告
- リスク管理
これらが見積もりに含まれていない場合、リリース後に問題が顕在化します。
ここまでで「自社の見積もりの内訳を見直したい」と感じたら、セカンドオピニオン相談をご利用ください。
安い見積もりで確認すべき 7 質問
安い見積もりが届いたとき、必ず聞くべき質問:
- 「要件定義は別費用ですか?」
- 「テストはどこまで含まれていますか?」
- 「セキュリティのレビューはありますか?」
- 「リリース後 30 日の不具合対応は含まれますか?」
- 「仕様変更時の追加費用の計算方法を教えてください」
- 「ソースコードは納品されますか?」
- 「契約終了時の引き継ぎは何が含まれますか?」
これらの返答で、安さの理由がはっきりします。「全部含まれています」と答えた上で、まだ安い場合は、実際の工数を確認 します。
予算別にできること
予算レンジ別の現実的なスコープ:
| 予算 | できること | できないこと |
|---|---|---|
| 50〜100 万円 | PoC、ノーコード MVP、軽微改修 | 認証必須の SaaS、課金あり、本番品質 |
| 300〜500 万円 | MVP 開発、認証・課金・KPI 計測 | リッチな管理画面、多言語、エンタープライズ |
| 1,000 万円〜 | 本番開発、スケール対応、セキュリティ | 短期間 (3 ヶ月以内) のフル機能 |
詳しくは スタートアップの開発予算は最初にいくら必要か で展開しています。
見積もりのセカンドオピニオン
複数社の見積もりを取って、判断に迷うときは、第三者のセカンドオピニオン が役立ちます。
セカンドオピニオンで確認する内容
- 各見積もりの内訳の妥当性
- 含まれていない項目の指摘
- 予算と実現可能性のマッチング
- 推奨できる発注先 (規模、特徴別)
min's での提供
- 1〜2 時間のセッション
- 見積もり 3 社を比較レビュー
- 質問項目の整理サポート
- 費用: 10〜30 万円 (内容による)
見積もりが透明な会社の特徴
信頼できる見積もりを出す会社の特徴:
- 内訳が工程別に明示されている
- 含まれていない項目が書かれている
- 仕様変更時の計算方法が明示されている
- 過去の類似案件の費用感を共有してくれる
- 「もっと安くする方法」も提案してくれる
逆に 「総額だけ」「内訳は秘密」「仕様変更は別途見積もり」 という会社は、後で揉める可能性が高くなります。
min's の見積もりスタンス
min's の見積もりは、以下の原則で出しています。
- 工程ごとの工数を明示 (要件、設計、実装、テスト、デプロイ)
- 含まれていない項目を明示
- 仕様変更時の費用計算方法を明示
- リリース後のサポート条件を明示
- AI 活用で短縮できる工程を明示
- 想定リスクと対応費用を明示
「総額が安い」よりも「内訳が透明で、リスクが共有されている 」を重視するスタイルです。
見積もりについて相談したい方へ
min's では、開発会社の見積もりレビュー、セカンドオピニオン、契約レビューを提供しています。
以下のような状態であれば、ご相談ください。
-
複数社の見積もりを比較しているが、判断材料が欲しい
-
安い見積もりの妥当性を確認したい
-
自社の予算で何ができるか相談したい
-
セカンドオピニオンを依頼したい
次に読む記事
参考
- Introducing Codex / OpenAI — テスト・実開発環境を組み込んだ検証可能な開発
- OpenAI frontier models and Codex on AWS / OpenAI — エンタープライズ導入での運用フロー整合