RFP テンプレートの作り方完全ガイド：目的・スコープ定義・評価基準を“比較できる言葉”に落とす

PMや管理職が「提案依頼書（RFP）」を作る場面は、ベンダー選定の入口であると同時に、プロジェクト全体の成否を左右する分岐点でもあります。ところが現場では「とりあえず過去のRFP 雛形を流用」「目的は“DX推進”の一言」「範囲は“既存システムの刷新”」のように、比較の土台が薄いまま進んでしまうことが少なくありません。その結果、見積の前提が各社でズレ、価格差だけが目立ち、契約後にスコープ定義の追加・変更が連鎖して炎上します。

本記事では、実務で使えるRFP テンプレート（提案依頼書 テンプレート）の作り方を、目的・スコープ定義・評価基準（選定基準）を中心に解説します。単なる項目一覧ではなく、「なぜその情報が必要か」「どう書けば比較できるか」「どこで合意を取るか」まで踏み込み、社内調整とベンダー評価を前に進めるための型に落とします。

1. なぜRFP テンプレートの品質が「見積のブレ」と「炎上」を生むのか

RFP テンプレートの役割は、発注側の希望を“仕様書として固定する”ことではありません。選定前に重要なのは、各ベンダーが同じ前提で提案し、同じ物差しで評価できる状態を作ることです。ここが弱いと、各社は自社の得意領域に合わせて前提を置きます。たとえば、A社は移行と運用を含めたスコープで見積もり、B社は開発のみで見積もる。C社は性能要件を高めに想定し、D社は最低限の想定でコストを抑える。すると、価格や工期の差は“実力差”ではなく前提差になります。

このズレを放置すると、契約後に「そこまで含まれていない」「それは追加」「想定外」の応酬が発生し、スコープ追加 → 再見積 → 稟議やり直し → 納期遅延という負の連鎖に入ります。しかも責任が曖昧になりやすく、PMは火消しに追われ、管理職は意思決定の根拠を失います。だからこそ、RFP 雛形は“書類作成”ではなく、意思決定の再現性を作る設計だと捉えるべきです。

実務上は、RFP テンプレートを「比較の設計図」として扱い、目的とスコープ定義を固めたうえで、評価基準（ベンダー評価の物差し）までをセットで提示します。これにより、提案の良し悪しを“価格”だけでなく妥当性・実現性・品質・体制で説明でき、稟議や取締役会でも通しやすくなります。逆に評価基準がないままRFPを出すと、社内の評価者がそれぞれ別の観点で見てしまい、最後は声の大きい人の意見で決まりがちです。

2. まずは章立てを固定する：実務で回るRFP テンプレートの最小構成

RFP テンプレート作成で最初にやるべきは、情報を集めることではなく、章立て（骨格）を先に固定することです。骨格がないまま現場ヒアリングをすると、欲しい情報が散らばり、資料が肥大化し、結局「どこが決定事項で、どこが提案依頼なのか」が曖昧になります。おすすめは、RFP テンプレートを“最小構成”として先に決め、空欄を埋める運用にすることです。

最小構成の例は、(1)背景・目的、(2)現状と課題、(3)スコープ定義（In/Out/前提・制約）、(4)要件（機能/非機能/移行/運用）、(5)成果物と進め方（体制・会議体・マイルストーン）、(6)見積条件（前提・検収・保守）、(7)評価基準（選定基準・配点・足切り・選考プロセス）です。この7点が揃えば、ベンダーは提案を組み立てやすく、発注側は比較しやすくなります。RFP テンプレートの“上手い／下手”は文章力ではなく、比較に必要な情報が揃っているかで決まります。

もう一つのコツは、各章を「確定していること」と「提案してほしいこと」に分けることです。たとえば目的は確定でも、アーキテクチャは提案依頼にする。運用方針は確定でも、運用自動化の実装方法は提案依頼にする。RFP テンプレートに「仮置き（暫定）」「要協議（選定後にSOWで確定）」の表現を許す欄を用意しておくと、未確定事項を隠さず管理でき、後で揉めにくくなります。

3. 目的を明文化する：KPIまで落として「提案の勝負どころ」を作る

目的の章は軽視されがちですが、実はベンダー評価の軸を決める最重要パートです。目的が抽象的だと提案は“機能の羅列”になり、評価基準も“良さそうかどうか”の印象論になります。逆に目的が具体化されていれば、ベンダーは目的達成のための方針・優先順位・リスク対策で勝負でき、発注側も比較できます。

