プロジェクトの炎上原因を遡っていくと、驚くほど多くのケースで「契約を結んだ時点で、すでに炎上が決まっていた」ことに気づく。

要件が固まっていないのに一括請負で発注した。曖昧なRFPを出したので、各社の提案がバラバラで比較できなかった。最安値のベンダーを選んだら、追加費用で結局一番高くついた。仕様変更のたびに価格交渉が発生し、関係が悪化していった。

これらは現場のPMの努力ではどうにもならない。契約と調達の設計ミスは、プロジェクトの構造そのものに埋め込まれるからだ。本稿では、契約・調達・ベンダー選定の5つの論点を、行動経済学・認知科学・成功する発注者の実践知・AI活用の4軸で解体する。

※本稿は契約形態の考え方を実務の観点から整理したものです。個別の契約条項の法的な有効性や解釈については、必ず弁護士・法務部門にご確認ください。

---

論点① 契約形態の使い分け――「不確実性の高さ」で選ぶ

なぜ誤った契約が炎上を作るのか：「リスクの押し付け合い」

契約形態の本質は、「不確実性のリスクを、誰がどれだけ負担するか」の取り決めだ。請負契約は「完成」を約束するため、ベンダーがリスクを負う。準委任契約は「業務の遂行」を約束するため、発注者がリスクを負う。成果報酬型は、リスクと利益を両者で分け合う。

問題は、要件が固まっていないプロジェクトを請負で発注するケースだ。発注者は「完成責任を相手に負わせられるから安全だ」と考える。しかしベンダーは、不確実性を価格に上乗せするか、仕様を最小限に解釈して自己防衛する。結果、発注者は高い価格を払うか、「仕様に書いていない」という理由で欲しいものが手に入らないかのどちらかになる。

行動経済学的には、これは「リスクの移転の錯覚」だ。リスクは契約書で相手に移したつもりでも、実際には価格・品質・関係性の悪化という形で必ず発注者に戻ってくる。

具体的な実践策

【「要件確定度」を発注前に自己評価する】
発注前に、次の3問に答える。①画面・機能の一覧を今すぐ書き出せるか ②プロジェクト中に仕様が変わる可能性は30%以下か ③類似案件の実績が社内にあるか。3つともYesなら請負、1つでもNoなら準委任かフェーズ分割を検討する。「請負にしておけば安心」という直感を、この3問で検証する。

【フェーズ分割で「確定してから約束する」】
要件が固まっていない案件は、要件定義フェーズを準委任で先行発注し、その成果物（要件定義書）をもとに開発フェーズを請負で見積もり直す。これにより、ベンダーは不確実性への上乗せをせずに済み、発注者は根拠のある価格で開発を発注できる。不確実性を「分解して段階的に確定させる」設計だ。

【AIによる「契約形態の適合性チェック」】
プロジェクトの概要・要件の現状・変更の見込みをAIに入力し、「このプロジェクトの不確実性の高さを評価し、請負・準委任・フェーズ分割のうちどれが適しているか、理由とリスクとともに提案してください」とプロンプトを投げる。慣習で決めていた契約形態を、プロジェクト特性に基づいて見直すきっかけになる。

---

論点② RFPの書き方が結果を決める――曖昧な依頼は曖昧な提案しか呼ばない

なぜRFPの質が提案の質を決めるのか：「解釈の自由度」

RFP（Request for Proposal：提案依頼書）は、ベンダーに「何を作ってほしいか」を伝える文書だ。しかし多くのRFPは、「何を作るか」は書いてあっても「なぜ作るか」「何を達成したいか」が書かれていない。

曖昧なRFPを受け取ったベンダーは、解釈の自由度が高い分、それぞれの得意分野や過去の類似案件に引き寄せて提案を作る。認知科学の「アンカリング」が各社で別々に働く。結果、提案書は5社5様の方向を向き、比較することすらできない。発注者は「どれも微妙に違う」と感じながら、価格で選ぶしかなくなる。

具体的な実践策

【「機能」ではなく「課題と成功の定義」を書く】
RFPの中心を機能一覧から「解決したい課題」と「成功の数値目標」に移す。「顧客管理システムがほしい」ではなく、「営業担当者が顧客情報を探すのに1件あたり平均8分かかっており、これを1分以内にしたい」と書く。課題を渡せば、ベンダーは解決策の提案で競い合う。機能を渡せば、価格でしか競えない。

