システム開発の相見積もりのコツ｜社数・条件のそろえ方と比較の観点

システム開発を発注するとき、「複数の会社から見積もりを取って比べたいが、どう比較すればいいか分からない」という方は多いはずです。相見積もりは有効ですが、やり方を間違えると金額だけを見て安い会社に飛びつき、あとで追加費用や品質差に泣くことになります。この記事では、相見積もりの目的と適正な社数、条件のそろえ方、金額以外に見るべき観点、金額がバラつく理由、安すぎ・高すぎの見分け方、そしてやってはいけないNG行為とマナーまで具体的に解説します。

相見積もりの目的と、適正な社数は2〜3社

相見積もりの目的は「一番安い会社を探すこと」ではありません。本当の目的は次の3つです。

• 相場観を持つ：1社だけだと、その金額が高いのか安いのか判断できない。複数見ることで妥当な水準が見えてくる。
• 提案の質を比べる：同じ依頼に対して、各社がどう考え、何を提案してくるか。ここに実力差が出る。
• 会社の姿勢を見極める：質問への答え方、見積書の丁寧さ、レスポンスの速さ。付き合う相手として信頼できるかを判断する。

社数は2〜3社が目安です。1社だけでは比較にならず、4社以上になると各社への説明・打ち合わせ・比較検討だけで発注側が疲弊し、かえって判断が雑になります。

社数	メリット	デメリット
1社のみ	手間が少ない	相場が分からず、妥当性を判断できない
2〜3社	相場が見え、提案も比べられる	説明の手間は増えるが許容範囲
4社以上	選択肢は多い	説明・比較の負担が大きく、判断が浅くなる

多く集めれば良い決断ができるわけではありません。同じ条件を丁寧に渡せる社数の上限が2〜3社だと考えると分かりやすいでしょう。

同じ条件でそろえないと、そもそも比較できない

相見積もりで最もよくある失敗が、各社にバラバラの説明をしてしまうことです。A社には「予約システムを作りたい」とだけ伝え、B社には機能を細かく話す。これでは前提が違うので、返ってきた金額を並べても比較になりません。

比較を成立させる鍵は、全社に同じ依頼書（RFP）を渡すことです。RFPと言っても大層な文書は要りません。次の項目を1枚にまとめて、同じものを各社に渡すだけで精度が段違いになります。

• 目的・背景：何に困っていて、何が解決すれば成功か
• ほしい機能の一覧：分かる範囲でよいので箇条書きに
• 使う人と規模：想定ユーザー数、社内利用か一般公開か
• 含めてほしい範囲：要件定義・テスト・保守を含むか
• 予算感と希望納期：上限を隠すより、レンジで伝える方が現実的な提案になる
• 優先順位：全部同じではなく「絶対に要る／あれば嬉しい」を分ける

依頼内容を文書でそろえる方法は提案依頼書（RFP）の書き方で詳しく解説しています。RFPを渡すと、各社が「同じ土俵」で金額と提案を出してくるため、差がどこから来るのかが読み取れるようになります。

逆に、口頭やチャットで各社に少しずつ違う説明をすると、金額差が「会社の実力差」なのか「渡した情報の差」なのか区別できません。比較の前提は、条件をそろえることです。ここを省くと、以降の比較作業がすべて意味を失います。

金額だけ見ない — 比較すべき7つの観点

見積書が届いたら、総額の1行だけを見て選ぶのは危険です。同じ「300万円」でも、含まれる範囲がまるで違うことがあるからです。次の7つの観点で並べて比べます。

観点	見るポイント	抜けていると起きること
内訳	工程ごと（要件定義・設計・開発・テスト・管理）に分かれているか	「一式」だと何が含まれるか分からない
作業範囲	どこからどこまでやるか。運用・保守は別か	想定していた作業が範囲外だった
前提条件	どんな前提で金額を出しているか	前提が崩れると金額が跳ね上がる
追加費用の条件	どうなったら追加になるか	当初金額が安くても総額が膨らむ
体制	誰が何人、どんな経験で担当するか	経験の浅い人ばかりで品質が出ない
納期・支払	納期と支払いのタイミング	資金繰りや進行が想定と合わない
権利	完成したソースコードの権利は渡るか	他社に引き継げず、囲い込まれる

このうち特に見落とされがちなのが前提条件と権利です。前提条件とは「既存データはこちらで用意する」「対応ブラウザは最新版のみ」といった、金額の土台になる約束事のこと。ここが崩れると金額は簡単に変わります。権利については、ソースコードを渡さない会社だと、あとで別の会社に乗り換えられずベンダーロックインに陥ります。

比較の実際は、次のように範囲まで並べて初めて本当の高い安いが見えます。

