見積もりが安すぎる・高すぎるときは？一番安いでよいかの見分け
【結論】見積もりが安すぎる・高すぎるときは、合計金額の前に、作業の範囲と前提条件がそろっているかを確かめます。一番安い見積もりがよいとは限りません。
- 早い段階の見積もりは、最終的な規模に対して大きくぶれるという数値例があります。
- 安さの原因は、含まない作業が多いことや、前提が楽観的なことであることがあります。
- 高さの原因は、範囲が広いことや、性能・信頼性・スケジュール制約が高いことであることがあります。
この記事では、複数社の見積書を受け取った担当の方に向けて、安すぎ・高すぎの見分けと、一番安いでよいかの判断の進め方をまとめます。概算はミツモリーでも確認できます。
見積もりが安すぎる・高すぎるとは
見積もりが安すぎる・高すぎるとは、同じ依頼に対して出た金額が、他社や自分の想定から大きく外れて見える状態です。外れて見える原因は、単価だけの差とは限りません。作業に含める範囲や、前提条件の置き方が違うことが多いです。
株式会社三菱総合研究所（CoBRA研究会）がまとめ、IPA（情報処理推進機構）のサイトに掲載されている資料「ソフトウェア開発見積りの基本的な考え方」（2012年）は、見積もりの対象を規模・工数・工期・コストに分けています。コストだけを比べると、規模や工数の前提が違う見積もりを、同じ土俵で見ていることになります。
一番安い見積もりでよいか
一番安い見積もりでよいかは、範囲をそろえたあとに判断します。安い側にだけサーバー構築やデータ移行が入っていないと、発注後に追加費用が出ることがあります。高い側にだけ保守や教育が入っていると、合計は上がりますが、別途契約が減ることもあります。
| 確かめ方 | 内容 |
|---|---|
| 明細の行を突き合わせる | 同じ機能・同じ付帯作業が入っているか |
| 「含まないもの」を読む | 書いていない費用が後から増えないか |
| 前提条件を読む | 画面数、データ件数、利用者数が同じか |
| 税込・税抜をそろえる | 表記の違いで安く見えていないか |
| 概算か正式かを見る | 概算はあとで金額が変わる前提 |
補助金・助成金では、同一条件の相見積もりを求め、最低価格を提示した者を選定する制度があります。その場合も、条件が同一であることが前提です。条件のそろえ方は「相見積もりの取り方とは？」「補助金の見積もりとは？」を参照してください。
安すぎるときに疑う点
| 疑う点 | なぜ金額が下がるか |
|---|---|
| 作業範囲が狭い | 移行・インフラ・テスト・教育が別見積もりになっている |
| 前提が楽観的 | データ件数や例外処理を小さく見ている |
| 品質・性能の要求が低い | 試験や冗長化の工数が少ない |
| 役割の単価が違う | 担当する技術者の役割が他社と違う |
| 概算の幅の下限だけ見ている | 上限を見ないと実態とずれる |
同資料は、システム化の方向性を決める段階では、最終的な規模に対して4倍〜1/4倍のぶれ幅があり得るという数値例（B. Boehmの文献とIPA/SEC編ガイドブックをもとにした整理）を示しています。早い段階で極端に安い金額だけを採用すると、あとから規模が伸びたときに不足が出やすくなります。
高すぎるときに疑う点
| 疑う点 | なぜ金額が上がるか |
|---|---|
| 作業範囲が広い | 他社が見ていない付帯作業や機器まで含めている |
| 性能・信頼性の要求が高い | 試験・監視・冗長化の工数が増える |
| 関わる部署が多い | 打ち合わせと確認の時間が増える |
| スケジュールが短い | 並行作業や要員増で工数が増える |
| 含まないものが少ない | 保守や教育まで一式に入っている |
同資料は、工数が規模だけでなく、性能への要求、信頼性への要求、要求の安定性、スケジュール制約などでも変わると示しています。高い見積もりは、要求の置き方が厳しいことの表れである場合もあります。
判断の進め方
- 見積依頼の条件（含むもの・含まないもの・前提）を文書でそろえる
- 各社の明細を、行ごとに同じ表に並べる
- 範囲が違う行は、金額比較の対象から外すか、追加見積もりを取る
- 残った同一範囲だけで金額を比べる
- 補助金を使う場合は、公募要領の社数・選定ルールも確かめる
内訳の読み方は「システム開発の見積もりとは？」、ベンダー全体の比べ方は「システム開発の比較とは？」もあわせてご覧ください。
ミツモリーでの進め方
ミツモリー（mitsumo.li）は、株式会社ワンオブゼムが運営する、AIでシステム開発の概算見積もりを出すサービスです。見積もりは無料で、会員登録はいりません。
- ミツモリーのトップで、作りたいものを一言で書く
- 概算の内訳と、含まないものの目安を確認する
- 見積書を依頼する
- 相見積もりが必要なら、同じ条件の見積依頼書（金額なし）を作る
- 他社の見積書と、範囲をそろえて比べる
概算見積書はAIによる概算で拘束力はありません。正式見積書の受付は平日10:00〜18:00（締切17:30）です。先に水準を見たい方は、ミツモリーで見積もるから進められます。
よくある質問
見積もりが安すぎるときはどうすればよいですか？
合計の前に、明細と「含まないもの」を他社と突き合わせます。範囲が狭い、前提が楽観的、概算の下限だけ見ている、のどれかが多いです。不足している作業を同じ条件で聞き直してから判断します。
見積もりが高すぎるときはどうすればよいですか？
他社より広い範囲や、高い性能・信頼性・短い納期が入っていないかを見ます。不要な範囲があれば外す見積もりを取り直し、必要な要求なら工数増の説明として受け止めます。
一番安い見積もりを選べばよいですか？
範囲と前提が同一なら、価格は有力な判断材料です。範囲が違うまま一番安さを選ぶと、あとから追加費用が出ることがあります。補助金でも、同一条件であることが前提です。
早い段階の見積もりはどれくらいぶれますか？
IPA掲載の資料は、システム化の方向性を決める段階で、最終規模に対し4倍〜1/4倍のぶれ幅があり得るという数値例を示しています。幅のある金額として受け取るのが実態に合います。
単価が安い会社は得ですか？
単価だけを比べても、工数の置き方や役割が違うと比較になりません。工数×単価の積み上げと、含む作業をセットで見ます。単価の読み方は「システム開発の単価・人月単価とは？」も参照してください。
相見積もりで安すぎる1社だけ外してよいですか？
制度や社内ルールによります。まずは条件が同一かを確認し、同一なのに極端に安い場合は根拠を確認します。補助金では、見積依頼書と見積書の対が必要な制度があります。
概算と正式のどちらで安さを判断しますか？
候補絞り込みは概算、発注判断は正式が向きます。概算の下限だけを正式と比べないでください。同じ段階の見積もり同士で比べます。
ミツモリーで安すぎ・高すぎの判断材料は取れますか？
取れます。ミツモリーの概算で内訳と含まないものの目安を確認し、同じ条件の見積依頼書で他社と揃えて比べられます。採択や最終金額の保証はありません。
参考にした資料
- 株式会社三菱総合研究所（CoBRA研究会）／IPAサイト掲載「ソフトウェア開発見積りの基本的な考え方」（2012年）
- 関連記事: システム開発の見積もりとは？、相見積もりの取り方とは？、システム開発の比較とは？、補助金の見積もりとは？
- 概算見積もり: ミツモリー