なぜ「総額」だけで比較すると失敗するのか
複数社から見積もりを取得（相見積もり）した後、つい「一番安いところに頼もう」と判断したくなります。しかし、これは多くの場合、最終的に最も高くつく選択になります。
理由は3つあります。
- 項目立てが揃っていない: A社とB社で「開発費」の定義が違うため、安く見える方は要件定義やテストが含まれていないことがある
- 前提が異なる: A社は固定見積もり、B社は準委任など、契約形態が違うと総額の意味が違う
- 品質責任が見えない: 安い見積もりは、納品後の保守・障害対応がオプション扱いになっていることが多い
総額だけで比較するのは、車の値段を「ハンドルとタイヤだけ」の値段で比べるようなものです。
本記事では、見積もりを正しく比較するための13のチェック項目を解説します。
比較の前提: 同じ条件で見積もりを依頼する
そもそも、各社に「同じ条件」で見積もりを依頼していなければ、比較する意味がありません。最低限揃えるべき条件:
- 要件: 機能一覧（少なくとも箇条書き）
- 想定ユーザー数 / 利用シーン
- 非機能要件: 性能・セキュリティ・可用性
- 納期 or 段階リリース希望
- 保守・運用に関する希望
要件が揃っていない状態で総額を比較するのは時間の無駄です。
チェックリスト: 13の観点
以下のチェックリストを使い、各社の見積書を点数化（◎/○/△/×）してみてください。
観点1: フェーズ別の内訳が明示されているか
- ◎: 要件定義 / 設計 / 実装 / テスト / リリースの5フェーズ以上で分解
- ○: 大まかなフェーズ分け
- △: 「開発費一式」など曖昧
- ×: 内訳なし、総額のみ
→ 内訳が見えない見積もりは、後の交渉余地もありません。
観点2: 工数（人日 or 人月）が明記されているか
- ◎: フェーズごと・役割ごとに人日まで記載
- ○: フェーズごとの合計人日のみ
- △: プロジェクト全体の人日のみ
- ×: 工数情報なし
→ 工数が見えれば「単価×時間」で妥当性を検証できます。
観点3: 単価が開示されているか
- ◎: 役割別（PM、エンジニア、デザイナー）の単価明示
- ○: 平均単価のみ
- △: 単価非開示
- ×: 単価情報なし
→ 単価相場（PM 100〜150万/月、エンジニア 80〜120万/月など）と照合できます。
観点4: プロジェクト管理（PM）費用が含まれているか
- ◎: PMの工数と費用を独立項目で明記
- ○: 各フェーズに含まれている旨記載
- △: 「サービス」と書かれている
- ×: 言及なし
→ PMが明示されていない案件は、進捗管理が形骸化します。
観点5: テスト工数の比率が適切か
- ◎: 総工数の15〜20%以上
- ○: 10〜15%
- △: 5〜10%
- ×: 5%未満 or 言及なし
→ テストが薄い見積もりは、品質リスクとリリース後の改修費で結局高くつきます。
観点6: 仕様変更時のルールが明記されているか
- ◎: 変更管理プロセスと費用算定ルールが書かれている
- ○: 「都度協議」と書かれている
- △: 言及なし（暗黙的に対応？）
- ×: 「変更不可」と書かれている
→ 中規模以上のプロジェクトで仕様変更ゼロは現実的ではありません。
観点7: インフラ初期費用が含まれているか
- ◎: クラウド初期構築 / ドメイン / SSL等が明記
- ○: 一部含まれる
- △: 別途請求
- ×: 言及なし
→ 「あとからインフラ費が発生」を避けるため、見積もり段階で確認。
観点8: 保守・運用費の方針が示されているか
- ◎: 月額保守費 + 軽微改修工数の目安が明記
- ○: 月額保守費のみ
- △: 「都度見積もり」のみ
- ×: 保守の話題が皆無
→ システムは動き始めた瞬間から劣化します。保守なしは選択肢になりません。
観点9: 体制とアサインメンバーが明確か
- ◎: PM・リードエンジニアの氏名・経歴を提示
- ○: 役割と人数の明記
- △: 「適任者をアサイン」とのみ
- ×: 体制記載なし
→ 見積もり段階で「誰が担当するか」が見えない案件は、契約後にミスマッチが起きやすい。
観点10: 開発手法と工程モデルが説明されているか
- ◎: ウォーターフォール / アジャイル / 段階リリースなどが明記、根拠も説明
- ○: 開発手法が書かれている
- △: 暗黙的
- ×: 説明なし
→ 開発手法は予算とリスクに直結します。
観点11: 過去の類似実績が示されているか
- ◎: 類似業界・類似規模の実績が3件以上提示されている
- ○: 1〜2件
- △: 「実績多数」と概要のみ
- ×: 実績情報なし
→ 「初めての領域」のシステムを引き受ける会社は、技術リスクが高い。
観点12: 見積もりの前提条件・制約が明文化されているか
- ◎: 「この見積もりが成立する前提」（要件凍結時期、人員可用性等）が明記
- ○: 一部記載
- △: 言及なし
- ×: 「諸条件によって変動する」のみ
→ 前提が見えない見積もりは、後で「想定外」と言われやすい。
観点13: 質問への回答品質
- ◎: メールで質問してから24時間以内に技術的に正確な回答
- ○: 48時間以内に回答、若干の認識違いあり
- △: 回答は遅いが内容は正確
- ×: 回答が遅く、的外れ
→ 見積もり段階のレスポンスは、契約後のレスポンスをそのまま反映します。
チェックリスト集計シート
各社の見積書をこの表にまとめると、比較がしやすくなります。
観点 | A社 | B社 | C社 |
|---|---|---|---|
1. フェーズ別内訳 | ◎ | ○ | △ |
2. 工数明記 | ◎ | ○ | × |
3. 単価開示 | ○ | ○ | △ |
4. PM費用 | ◎ | △ | △ |
5. テスト工数比率 | ◎ | ○ | × |
6. 変更ルール | ◎ | ○ | △ |
7. インフラ費 | ◎ | ○ | △ |
8. 保守方針 | ◎ | ○ | × |
9. 体制/メンバー | ◎ | ○ | △ |
10. 開発手法 | ◎ | ○ | △ |
11. 類似実績 | ◎ | ○ | △ |
12. 前提・制約 | ◎ | △ | × |
13. 回答品質 | ◎ | ○ | △ |
◎ = 4点 / ○ = 3点 / △ = 2点 / × = 1点 で計算してみてください。
40点以上が候補レンジ。30点未満の見積もりは、総額が安くても採用は推奨しません。
「総額が安い」会社を選んでよいケース
例外的に、総額の安さで選んでよいケースもあります。
- PoC・プロトタイプ目的: そもそも捨てる前提のコードを作る場合
- 小規模で要件が固まっている: 100人日以下で、変更余地が極小
- 継続的な発注先候補: 関係構築フェーズとして小さい案件で品質を見る
逆に言えば、本格運用するシステムで総額の安さを優先するのは原則NGです。
比較プロセスの推奨フロー
- 要件文書を整備（最低限の機能一覧と非機能要件）
- 3社程度に依頼（少なすぎても多すぎても比較精度が落ちる）
- 同じテンプレートで提出を依頼（このチェックリストを共有してもよい）
- 質疑応答を必ず行う（書面では分からない部分を確認）
- チェックリストで採点
- 総額・点数・体制を総合判断
まとめ
見積もり比較で大事なのは「総額」ではなく「比較できる粒度に揃っているか」と「品質要素が十分か」の2点です。本記事のチェックリストを使って、相見積もりを健全に比較してください。
弊社では、見積もり段階から内訳・工数・単価・体制をすべて開示し、本チェックリストの全項目を満たす提案をお約束しています。
関連記事
比較対象に弊社を加えませんか
弊社では、見積もり段階から透明な情報開示で、本チェックリストの全項目を満たす提案を行っています。