比較項目	A社	B社
提示総額	280万円	350万円
要件定義	含まない	含む
テスト	簡易のみ	一通り実施
保守（月額）	別途5万円	3万円込み（3ヶ月）
ソースコード	原則渡さない	納品

一見A社が70万円安く見えますが、要件定義とテストが薄く、保守も割高で、コードも渡りません。抜けを埋めていくと実質はほぼ並ぶか逆転します。安いだけで選ぶと、抜けていた工程が後から追加費用として戻ってくるのです。

なぜ会社によって金額がこんなにバラつくのか

同じ依頼なのに、A社100万円、B社300万円ということが実際に起こります。「どちらかがぼったくり」と考える前に、バラつきの理由を理解しておきましょう。主な要因は次の通りです。

• 作業範囲の解釈が違う：要件定義・テスト・保守を含むか含まないかで、総額は大きく変わる。
• 体制・人員の質が違う：経験豊富な人を充てれば単価は上がるが、手戻りは減る。安い体制は単価が低い代わりに品質リスクがある。
• 作り方が違う：既製のパッケージやクラウドサービスを流用するか、一から個別開発するかで工数が数倍変わる。
• 前提の置き方が違う：情報が少ないと、会社は「たぶんこのくらい」と余裕を大きく取る。渡す材料が薄いほど金額は高く、幅も広くなる。
• リスクの見込み方が違う：不確実性が高い案件ほど、会社はバッファを積む。

つまり金額差は、多くの場合「どちらが得か」ではなく「何が含まれ、何が省かれているか」の差です。安い見積もりは範囲を削って安く見せているだけかもしれず、高い見積もりは丁寧な工程や手厚い体制を積んでいるのかもしれません。だからこそ、金額を並べる前に前提と内訳をそろえる必要があります。費用そのものの相場観はシステム開発の費用相場も参考にしてください。

安すぎ・高すぎの見分け方（人月で検算する）

金額の妥当性は、人月単価を使ってざっくり逆算できます。

• 人月単価の目安：初級40〜60万円／中堅60〜100万円／上級100〜160万円（1人が1ヶ月働く作業量＝1人月）
• 総額 ÷ 人月単価 ≒ 想定されている人月

例えば「400万円」の見積もりなら、単価80万円として約5人月（1人で5ヶ月ぶんの作業量）。その規模の機能を作るのに5人月が妥当か——と考えると、極端に高い・安いの当たりが付きます。人月の意味は人月・人月単価とはで解説しています。

• 安すぎるケース：総額を人月で割ると工数が明らかに少なすぎる。テストや要件定義が抜けている、経験の浅い人だけで進める、といった裏がある可能性。
• 高すぎるケース：工数が規模に対して多すぎる。不要な機能や過剰な体制、大きすぎるバッファが乗っている可能性。

**例：予約システムで3社から見積もりを取り、150万円・280万円・550万円が出たケース。**単価80万円で割ると、それぞれ約1.9人月・3.5人月・6.9人月です。ログイン・予約カレンダー・管理画面・決済連携まで含むなら、1.9人月は明らかに少なすぎて、テストや要件定義が抜けている疑いが濃厚。逆に6.9人月はやや過剰で、何にそれだけ掛かるのかを質問すべきです。真ん中の3.5人月あたりが妥当線と当たりが付きます。検算は金額を疑うためではなく、どこを質問すべきかを見つけるために使います。安さの裏のリスクは安いシステム開発は危険？でも解説しています。

やってはいけないこと と 相見積もりのマナー

相見積もりは発注側の当然の権利ですが、やり方を誤ると信頼を失い、良い会社ほど手を引いてしまいます。次のNGは避けましょう。

やってはいけないこと	なぜダメか
詳細要件・設計をタダで各社に作らせる	本来は有償の作業。無償で引き出して他社に流用するのは信頼を損なう
値切り一辺倒で交渉する	単価を無理に下げると、会社はテスト・品質を削って帳尻を合わせる
あいまいな依頼のまま金額だけ比べる	前提がバラバラで比較にならず、安い会社に誤って飛びつく
「一式見積もり」を鵜呑みにする	内訳が見えず、何が追加になるか判断できない
最初から1社に決めているのに形だけ相見積もり	各社の工数を無駄にし、業界内で評判を落とす

特に危険なのが詳細設計や要件定義を無償で各社にやらせることです。これは本来お金を払って依頼する工程で、タダで引き出そうとすると、誠実な会社ほど「この客とは付き合えない」と判断します。相見積もりは価格を叩く場ではなく、条件をそろえて提案を比べる場だと考えてください。

マナーとして最低限守りたいのは次の3点です。

• 相見積もりであることを伝える：隠さず「複数社で検討している」と最初に共有する。
• 各社に同じ条件を渡す：情報の出し方に差をつけない。
• 断るときは一報を入れる：見送る会社にも、決まった旨を簡潔に連絡する。

