3社の見積もりが並んだとき、あなたはどう判断する
公開日：2026年8月4日｜カテゴリ：システム開発・外注管理・プロジェクト実務
「A社1,200万円、B社800万円、C社450万円」——3社の見積もりが並んだとき、あなたはどう判断するだろうか。
ここで金額を比べ始めた時点で、すでに間違っている。金額が3倍も違うのは、各社が「違うものを作る前提」で見積もっているからだ。同じものを作る前提が揃っていない見積もりは、そもそも比較できない。
外注成功のゴールはシンプルだ。「目的が共有され、要件定義の粒度が揃い、RFPの条件が統一された状態で相見積もりに入る」——これができると「比較できない」「後から増える」「進め方が分からない」という3大失敗が一気に減る。
本記事では、行動経済学・認知科学・成功者の思考パターンをもとに、ソフト開発外注の勘所——要件定義のポイント、予算の立て方、相見積もりの実務、そしてスクラッチ開発を選ぶべきかの判断——を具体的に解説する。
第1章：要件定義——「Must/Want」で分けるだけで見積もりが変わる
丸投げが最も高くつく理由
見積もり精度を高めるためには、開発会社に丸投げするのは避けたい。理由は単純だ。要件が曖昧なとき、開発会社はリスクを金額に上乗せする。「何を要求されるか分からない」不確実性を、バッファとして見積もりに含めるからだ。
逆に言えば、要件が明確なほど見積もりは下がる。要件定義に時間をかけることは、コスト削減の最も確実な手段なのだ。
最重要ポイント：Must と Want を分ける
要件定義で最も効果が高く、最も簡単にできることが「Must（必須機能）」と「Want（あれば望ましい機能）」の区別だ。
この2つを分けておくと、開発会社は予算調整の提案がしやすくなる。たとえば「シンプルな検索機能は付けるが、メタ検索機能は付けないでコストを抑える」といった具体的な調整案が出てくる。区別がないと、開発会社は全部Mustとして見積もるしかなく、金額が膨らむ。
認知科学：「知識の呪縛」が要件漏れを生む
自社業務に詳しい人ほど、要件定義で罠にはまる。認知科学の「知識の呪縛」——熟知した人は自分の前提を説明し忘れる——により、「そんなの当たり前」と思っていることが要件書から抜け落ちる。
「月末は処理件数が10倍になる」「この帳票は税理士に提出する」「ベテランは裏技的な入力をしている」——こうした前提が伝わらないまま作られたシステムは、稼働後に「使えない」と言われる。
対策：要件書をAIに読ませ、「この要件定義書で、外部の開発会社が理解できない前提・説明が不足している箇所を指摘して」と依頼する。第三者視点で前提の抜けを機械的に洗い出せる。
図1｜要件定義 できているかチェックリスト
| 確認項目 | できている状態 | 危険な状態 |
|---|---|---|
| 目的（Why） | 「月40時間の集計作業を10時間に」など、解決したい課題が数字で書かれている | 「業務効率化のため」だけ。何がどうなれば成功か定義されていない |
| Must / Want の区別 | 機能一覧が必須・希望に分類され、優先順位が付いている | 機能が羅列されているだけ。全部必須に見えるため予算調整ができない |
| 利用者と件数 | 同時利用者数・月間処理件数・ピーク時の負荷が明記されている | 未記載。稼働後に「遅すぎて使えない」が発生する典型パターン |
| 既存システム連携 | 連携先システム名・データ形式・移行するデータ量が具体的に書かれている | 「既存システムと連携」の一言。データ移行は追加費用の最頻出項目 |
| やらないこと | 「今回は対象外」の範囲が明記されている（スマホ対応・多言語など） | 記載なし。認識のズレが開発後半で発覚し、揉める |
| 現場の関与 | 実際に使う現場担当者がレビューし、承認している | 管理職だけで作成。稼働後に現場から「これでは仕事にならない」 |
※6項目すべてが「できている状態」なら相見積もりに進んでよい。2つ以上が危険な状態なら、まず要件定義に戻る。
第2章：予算の立て方——「開発費」だけで組むと必ず足りなくなる
プランニング・ファラシー：人は必ず楽観的に見積もる
行動経済学の「計画錯誤（Planning Fallacy）」——人は所要時間とコストを systematically に過小評価する——は、システム開発で最も再現性の高い法則だ。カーネマンの研究では、専門家であっても自分のプロジェクトについては楽観的に見積もることが示されている。
対策は精神論ではなく数字だ。予備費として開発費の20〜30%を最初から確保しておく。「使わなければ返す」前提で組む。これがないと、仕様変更が発生した瞬間にプロジェクトが止まる。
予算に含め忘れる5つの費目
開発費だけを予算化して失敗するケースが後を絶たない。以下は必ず別枠で計上すべき費目だ。
① 予備費（開発費の20〜30%）：仕様変更・追加要望への対応原資。ゼロで組むと、変更のたびに稟議が必要になり、プロジェクトが硬直する。
② 保守運用費（開発費の15〜25%／年）：初年度から発生する。5年使うなら開発費とほぼ同額が積み上がる。
③ インフラ費用：サーバー・クラウド・ライセンス費。月額で継続的に発生する。
④ 社内工数：要件定義・テスト・移行作業に社員の時間が取られる。「見えないコスト」だが実在する。担当者の稼働率を3〜5割見込む。
⑤ 教育・移行費：マニュアル作成、研修、並行稼働期間の二重作業コスト。
図2｜予算構成の目安（開発費1,000万円のケース）
| 費目 | 目安金額 | 備考 |
|---|---|---|
| 開発費（見積本体） | 1,000万円 | 要件定義・設計・実装・テストを含む契約金額 |
| 予備費 | 200〜300万円 | 開発費の20〜30%。仕様変更・追加要望の原資。これがない予算は必ず破綻する |
| 保守運用費（年間） | 150〜250万円 | 開発費の15〜25%／年。5年使えば750〜1,250万円が積み上がる |
| インフラ・ライセンス | 月数万〜数十万円 | クラウド利用料・ソフトウェアライセンス。継続的に発生 |
| 社内工数（見えない費用） | 担当者の3〜5割 | 要件定義・テスト・移行に社員の時間が取られる。人件費換算で数百万円相当 |
| 初年度の実質総額 | 約1,400万円〜 | 見積額の約1.3〜1.5倍が現実的な初年度予算。ここを社内で握っておくと後で揉めない |
第3章：相見積もり——「3社」が最適解である理由
なぜ2社では足りず、5社では多すぎるのか
相見積もりは3社程度が最適とされる。2社では比較対象が少なく、5社以上では各社との打ち合わせ・調整に時間が取られすぎる。3社の中で提案内容・金額・担当者の対応・実績を総合的に判断するのが現実的だ。
認知科学的にも裏付けがある。「選択のパラドックス」——選択肢が増えるほど意思決定の質が落ち、満足度も下がる——により、5社以上の比較は判断を鈍らせる。3社は比較の効果を最大化しつつ、認知負荷を抑えられる数だ。
相見積もりの絶対条件：RFPで前提を揃える
RFP（提案依頼書）を用意した上で複数社に依頼すると、各社の提案内容と金額を同じ土俵で比較できるようになる。逆にRFPなしで「見積もりください」と言えば、各社が勝手に前提を置き、冒頭のように3倍の開きが出る。
RFPは難しく考えなくてよい。自社の「Why」を明文化するという基本に立ち返れば作成は難しくない。目的・必要機能・予算感・納期・技術要件をまとめた文書があれば、それがRFPだ。
発注決定までの現実的なスケジュール
見積もり依頼から発注決定までは、プロジェクト規模にもよるが通常1〜2ヶ月程度を見込む。この期間を確保せず「来月から開発開始」と決めてしまうと、比較検討が形骸化し、結局は最初に会った会社に発注することになる。
第4章：スクラッチ開発は本当に手間がかかるのか
結論から言えば「手間はかかる。ただし、その手間に見合う場面がある」。問題は、見合わない場面でスクラッチを選んでしまうことだ。判断基準を整理する。
図3｜スクラッチ開発 vs パッケージ/ローコード 判断早見表
| 観点 | スクラッチ開発 | パッケージ／ローコード |
|---|---|---|
| 発注側の手間 | 大きい。要件定義を一から作り込む必要がある。打ち合わせ回数も多い | 小さい。既存機能を見ながら「使う／使わない」を選ぶ形で進む |
| 初期費用 | 高い。ゼロから作るため工数がそのまま金額になる | 低い。月額サブスクや初期設定費のみで始められるものも多い |
| 業務への適合度 | 完全適合。自社の業務フローをそのまま実装できる | 要調整。業務をシステムに合わせる必要が出る場合がある |
| 導入までの期間 | 長い。数ヶ月〜1年以上。要件定義だけで数ヶ月かかることも | 短い。数週間〜数ヶ月で稼働できる |
| 向いている場面 | 業務プロセス自体が競争力の源泉／既製品では絶対に代替できない独自要件／長期利用が確実 | 一般的な業務（勤怠・経費・在庫）／まず小さく始めたい／要件が固まりきっていない |
※2026年の実務では「まずパッケージ/ローコードで試し、どうしても足りない部分だけスクラッチ」というハイブリッドが増えている。
スクラッチの手間を減らす現実的な方法
① 段階分割（フェーズ化）：全機能を一度に作らず、Must機能だけで第1弾をリリースし、使いながらWant機能を追加する。要件定義の負荷が分散し、実際に使った結果を反映できるため精度も上がる。
② プロトタイプ先行：AI活用により試作が安価になった今、「動くもの」を先に作って認識合わせをする方法が現実的になった。文書で議論するより、画面を見ながらのほうが誤解が激減する。
③ AIで要件定義を加速：後述するAI活用で、従来は数ヶ月かかった要件定義の作業部分を大幅に短縮できる。
第5章：AIを「発注者側の武器」にする4つの使い方
発注の失敗の多くは「開発会社は技術を知り、発注者は知らない」という情報の非対称性から生まれる。2026年、この差はAIでかなり埋められる。
① RFPの叩き台を作らせる：「在庫管理システムを外注します。業種は製造業、従業員50名、利用者10名、予算800万円。開発会社に渡すRFPを、目的・機能要件（Must/Want別）・非機能要件・スケジュール・評価基準の構成で作ってください」——数分で骨子ができる。
② 要件の抜けを指摘させる：「この要件定義書で、外部の開発会社が理解できない前提や、記載が不足している観点を指摘してください。特に権限管理・データ移行・帳票・例外処理の観点で」——知識の呪縛を第三者視点で破る。
③ 見積書を横並びで比較させる：3社の見積内訳（社名は伏せる）をAIに入力し、「各社の見積もりで、含まれる範囲の違い・工数の妥当性・後から追加請求されそうな箇所を比較表にして」と依頼する。金額だけでは見えない差が浮かび上がる。
④ 商談用の質問リストを作らせる：「この見積書について開発会社に確認すべき質問を10個。特に対応範囲の曖昧さと追加費用のリスクを重点的に」——鋭い質問ができる発注者は、それだけで軽く扱われなくなる。
第6章：成功者の思考パターン——「良い発注者」が良い提案を引き出す
見落とされがちな事実がある。優良な開発会社ほど、客を選んでいる。要件が曖昧で、決定が二転三転し、丸投げ体質の発注者は、良い会社から敬遠される。結果、「どんな案件でも受ける会社」としか出会えなくなる。
行動経済学の「互恵性の原理」——人は与えられたものに報いようとする——が、ここでも働く。丁寧なRFPを用意し、質問に迅速に回答し、議事録を確認する発注者に対して、開発会社は自然と質の高い提案で応えようとする。準備の労力は、提案の質という形で必ず返ってくる。
優れた経営者は、外注を「安く買い叩く交渉」ではなく「良いパートナーとの共同作業」として設計する。相見積もりも、値切るためではなく「自社の課題を最も深く理解した会社を見つけるため」に行う。この目的の違いが、5年後のシステムの価値を決める。
まとめ：今日から動ける3つのアクション
アクション1（今週中）： 欲しい機能を紙に書き出し、Must と Want に分ける。この作業だけで見積もりの精度が変わり、予算調整の選択肢が生まれる。所要時間は1時間で済む。
アクション2（今月中）： 予算を「見積額の1.3〜1.5倍」で社内合意する。予備費20〜30%と保守費15〜25%／年を最初から計上しておく。後から追加稟議を出すより、はるかに通りやすい。
アクション3（発注1〜2ヶ月前）： RFPを作り、3社に同一条件で依頼する。AIに叩き台を作らせれば1日で用意できる。比較検討の期間を1〜2ヶ月確保することを、スケジュールに先に組み込む。
ソフト開発外注の勘所は、技術の知識ではない。「同じ前提で比較できる状態を作れるか」——ただこの一点だ。要件を分類し、予算に余白を持たせ、RFPで土俵を揃える。この3つができれば、あなたの発注は失敗する確率が劇的に下がる。
データ出典：株式会社GeNEE・システム幹事・発注ラウンジ（発注ナビ）・ファーストネットジャパン・ソフィエイト・各社公開情報（2025〜2026年）。金額・相場は案件規模や地域により変動します。契約に関する最終判断は専門家にご相談ください。
タグ： システム開発 | 外注 | 要件定義 | RFP | 相見積もり | 予算 | スクラッチ開発 | AI活用 | 行動経済学 | 発注ノウハウ