書き方の型は、課題（困りごと）→到達状態（どうなれば成功か）→測定（KPI/判断基準）です。「クラウド移行したい」は手段なので、目的は「障害復旧時間を半減」「月次締めを3日短縮」「問い合わせ一次解決率を◯%に」「運用工数を◯%削減」など、業務成果で表現します。これらはそのまま評価基準に接続できます。提案の妥当性は“目的に効いているか”で見られますし、価格も“目的達成に必要な投資か”として説明できます。

実務で効く書きぶりとして、目的を「必達ゴール」と「加点ゴール」に分ける方法があります。必達は“これを満たさない提案は失格”で、評価基準の足切り条件に直結します。加点は“より良い提案ほど高評価”で、ベンダーの創意工夫を引き出す余地になります。さらに、目的の章に「成功の定義（受入基準の考え方）」を1段落で置くと、後工程の受入テスト設計までスムーズになります。

加えて、制約条件も目的の章に寄せて書くと実務が回ります。期限（法改正や契約更新に合わせる等）、予算感（上限/目安/柔軟性）、対象ユーザー規模、必須のセキュリティ要件、既存資産（残す/捨てるの方針）などです。これらが曖昧だとスコープ定義が膨らみ、評価基準もブレます。稟議では「なぜ今やるのか」「どの成果をいつ出すのか」を問われるため、目的をKPIまで落としておくことが、結局いちばんの近道になります。

4. スコープ定義の作り方：In/Out/前提で“境界線”を見える化する

スコープ定義（範囲定義・要件範囲）はRFP テンプレートの心臓部です。ここが弱いと見積条件が揃わず、評価基準も機能しません。実務ではまずIn Scope（含む）／Out of Scope（含まない）／Assumptions（前提）の3点セットで書きます。ポイントは、曖昧な動詞（対応する、検討する）を避け、名詞で切ることです。「対象部門：営業・カスタマーサポート」「対象拠点：国内3拠点」「対象データ：顧客基本情報・契約情報・問い合わせ履歴」「対象外：人事給与・会計仕訳」「前提：既存ID基盤を継続利用」など、境界線を明確にします。

次に、スコープ定義を作業責任（誰が何を持つか）まで落とします。たとえば移行は「発注側がデータクレンジングを実施」「ベンダーが移行ツールと移行手順を提供」「共同でリハーサルを2回」など、責任分界を明記します。運用も同様に、監視、障害一次対応、夜間対応、問い合わせ窓口、SLA/SLOの考え方を最低限書きます。

非機能（性能、可用性、セキュリティ、監査証跡、バックアップ、ログ保全）は後から“必須”になりやすい領域です。RFP 雛形の段階で、要求水準と確認方法（性能試験、脆弱性診断、監査ログレビュー等）の方向性だけでも明記しておくと、見積が揃います。

さらに、スコープ定義は「何を作るか」だけでなく「どこまで保証するか」も含みます。たとえば可用性99.9%は、インフラ冗長化だけでなく運用体制（監視・復旧手順・オンコール）まで含めて初めて実現します。ここをRFP テンプレートで触れておくと、ベンダーは運用設計を提案に含めやすくなり、後から運用費が跳ねる事故を防げます。

最後に、スコープ定義は“変更されるもの”だと明示し、変更管理のルールを1段落で置きます。「スコープ変更は、影響（費用・納期・品質）を見積更改し、承認後に反映」「変更要求の受付窓口と判断者」「変更の優先順位付け（Must/Should/Couldの見直し）」です。ここまで書けると、ベンダー側も無理な前提で安値を出しにくくなり、結果的にプロジェクトが安定します。

5. 評価基準の設計：配点・足切り・証跡でベンダー評価を再現可能にする

評価基準（選定基準）は、RFP テンプレートにおける意思決定の設計図です。ここが曖昧だと、結局「知名度」「営業の印象」「安さ」で決まってしまい、後から説明できません。おすすめは、評価基準を観点（何を見るか）と証跡（何が出ていれば合格か）に分けることです。観点は、(1)課題理解と提案方針の妥当性、(2)実現性（計画・リスク・技術）、(3)品質（非機能・運用・セキュリティ）、(4)体制とコミュニケーション、(5)価格（TCO）に整理すると、多くの案件で使い回せます。

配点は「価格20：技術・進め方60：体制20」のように、価格だけで決まらない比率にするのが定石です。ただし配点だけでは弱く、足切り条件を入れると運用が安定します。例として「必須セキュリティ要件を満たさない場合は失格」「体制のキーパーソンがアサイン不可なら失格」「SLAの下限を満たさない場合は失格」などです。これにより、安くても危険な提案を早期に落とせます。逆に足切りがないと、評価会議で“安いけど不安”を抱えたまま妥協し、後で大きくコストを払うことになります。