誠実に進めれば、相見積もりは会社側の対応の質を見極める良い機会になります。質問への答え方が丁寧か、レスポンスが速いか、渋らず内訳を出すか——ここに会社の姿勢が表れます。悪い会社の兆候は悪い開発会社の見分け方、契約時の注意点は開発契約の注意点もご覧ください。

業種・シーン別の相見積もりの進め方

相見積もりの取り方は、案件の性質によって重心が変わります。自社がどのタイプかを意識すると、比較の焦点が定まります。

シーン	重視すべき観点	よくある落とし穴
業務システム（在庫・受発注など）	既存業務との整合、データ移行、保守体制	現場の運用を伝えきれず、後から機能が膨らむ
一般公開のWebサービスやEC	セキュリティ、負荷対応、運用の継続性	初期費だけ見て、月額の運用費を見落とす
スマホアプリ	iOS/Android両対応の範囲、審査対応、更新体制	片方だけの見積もりで比較してしまう
小規模ツール・自動化	スピード、費用対効果、割り切り	過剰な体制の会社に高く見積もられる

いずれの場合も、各社に同じ条件を渡すという原則は変わりません。ただし重視する観点が違えば、見積書のどの行を重点的に読むかも変わります。たとえば一般公開サービスなら、初期費が同じでも月額の運用費が数倍違うことがあり、そこを比べないと本当のコストが見えません。

見積書が3社ぶん揃ったら、選ぶ前に次のチェックリストを上から順に確認してください。半分以上に「はい」と言えないなら、質問して埋めてから比較に進みます。

• 各社に同じ条件（RFP・機能一覧・範囲・予算感）を渡せているか
• 工程ごと（要件定義・設計・開発・テスト・管理）に内訳が分かれているか
• 「一式」でごまかされている項目がないか
• 総額を人月単価で割った工数が、規模に対して妥当か
• 要件定義・テスト・保守が含まれるか別かが明確か
• 「追加費用になる条件」が文書に書かれているか
• 体制（誰が何人・どんな経験か）が示されているか
• 完成したソースコードの権利がこちらに渡るか
• 質問に快く、具体的に答えてくれる会社か

このリストは、金額の高い安い以前に「見積書として成立しているか」「比較の前提がそろっているか」を確かめるものです。ここが埋まって初めて、価格比較に意味が出ます。多くのトラブルは金額そのものではなく、この線引きが曖昧なまま契約に進んだことから起きます。確認した内容は口頭で終わらせず、見積書の改訂版やメールとして残しておくと、後で「言った言わない」を避けられます。

「一式見積もり」の危険と、一律料金なら比較が楽な理由

相見積もりの比較を難しくしている最大の原因は、会社ごとに前提・内訳・追加条件がバラバラで、しかも「最終的にいくらになるか」の不確実性が最後まで残ることです。特に「システム開発一式 ◯◯万円」とだけ書かれた見積もりは、内訳が見えず、何が含まれ何が追加になるか判断できません。ここまで見てきたRFPの用意・7観点の比較・人月の検算は、突き詰めればこの不確実性を減らすための作業でした。

裏を返せば、総額が最初から決まっていれば、相見積もりの比較作業の大半は不要になります。金額が動かないなら、範囲をそろえて検算したり、追加条件を疑ったりする必要がそもそもありません。

D-oneAppは料金が一律100万円（大規模なプロプランは一律200万円）で、追加費用なし・着手前に総額が確定します。相見積もりで各社を比べるときも、「D-oneAppは100万円で、追加なし・コード納品」という一点が基準になるため、他社の見積もりが「その範囲でその金額なら妥当か」を判断しやすくなります。さらに完成したソースコードの権利は顧客に渡るため、あとで別の会社に引き継ぐこともできます。100万円でどこまでできるかは100万円でできること、発注全体の流れは発注の流れ、見積書の読み方は見積もりの見方もご覧ください。

まとめ

相見積もりのコツは、①社数は2〜3社に絞る、②全社に同じRFP（依頼条件）を渡す、③金額だけでなく内訳・範囲・前提・追加条件・体制・権利の7観点で比べる、④安すぎ高すぎは人月で検算する、⑤詳細設計をタダで作らせない・値切り一辺倒にしないなどのNGとマナーを守る——の5つに集約できます。

金額のバラつきは「どちらが得か」ではなく「何が含まれ、何が省かれているか」の差です。比較作業の大半は、その隠れた不確実性を洗い出すことに費やされます。総額が最初から固定されていれば、その手間そのものが不要になります。相見積もりの比較に疲れたら、総額が最初から決まる無料相談で「100万円でどこまでできるか」を整理しましょう。