システム開発の見積もりが会社によって3倍違うのはなぜか

同じ要件定義書を3社に渡したのに、400万・900万・1,200万という数字が並ぶ。どこかが不当に高いのか、安いところが手を抜くつもりなのか、判断がつかない。発注前にこの状態で止まる会社は多い。

金額差そのものは異常ではない。見積もりは4つの数字を掛けて足したものなので、どれか一つが変われば全体が数倍になる。逆に言えば、4つに分解すれば差の正体は説明できる。

見積もりは4つの数字でできている

金額 ＝ 工数 × 単価 ＋ バッファ
        ↑ここに「どこまで含めるか」が効く

見積書に載るのは合計金額だけだが、内訳はこの形になっている。3倍の差が出るとき、4つのうち複数が同時にずれている。

工数 — 何を数えたかで変わる

「ログイン機能」を見積もるとき、実装だけを数えるか、設計・レビュー・テスト・バグ修正・仕様変更の反映まで数えるかで、同じ機能が3人日にも12人日にもなる。

経験のある会社ほど後者を数える。実装が終わってからテストとレビューで同じくらいの時間がかかることを知っているからだ。数えていない会社の見積書が薄く見えるのは、その分の作業が消えたからではなく、まだ数えていないだけである。

工数が小さいのに手抜きではないケースもある。認証・管理画面・権限まわりの社内テンプレートを持っている会社は、毎回ゼロから作らない。使い回せる部分が多いほど工数は正当に小さくなる。「なぜその工数で済むのか」を聞けば区別できる。

単価 — 誰が作業するのか

人月単価は会社の規模と体制で決まる。元請けが受けて下請けに流す構造なら、中間のマージンが単価に乗る。単価が高い会社が悪いのではなく、その金額を払って誰が手を動かすのかが見えているかどうかが問題になる。

聞くべきことは決まっている。設計する人と実装する人は同じか。プロジェクトに何人が何割の稼働で入るか。途中でメンバーが入れ替わる前提か。単価だけを比べても意味がない。

含まれる範囲 — ここで一番差が出る

金額が大きく開くのはここである。見積書に金額として書かれない項目がある。

項目	抜けているとどうなるか
要件定義への同席	決まっていない仕様を発注側が全部詰める必要が出る
テスト	動作確認が発注側の作業になる。不具合が出るのはリリース後
環境構築（本番・ステージング）	開発は終わったが動かす場所が無い
CI / デプロイの仕組み	毎回手作業でリリースすることになる
監視・バックアップ	障害に気づくのがユーザーからの連絡になる
ドキュメント	次の改修を別の会社に頼めない
データ移行	既存システムからの移行が別見積もりになる
リリース後の不具合対応	検収後の修正が追加費用になる

抜けていること自体は不誠実ではない。「その前提で出しています」という話であり、前提が書いてあれば正しい見積書である。問題は前提が書かれていない見積書のほうで、その場合は後から追加費用として戻ってくる。

バッファ — 不確実性への保険

要件が曖昧なほど、見積もる側は幅を取る。「詳細は開発中に決める」と書かれた要件に対して、最悪ケースを想定した数字を出すのは当然の判断になる。

ここは発注側が動かせる数少ない変数でもある。仕様を1段階詰めてから再見積もりを取ると、金額が下がることがある。高いと感じたときに値引きを交渉するより、要件を具体化するほうが効く。

安い見積もりから抜けているもの

安い見積書を見たときに確認する順番はだいたい決まっている。

テスト。 単体テストを書くか、結合テストを誰がやるか。テストを書かない前提の見積もりは初期費用が下がる代わりに、改修のたびに動作確認の工数が増える。半年運用すると逆転することがある。

環境構築。 本番環境だけでなく、検証用の環境を作るか。検証環境が無いプロジェクトは、本番で初めて確認することになる。

非機能要件。 同時に何人が使うか、どのくらいの速度で応答するか、データが消えたときにどこまで戻せるか。この3つが要件に書かれていないと、見積もりからも抜ける。あとで性能が出ないと分かってからの作り直しは高い。

リリース後の対応期間。 納品後どのくらいの期間、不具合を無償で直すか。1か月なのか3か月なのか、そもそも無いのか。

ドキュメント。 環境の構築手順とデータ構造の説明が無いと、次に別の会社へ引き継ぐときの費用が跳ね上がる。

比較するときに見る点

金額を並べる前に、見積書を同じ土俵に乗せる作業がいる。

1. 前提条件が書いてあるか。 「〜は含みません」が明記された見積書は信頼できる。何も書いていない見積書は、比較する材料が足りていない
2. 分解されているか。 一式いくら、ではなく機能ごとの工数が並んでいるか。分解されていれば、どの機能を削れば予算に収まるかを発注側が判断できる
3. 検収の定義。 何をもって完了とするか。この定義が曖昧なプロジェクトは、終盤で「これは追加です」「いや含まれるはずです」の押し合いになる
4. 変更したときどうなるか。 途中で仕様を変えた場合の扱い。都度見積もりなのか、一定の範囲までは含むのか
5. 保守と運用の扱い。 月額いくらで何をするか。障害時の連絡先と対応時間帯
6. 有効期限と再見積もりの条件。 要件が変わったらいつ出し直すか

この6点を揃えると、金額差の一部は前提の違いとして説明がつく。そこを消してから残った金額が、比較すべき本当の差になる。

差が正当な場合と、そうでない場合

正当な差は、説明できる差である。範囲が広い、テストを書く、経験のあるメンバーが入る、移行作業を含む。理由を聞けば数字が動いた場所を指し示せる。

そうでない差は、聞いても返ってこない。「だいたいこのくらいです」で終わる見積もりは、根拠が無いか、内訳を出したくないかのどちらかになる。どちらにしても、発注後に金額が動く可能性が高い。

金額の大小より、質問に対して数字で答えが返ってくるかを見たほうが外れにくい。

判断に迷ったら

見積書を並べても決められないとき、多くの場合は見積もりの問題ではなく、発注側に判断材料が足りていない。前提条件が書かれていない見積書は、書いた側に聞けば埋まる。聞き方が分からない段階で止まっていることが多い。

私たちは、他社の見積もりを見た上でのご相談も受けています。発注先を決める前の段階で、前提条件の揃え方や、要件をどこまで詰めれば金額が動くかについてお話しできます。相談だけで終わっても構いません。

→ 相談する