さらに重要なのが証跡です。たとえば「実現性」ならWBSの粒度、リスク一覧と対応策、移行リハーサル計画、品質計画（レビュー/テスト/受入）など、提出物で判断できる形にします。「体制」なら担当者の役割定義、稼働比率、過去実績の類似性、コミュニケーション設計（定例、課題管理、エスカレーション）です。ここまでRFP テンプレートに書けば、ベンダー評価は“会議で揉める”のではなく、基準に照らして採点する作業になります。

価格の評価では、初期費用だけでなくTCO（総保有コスト）を見ます。保守費、クラウド利用料、ライセンス、追加開発単価、運用工数、内製コストを含めた比較のルールをRFP 雛形に書くと、提案の比較がフェアになります。また、見積条件（稼働前提、体制、再委託、検収条件）を揃えないと価格評価が成立しないため、評価基準の章末に「見積の前提が異なる場合は比較対象外／再提出」と明記しておくと実務が安定します。

最後に、評価基準はスコープ定義と必ず整合させます。スコープ定義で「運用まで含む」と書いたなら、評価基準でも運用設計やSLAを評価する。逆に運用をOut of Scopeにしたなら、その分は価格比較や将来拡張の評価に回す。RFP テンプレートの段階でこの整合を取っておくことが、発注側の納得感を作り、選定後の“こんなはずじゃなかった”を減らします。

6. 提案依頼〜選定〜契約前までの進め方：RFP テンプレートを「運用」する手順

良いRFP テンプレートは、文書の出来栄えだけでなく運用手順とセットで機能します。おすすめの進め方は、(1)キックオフで目的とスコープ定義の仮置きを作る、(2)現場ヒアリングでAs-Is/課題/制約を集める、(3)Must/Should/Couldで優先順位をつける、(4)評価基準と提出物（提案書フォーマット）を確定する、(5)質疑応答→提案→プレゼン→採点、という流れです。特に(4)で提案書のフォーマットを軽く指定すると、各社の提案が揃い、ベンダー評価が楽になります。

質疑応答の運用も明文化します。質問受付期間、回答期限、回答は全社に共有、前提が変わる質問はスコープ定義や評価基準の改訂として扱う、といったルールです。これをRFP テンプレートに書いておくと、情報の非対称性が減り、選定プロセスの透明性が上がります。管理職としては「公平性」と「再現性」が担保されるため、社内説明が容易になります。

また、評価会議の進め方も先に決めます。評価者は業務部門・情報システム・セキュリティ・購買（必要なら法務）を最低限含め、採点の観点ごとに責任者を置くと印象論が減ります。採点前に「スコープ定義の理解が一致しているか」を確認し、ズレがある提案は質疑で是正する。これだけでベンダー評価の納得度が大きく上がります。

選定後の注意点として、RFPは契約書そのものではない点を押さえます。選定後は、RFP テンプレートで合意したスコープ定義・成果物・見積条件をもとに、SOW（作業範囲記述書）や個別契約で確定させます。このとき、RFPで曖昧だった仮置き事項を、追加費用や納期影響とセットで確定します。つまりRFP テンプレートは契約前の“比較の土台”であり、契約文書はその土台を拘束力ある合意に変換するものです。ここを混同すると、後から「RFPに書いてあったのに」が火種になります。

まとめ：目的・スコープ定義・評価基準の3点セットで「比較できるRFP テンプレート」にする

RFP テンプレート（提案依頼書 テンプレート）を実務で効かせる鍵は、項目を増やすことではなく、比較できる言葉に落とすことです。目的をKPIまで明文化し、スコープ定義をIn/Out/前提で切り、評価基準（選定基準）を配点・足切り・証跡まで設計する。この3点セットが揃えば、見積の前提が揃い、ベンダー評価が再現可能になり、選定後の追加費用や手戻りを減らせます。

逆に、目的が抽象的で、スコープ定義が曖昧で、評価基準が「総合的に判断」だと、選定は“運”に近づきます。PMの負荷も管理職の説明責任も増えます。RFP 雛形を見直すことは、調達コスト削減だけでなく、プロジェクト成功確率を上げる投資です。まずは、この記事の最小構成をベースに、自社の案件に合わせてRFP テンプレートを一度“比較設計図”として作り直してみてください。