外注費用を適正化する相見積もりの取り方

大規模ITプロジェクトは平均で45%の予算超過、想定価値の56%を取り逃がす――McKinseyとOxfordの共同研究で示された現実は、見積り精度と発注判断の難しさを物語ります。¹ 研究データでは、競争性のある見積りプロセスを設けた案件は、単一指名発注と比べて調達費用が二桁パーセンテージ改善するケースが報告されています。²⁴ 現場でしばしば指摘されるのは、複数見積りは単なる値引き交渉の仕掛けではなく、前提の揃え込みと比較方法の設計が成果を分けるという点です。つまり、**「同じものを、同じ前提で、同じ物差しで比べる」**ことが、費用の適正化とリスク低減の両立につながります。

相見積もりの成否を分けるのは前提設計にある

複数社からの見積りを成功させる最短経路は、提案依頼書（RFP: Request for Proposal）を配布する前にベースラインを固めることです。プロダクトの狙い、対象ユーザー、KPIの初期値と目標値、非機能要件、運用体制、リリース計画、依存関係、既存資産の再利用方針を、発注側で一度言語化します。ここでの目的は仕様の凍結ではなく、ベンダーが同一の仮説で見積れるだけの精度を担保することにあります。APIのレート制限やSLO（Service Level Objective）、セキュリティ制約、データ所在地、監査要件、認証方式といった非機能の曖昧さは、事業者ごとのリスクバッファ差を生み、費用比較のノイズになります。扱うデータの分類やPII（個人を特定可能な情報）の取扱い方針、RBAC（役割に基づくアクセス制御）の粒度まで踏み込むほど、不要な「安全率」は減ります。

もう一つの鍵は、発注側がShould-Cost（あるべきコスト）モデルを先に作ることです。これは「内製した場合の想定コスト」のことです。社内の標準レートカード、過去案件の生産性（ベロシティ）の実績、品質基準に照らして、要件を役割別の工数に割り付け、SaaSやクラウド、テスト環境、ライセンス、トレーニングといった非人件費を含めた概算を用意します。これはベンダーの価格を押し下げるための棒ではなく、見積りの構造を検査するためのルーペです。たとえばバックエンドのCRUD中心な領域で、ジュニア主体のアサインと高い生産性が同時に示されていれば、前提の矛盾を指摘して正します。Should-Costは、過小見積りによるスケジュール遅延やスコープ縮小といった副作用も同時に可視化します。

この段階で、評価軸も先に決めておきます。価格だけでなく、過去実績、技術適合性、体制の弾力性、リスクマネジメントの成熟度、コミュニケーションの透明性、セキュリティ適合性といった重み付けを固定すると、後の交渉が感情的になりません。評価観点は後述のスコアリングに接続しますが、ここでも大切なのは**「コスト」ではなく「価値あたりのコスト」**で評価する姿勢です。

RFPと見積依頼はフォーマットの勝負

見積りの実効性はRFPの設計品質でほぼ決まります。背景と目的、成果物と受入基準、体制像、ガバナンス、マイルストーン、期待する品質基準、開発と運用の責任境界、知財・成果物の帰属、SLA（Service Level Agreement）と罰則、変更管理の流れ、支払条件、検収方法を明記します。そのうえで、見積の粒度と形式を標準化します。役割別の時間単価と時間数、ワークストリーム別の工数、下請けやNearshore/Offshoreの構成比、三者割当のための稼働率、第三者費用、旅費交通費、ツールやライセンス費用、クラウドのランレートなど、費目を横並びにできるよう指定します。固定価格の場合も、内部の想定工数と前提レート、リスクバッファの内訳、想定変更率に対する条件を開示してもらうと、後工程での揃え込みが容易になります。

比較可能性を高めるには、前提に関するQ&Aの透明性が欠かせません。全ベンダーに同一の質問票を配布し、回答は匿名化して全社に共有します。ここで、**Assumptionシート（前提条件の一覧）**を配ります。データ件数、同時接続数、平均レスポンス、リリース頻度、ブランチ戦略、CI/CDの段階数、テスト自動化率、非機能の合格基準、依存する外部APIのSLA、モックの提供可否など、見積に影響する変数を列挙し、数値で固定します。加えて、参照アーキテクチャ、既存コードの抜粋、APIスキーマ、UIワイヤーを共有し、暗黙知を減らします。NDAと情報セキュリティの前提は先にクリアにしておくと、必要な具体が見積りに反映されます。

