システム開発の見積もりが3倍違うのはなぜ？相見積もりの正しい比べ方と判断ポイント

システム開発を複数の会社に相見積もりしたら、金額が2倍、3倍と大きく違っていた。どれが妥当なのか分からず、社内にも説明できない。システム開発の見積もりで、発注者の方が最もよく戸惑う場面の一つです。

先に結論をお伝えします。見積もりの金額差の多くは、各社が想定している「前提条件」の違いから生まれます。どこまでを作業範囲に含めているか、どんな作り方を想定しているか、どこまでの品質や安全性を見込んでいるかが違えば、金額が数倍違うことも珍しくありません。

つまり、見るべきなのは総額ではなく「何に対していくらなのか」です。この記事では、見積もりが会社ごとに大きく違う理由と、相見積もりを正しく比べるための手順を、チェックリスト・開発会社への質問例とあわせて解説します。

システム開発の見積もりが会社ごとに大きく違う5つの理由

まずは「なぜ差が出るのか」を押さえましょう。差が出る理由はほぼ決まっていて、多くは次の5つのどれかに当てはまります。

理由1：見積もりに含まれている作業範囲が違う

システム開発には、プログラムを作る以外にもさまざまな作業があります。

• 要件定義（＝何を作るかを文章で決める工程）
• 画面のデザイン
• テスト（動作確認）
• 今のExcelや旧システムからのデータ移行
• 操作マニュアルの作成や社内説明会
• 公開後の保守（不具合対応・問い合わせ対応）
• サーバーなどの利用料

A社はこれらをすべて含めて見積もり、B社はプログラム作成だけを見積もっている、ということはよくあります。この場合、B社の金額が安く見えても、あとから別料金になる可能性があります。

理由2：「作り方」の想定が違う

同じ要望でも、実現の仕方は一つではありません。既存のクラウドサービスやパッケージ（＝あらかじめ用意された既製のソフトウェア）を組み合わせる会社もあれば、ゼロから作る（スクラッチ開発）前提の会社もあります。

既製品を使えば費用は抑えやすい一方、自社の業務に合わせた細かな調整はしにくくなります。どちらが正解というより、各社が「あなたの会社にはこの作り方が合う」と考えた結果の違いです。

理由3：速さ・止まりにくさ・安全性の想定が違う

「どんな機能があるか」とは別に、「どのくらい速く動くか」「どのくらい止まらないか」「どこまでセキュリティ対策をするか」といった品質面の要求があります。これを非機能要件（＝機能以外にシステムに求める性能や信頼性）と呼びます。

📰 出典：IPA（情報処理推進機構）「非機能要求グレード」紹介ページ

IPAは、非機能要求についてユーザ（発注者）と開発者の認識の行き違いを防ぐことを目的に「非機能要求グレード」というツール群を公開しています。発注者が明確に伝えていない部分ほど、各社は自社の経験で想定を置くため、ここが見積もりの差につながりやすいのです。

たとえば「24時間止まらないように二重化する」前提と「業務時間内に使えればよい」前提では、費用はまったく変わります。

理由4：まだ決まっていない部分への「備え」の見込み方が違う

相見積もりの段階では、細かな仕様はまだ決まっていないことがほとんどです。決まっていない部分をどう見込むかは、会社によって異なります。

• 不確定な部分を多めに見込み、あとで追加費用が出にくいようにする会社
• 分かっている範囲だけで見積もり、決まったら追加で見積もる会社

前者は高く、後者は安く見えます。しかし、最終的に支払う総額が逆転することもあり得ます。

理由5：体制・進め方・単価が違う

システム開発の見積もりは、「人月（＝1人が1か月働いた作業量）」×「単価」で計算されることが一般的です。経験豊富な技術者を多く配置する会社、プロジェクト管理の手厚い会社は、その分金額が上がります。逆に、少人数で効率的に進める体制を得意とする会社もあります。

「見積もりには精度の段階がある」と知っておく

もう一つ知っておきたいのが、見積もりは、要件が決まるにつれて精度が上がっていくものだということです。

