目次
RFP(Request for Proposal/提案依頼書)とは、システムやサービスの発注前に、自社の課題・要件・条件をまとめてベンダーへ提案を依頼する文書です。 読み方は「アールエフピー」。提案の品質はRFPの品質で決まるため、発注側が書く最も重要なドキュメントといえます。この記事では、RFI・見積依頼との違い、構成10項目、作成の進め方、提案が集まる書き方のコツを解説します。
なぜRFPが必要なのか
RFPなしの発注は、「口頭やメールの断片的な要望→ベンダーが推測で見積→導入後に『思っていたものと違う』」という典型的な失敗コースをたどります。システム導入のトラブルの多くは技術力ではなく、発注側の要望が文書として確定していなかったことが原因です。
RFPを書くことには3つの効果があります。
- 提案を比較できるようになる — 全ベンダーが同じ情報を基に提案するため、内容と価格を同じ土俵で比べられます
- 社内の要望が確定する — 書く過程で部門間の要望の食い違いが表面化し、発注前に決着がつきます
- 導入後の「言った・言わない」を防ぐ — RFPと提案書が契約の前提資料になり、検収の基準にもなります
逆に、対象が数万円のツール1本のような小さな買い物なら、RFPは大げさです。複数部門に影響する・年間数百万円以上・複数社を比較したいのいずれかに当てはまるときがRFPの出番です。RFPが購買全体のどの段階に位置するかは、購買プロセスの7ステップで確認できます。
RFI・RFP・見積依頼はどう使い分けるのか
| 文書 | 目的 | 段階 | 送る社数の目安 |
|---|---|---|---|
| RFI(情報提供依頼) | 製品・会社情報の収集 | 情報収集 | 5〜10社 |
| RFP(提案依頼) | 要件への提案と見積を依頼 | 選定 | 3〜5社 |
| 見積依頼(RFQ) | 仕様確定後の価格確認 | 発注直前 | 1〜3社 |
いきなりRFPから始めると、要件が市場の実態とずれたまま選定が進みます。候補が絞れていない段階ではRFIで情報を集め、要件が固まってからRFPを出すのが定石です。RFIの作り方はRFI作成ツールで文書ごと生成できます。
RFPの構成10項目
- プロジェクトの背景・目的 — なぜ今やるのか。目的は「何がどうなったら成功か」まで書く
- 会社・事業の概要 — ベンダーが提案の前提にする情報(規模・拠点・ユーザー数)
- 現状の業務と課題 — 現行システム・業務フロー・困りごと。ここが具体的なほど提案が具体的になります
- 実現したいこと(要件) — 必須要件と希望要件を分けて書く。全部「必須」にすると総額が跳ね上がります
- 対象範囲(スコープ) — 対象業務・部門・データ移行の有無。範囲外も明記する
- 予算 — 上限または幅で提示。非開示は比較不能な提案を招きます
- スケジュール — 稼働希望時期と、あれば背景(法改正・繁忙期など)
- 提案してほしい内容 — 提案書に含めてほしい項目(構成・体制・実績・見積内訳・保守)
- 選定の進め方と評価基準 — 提出期限・プレゼン日程・評価の観点・連絡窓口
- 契約条件・特記事項 — 秘密保持・検収条件・再委託の扱いなど
書き出しの例文(背景・目的と課題)
RFPで最も筆が止まるのは冒頭の「背景・目的」です。書き方の型は**「現状→困りごと→目指す状態」の3文**です。
1. プロジェクトの背景・目的
当社は従業員100名の専門商社であり、顧客情報・商談履歴を
各営業担当者が個別のExcelで管理している。
このため、担当者の異動・退職時の引き継ぎに平均2週間を要し、
直近1年では引き継ぎ漏れによる失注も発生している。
本プロジェクトでは顧客情報を一元管理する仕組みを導入し、
「担当者が替わっても営業活動が止まらない状態」の実現を目的とする。
2. 現状の課題
・商談情報が属人化しており、上長が案件状況を把握できない
・報告資料の作成に営業1人あたり月3時間かかっている
・過去の提案・見積の再利用ができず、同じ資料を作り直している
数値(100名・2週間・月3時間)が入っているほど、ベンダーは効果試算まで踏み込んだ提案を書けます。この先の10項目をすべて埋めた記入例つきWordテンプレートを無料配布しています(登録不要): RFP(提案依頼書)テンプレート(Word)
RFP作成の進め方5ステップ
- 課題の棚卸し(1〜2週間) — 現場部門にヒアリングし、困りごとを業務の言葉で集めます。この段階の粒度が最終的な提案品質を決めます
- RFIで情報収集(必要なら) — 製品の相場観がないまま要件を書くと市場とずれます。候補が絞れていなければRFIを5〜10社に送り、機能・価格帯の実態を掴みます
- 要件の優先順位づけ — 集めた要望を必須/希望に仕分けます。関係部門との合意はこの段階で取り切ります(RFP配布後の変更はマナー違反)
- RFP作成・社内承認 — 構成10項目に沿って文書化し、決裁を通します。予算の根拠づくりには投資対効果(ROI)計算ツールが使えます(稟議書の書き方も参照)
- 配布・質疑応答・提案受領 — 3〜5社に同時配布し、質問への回答は全社に共有します。提案準備期間は2週間以上を確保します
提案品質を上げる3つのコツ
- 提案準備期間を2週間以上取る — RFP受領から提出まで2週間を切ると、ベンダーは既存資料の流用で返すしかなく、提案は薄くなります。良い提案が欲しければ準備期間で誠意を示します
- 課題は業務の言葉で書く — 「DXを推進したい」ではなく「受注入力が二重作業で月40時間かかっている」。ベンダーは課題の具体性に比例して具体的な解決策を書けます
- 評価基準を先に決めて公開する — 価格・機能適合・実績・体制の配点を決めておくと、社内の意思決定も速くなり、ベンダーも重点を絞れます。選定後の導入計画はWBSの作り方へ。WBS作成ツールを使えば、テンプレートから導入工程表をその場で作れます
よくある失敗
- 要件を「ベンダーに考えてもらう」 — RFPは丸投げの道具ではありません。課題と目的は発注側にしか書けず、ここが空のRFPには一般論しか返ってきません
- 全要件を必須にする — 優先順位がないと、価格も提案もコントロールできません。必須/希望の2段階が最低ラインです
- 予算・評価基準の非開示 — 情報を隠すほど提案の精度は下がります。選定の公平性は「同じ情報を全社に渡す」ことで担保します
- RFPを出してから要件を変え続ける — 途中変更は全ベンダーへ同時に通知し、提出期限も延ばすのがマナーです
対象がCRM/SFAならCRM/SFAの選び方、MAツールならMAツールの導入で製品選定の観点を確認してから要件に落とすと精度が上がります。まずはRFP作成ツールでたたき台を生成し、自社の課題を上書きするところから始めてください。
よくある質問
RFPとは何ですか?
Request for Proposal(提案依頼書)の略で、システムやサービスの発注前に、自社の課題・要件・条件をまとめてベンダーに提案を依頼する文書です。RFPの品質がそのまま提案の品質になるため、発注側の最重要ドキュメントといえます。
RFPとRFIの違いは何ですか?
RFI(情報提供依頼)は製品情報を広く集める情報収集の段階、RFP(提案依頼)は要件を示して具体的な提案と見積を求める選定の段階で使います。順序はRFI(5〜10社)→RFP(3〜5社)が一般的です。
RFPに予算は書くべきですか?
書くことを推奨します。予算感がないとベンダーは提案の規模を決められず、桁違いの提案が集まって比較になりません。金額を確定額で書きたくない場合は「予算上限◯円」「◯円〜◯円の範囲」のような幅での提示が実務的です。
RFPは誰が書くものですか?
発注側(ユーザー企業)の担当部門が書きます。システム部門だけでなく、実際に業務を行う現場部門の課題を反映することが重要です。ベンダーに下書きを依頼する方法もありますが、課題と目的だけは発注側にしか書けないため、丸投げすると提案は一般論になります。