システム開発の見積もりが高い・安いはどう判断する？見積書で見るべきポイント

「A社は500万、B社は1,200万、C社は800万——何が違うの？」

見積もり金額だけを並べても、判断はできない。金額の差は、ほぼ必ず見積もりの中身の差だ。高い・安いは、同じ前提・同じスコープに揃えて初めて語れる。

見積書は値段表ではなく、事業リスクに対する投資計画として読む。

見積書で最初に見る5つの欄

確認項目	見るべき内容
前提条件	何を前提に工数を積んだか
スコープ	含む機能・含まない機能
工数内訳	要件定義・設計・開発・テストの比率
体制	誰が何日参画するか
除外事項	明示的に「やらない」と書かれたこと

この5つが書かれていない見積書は、比較対象にならない。金額欄だけ埋まったExcelは、判断材料ではない。

「安い」見積もりに潜む3つのパターン

1. スコープが削られている

テスト工程がない。ドキュメントがない。運用設計がない——見た目の金額は安いが、後から全部追加になる。

2. 前提が楽観的すぎる

「要件は確定済み」「外部API連携は問題なし」「既存データはきれいに整っている」——現実とズレた前提で工数を削っている。

3. ジュニア単価で見積もっている

着手後にシニアが入り、工数が膨らむ。または品質問題で手戻りが発生する。単価表が「一律」だけの見積もりは、中身が見えない。

「高い」見積もりが妥当なケース

高い＝ぼったくり、とは限らない。

• 要件定義・設計に十分な工数を見ている
• テスト・品質保証が組み込まれている
• リスクバッファが明示されている
• 実際に参画するメンバーのスキルに見合った単価

同じスコープで2倍以上の差があるなら、安い方の「削られている項目」を特定する。差の説明が「弊社は効率が良い」だけでは不足で、どの工程を何人日削ったのかまで聞く。

具体例：800万と1,400万、どちらが妥当か

匿名化した一例だ。会員向けWebの改修で、A社800万・B社1,400万が並んだ。初見ではA社が優勢に見えた。

表にすると差はこうだった。

項目	A社	B社
要件定義・設計	ほぼなし（「確定済み前提」）	全体の約25%
テスト	単体のみ	結合・UAT支援込み
PM	月2回定例のみ	週次＋課題管理
除外	権限改修、バッチ、移行	移行のみ除外

発注側の実態は「要件は半分しか固まっていない」だった。A社の前提が崩れた時点で、追加見積もりが確実になる。結果としてB社の方が総コスト見通しは低く、採択後の炎上も少なかった。

金額の順位と、前提の一致度の順位は別物だ。

3社比較の実践テンプレ

1. 各社の見積書から「含む／含まない」を表に起こす
2. 前提条件の差分を洗い出す
3. 工数内訳の比率を比較する
4. 不明点は各社に同じ質問リストで確認する
5. 追加になりそうな項目の概算を足した「総コスト仮置き」を作る

金額の順位ではなく、スコープの一致度で比較する。

よくある誤解（赤旗）

• 「一式」が多い — 中身が検証できない
• 前提条件が「要相談」だけ — 安い数字の根拠がない
• テスト比率が5%未満 — 品質コストが後送り
• バッファがゼロで納期が短い — 遅延リスクを発注者負担にしている
• 「他社よりXX%安い」が主訴求 — 比較軸が金額に固定されている

判断軸：高い／安いをどう扱うか

状況	推奨
5欄が揃い、前提が自社実態と一致	金額比較してよい
最安だけ前提が楽観的	前提を揃える再提出を求める
高額だがバッファとテストが明示	「高い」ではなく妥当性を検証する
差が2倍以上で説明が抽象	採択しない。差分の工程表をもらう

次に確認すること

1. 前提・スコープ・除外を1枚の比較表にしたか
2. 工数比率（設計／開発／テスト／PM）は妥当か
3. 体制の実名と人日は出ているか
4. 安い見積もりの「削り」は特定できたか
5. 高い見積もりの「守り」は説明できるか
6. 総コスト仮置き（追加見込み込み）を見たか

まとめ

見積もりは「値段表」ではない。事業リスクに対する投資計画だ。

金額だけで選ぶと安く見える。中身で選ぶと、失敗コストごと計算できる。高い・安いは、揃えた表の上で初めて意味を持つ。

---

見積もりの妥当性レビュー・要件整理からの相談は、お問い合わせフォーム からどうぞ。