RFPの書き方｜ベンダー選定で失敗する5つの罠と回避策【現場PMの実践】
「納品されたシステムが現場で使われない…」
「想定外の高額見積もりで、予算調整に追われている…」
「キックオフ直後から、ベンダーが完全に『指示待ち』だ…」
プロジェクトの序盤で、このような頭を抱えるような事態に直面したことはありませんか？
実は、こうしたトラブルの多くは、RFP（提案依頼書）が「ただの機能一覧」になってしまっていることに原因があります。この初期段階のズレを放置したまま開発に進むと、フェーズが進むごとに手戻りが雪だるま式に膨れ上がり、リカバリー不能なコスト増やスケジュール遅延といった最悪の事態を招きかねません。
この記事では、厳しい現場のリアルな実態に基づき、ベンダー選定で失敗しないための「RFPに本当に書くべきこと」と、優秀なパートナーを見極める実践的なテクニックを解説します。
【基礎】RFPの書き方｜機能一覧ではなく「成功条件」を定義する
RFP（提案依頼書）とは？
RFP（Request for Proposal：提案依頼書）とは、システム開発においてベンダー（開発会社）に具体的な提案を依頼するための文書であり、プロジェクトの要件・予算・体制・評価基準などを明確にする役割を持ちます。
RFPを作成する際、どうしても「システムで何ができるか」という機能要件の洗い出しにばかり時間をかけてしまいがちです。しかし、RFPはベンダーへの単なる「発注指示書」ではありません。プロジェクトの「成功を約束する契約の前段階」であり、「我々はこういう条件で成功を目指すが、共に戦えるか？」と問うためのドキュメントなのです。
多くの炎上プロジェクトを見てきて痛感するのは、現場のPMがプロジェクト参画後に「これ、発注時に決まっていればこんなに苦労しなかったのに……」と絶望するポイントは、大抵決まっているということです。
機能が足りないことよりも、「目的のブレ」「予算の隠蔽」「体制の不備」「役割分担の曖昧さ」こそが、プロジェクトの命取りになります。だからこそ、RFPは「現場の不満や懸念」から逆算して、あらかじめ防波堤を築いておく必要があるのです。
【実践】ベンダー選定で失敗する5つの罠とRFPでの回避策
RFP段階で防いでおくべき「5つの罠」と、その具体的な回避策を整理しました。
罠①：誰も欲しがっていないシステム（現行踏襲の落とし穴）
「とりあえず現行踏襲で」という言葉の裏で、現場の温度差や業務のサイロ化を放置している状態です。
- 放置した末路： リリース後、現場から「前のほうが使いやすかった」とクレームの嵐。利用率が上がらず、投資対効果がゼロになります。
- RFPでの回避策：【現場のKGI/KPIを明記する】
単なる機能要件ではなく、「誰の・どんな課題を・どう解決したいか」を記載します。さらに、ベンダーに対して「現場を巻き込む施策（チェンジマネジメント）」まで踏み込んだ提案を求めてください。
罠②：予算不明の「お祭り」プロジェクト
予算上限を隠したまま、あるいはざっくりとした要望だけで「とりあえず提案して」と要求する状態です。
- 放置した末路： ベンダーから想定外の高額見積もりが出て、機能の削り合いという不毛な調整に数ヶ月を費やすことになります。
- RFPでの回避策：【予算感（レンジ）を明示する】
予算を隠すメリットはありません。予算の枠組みを伝えた上で、「フェーズ分け（段階的リリース）」による見積もりと、実現までのロードマップ提案を求めましょう。
罠③：箱（体制図）だけ立派なバラバラ組織（発注側の問題）
自社（発注側）の体制図で、情報システム部や各業務部門の名前が綺麗に並んでいるだけで、実際の連携や意思決定のフローが曖昧な状態です。
- 放置した末路： 要件定義の段階で部門間の意見が対立し、誰も決断できずにプロジェクトが停滞します。最悪の場合、ベンダーが板挟みになって疲弊し、開発がストップしてしまいます。
- RFPでの回避策：【自社の意思決定プロセスを明記する】
単に部署名を並べるのではなく、「誰が最終的な意思決定権を持つのか（エスカレーションルート）」をRFPで明確に定義します。その上で、自社の複雑なステークホルダーをどう巻き込み、合意形成を図っていくか、ベンダーのPMに「コミュニケーションプランや会議体の設計」を提案させましょう。
罠④：依存心が生む「丸投げ」
「お金を払うのだから、ベンダーが全部やってくれるはず」という甘い期待を持っている状態です。
- 放置した末路： ベンダーは「要件が提示されないから動けない」と待ちの姿勢になり、プロジェクトが完全に停滞します。
- RFPでの回避策：【発注者側の「役割と責任」を明記する】
「我々（発注者）はデータ準備と業務決定をやる。だから貴社はこれをやってくれ」と、RFPの段階で厳しい役割分担の線を引いておくことが不可欠です。
罠⑤：誰も仕様を知らない「ブラックボックス」のリプレイス
当時の開発ベンダーは撤退し、自社の担当者も退職。現行システムの仕様が完全にブラックボックス化しているのに、「とりあえず今のシステムと同じように作って」と依頼してしまう状態です。
- 放置した末路： 優秀なベンダーほど「得体が知れずリスクが高すぎる」と判断し、超高額なバッファを積んだ見積もりを出すか、コンペを辞退します。無理に進めても、後から隠し仕様が次々と発覚し確実に炎上します。
- RFPでの回避策：【「分からない」と正直に書き、Phase0（調査）を設ける】
RFPで「ドキュメントは古く、現行仕様は我々も完全に把握できていない」と正直に開示してください。その上で、いきなり全機能の開発を依頼するのではなく、「まずは現行システムの調査・リバースエンジニアリング（Phase 0）」を最初のフェーズとして切り出して委託し、その結果を踏まえて本開発のスコープと見積もりを決めるアプローチを提案させましょう。
【面談対策】ベンダーの実力を見抜く逆質問と評価基準
RFPを提示した後のベンダープレゼンにおいて、見るべきは「スライドの綺麗さ」や「営業担当の流暢なトーク」ではありません。本当に重要なのは、「こちらの懸念に対する回答の具体性」と「ベンダーPMの実力」です。
優秀なベンダーを見極めるために、プレゼンや面談の場では以下のような「逆質問」を投げかけてみてください。
- 「今回のRFPの要件の中で、御社が最も『リスクが高い（炎上しやすい）』と考える部分はどこですか？また、その理由はなんですか？」
- 評価基準: ここで「特にリスクはありません」と答えるベンダーは危険です。優秀なベンダーほど、要件の矛盾や曖昧な部分を的確に突いてきます。耳の痛い指摘をしてくれるベンダーこそ、信頼できるパートナーの候補です。
- 「仮に、我々（発注者側）の意思決定が2週間遅れた場合、プロジェクトマネージャーとしてどのようなアクションをとりますか？」
- 評価基準: 「御社の指示を待ちます」ではなく、「遅延の影響範囲を即座に可視化し、代替案を提示した上で、エスカレーションルートを使って意思決定を促します」といった、具体的なリカバリープランや能動的な姿勢を引き出せるかを見ます。
- 「過去に類似のプロジェクトで失敗（または大きなトラブル）を経験したことはありますか？そこから何を学び、今回の提案にどう活かしていますか？」
- 評価基準: 失敗を隠さず、そこから得た教訓を組織のプロセスや今回の体制構築にどう落とし込んでいるかを語れるか。PMの誠実さと経験値が如実に表れます。
ベンダーからの「指摘」を喜べるスタンスを持つことが、良い選定の第一歩です。
【まとめ】RFPは「下請け」ではなく「パートナー」を探すための招待状
数々のプロジェクト現場を経験してきて強く感じるのは、システム開発の成否を分ける最後の砦は、結局のところ「人と人との信頼関係」だということです。 いくら完璧な契約書を結んでも、現場の信頼関係が崩れていればプロジェクトは回りません。
- 機能一覧ではなく「成功条件」を書く
- 役割分担と体制を明確にする
- 面談では「逆質問」で本音を引き出す
RFPは「完璧な仕様書」を目指す必要はありません。現場の不満や懸念を隠さずぶつけ、「我々は本気でこのプロジェクトを成功させたい。単なる作業者（下請け）としてではなく、同じ船に乗るパートナーとして一緒に泥をかぶってくれるか？」と問いかけるための「最高のチームを組むための招待状」として活用してください。
その熱量と覚悟は、必ず優秀なベンダーのPMに伝わり、期待以上の提案を引き出す力になるはずです。
あわせて読みたい： 優秀なパートナーを見つけたら、次は「契約」です。要件定義からリリースまで、プロジェクトを炎上させないための「請負と準委任」のリアルな使い分けについては、以下の記事をご覧ください。 請負と準委任の違いと選び方｜システム開発で炎上しない契約のポイント