生産性の仮定を統一する工夫も効果的です。アジャイルを前提とする場合、ストーリーポイントの定義とポイントあたりの時間換算係数、チームの期待ベロシティ、スプリント長、定常化までのランプアップ期間を共通化します。ウォーターフォールならWBSの標準分解と標準比率を共有します。こうした共通物差しがないと、あるベンダーは低レート高工数、別のベンダーは高レート低工数で提示し、価格の差に見えて実は生産性仮定の差を見ているだけ、という事態が起こります。

正規化の技術で「同じ土俵」に並べる

最大の難所は、提出物を**正規化（比較に不要な差分を取り除き、前提をそろえること）**して同じ土俵に乗せる工程です。通貨、消費税、源泉徴収、旅費の扱い、値引きの適用条件、支払サイトによる資金コスト、価格改定条項、為替の想定レートなど、純粋な実行費用以外の要素を一度取り除きます。次に、事業者ごとの生産性や品質基準の差を補正します。たとえばA社が時間単価8,500円で9,800時間、B社が11,000円で7,600時間、C社が固定価格9,500万円と提示したとします。一見A社が安く見えますが、品質基準（テスト自動化率、レビュー密度、欠陥の許容水準など）を合わせると、A社の必要時間が8%増える一方、B社は変わらないといった調整が起こりえます。この補正後に、A社の実効費用は約8,999万円、B社は約8,360万円、C社は変更余地とバッファの取り扱いを確認したうえで約1億300万円と算出され、最初の印象とは異なる並びに変わります。

不確実性の扱いも正規化の一部です。三点見積り（楽観・最頻・悲観）を依頼し、PERT（重み付け平均）で期待値を出すと、価格だけでなくばらつきの小ささも評価できます。P50、P80のような確率付きの総工数を出してもらい、どの水準をコミットにするか合意すると、追加費用の地雷を避けやすくなります。変更要件の発生率は過去プロダクトの実績から推定し、年間のCR（Change Request）予算をTCO（総保有コスト）に含めます。ここで重要なのは、初期構築費だけでなく12〜24カ月のTCOで判断することです。運用監視、SLA対応、当番体制、パフォーマンスの季節変動、容量計画、セキュリティパッチ、脆弱性診断、監査対応まで含めて、事業者間の差を可視化します。運用が弱い提案は初期見積りが安くても、翌年の費用で逆転します。大規模案件では遅延や予算超過が一般的に観察されることも背景にあります。³

生産性の基準化には、ベロシティから費用へ橋を架ける換算表も役立ちます。たとえば、1ポイント=3.5〜5.0時間という帯で内部実績があるなら、全社に4.0時間で固定して算出させます。これに平均レートを掛け合わせれば、ポイント単価が見えます。ポイント単価が近いのに総額が大きく異なる場合は、解釈の揺らぎか、ガバナンスに対する余分な乗数が潜んでいる可能性があります。ストーリーの不確実性が高い領域は、スパイクやPoCのための予備費を独立して積むと、各社の安全率が過剰に膨らむのを防げます。こうして揃え込みを終えると、差は実力と戦略の違いに近づき、交渉の土台が整います。

交渉と意思決定は「価値/コスト」の均衡で決める

交渉では、最安値争いに引き込まれない設計が肝心です。Should-Costを提示してアンカリングし、差分の理由を具体の仮説で議論します。差が工数なら生産性仮定の擦り合わせを、差がレートならアサインのシニア比率やオンサイト比率を、差が第三者費用ならツール選定やSaaSのプランを再構成します。価格を下げる代わりに、スコープの段階化、成果物の共有範囲、知識移転の強化、支払条件の前倒し、ガバナンス頻度の最適化、リードタイム短縮など、価値の総量を維持するトレードを提案します。ここで、委託契約の条項と整合するよう、SLAのペナルティとインセンティブを再設計すると、短期の値引きよりも持続的な費用改善が効きます。複数の外部パートナーを適切に組み合わせるマルチソーシングは、コストとパフォーマンス改善の両面で有効とする報告もあります。⁵

