# システム開発の相見積もり比較術 — 金額だけ見ると失敗する > システム開発の相見積もりで損をしないための実務ガイド。見積内訳（人月・非機能・保守）の読み方、安すぎる見積もりの危険信号、そして同一要件で正しく比較する方法を、発注者の視点で解説します。金額を最後に見るための多軸スコアリングと、相見積もりのアンチパターンまで、実プロジェクトの知見から体系化しました。 - 公開日: 2026-07-07 - 著者: 友田 陽大 - タグ: 受託開発, システム開発, 発注, コスト最適化, 技術選定, B2B SaaS - URL: https://tomodahinata.com/blog/system-development-quotation-comparison-guide - カテゴリ: 発注・内製化・コスト - 総合ガイド: https://tomodahinata.com/blog/system-development-outsourcing-guide-vendor-selection-cost ## 要点 - 相見積もりは『最安を選ぶ作業』ではなく『各社を同じ土俵に載せる作業』。金額は最初に比較してはいけない軸で、最後に見る - 先にRFP・要件定義・非機能の期待水準を固め、全社に同じ資料を渡さないと、各社が見ている前提が違って比較が成立しない - 見積内訳は『機能（人月）／非機能（性能・セキュリティ・テスト・監視）／運用・保守』の3レイヤーに分解して並べ替えると差が見える - 安すぎる見積もりの正体は、要件定義・非機能・保守・テストの『抜け』。10の危険信号で機械的に弾ける - 最終判断は技術力・要件理解・透明性・保守体制・金額の多軸スコアリング。最安でも最高でもなく『内訳が明快で妥当な相手』を選ぶ --- 結論から述べます。**相見積もりは「最も安い会社を選ぶ作業」ではありません。「各社を同じ土俵に載せる作業」です。** そして金額は、比較のなかで**最初に見てはいけない軸**であり、**最後に見る軸**です。なぜなら、複数社の見積もりを並べたとき、金額が違う最大の理由は「実力の差」ではなく、**各社が見ている要件と、見積もりに含めた範囲が、そもそもバラバラだから**です。りんごとみかんを並べて「みかんの方が安い」と選んでいるのに、それに気づかない——これが相見積もりで失敗する構造です。 本記事は、発注者（経営者・事業責任者・情報システム担当）が、金額に惑わされず**内訳（人月・非機能・保守）を読み、危険信号を弾き、同一要件で正しく比較する**ための実務ガイドです。費用の相場そのものは[システム開発の費用相場と見積もりの内訳](/blog/system-development-cost-estimate-market-rate-guide)に、発注全体の意思決定は[システム開発の発注 完全ガイド](/blog/system-development-outsourcing-guide-vendor-selection-cost)に譲り、ここでは「複数の見積もりをどう比較するか」に集中します。 > **数字の前提**: 本文の相場（人月単価・保守費率など）は公開された一般的な目安です。私の実プロジェクトに紐づく定量値（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が公開している[非機能要求グレード](https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/index.html)です。可用性・性能・拡張性・運用保守性・セキュリティといった非機能を項目化し、要求レベルを段階で示せるため、**「発注者が非機能を語れない」問題を構造的に解消**できます。これを添えるだけで、各社の見積もりに非機能行が入るようになり、比較の解像度が跳ね上がります。 ### 2-2. 見積もり依頼時に「フォーマット」を指定する 各社が自由なフォーマットで出すと、粒度も項目もバラバラで並べ替えられません。依頼段階で、次の項目を**必ず内訳に含めること**を指定します。 | 指定する項目 | 目的 | |---|---| | **対象範囲（含む／含まない）** | スコープの前提を各社で揃える | | **工程別の工数（人日・人月）** | 「一式」を禁止し、粒度を揃える | | **非機能要件の項目と工数** | 性能・セキュリティ・テスト・監視を独立行に | | **前提条件と除外事項** | 「〜は別途」を明文化させ、後の追加費用を防ぐ | | **運用・保守の範囲・費用・SLA** | ランニングコストを比較可能にする | | **主要リスクと対応方針** | 各社のリスク感度を可視化する | このフォーマット指定こそが、相見積もりの成否を分けます。**同じ器に入れさせて初めて、中身の差が見える**のです。 --- ## 3. 見積内訳の読み方 — 3レイヤーに分解する 各社の見積もりが揃ったら、金額の前に**内訳を3レイヤーに分解**して並べ替えます。 ```text レイヤー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の[ソフトウェア開発分析データ集](https://www.ipa.go.jp/digital/software-survey/metrics/index.html)が役立ちます。多数の実プロジェクトから、工数・工期・規模・生産性・信頼性の定量データが公開されており、**外部ベンチマークとして見積もりの妥当性を照合**できます。「A社の工数が相場の半分」なら、それは安いのではなく何かが抜けている、という仮説を立てられます。 --- ## 6. 相見積もりのアンチパターン — やってはいけない4つ 最後に、相見積もりを**逆効果**にしてしまう典型を挙げます。 ### 6-1. 最安をぶつけて値切りの材料にする 「A社は800万円だった。同じ金額でやれないか」——これは短期的には効いても、実際にはベンダーに**「品質を削って帳尻を合わせる」インセンティブ**を与えます。削られるのは、目に見えない非機能とテストです。相見積もりは値切りの道具ではなく、**同一要件で範囲と品質を揃えるための道具**だと理解してください。 ### 6-2. 相見積もりを「要件定義の代わり」にする 要件が固まっていないまま各社に投げ、返ってきた提案の寄せ集めで要件を決める——これは順序が逆です。曖昧な要件は各社バラバラの前提を生み、比較を壊します。**要件定義そのものを最初の工程として発注する**（小さく準委任で始める）ほうが、結果的に速く安全です。 ### 6-3. 社数を増やしすぎる／少なすぎる 1社では相場観が持てず、妥当性を検証できません。かといって5社以上に広げると、各社への説明と見積もり読み込みで発注者側が疲弊し、比較の質が落ちます。**3社前後**が現実的な着地点です。 ### 6-4. 「一人 × 生成AI」の見積もりを同じ枠で誤読する 近年は、私のような**一人（少人数）× 生成AI**の見積もりが比較対象に入ることがあります。この見積もりが安く見えるのは、**中間マージンと調整コストがなく、発注額がそのまま開発に向かうから**であって、品質を削っているからではありません（[費用相場の記事](/blog/system-development-cost-estimate-market-rate-guide)で詳述）。逆に、**検証ゲート（型安全な境界検証・自動テスト・静的解析・セキュリティ監査）を説明できるか**が、その安さが健全かどうかの分かれ目です。私の場合、木材DXの認証欠落0件、決済の二重課金0件、テストカバレッジ100%といった実測値が、その担保です。相見積もりに一人×AIを入れるなら、「なぜ安いのか」の根拠を内訳と検証プロセスで確認してください。 --- ## まとめ：土俵を揃え、内訳を読み、金額は最後に 相見積もりで損をしないための順序を、もう一度整理します。 1. **金額は最初に比較しない**——差の大半は実力ではなく「範囲と前提の差」。 2. **先に土俵を揃える**——RFP・要件定義・非機能の期待水準を全社に同一で渡す。 3. **内訳を3レイヤーに分解**——機能（人月）／非機能／運用・保守で並べ替える。 4. **危険信号を機械的に弾く**——一式・非機能ゼロ行・保守未記載・テスト過少は要注意。 5. **金額は最後、多軸で選ぶ**——妥当なレンジの中で内訳が明快な相手を選ぶ。 相見積もりの内訳が読み切れない、あるいは「この金額は妥当か」を第三者の目で確認したい——そうしたご相談も歓迎します。要件の棚卸しから、各社の見積もりを同じ土俵に翻訳し、何にいくらかかるのかを構造化するところまで、発注者の側に立って整理します。