【予算レンジを開示する】
「予算を開示すると足元を見られる」という懸念から非公開にする発注者は多い。しかし非公開にすると、1,000万円の想定に対して300万円の簡素な提案と3,000万円の過剰な提案が混在し、比較不能になる。「500万〜800万円程度を想定」とレンジで開示することで、各社が同じ規模感で最善の提案を作れる。

【評価基準と配点を事前に公開する】
「提案内容40点・実績20点・体制20点・価格20点」のように評価基準を公開する。ベンダーは何に力を入れるべきかが分かり、発注者は選定理由を説明可能になる。評価基準を後から決めると、無意識に「好印象だった会社」に合わせた基準を作ってしまう（後付け合理化）。

【AIによる「RFPの曖昧さチェック」】
作成したRFPをAIに入力し、「あなたは提案を検討しているベンダーです。このRFPを読んで、解釈が分かれる箇所・前提条件が不明で見積もりに困る箇所・質問したい点を列挙してください」とプロンプトを投げる。ベンダーから質疑で返ってくる前に、RFPの穴を塞げる。

---

論点③ ベンダー選定の「安さの罠」――最安値が最高コストになる理由

なぜ安さに引き寄せられるのか：「目に見える価格」と「見えないコスト」

提案価格は明確な数字で比較できる。一方、品質・保守性・コミュニケーションコスト・追加費用のリスクは、比較が難しい。行動経済学の「顕著性バイアス」により、人間は比較しやすい数字（価格）に判断を強く引っ張られる。

しかし、最安値の提案には理由がある。工数を低く見積もっている、経験の浅い人員を配置している、テストやドキュメントを最小限にしている、そして「後から追加費用で回収する」前提で入札しているケースだ。契約後に「それは見積もりの範囲外です」という追加請求が続き、最終的な総額は最も高くなる。

具体的な実践策

【「総保有コスト（TCO）」で比較する】
提案を比較するとき、初期費用だけでなく5年間の総保有コストを各社に提示させる。項目は、初期開発費・想定される追加費用の目安・年間保守費・インフラ費・想定障害対応費。この比較表を作るだけで、「安いが後で高くつく」提案が可視化される。

【「なぜ安いのか」を必ず質問する】
他社より大幅に安い提案には、「他社と比べて安価な理由を教えてください」と直接質問する。正当な理由（自社製品の流用・効率的な開発手法）があれば明確に答えられる。曖昧な回答しか返ってこない場合、工数の過小見積もりか後からの追加請求を前提にしている可能性が高い。

【過去の発注者にリファレンスを取る】
候補ベンダーに、過去の類似案件の発注者を紹介してもらい、「当初見積もりに対して最終的な総額はどうだったか」「追加費用はどれくらい発生したか」を聞く。提案書の自己申告よりも、実際の取引実績のほうが遥かに信頼できる情報だ。

---

論点④ 相見積もりの「比較不能」問題――同じ土俵を作る方法

なぜ比較できないのか：「前提条件のバラつき」

3社から見積もりを取った。A社800万円、B社1,200万円、C社1,500万円。一見するとA社が最も安い。しかし中身を見ると、A社はテスト工程を含まず、B社はデータ移行を含まず、C社は初年度保守まで含んでいる。それぞれが違うものの価格を出しているのだ。

この状態で金額を比較するのは、りんごとみかんとメロンの値段を並べて「りんごが安い」と言うのと同じだ。しかし人間は、並んで提示された数字を自動的に比較してしまう（並置比較のバイアス）。前提の違いを意識的に確認しない限り、見かけの価格差に判断が引っ張られる。

具体的な実践策

【「見積もりフォーマット」を発注者が指定する】
各社の自由形式で見積もりを出させるのをやめ、発注者側で工程別・項目別の見積もりフォーマット（Excel）を用意して配布する。行は「要件定義・設計・開発・テスト・移行・研修・保守」、列は「工数・単価・金額・前提条件」。全社が同じ表を埋めることで、自動的に比較可能になる。

【「含まない項目」を明示させる】
見積もりに「含まれるもの」だけでなく、「含まれないもの（範囲外）」を明記させるルールにする。後で「それは範囲外です」と言われるトラブルの大半は、この項目が曖昧なことから生まれる。範囲外の明示は、契約後の追加請求を予防する最も効果的な方法だ。

【AIによる「見積もりの前提条件の差分抽出」】
各社の見積書と提案書をAIに入力し、「これらの見積もりについて、含まれている工程・含まれていない工程・前提条件の違いを表形式で整理してください。同じ範囲に揃えた場合の概算比較も試算してください」とプロンプトを投げる。人間が見落としがちな前提条件の差（「データ移行は発注者側で実施」など細かな記載）を、AIが網羅的に拾い上げる。