📰 出典：IPA「情報システム・モデル取引・契約書（第二版）」

IPAと経済産業省が公開している「情報システム・モデル取引・契約書」の解説では、見積もりの時期とリスクの関係を踏まえ、工程ごとに個別に契約を結ぶ「多段階契約」と、曖昧さがある段階の見積もりを要件が明確になった段階で見積もりなおす「再見積り」の考え方を採用しています。また、構想・計画・要件定義の段階の見積もりは「確定見積」ではないこと、画面や帳票を決める外部設計（＝画面や操作の仕様を決める工程）の段階で確定見積が可能と考えられることも示されています。

同じ解説では、発注者にはできるだけ早く要件を固めることが正確な見積もりに必要だと認識すること、開発会社には見積もりの精度を高める取り組みと十分な説明責任が求められることにも触れています。見積もりの精度は、発注者と開発会社の両方で高めていくものなのです。

見積もりの段階をかんたんに整理すると、次のようになります。

段階	主なタイミング	金額の扱い
試算（ざっくり）	構想・計画の段階	予算を立てるための参考値
概算	要件定義の後	目的と範囲は決まったが、細部は未確定
確定	画面や操作の仕様が決まった後	契約金額として固めやすい

初期の相見積もりは、多くの場合「試算」か「概算」の段階です。この段階の金額を、確定した値段のように比べてしまうと判断を誤りやすくなります。なお、モデル契約書は、対等な交渉力を持つ民間大手企業と開発会社の取引などを想定したひな型なので、中小企業の案件にそのまま当てはめるものではありません。考え方の参考にしてください。

相見積もりを正しく比べる5つのステップ

ここからは、実際に見積もりを比べる手順です。

ステップ1：全社に同じ資料・同じ条件で依頼する

比較の前提として、各社に渡す情報をそろえることが大切です。口頭の説明だけだと、会社ごとに伝わり方が変わってしまいます。目的・使う人・必須の機能・予算の目安・希望時期などをまとめた同じ資料を、全社に渡しましょう。

すでに見積もりを受け取っていて条件がバラバラだった場合も、あきらめる必要はありません。ステップ2以降で前提をそろえ、必要に応じて再見積もりを依頼できます。

ステップ2：見積書を「項目ごとの比較表」に並べ直す

各社の見積書は書式がばらばらなので、そのままでは比べられません。次のような表に書き写してみましょう。

項目	A社	B社	C社
要件定義	含む	含む	別途
デザイン	含む	簡易	含む
開発（プログラム作成）	◯円	◯円	◯円
テスト	含む	含む	記載なし
データ移行	含む	別途	記載なし
マニュアル・操作説明	含む	なし	記載なし
保守（月額）	◯円	◯円	別途見積
サーバー等の利用料	発注者負担	含む	記載なし
作り方	ゼロから開発	既存サービス活用	ゼロから開発

表にすると「安い会社は、実はデータ移行やテストが入っていなかった」「高い会社は、公開後の保守まで含んでいた」といった違いが見えてきます。「記載なし」の欄こそ、確認が必要な場所です。

ステップ3：「前提条件」と「含まれないもの」を読む

見積書には、金額の根拠となる前提条件や、対象外の作業が書かれていることが多くあります。

📰 出典：IPA「情報システム・モデル取引・契約書（第二版）」

モデル契約書の資料では、開発会社が提案書に記載すべき項目の一つとして「見積条件（見積の前提となった条件や、発注者側・開発会社側の役割）」が挙げられています。たとえば、使う開発手法やツール、開発規模、稼働環境、契約条件、実装するセキュリティ対策などです。

特に確認したいのは、次のような点です。

• 発注者側がやる前提の作業（データの準備、テスト、社内調整など）
• 仕様変更や追加が出たときの扱い
• 何回まで修正に対応してくれるか
• 見積もりの有効期限

ステップ4：差が大きい項目は、各社に理由を聞く

比較表で金額差が大きい項目が見つかったら、遠慮せずに理由を聞きましょう。「なぜ高いのか」ではなく、「この金額にはどんな作業や想定が含まれていますか」と聞くと、相手も答えやすくなります。

