同じ要件を配ったのに、見積が数倍開くのは珍しくない
「同じ要件で相見積を取ったのに、A 社は 300 万円、B 社は 900 万円、C 社は 1,500 万円だった」——システム開発の発注担当者からよく聞くお話です。3 倍以上の差を前にすると、「どこかが吹っかけているのでは」「一番安いところで良いのでは」と考えたくなります。しかし実際には、A 社も B 社も C 社も、自社の前提の中では正当に見積もっていることがほとんどです。
差の原因は「単価」だけではありません。工数の積み方、想定するスコープ、リスクの見方、得意領域との相性——複数の要因が積み重なって、最終的に見えている「総額の差」を作っています。この記事では、なぜ開発会社ごとに見積が数倍変わるのかを構造から解きほぐし、発注側が 3 社比較で見るべきポイントを整理します。
1. 見積差が発生する 4 つの構造要因
同じ RFP を複数社に配っても、返ってくる金額は驚くほど揃いません。その裏側には、大きく分けて 4 つの構造的な要因があります。
(1) 人月単価の差
エンジニア 1 人月あたりの費用は、会社の体制・所在地・保有スキルによって大きく変わります。都心の開発会社と地方拠点のみで運営する会社では、同じ役割でも数十万円の差が生じます。
(2) 工数積算方針の差
同じ機能を作るのに何人月見込むかは、会社の見積カルチャーに依存します。「経験ベースでざっくり」の会社と「WBS に落として一項目ずつ積む」会社では、同じ機能でも 1.3〜1.8 倍の差が出ることがあります。
(3) リスク許容量の差
「不確実な要件にどれだけバッファを積むか」も会社ごとに違います。要件が曖昧な部分に厚めのバッファを積む会社は総額が上がり、「走りながら詰める」を許容する会社は総額が下がります。
(4) 得意領域と適合度の差
会社にはそれぞれ得意領域があります。得意な領域なら過去の資産を流用でき、工数が下がります。逆に不慣れな領域は、学習コスト・調査工数がそのまま見積に乗ります。
要因の分解の詳細は 開発見積が高くなる／安くなる要因 でも扱っています。
2. 単価差の内訳｜社員・BP・オフショアの構成比
「単価が高い／安い」の裏側には、会社の人員構成があります。
社員比率が高い会社
自社の正社員エンジニアが中心の会社は、教育コスト・福利厚生・オフィス維持費などの間接費を単価に乗せています。そのぶん、コミュニケーションのブレは少なく、長期の品質・引き継ぎに強くなる傾向があります。
BP (ビジネスパートナー) 活用型
自社社員に加えて、協力会社のエンジニア (BP) をアサインする体制です。案件ごとにスキルを持つ人を集めやすく、繁閑にも対応しやすいため、単価は中間帯に落ち着きます。ただしプロジェクトごとにチームメンバーが入れ替わるため、社内ナレッジは蓄積しにくくなります。
オフショア／ニアショア中心
海外拠点や地方拠点の開発者を主戦力にする形態です。単価は国内正社員の半分以下になることもあり、大規模開発ではコストメリットが出ます。一方で、要件伝達・ブリッジ SE の品質・時差の運用がプロジェクトの成否を左右します。
間接費と利益率
同じ人月単価でも、内訳は会社ごとに違います。営業・広報・オフィス・PMO などの「案件外の人件費」が単価にどれだけ乗っているかは各社で異なり、これが最終的な見積差の一部となります。「利益率が高い＝ぼったくり」ではなく、品質保証やアフターフォローの余力に転化されているケースも多く見られます。会社類型ごとのコスト構造の違いは SIer・受託・Web 系の違い で詳しく整理しています。
3. 「同じ要件」でも各社の想定スコープはそろわない
発注側から見ると「同じ要件書を渡した」のに、各社の見積が揃わない最大の理由は、実はスコープ解釈の違いです。
テスト範囲の想定差
「テストを行います」の一言でも、単体テストのみか、結合テスト・受け入れテスト・負荷テストまで含むかで工数は数倍変わります。自動テストのカバレッジ目標を 80% に置く会社と、手動テストで最低限確認する会社では、テスト工数が 2〜3 倍違うこともあります。
非機能要件の解釈差
同時アクセス数・応答時間・可用性・セキュリティ水準など、機能一覧に載らない要件をどこまで作り込むかは、会社の標準が違います。「金融水準のセキュリティ」を暗黙に想定する会社と、「一般的な Web サービス水準」を想定する会社では、同じ機能でも見積が変わります。
成果物の粒度差
要件定義書・設計書・運用手順書・引き継ぎ資料——ドキュメントをどこまで残すかも会社ごとに違います。ドキュメント一式を納品する会社は、そのぶんの工数が見積に反映されています。
保守・引き継ぎの前提差
「納品後の初期不具合対応は無償」「1 か月間の瑕疵対応込み」「保守契約前提で低めに提示」——初期見積にどこまで含めるかは、会社ごとに慣行が違います。「安い見積」の裏には、保守契約でリカバリする前提が置かれていることもあります。
同じ RFP でも、これら 4 つの想定差だけで見積は倍近く動くことがあります。
FIXIT同じ要件書を渡したのに、なんで見積がこんなに揃わないの？
Shiori大きな理由は、要件書に載らない前提を、各社が違うふうに想定するからです。
FIXITShioriテスト範囲、非機能要件、成果物のドキュメント、瑕疵担保の期間などです。
FIXITShioriはい。「あなたが想定している前提を教えてください」と聞くのが一番早いです。
4. 得意領域と適合度がもたらす見積差
もう 1 つ見落とされがちな要因が、会社の得意領域と案件のマッチ度です。
得意領域を発注すると見積が下がる
過去に似た案件を多数手掛けている会社は、テンプレート・共通コンポーネント・運用ノウハウを持っています。ゼロから作らずに済むため、工数が下がり、見積も下がります。品質面でも安定します。
不慣れな領域は「学習コスト」が乗る
たとえば EC サイト構築を得意とする会社に、複雑な業務システムを発注すると、業務理解・要件整理・アーキテクチャ選定のすべてに調査工数が乗ります。同じ機能でも、得意な会社より 2 倍近い工数を積む場合があります。
「安い＝得意」「高い＝不得意」ではない
得意領域だからこそ、品質保証水準を高く保ちたくて価格が上がる会社もあります。単純な高低ではなく、「その会社にとって、この案件がどの位置づけか」を確認するのが実務的です。ヒアリング時に「過去の類似案件」を尋ねると、適合度が見えてきます。
5. 「安い会社が悪い」「高い会社が良い」ではない
見積差を理解したうえで、発注側が持つべき視点は「どの会社が自社の案件に適合するか」です。金額の絶対値で判断するのは、多くの場合ミスリードにつながります。
安さの背景を確認する
安い見積を受け取ったときは、その安さの背景を確認します。次の 4 つのいずれかが背景にあることが多く見られます。
- 機能を絞った MVP 前提で見積もっている
- テンプレート流用でオリジナル要素を減らしている
- 保守フェーズでリカバリする前提を置いている
- 若手中心のチームで学習しながら進める前提を置いている
いずれかであれば、その前提を発注側が受け入れられるかを検討します。前提が曖昧なままの「とにかく安い見積」は、要件が固まった段階で追加費用が積み上がる典型パターンなので注意が必要です。詳しくは 安すぎる開発見積の危険 を参照してください。
高さの背景を確認する
高い見積を受け取ったときも、同様に背景を見ます。次の 4 つのいずれかが多く見られます。
- ドキュメント・テスト・非機能要件を厚く積んでいる
- シニア中心のチーム編成で構成している
- 保守・引き継ぎまで含んだ長期前提で見ている
- 得意領域で品質を担保するプレミアムが乗っている
「高い」には「品質保証の厚み」「長期運用への備え」といった価値が含まれていることが多く、案件の重要度によっては妥当な選択になります。
適正判断の軸
最終的に「適正か」を判断するのは、金額そのものではなく次の問いです。
- 自社の案件のリスクレベル (止まったら困る度合い) に見合った品質水準か
- 見積の前提が自社の運用体制と合致しているか
- 発注後のコミュニケーションが継続可能な体制か
コツ
3 社の中央値を選ぶ判断は、実は根拠が薄い方法です。前提が違う 3 社の中央値には意味がなく、なぜその金額なのかの理由が明確で、自社の案件条件と合っている会社を選ぶのが実務上の正解です。
6. 3 社比較で発注側が見るべき 5 項目
見積を並べて比較する際、金額欄だけを見比べても本質的な差は分かりません。次の 5 項目をそろえて確認すると、比較の解像度が上がります。
(1) 体制
PM・エンジニア・デザイナー・QA の構成、社員／BP／オフショアの比率、各メンバーの経験年数を確認します。同じ「10 人月」でも、シニア中心のチームとジュニア中心のチームでは意味が変わります。
(2) 見積前提
想定しているテスト範囲、非機能要件のレベル、ドキュメント粒度、瑕疵担保期間を確認します。ここが揃っていないと、金額比較は成立しません。
(3) 成果物
納品されるコード・ドキュメント・環境構築物の一覧を確認します。ソースコードの権利関係 (買取／使用許諾) も含めて確認してください。
(4) 保守・運用
リリース後の保守契約の前提、月額費用の想定、対応時間帯、SLA を確認します。初期見積が安くても、保守費用が高ければ総保有コストは変わりません。詳細は 開発後の保守・運用の見積 で扱っています。
(5) 実績
自社案件と類似領域での過去実績、規模感、体制継続性を確認します。得意領域とのマッチを見極める重要な材料です。
この 5 項目を並べた比較表を作ると、金額の差が「単価差」「スコープ差」「品質差」「適合度差」のどれに由来するかが見えてきます。相見積の実務手順は 相見積の取り方 にまとめています。
まとめ
開発会社ごとの見積差は、単価差・工数積算方針・リスク許容量・得意領域適合度が積み重なった結果です。「同じ要件」でも各社の想定スコープ (テスト範囲・非機能・成果物・保守) は揃わず、そのぶんの差が総額に反映されます。安い・高いの善悪判断ではなく自社案件との適合度で選ぶこと、そして 3 社比較では体制・見積前提・成果物・保守・実績の 5 項目をそろえて確認すること——この 2 点を押さえるだけで、比較の解像度は大きく変わります。
AI 駆動開発のクリエイティブスタジオである FIXIT では、発注担当者と一緒に要件と前提を整理し、「なぜこの金額になるのか」の内訳を開示する見積方針で相談を受けています。相見積の比較に迷ったときや、各社の見積差の読み解きにお困りの方は 無料相談 からお気軽にご連絡ください。進め方の全体像は AI 駆動開発サービス もあわせてご覧ください。