---

論点⑤ 契約書に書くべき「変更の値段」――交渉を毎回しない設計

なぜ変更交渉が関係を壊すのか：「毎回の交渉コスト」と「公正さの感覚」

プロジェクト中の仕様変更は避けられない。問題は、変更のたびに「いくらかかるか」をゼロから交渉する運用だ。発注者は「この程度の変更で費用がかかるのか」と不満を持ち、受注者は「無償でやらされる」と不満を持つ。毎回の交渉が、少しずつ信頼を削っていく。

行動経済学の「公正さの感覚（Fairness）」の研究によれば、人間は金額の大小そのものより、「決め方が公正かどうか」に強く反応する。事後に一方が提示した金額は、たとえ妥当でも「足元を見られた」と感じやすい。一方、事前に合意したルールに基づく金額は、同じ額でも受け入れられやすい。

具体的な実践策

【「変更枠（チェンジバジェット）」を契約に組み込む】
契約金額とは別に、「月〇時間までの軽微な変更は追加費用なし」という変更枠を設ける。発注者は細かな修正を気兼ねなく依頼でき、受注者は枠を超えた分から正当に請求できる。毎回の小さな交渉が消え、関係性のストレスが大きく下がる。

【工数単価を契約時に合意する】
中規模の変更に対して、「1人時あたり〇円」という単価を契約時に合意しておく。変更が発生したら、見積もり工数×単価で自動的に金額が決まる。議論は「金額が妥当か」ではなく「工数見積もりが妥当か」に絞られ、はるかに建設的になる。

【AIによる「変更要求の規模判定と影響分析」】
変更要求が来たら、その内容と現在の設計情報をAIに入力し、「この変更要求の規模（軽微・中規模・大規模）を判定し、影響を受ける範囲と想定工数の目安を分析してください」とプロンプトを投げる。規模判定の初期見立てを素早く出せるため、「どの承認ルートに乗せるか」の判断が速くなり、変更管理のリードタイムが短縮される。

---

5つの論点に共通する原則――「契約」は関係性の設計図である

契約形態の選択、RFPの設計、安さの罠、見積もりの比較、変更の値段。5つの論点に共通するのは、契約と調達は「法務の手続き」ではなく「プロジェクトの構造設計」だという点だ。

不確実性が高いのに請負で発注すれば、リスクの押し付け合いが構造化される。曖昧なRFPは、比較不能な提案を構造的に生む。安さだけで選べば、追加費用の発生が構造的に約束される。前提の揃わない見積もりは、誤った選定を構造的に誘発する。変更の値段が決まっていなければ、毎回の交渉が関係を構造的に壊す。

成功する発注者は、契約を「相手を縛る道具」ではなく「両者が同じ方向を向くための設計図」として扱う。不確実性を正直に認め、リスクを合理的に分担し、変更のルールを事前に決める。これは相手への譲歩ではなく、自社の総コストとプロジェクトの成功確率を最大化する合理的な選択だ。

AIは、この設計を支える強力な道具になる。契約形態の適合性評価、RFPの曖昧さ検出、見積もりの前提条件の差分抽出、変更要求の規模判定。これまで調達の専門家や経験豊富な発注担当者に依存していた判断の質を、AIとの協働で底上げできる。

---

まとめ：契約・調達・ベンダー選定の5つの論点

論点	根本原因（認知メカニズム）	今日から始める打ち手	AIの活用法
⑥契約形態	リスクの移転の錯覚	要件確定度の3問チェック＋フェーズ分割	不確実性を評価し契約形態を提案
⑦RFPの設計	解釈の自由度・各社別のアンカリング	課題と成功定義を書く＋予算レンジと評価基準を開示	ベンダー視点で曖昧な箇所を指摘
⑧安さの罠	顕著性バイアス（価格への過剰注目）	5年TCOで比較＋「なぜ安いか」を質問	総保有コストの比較表を作成
⑨見積もりの比較	並置比較のバイアス	見積もりフォーマットの指定＋範囲外の明示	前提条件の差分を網羅的に抽出
⑩変更の値段	公正さの感覚・毎回の交渉コスト	変更枠の設定＋工数単価の事前合意	変更要求の規模判定と影響分析

今日から一つだけ始めるとすれば、次に見積もりを依頼するとき、発注者側で見積もりフォーマットを作って配布することを勧める。Excelの表を1枚作るだけで、各社の見積もりは自動的に比較可能になり、「最安値の罠」の多くを回避できる。調達の質は、交渉力ではなく、比較の土俵をどう設計するかで決まる。