「前提を聞いてもらえると助かります。こちらも『ここは念のため厚めに見ています』と説明できるので、不要なら外して金額を下げる相談ができるんです」

説明が具体的で分かりやすいかどうかは、その会社と一緒に仕事を進めやすいかを判断する材料にもなります。

ステップ5：条件をそろえて再見積もりを依頼する／段階的に発注する

ステップ2〜4で分かった違いをもとに、「データ移行は含める」「保守は別見積もりで」など条件をそろえて、再見積もりを依頼します。前提がそろえば、金額差はかなり縮まることが多いものです。

それでも不確定な部分が大きい場合は、まず要件定義だけを依頼し、その成果をもとに開発の見積もりを取り直す進め方もあります。これが先ほど紹介した「多段階契約」の考え方です。どの契約形態が適しているか、契約書の条文をどうするかといった個別の判断は、弁護士などの専門家に確認することをおすすめします。

相見積もりでやりがちな失敗

• 総額だけを見て一番安い会社に決める：必要な作業が含まれておらず、あとから追加費用が重なって、結果的に高くつくことがあります
• 「真ん中の金額なら安心」と考える：3社の前提がそろっていなければ、真ん中にも根拠はありません
• 高い見積もりを「割高」と決めつける：不確定な部分への備えや、公開後の保守まで含めた誠実な見積もりである場合もあります
• 他社の金額を伝えて値下げだけを求める：前提が違うまま金額だけを合わせると、作業範囲や品質が削られることがあります。値下げを相談するなら「どの範囲を減らせば、いくらになるか」を聞きましょう
• 公開後の費用を見ていない：保守費用やサーバー代など、毎月かかる費用も含めて比べないと、数年単位の総額で逆転することがあります

発注者がやることチェックリスト

• ☐ 全社に同じ資料（目的・使う人・必須機能・予算の目安・時期）を渡した
• ☐ 各社の見積書を、項目ごとの比較表に書き写した
• ☐ 「含まれていない作業」「記載がない作業」に印をつけた
• ☐ 見積もりの前提条件（作り方・品質の想定・発注者側の作業）を確認した
• ☐ その見積もりが「試算・概算・確定」のどの段階かを確認した
• ☐ 公開後の保守費用・サーバー代など、毎月かかる費用も比べた
• ☐ 金額差の大きい項目について、各社に理由を質問した
• ☐ 条件をそろえた再見積もり、または段階的な発注を検討した

開発会社への質問例

見積もりの説明を受けるときに、そのまま使える質問です。

• 「この見積もりに含まれている作業と、含まれていない作業を一覧で教えていただけますか？」
• 「この金額は、どのような前提条件（作り方・利用人数・止まらなさの想定など）で計算していますか？」
• 「この見積もりは概算ですか、確定ですか？金額が変わる可能性があるのはどんな場合ですか？」
• 「この部分を減らしたり、既存のサービスで代用したりした場合、金額はどのくらい変わりますか？」
• 「公開後に毎月・毎年かかる費用は、どのくらいを見込んでおけばよいですか？」

こうした質問に対して、根拠を示しながら丁寧に答えてくれるかどうかも、開発会社を選ぶ大切なポイントになります。

まとめ：見積もりは「総額」ではなく「前提」で比べる

システム開発の見積もりが会社によって3倍違うのは、どこかの会社が不当な金額を出しているからとは限りません。多くの場合、作業範囲・作り方・品質の想定・不確定部分への備えといった前提条件が違うことが原因です。

• 全社に同じ条件で依頼する
• 見積書を項目ごとの比較表に並べ直す
• 前提条件と「含まれないもの」を確認する
• 差の大きい項目は理由を聞く
• 条件をそろえて再見積もり、または段階的に発注する

この手順を踏めば、「どれが妥当か分からない」状態から、「この条件ならこの金額が妥当」と社内にも説明できる状態に近づけます。まずは手元の見積書を、比較表に書き写すところから始めてみてください。

あわせて読みたい関連記事