結論から述べます。相見積もりは「最も安い会社を選ぶ作業」ではありません。「各社を同じ土俵に載せる作業」です。 そして金額は、比較のなかで最初に見てはいけない軸であり、最後に見る軸です。なぜなら、複数社の見積もりを並べたとき、金額が違う最大の理由は「実力の差」ではなく、各社が見ている要件と、見積もりに含めた範囲が、そもそもバラバラだからです。りんごとみかんを並べて「みかんの方が安い」と選んでいるのに、それに気づかない——これが相見積もりで失敗する構造です。
本記事は、発注者（経営者・事業責任者・情報システム担当）が、金額に惑わされず内訳（人月・非機能・保守）を読み、危険信号を弾き、同一要件で正しく比較するための実務ガイドです。費用の相場そのものはシステム開発の費用相場と見積もりの内訳に、発注全体の意思決定はシステム開発の発注 完全ガイドに譲り、ここでは「複数の見積もりをどう比較するか」に集中します。
数字の前提: 本文の相場（人月単価・保守費率など）は公開された一般的な目安です。私の実プロジェクトに紐づく定量値（221エンドポイント、4ラウンドのセキュリティ監査、本番二重課金0件など）はリポジトリから検証可能な実測値であり、事業ROIはクライアントの実データが必要なため断定しません。
1. 相見積もりが失敗する構造 — 「金額」は最も比較してはいけない軸
3社に相見積もりを取り、A社800万円・B社1,200万円・C社1,600万円が並んだとします。多くの発注者はここで「A社は安い、C社は高い」と考えます。これが最初の間違いです。
金額が違う理由を分解すると、ほぼ次のどれかに落ちます。
| 金額が違う理由 | 実態 |
|---|---|
| 対象範囲の差 | A社は「主要画面だけ」、C社は「管理画面・帳票・権限まで」を見ている |
| 非機能要件の有無 | 安い側は性能・セキュリティ・テスト・監視を見積もりに含めていない |
| 要件定義工程の有無 | A社は要件定義をスキップし、曖昧さを発注者に押し付けている |
| 保守・運用の扱い | A社は「作って終わり」、C社はリリース後の保守まで含む |
| 人月単価の差 | 多重下請け構造のマージンが乗っているかどうか |
つまり、金額の差の大半は「品質の差」ではなく「範囲と前提の差」です。この状態で金額を比較しても、「いちばん範囲が狭くて非機能を省いた見積もり」が最安として選ばれるだけ——それは「いちばん危ない見積もり」を選んでいるのと同義になりかねません。
だから発注者が最初にやるべきは、見積もりを比較することではありません。全社が「同じ要件・同じ範囲」で見積もれる土俵を作ることです。土俵さえ揃えば、金額はほとんど勝手に「意味のある比較軸」に変わります。
2. 同一要件で比較する — 先に「土俵」を固める
比較を成立させる鍵は、見積もりを取る前にあります。各社に投げる依頼内容を揃えるのです。
2-1. 全社に同じ資料を渡す
口頭やメールで「こんな感じのシステムを」と各社にバラバラに伝えると、各社は各自の解釈で範囲を決めます。これが比較を壊す元凶です。最低限、次を同一の文書として全社に渡します。
- RFP（提案依頼書）——背景・目的・スコープ・制約・スケジュール・評価基準
- 要件定義（あるいはその素案）——実現したい機能の一覧と優先度
- 非機能の期待水準——性能・可用性・セキュリティ・運用にどこまで求めるか
3番目の「非機能の期待水準」は、発注者が最も言語化しづらい部分です。ここで有効なのが、IPAが公開している非機能要求グレードです。可用性・性能・拡張性・運用保守性・セキュリティといった非機能を項目化し、要求レベルを段階で示せるため、「発注者が非機能を語れない」問題を構造的に解消できます。これを添えるだけで、各社の見積もりに非機能行が入るようになり、比較の解像度が跳ね上がります。
2-2. 見積もり依頼時に「フォーマット」を指定する
各社が自由なフォーマットで出すと、粒度も項目もバラバラで並べ替えられません。依頼段階で、次の項目を必ず内訳に含めることを指定します。
| 指定する項目 | 目的 |
|---|---|
| 対象範囲（含む／含まない） | スコープの前提を各社で揃える |
| 工程別の工数（人日・人月） | 「一式」を禁止し、粒度を揃える |
| 非機能要件の項目と工数 | 性能・セキュリティ・テスト・監視を独立行に |
| 前提条件と除外事項 | 「〜は別途」を明文化させ、後の追加費用を防ぐ |
| 運用・保守の範囲・費用・SLA | ランニングコストを比較可能にする |
| 主要リスクと対応方針 | 各社のリスク感度を可視化する |
このフォーマット指定こそが、相見積もりの成否を分けます。同じ器に入れさせて初めて、中身の差が見えるのです。
3. 見積内訳の読み方 — 3レイヤーに分解する
各社の見積もりが揃ったら、金額の前に内訳を3レイヤーに分解して並べ替えます。
レイヤー1 機能開発 … 画面・API・帳票など「動くもの」を作る工数
レイヤー2 非機能 … 性能・セキュリティ・テスト・監視・可用性
レイヤー3 運用・保守 … リリース後のランニング（障害対応・改修・SLA）
多くの発注者はレイヤー1だけを見て金額を比較します。しかし、発注後に地雷を踏むのはレイヤー2とレイヤー3です。ここが薄い（あるいは空白の）見積もりは、安いのではなく「あとで効いてくる費用が隠れている」だけです。
比較テンプレート
各社をこの構造に「翻訳」して並べます。「開発一式」で来た会社には、この形での再提出を求めてください。
| 内訳 | A社 | B社 | C社 |
|---|---|---|---|
| レイヤー1：機能開発（人月） | 6人月 | 7人月 | 8人月 |
| レイヤー2：非機能（性能・セキュリティ・テスト・監視） | 記載なし | 2人月 | 3人月 |
| レイヤー3：運用・保守（年額） | 記載なし | 初期の15%前後 | 初期の15%前後＋SLA |
| 要件定義工程 | 含まず | 含む | 含む |
| 前提・除外の明記 | なし | あり | あり |
こうして並べ替えると、「A社が安い」のではなく「A社は非機能・保守・要件定義を見ていない」ことが一目でわかります。A社を選ぶ＝レイヤー2・3を後から追加費用で買い直すという意思決定になる、と正しく理解できます。
非機能がいかに工数を占めるか（実例）
「非機能なんて誤差では？」と思われるなら、実際の規模感で示します。私が手がけた木材流通のB2B SaaS（経済産業大臣賞を受賞）は、221本のAPIエンドポイント、17のTerraformモジュール、12のLambda、4ラウンドのセキュリティ監査という構成でした。このうち「画面が動く」ための工数はごく一部で、大半は認証・権限（マルチテナントのデータ分離）・可用性・監視・セキュリティという非機能に費やされています。全221エンドポイントで認証欠落0件を第三者ペネトレーションテストで実証していますが、この「0件」は非機能に工数を割いた結果です。非機能を省いた見積もりは、この土台を丸ごと省いている、ということです。
4. 安すぎる見積もりの危険信号 — 10のレッドフラグ
金額が飛び抜けて安い見積もりは、歓迎する前に疑うのが鉄則です。次のうち1つでも当てはまれば、そのまま選ぶのは危険です。機械的なチェックリストとして使ってください。
- 「開発一式」で丸められ、工数の内訳がない——根拠が検証できない
- 要件定義・設計の工程が見積もりに存在しない——曖昧さのツケを後で払う
- 非機能要件（性能・セキュリティ・監視）の行が1行もない——本番で破綻する
- テスト工数が極端に少ない、またはゼロ——リリースのたびにバグが出る
- 運用・保守の記載がない——「作って終わり」で、障害対応も改修も別料金
- 前提条件・除外事項が書かれていない——追加費用の温床
- 工期が他社比で不自然に短い——品質を削るか、後で遅延して揉める
- 主要リスクへの言及が一切ない——リスクを見ていない＝見えていない
- こちらの質問への回答が曖昧・後回し——見積もり後の火種
- 金額だけ先に提示し、内訳は「契約後に」と言う——最も危険な兆候
とりわけ、決済や個人情報を扱うシステムでは要注意です。たとえば決済に「冪等性（リトライしても二重課金しない仕組み）」の設計が見積もりに含まれていなければ、それは**「いつか二重課金事故を起こすシステム」を安く買っているということです。私が運用する決済プラットフォームは本番稼働中の二重課金0件**を維持していますが、これは冪等性という構造をあらかじめ設計工数に織り込んだ結果であり、後付けできる類のものではありません。安さの裏でこの種の土台が抜けていないか——それを内訳から読み取るのが、危険信号チェックの本質です。
5. 金額を最後に見る — 多軸スコアリング
内訳を揃え、危険信号を弾いて、ようやく最終比較です。ここでも「最安」を選ぶのではなく、複数軸に重みを付けてスコアリングします。
| 評価軸 | 重み（例） | 見るポイント |
|---|---|---|
| 技術力・実績 | 25% | 同種の本番実績、公開できる成果物、技術スタックの妥当性 |
| 要件理解度 | 20% | こちらの課題を言い換えられるか、逆質問の質 |
| 見積もりの透明性 | 20% | 内訳の粒度、前提・除外の明記、一式の有無 |
| 非機能・品質の網羅 | 15% | 性能・セキュリティ・テスト・監視が独立項目であるか |
| 保守・運用体制 | 10% | リリース後の範囲・SLA・連絡体制 |
| 金額 | 10% | 妥当なレンジ内か（外部ベンチマークと照合） |
金額の重みが**わずか10%**であることに注目してください。相見積もりで守るべきなのは、「最安を選ぶこと」ではなく「妥当なレンジの中で、内訳が明快で、非機能と保守を含み、要件を正しく理解している相手を選ぶこと」です。最安でも最高でもない、構造が信頼できる見積もりが正解になることがほとんどです。
人月・工数の妥当性は外部ベンチマークで確認する
「そもそもこの人月は妥当なのか」を発注者が独力で判断するのは難しいものです。ここでIPAのソフトウェア開発分析データ集が役立ちます。多数の実プロジェクトから、工数・工期・規模・生産性・信頼性の定量データが公開されており、外部ベンチマークとして見積もりの妥当性を照合できます。「A社の工数が相場の半分」なら、それは安いのではなく何かが抜けている、という仮説を立てられます。
6. 相見積もりのアンチパターン — やってはいけない4つ
最後に、相見積もりを逆効果にしてしまう典型を挙げます。
6-1. 最安をぶつけて値切りの材料にする
「A社は800万円だった。同じ金額でやれないか」——これは短期的には効いても、実際にはベンダーに**「品質を削って帳尻を合わせる」インセンティブ**を与えます。削られるのは、目に見えない非機能とテストです。相見積もりは値切りの道具ではなく、同一要件で範囲と品質を揃えるための道具だと理解してください。
6-2. 相見積もりを「要件定義の代わり」にする
要件が固まっていないまま各社に投げ、返ってきた提案の寄せ集めで要件を決める——これは順序が逆です。曖昧な要件は各社バラバラの前提を生み、比較を壊します。要件定義そのものを最初の工程として発注する（小さく準委任で始める）ほうが、結果的に速く安全です。
6-3. 社数を増やしすぎる／少なすぎる
1社では相場観が持てず、妥当性を検証できません。かといって5社以上に広げると、各社への説明と見積もり読み込みで発注者側が疲弊し、比較の質が落ちます。3社前後が現実的な着地点です。
6-4. 「一人 × 生成AI」の見積もりを同じ枠で誤読する
近年は、私のような一人（少人数）× 生成AIの見積もりが比較対象に入ることがあります。この見積もりが安く見えるのは、中間マージンと調整コストがなく、発注額がそのまま開発に向かうからであって、品質を削っているからではありません（費用相場の記事で詳述）。逆に、検証ゲート（型安全な境界検証・自動テスト・静的解析・セキュリティ監査）を説明できるかが、その安さが健全かどうかの分かれ目です。私の場合、木材DXの認証欠落0件、決済の二重課金0件、テストカバレッジ100%といった実測値が、その担保です。相見積もりに一人×AIを入れるなら、「なぜ安いのか」の根拠を内訳と検証プロセスで確認してください。
まとめ：土俵を揃え、内訳を読み、金額は最後に
相見積もりで損をしないための順序を、もう一度整理します。
- 金額は最初に比較しない——差の大半は実力ではなく「範囲と前提の差」。
- 先に土俵を揃える——RFP・要件定義・非機能の期待水準を全社に同一で渡す。
- 内訳を3レイヤーに分解——機能（人月）／非機能／運用・保守で並べ替える。
- 危険信号を機械的に弾く——一式・非機能ゼロ行・保守未記載・テスト過少は要注意。
- 金額は最後、多軸で選ぶ——妥当なレンジの中で内訳が明快な相手を選ぶ。
相見積もりの内訳が読み切れない、あるいは「この金額は妥当か」を第三者の目で確認したい——そうしたご相談も歓迎します。要件の棚卸しから、各社の見積もりを同じ土俵に翻訳し、何にいくらかかるのかを構造化するところまで、発注者の側に立って整理します。