意思決定は、重み付きのスコアリングに落とし込みます。価格の重みを高くしすぎると長期の費用を悪化させますが、低すぎると予算制約を超えます。たとえば価格35、技術適合25、デリバリー能力20、セキュリティ10、コミュニケーション10のように配分し、ワークショップで合意形成します。参考確認として、小規模なペイドPoCを実施し、ベロシティ、品質、コミュニケーション、エスカレーションの反応速度を定量化します。最後に、価格交渉の打ち手として、長期契約割引、リソースのミックス変更、クラウド費の共同最適化、テスト自動化の比率引き上げ、ナレッジ移転の計画明文化など、将来のコストカーブを下げる取り決めを契約に織り込みます。

実務の現場では、反事例から学ぶのが早いものです。あるSaaS連携案件で、A社は低レート高工数、B社は高レート低工数で拮抗しました。正規化後のTCOはほぼ同等でしたが、B社は変更要求の取り込み費用が低く、年間のCRを15%と仮定したときの総額は約6%低くなることが分かりました。さらに、B社はリリース頻度を週次から隔週に変更する代わりに、自動化カバレッジを30%から60%へ上げる提案を提示し、障害対応のオンコールを縮小できる見込みが立ちました。結果として初期費用は据え置き、運用の年間費用を二桁パーセンテージで削減し、総合スコアで最適解となりました。

コストの見える化でチームの合意をつくる

複数見積りは調達の営みであると同時に、組織内の合意形成プロセスでもあります。アーキテクト、セキュリティ、SRE、プロダクト、財務、法務が同じ表を見て議論できるよう、費目を縦軸に、ベンダーを横軸に並べた比較シートを用意します。初期構築、運用、変更、教育、退出時の引き継ぎ費用まで含めたTCOの視点で並べると、議論は自然と中長期の意思決定に向きます。テスト密度や自動化、SLAの水準、監視の深さ、復旧時間の期待値は費用と直結します。費用対効果の表現は、KPIへのインパクト（例：カート放棄率の1%改善が年間いくらの粗利に相当するか）と紐づけると、価格の数値が価値の文脈で理解されます。こうして、**「安い」ではなく「安くて価値が高い」**選択を、チーム全体で説明可能にしていきます。

情報非対称を減らすためのベンチマーク活用

最後に、情報非対称に対する備えとして、外部ベンチマークを活用します。市場のレートレンジ、役割別の稼働率、品質基準とテスト密度の相場、クラウド費の最適化余地、標準的なガバナンスのコストなどを、第三者データと照合します。社内の過去案件とも突き合わせ、Should-Costを定期的に更新します。課題は常に変化します。新しい規制、アーキテクチャの潮流、ツールのライセンス体系の変更、為替の変動は、すべて費用に跳ね返ります。だからこそ、ITコスト・ベンチマークをプロセスに組み込み、見積りの精度と交渉力を継続的に高めていきます。²

まとめ：相見積もりはコスト交渉ではなく設計で勝つ

外注費の適正化は、値札を叩く行為ではなく、前提を設計し、比較を可能にし、価値基準で判断する営みです。RFPの精度、Assumptionの統一、Should-Costの用意、揃え込みの技術、TCOでの意思決定、そして価値を損なわない交渉設計が揃えば、二桁パーセンテージの費用改善とリスク低減は両立できます。次の案件で、まず何から始めますか。要件の曖昧さを一枚のAssumptionシートに落とし、社内の評価軸とShould-Costを半日で叩き台にしてみてください。そこから配るRFPは、ベンダーにとっても、あなたのチームにとっても、公平で生産的な出発点になります。最終的に選ぶのは最安ではなく、価値あたりの費用が最も低い提案です。今日の一歩が、明日の健全なコスト構造と、より速い学習サイクルを連れてきます。

参考文献

McKinsey & Company. Delivering large-scale IT projects on time, on budget, and on value. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
McKinsey & Company. Big procurement footprint: better bidding yields bigger savings. https://www.mckinsey.com/capabilities/operations/our-insights/big-procurement-footprint-better-bidding-yields-bigger-savings
McKinsey & Company. Managing big projects: the lessons of experience. https://www.mckinsey.com/capabilities/operations/our-insights/managing-big-projects-the-lessons-of-experience
会計検査院. 入札制度の研究（競争入札と価格形成に関する記述）。https://www.jbaudit.go.jp/koryu/study/mag/7-4.html
CIO.com. Process improvement: Cutting costs with multiple outsourcers. https://www.cio.com/article/272113/process-improvement-cutting-costs-with-multiple-outsourcers.html