RFPとは？提案依頼書の書き方・テンプレートと営業担当者の対応ガイド【2026年版】
RFPとは？提案依頼書の書き方・テンプレートと営業担当者の対応ガイド【2026年版】
RFP（Request for Proposal：提案依頼書）とは、発注企業がベンダーに対して自社の課題・要件・条件・評価基準を明示し、正式な提案書の提出を依頼する文書である。
この記事の要点
- RFPは発注側と受注側の「共通言語」——要件・評価基準を文書化することで認識のズレを防ぎ、公正なベンダー選定を実現する
- RFI→RFP→RFQの順で候補を絞り込む。 それぞれ目的と発行タイミングが異なるため使い分けが重要
- 受注側（営業担当者）にとってもRFPは戦略的な文書。 Bid/No-Bid判断と提案書の差別化が勝率を左右する
- 失敗パターンを事前に把握し、評価マトリクスで属人的判断を排除する
- **DSR（デジタルセールスルーム）**でRFP関連資料の一元管理・閲覧分析・Q&A管理を効率化できる
「RFPを出したいが何を書けばいいかわからない」「RFPを受け取ったが対応の優先度をどう判断すればいいか」——B2B営業の現場ではこうした声が絶えません。
多くの解説記事は発注側の視点に偏っていますが、受注側の営業担当者にとってもRFPは案件の勝敗を分ける重要な起点です。
本記事では、発注側の書き方・テンプレート・失敗パターンに加え、受注側（営業担当者）の対応フローまで、実務レベルで網羅的に解説します。
RFPとは？提案依頼書の定義・目的・活用場面
RFP（Request for Proposal）の定義
RFP（Request for Proposal）とは、発注企業がベンダーや提案企業に対して、自社の課題・要件・条件を提示し、正式な提案書の提出を依頼する文書です。日本語では「提案依頼書」と訳されます。
RFPは単なる仕様書や発注書ではありません。「こういう課題を抱えている。どのようなアプローチで、どの程度のコストで解決できるか提案してほしい」という発注側の意思表示であり、公正な比較評価と最適なベンダー選定を実現するための戦略的文書です。
RFPの目的 — なぜ提案依頼書が必要なのか
RFPが必要とされる根本的な理由は、ベンダー選定における情報の非対称性を解消するためです。
RFPがない状態では、発注側の要望が口頭やメールで断片的に伝わるだけで、ベンダーは提案の方向性を見誤ります。結果として「提案のピントがずれた」「見積の粒度がバラバラで比較できない」というトラブルが発生します。RFPを作成することで、以下の効果が得られます。
- 社内の認識統一：課題・要件を整理する過程で関係者の合意形成が進む
- 公平な比較基盤：複数ベンダーに同一情報を提供し、評価の土台を揃える
- 属人的判断の排除：評価基準を事前に設計することで透明性のある選定を実現
- スコープクリープの防止：目的・範囲を文書化し、後工程での範囲膨張を防ぐ
RFPが使われる場面・業界
RFPが特に有効なのは、金額規模が大きく複数ベンダーの比較が必要な案件です。
- システム導入・刷新：基幹システム、SaaS導入、DXプロジェクト
- 大型コンサルティング案件：経営戦略、業務改善、組織変革
- マーケティング施策の委託：広告運用、PR、コンテンツ制作
- Webサイト制作・リニューアル：コーポレートサイト、ECサイト
Gartnerの調査によると、B2B購買の意思決定に関わるステークホルダーは平均6〜10人に上り、複数部門にまたがる5つ以上のビジネス機能から構成されます（Gartner, The B2B Buying Journey）。このような複雑な意思決定構造の中で、RFPは関係者間の評価基準を統一するための不可欠なツールです。
RFI・RFQ・RFPの違い【比較表付き】
RFI（情報提供依頼書）とは
RFI（Request for Information）は、市場調査とベンダーの能力把握を目的とした文書です。要件が固まる前の情報収集段階で発行し、候補ベンダーを10〜15社程度に広く募ります。
RFQ（見積依頼書）とは
RFQ（Request for Quotation）は、仕様が確定した段階で価格・納期を比較するための文書です。RFPで提案内容を評価した後、最終候補1〜3社に発行するのが一般的です。
RFI → RFP → RFQ の活用フローと判断基準
| 文書 | 正式名称 | 目的 | 対象社数 | 発行タイミング |
|---|---|---|---|---|
| RFI | Request for Information | 市場調査・ベンダー能力の把握 | 10〜15社 | 要件定義前の情報収集段階 |
| RFP | Request for Proposal | 具体的な提案内容と概算費用の比較 | 3〜5社 | 要件が固まった選定段階 |
| RFQ | Request for Quotation | 確定仕様に基づく価格・納期の比較 | 1〜3社 | 仕様確定後の最終段階 |
判断基準：どの文書を使うべきか
- 要件が曖昧で市場の選択肢を把握したい → RFIから開始
- 課題と要件が明確で、複数社の提案を比較したい → RFPを発行
- 仕様が確定しており、価格と納期だけを比較したい → RFQで十分
3文書すべてを使う必要はありません。要件の確度に応じて「RFI→RFP→RFQ」のどこから始めるかを判断しましょう。小規模案件や仕様が確定している場合はRFQのみで進めるケースもあります。
RFPを作成する5つのメリット
1. 要件を正確にベンダーへ伝えられる
RFPで要件を文書化することで、口頭では伝えきれない詳細な条件や背景情報をベンダーに正確に伝えられます。「言った・言わない」のトラブルを未然に防ぎ、提案の精度が大幅に向上します。
2. 複数社の提案を公平に比較できる
同一のRFPに基づく提案は、フォーマットや回答範囲が揃うため、横並びで比較しやすくなります。Responsive社の2024年調査によると、B2B購買者の81%がベンダーのRFP回答が意思決定に「非常に大きい」または「極めて大きい」影響を与えると回答しています（Responsive, RFP Research 2024）。
3. プロジェクトのトラブルを未然に防げる
要件・スコープ・予算・スケジュールが文書化されることで、プロジェクト開始後の「聞いていなかった」「想定外だった」という認識の齟齬を大幅に減らせます。RFPはプロジェクト契約の基礎資料としても機能します。
4. 自社の課題と要件を客観的に整理できる
RFP作成は、自社の現状課題を言語化し、理想像とのギャップを明確にするプロセスでもあります。このプロセスを通じて「そもそも何を解決したいのか」が組織内で共有され、プロジェクトの方向性が定まります。
5. 社内合意形成のツールになる
Gartnerが2024年に632名のB2B購買者を対象に実施した調査では、購買グループ内で合意形成できたチームは高品質な取引を達成する確率が2.5倍という結果が出ています（Gartner, 2025）。RFPは複数部門の関係者が「何を評価し、何を優先するか」を事前に議論するきっかけになり、選定後の社内反対を防ぐ役割を果たします。
RFPの構成要素と記載項目【テンプレート付き】
RFPに含めるべき7つの構成要素を、記載例とNG例を交えて解説します。案件規模や業種に応じて取捨選択してください。
1. プロジェクト概要（背景・目的・ゴール）
プロジェクトの「Why（なぜ）」を明確にするセクションです。
【良い例】
目的：受注管理のリアルタイム化により、営業部門の週次報告作成工数を80%削減し、
データに基づく迅速な経営判断を可能にする。
【NG例】
目的：受注管理システムの導入。
→ 「なぜ導入するのか」が不明で、ベンダーは提案の方向性を判断できない。
2. 現状の課題と理想像（As Is / To Be）
「現状→理想→ギャップ」のフレームで記載すると、ベンダーが課題の本質を理解しやすくなります。
【現状（As Is）】
受注管理をExcelで行っており、週次更新に担当者が3時間かけている。
データの属人化が進み、担当者不在時に最新情報を確認できない。
【理想（To Be）】
リアルタイムで受注状況が全社から閲覧でき、営業全員が最新データにアクセスできる。
【ギャップ】
リアルタイム更新の仕組みがなく、データの鮮度・アクセス性に課題がある。
3. 機能要件・非機能要件
要件はMust（必須）/ Want（推奨）/ Nice to Have（任意） の3段階で優先順位を明示します。
| 分類 | 意味 | 記載例 |
|---|---|---|
| Must（必須） | 未対応なら選定対象外 | 「受注データのリアルタイム更新ができること（必須）」 |
| Want（推奨） | 対応すれば加点 | 「モバイルからの閲覧に対応していることが望ましい」 |
| Nice to Have（任意） | 提案があれば評価 | 「AIによる受注予測機能への対応も検討可」 |
非機能要件（レスポンスタイム、稼働率、セキュリティ基準など）も数値で定義しましょう。「高速」「安定」といった曖昧な表現は避け、「ページ表示3秒以内」「稼働率99.9%以上」と具体化します。
4. 予算・スケジュール・体制
予算はレンジ表記でも構いません。予算を完全に非開示にすると、ベンダーが規模感を見誤り、要件に見合わない提案が集まるリスクがあります。
- 費用の記載形式：初期費用／月額費用／保守費用を分離して記載を依頼
- スケジュール：RFP提出期限・Q&A回答期日・選定完了予定日・プロジェクト開始日を逆算で設計
- 体制：発注側のプロジェクトオーナー・PM・各部門代表を明記
5. 提案依頼事項（提案書に含めてほしい内容）
提案書の提出形式、必須記載事項、ページ数の目安、提出期限と提出先を明示します。フォーマットを指定することで、比較の手間を大幅に減らせます。
6. 評価基準と選考プロセス
RFPで最も重要なのが評価基準の明示です。配点（ウェイト）を事前に設計し、RFP内で公開することを推奨します。
【ベンダー評価マトリクスの例】
┌────────────────────┬──────┬───────────────────────────────┐
│ 評価項目 │ 配点 │ 評価の観点 │
├──────────────────┼──────┼─────────────────────────────┤
│ 技術力・実現性 │ 30点 │ 要件充足度、アーキテクチャ妥当性 │
│ 費用 │ 25点 │ 初期・運用費用の合理性 │
│ 実績・信頼性 │ 20点 │ 同種案件の実績数、顧客満足度 │
│ 推進体制 │ 15点 │ PM体制、担当者の経験 │
│ 提案の独自性 │ 10点 │ 課題解決の創意工夫、付加価値 │
├──────────────────┼──────┼─────────────────────────────┤
│ 合計 │ 100点 │ │
└──────────────────┴──────┴─────────────────────────────┘
選考プロセス（書類評価→プレゼン→デモ→最終選定）と結果通知方法も記載しましょう。
7. 制約条件・前提条件
既存システムとの連携要件、セキュリティ基準、社内規定による制約（特定クラウドの利用不可など）、NDAの要否を明記します。制約条件を事前に共有することで、対応不可能なベンダーの工数を無駄にしません。
RFP作成の手順【7ステップで解説】
Step 1. プロジェクトの目的と背景を整理する
「なぜこのプロジェクトが必要か」を経営課題と紐づけて言語化します。前述の「現状→理想→ギャップ」フレームで整理すると、関係者間の認識が揃いやすくなります。
Step 2. 関係部署へのヒアリングで現状課題を洗い出す
情シス単独ではなく、事業部門・経営層・現場担当者を含むプロジェクトチームを結成します。各部署の課題・要望を構造化して整理し、優先順位を付けましょう。
ステークホルダーマップの活用がポイントです。「誰が決裁するか」「誰が実際に使うか」「誰が予算を持つか」を整理し、キーパーソンの要望を漏れなく反映します。BANTフレームワークの考え方は、関係者の予算・決裁権を把握する際にも応用できます。
Step 3. 要件を定義する（Must / Want / Nice to Have）
ヒアリング結果を基に、要件を3段階に分類します。すべてをMustにすると対応できるベンダーが激減し、見積金額が膨れ上がります。本当に譲れない要件だけをMustにする勇気が重要です。
Step 4. RFIで市場調査・候補ベンダーを絞り込む
要件が広範な場合は、まずRFIで10〜15社から情報を収集し、対応可能なベンダーを3〜5社に絞り込んでからRFPを発行します。すでに候補が明確な場合はこのステップを省略できます。
Step 5. RFP文書を作成する
前述の7つの構成要素に沿って作成します。業務担当者・IT部門・法務部門・経営層のレビューと承認を得ましょう。特に「予算の開示範囲」と「評価基準の配点」は社内で合意しておく必要があります。
Step 6. ベンダーへ配布し、質疑応答期間を設ける
RFPの配布は**クローズド（招待制）**が一般的です。配布から提出期限までは最低2〜3週間を確保します。
Q&Aのベストプラクティス：質問を一定期間に一括収集し、全ベンダーへ同時にQ&Aとして共有します。個別回答は情報格差を生むため避けましょう。
Step 7. 提案書を評価マトリクスでスコアリングする
Step 6で設計した評価基準に基づき、各提案にスコアを付けます。評価者は複数人で行い、個人の主観を平均化することで公正性を担保します。
スコアリングの進め方：
- 各評価者が独立してスコアを付ける（事前にすり合わせない）
- スコアを集計し、大きく乖離した項目を議論する
- プレゼン・デモで追加評価し、最終スコアを確定する
- 上位1〜3社にRFQを発行し、詳細見積を取得する
RFP作成でよくある失敗5パターンと対策
RFP作成の失敗は、プロジェクト全体のコスト超過やスケジュール遅延に直結します。競合上位記事では失敗パターンの具体的な解説が不足しているため、Before/After形式で対策を示します。
1. 機能の羅列に終始し「なぜ必要か」が不在
Before：「ダッシュボード機能を有すること」「レポート出力ができること」「API連携が可能であること」と機能だけを列挙。
After：「営業マネージャーが週次会議で受注状況を即座に確認できるよう、リアルタイムダッシュボードを提供すること。現状は週3時間かけてExcelを集計しており、この工数を80%削減したい」と課題と目的をセットで記載。
ベンダーは「なぜ必要か」がわかれば、機能だけでなく課題解決のアプローチを提案できます。
2. 予算を非開示にして非現実的な提案が集まる
Before：予算を一切記載しない。結果として「100万円の案件に5,000万円の提案」が届き、時間を浪費する。
After：「予算の目安は初期費用500〜1,000万円、月額運用費50万円以内」とレンジで記載。完全な非開示よりも、ベンダーが規模感を把握でき、現実的な提案が集まります。
予算を開示することで「安く見積もられるのでは」と懸念する声もありますが、予算レンジの提示は提案精度を高める効果の方が大きいのが実情です。
3. 評価基準が不明確で選定が恣意的になる
Before：「総合的に判断します」とだけ記載。選定後にベンダーから「何で落とされたのかわからない」と不信感を持たれる。
After：評価マトリクス（技術力30点・費用25点・実績20点・体制15点・独自性10点）を事前に公開。ベンダーは配点が高い項目に注力でき、発注側も一貫性のある評価ができます。
4. 情シス単独で作成し現場ニーズが反映されない
Before：IT部門だけでRFPを作成。導入後に営業部門から「使いにくい」「必要な機能がない」と不満が噴出。
After：プロジェクトチームに事業部門・経営層・現場代表を含め、各部門のヒアリング結果をRFPに反映。特に「実際に毎日使う人」の声を要件に組み込むことで、導入後の定着率が大きく変わります。
5. RFP提出後に要件を追加してしまう
Before：提案書提出後に「やっぱりこの機能も必要」と追加要件を出す。ベンダーは再見積が必要になり、スケジュールが崩壊。
After：要件フリーズのタイミングを事前に設計します。「RFP配布日をもって要件を確定とし、以降の変更はRFP改訂として全ベンダーに同時通知する」とルール化しましょう。Q&A期間中に出てきた新たなニーズは「次フェーズ要件」として切り分けます。
【営業担当者向け】RFPを受け取ったらやるべきこと
ここからは受注側（営業担当者）の視点でRFPへの対応方法を解説します。多くのRFP解説記事は発注側向けですが、営業担当者にとってもRFPは案件の勝敗を分ける重要な文書です。
Bid / No-Bid 判断の5軸フレームワーク
すべてのRFPに対応する必要はありません。Loopio社の2025年調査によると、RFPの**平均勝率は45%**です（Loopio, RFP Statistics 2025）。限られたリソースを勝率の高い案件に集中させるため、以下の5軸で対応可否を判断しましょう。
| 判断軸 | 対応すべきサイン | 見送りのサイン |
|---|---|---|
| 勝率 | 関係構築済み、要件が自社強みに合致 | 初対面、要件が競合に有利 |
| 収益性 | 規模・単価が採算ライン以上 | 予算上限が低すぎて赤字リスク |
| 工数対効果 | 準備工数が見込み利益の10%以内 | 対応工数が利益を圧迫する |
| 戦略的価値 | 参入したい業界・新規大型顧客 | 既存顧客で手一杯 |
| 実現可能性 | 要件を技術的に充足できる | 対応不可能な要件がある |
「アリバイRFP」の見極め方：MarketingProfsの調査によると、B2B購買者の16%は「すでに発注先を決めている状態」でRFPを発行しています（MarketingProfs, 2026）。要件が特定ベンダーの仕様に偏っている、Q&Aへの回答が形式的、選定スケジュールが不自然に短い場合はアリバイRFPの可能性があります。
RFPの読み解き方 — 隠れた要件と評価基準を推測する
RFPに明文化されていない「行間」を読み取る力が差別化のカギです。
- 評価基準の配点を読む：技術力の配点が高ければ革新的なアプローチを、費用の配点が高ければコスト最適化を軸に提案する
- 課題の背景を推測する：「現状のシステムを刷新したい」とあれば、なぜ今なのか（経営方針の変更？トラブル発生？競合の動き？）を考える
- 除外条件から読む：「クラウドのみ」と書かれていればオンプレは除外。制約条件の裏には必ず理由がある
一方で、MarketingProfsの同調査では39%のB2B購買者が事前に候補ベンダーを持たずにRFP発行に臨んでいると報告されており、先入観なく選定される案件も少なくありません。
提案書のフレームワーク — RFP各項目への対応マッピング
RFPの各項目に対して「どう応えるか」を体系的に整理します。
- 要件対応表を作成する：RFPの要件を一覧化し、「対応可能 / 条件付き対応可能 / 対応不可 / 代替提案あり」の4段階で回答
- 課題→アプローチ→成果のストーリーを構築する：発注企業の課題を起点に、自社のソリューションがどう解決し、どんな成果をもたらすかを論理的に展開
- 類似実績を具体的に示す：同業種・同規模の実績を「課題→導入→成果」のフレームで提示
B2B提案書の書き方については「B2B提案書の書き方完全ガイド」で詳しく解説しています。また、営業提案書テンプレート20選では提案書・見積書の具体的なフォーマットを紹介しています。
競合との差別化ポイントを見つける3つの視点
- 課題理解の深さで勝つ：Q&Aで鋭い質問を投げることで「この会社は課題を深く理解している」という印象を与える。質問の質が提案の質を予告する
- 体制・プロセスの透明性で勝つ：担当者のプロフィール、役割分担図、プロジェクト進行フローを明示し、「一緒に働くイメージ」を持たせる
- 提案の具体性で勝つ：抽象的な「当社なら対応可能です」ではなく、「御社の課題Aに対してBというアプローチで、C週間で実現します」と具体的に踏み込む
エンタープライズ案件ではMEDDICフレームワークを活用し、意思決定プロセス・経済的購買者・決定基準を把握した上で提案を組み立てると勝率が上がります。ソリューション営業のアプローチも、RFPの要件を顧客の商談プロセスと紐づけて理解する際に有効です。
RFP対応を効率化するデジタルセールスルーム活用法
RFP関連資料の一元管理と共有
従来のRFP対応では、メールにファイルを添付してやり取りするのが一般的でした。しかしこの方法では版管理が煩雑になり、「古い版の提案書を評価された」「添付ファイルの容量制限で送信できない」といった問題が頻発します。
デジタルセールスルーム（DSR）を活用すると、RFP原本・要件対応表・提案書・参考事例・Q&Aをすべて1つのURLに集約できます。常に最新版が参照され、ファイルの散逸や版の取り違えを防止できます。
| 比較項目 | メール+ファイル添付 | DSR活用 |
|---|---|---|
| 版管理 | ファイル名で手動管理 | 常に最新版を自動参照 |
| アクセス制御 | 転送されると制御不能 | 閲覧権限を個別設定可能 |
| 容量制限 | メールサーバーの制限あり | 制限なし |
| 閲覧状況の把握 | 不可能 | ページ別・ユーザー別に把握可能 |
| Q&A管理 | メールスレッドが散逸 | 資料ページごとにスレッド管理 |
提案書共有ツールの選び方については「提案書共有ツール選定ガイド」、セキュリティ面の詳細は「セキュアな提案書共有ガイド」もご参照ください。
提案書の閲覧データで「検討度」を可視化する
DSRの閲覧トラッキング機能を使えば、発注側の評価者がどのページをどれくらいの時間閲覧したかをリアルタイムで把握できます。
- 費用ページの閲覧時間が長ければ「価格交渉の準備」、技術ページが長ければ「技術評価中」と推測できる
- 閲覧されていないページがあれば、補足動画や追加資料を追加してフォローアップ
- 複数の評価者のうち誰が積極的に閲覧しているかで、キーパーソンを特定できる
営業コンテンツの一元管理と閲覧分析を組み合わせることで、RFP対応の精度が大きく向上します。
ベンダーとの質疑応答をスレッドで一元化する
RFPのQ&A期間中、メールでのやり取りは質問と回答が散逸しがちです。DSRなら資料のページごとにコメント・質問スレッドを持てるため、「この要件についての質問」が文脈付きで記録されます。
コンサルティングファームの提案書共有のベストプラクティスでは、DSRを活用した顧客協働の具体的な進め方を紹介しています。また、エンタープライズ営業におけるDSR活用法も合わせてご覧ください。
生成AIを使った提案書作成の効率化と組み合わせれば、RFP対応のスピードと品質を同時に向上できます。
RFP作成・対応チェックリスト
ここまでの内容を、発注側・受注側それぞれの行動チェックリストに落とし込みます。
発注側（RFP作成）チェックリスト
- 課題を「現状→理想→ギャップ」で言語化した
- 要件を「Must / Want / Nice to Have」の3段階に分類した
- 評価基準に配点（ウェイト）を明示した
- 予算の開示範囲を社内で合意した
- 非機能要件を数値で定義した（曖昧表現の排除）
- 関係部署のレビューを受けた（情シス単独で作成していない）
- Q&Aのスケジュールと回答方法を設計した
- 要件フリーズのタイミングを明記した
受注側（RFP対応）チェックリスト
- Bid/No-Bid判断を5軸で実施した
- RFPの評価基準・配点を分析し、提案の重点を設計した
- 要件対応表を作成し、対応可否を4段階で明示した
- 類似実績を「課題→導入→成果」のフレームで準備した
- Q&Aで課題理解の深さを示す質問を投げた
- 提案書をDSRで共有し、閲覧データを追跡する準備をした
よくある質問（FAQ）
RFPとは何ですか？
RFP（Request for Proposal）は「提案依頼書」と訳される文書で、発注企業がベンダーに対して自社の課題・要件・条件・評価基準を提示し、正式な提案書の提出を依頼するものです。システム導入やコンサルティング案件など、複数ベンダーを比較して最適なパートナーを選定する際に使われます。
RFPとRFIの違いは何ですか？
RFI（Request for Information）は要件が固まる前の情報収集段階で発行し、市場の選択肢やベンダーの能力を広く把握する文書です。対象は10〜15社。一方、RFP（Request for Proposal）は要件が固まった段階で3〜5社に発行し、具体的な提案内容と概算費用を比較します。一般的に「RFI→RFP→RFQ→契約」の順に進みます。
RFPとRFQの違いは何ですか？
RFQ（Request for Quotation）は「見積依頼書」です。仕様が確定した段階で最終候補1〜3社に発行し、価格と納期を比較します。RFPが「提案内容の比較」を目的とするのに対し、RFQは「確定仕様に対する価格の比較」に特化しています。
RFPに記載すべき項目は何ですか？
主要な7項目は「1. プロジェクト概要（背景・目的）、2. 現状課題と理想像、3. 機能要件・非機能要件、4. 予算・スケジュール・体制、5. 提案依頼事項、6. 評価基準と選考プロセス、7. 制約条件・前提条件」です。特に評価基準の配点明示と要件の優先度分類（Must/Want/Nice to Have）が提案精度を大きく左右します。
RFPを作成するメリットは何ですか？
主に5つあります。(1) 要件をベンダーに正確に伝えられる、(2) 複数社の提案を公平に比較できる、(3) プロジェクトのトラブルを未然に防げる、(4) 自社の課題を客観的に整理できる、(5) 社内の合意形成ツールになる。特に関係者が多いB2B購買では、評価基準を事前に統一する効果が大きいです。
RFPがないとどうなりますか？
ベンダーごとに提案の粒度がバラバラになり比較が困難になります。プロジェクト途中でスコープが膨張し追加費用が発生するリスクも高まります。さらに、要件が文書化されていないため社内合意が不十分なまま進み、選定後に反対意見が出て手戻りになるケースもあります。
RFPの作成は誰がやるべきですか？
情シスやIT部門だけでなく、事業部門・経営層・現場担当者を含むプロジェクトチームで作成すべきです。「実際に使う人」の声を反映することで導入後の定着率が上がり、経営層の関与があれば予算・スケジュールの意思決定もスムーズになります。
RFP作成にかかる期間はどのくらいですか？
案件規模により2週間〜2か月が目安です。「課題整理・ヒアリング（1〜2週間）→ 要件定義（1〜3週間）→ RFP文書化・社内レビュー（1〜2週間）」が典型的なスケジュールです。RFI実施を含む場合はさらに2〜3週間追加されます。
RFPのテンプレートはどこで入手できますか？
本記事内の「RFPの構成要素と記載項目」セクションで、7つの構成要素の記載例・NG例を含むテンプレートを提供しています。IPAの「ストーリーで学ぶ要件定義実践入門」にもRFPの参考フォーマットが掲載されています。
RFP提出後のベンダー選定の流れはどうなりますか？
一般的な流れは「(1) 提案書受領 → (2) 評価マトリクスでスコアリング → (3) 上位候補によるプレゼン・デモ → (4) 最終スコアの確定 → (5) 最終候補1〜3社にRFQで詳細見積を依頼 → (6) 契約交渉・締結」です。評価者は複数人で行い、スコアの乖離が大きい項目を重点的に議論するのがポイントです。
まとめ
RFP（提案依頼書）は、発注側・受注側の双方にとってプロジェクトの成否を左右する重要な文書です。
発注側（RFP作成）のポイント
- 課題を「現状→理想→ギャップ」で言語化し、要件を「Must/Want/Nice to Have」で分類する
- 評価基準に配点を明示し、属人的判断を排除する
- 関係部署を巻き込み、要件フリーズのタイミングを事前に設計する
受注側（RFP対応）のポイント
- Bid/No-Bid判断を5軸で徹底し、勝率の高い案件にリソースを集中する
- RFPの「行間」を読み解き、評価基準の配点に合わせた提案を設計する
- 要件対応表・類似実績・体制図で提案の具体性と透明性を担保する
デジタルツールによる効率化
- DSR（デジタルセールスルーム）でRFP関連資料の一元管理・閲覧分析・Q&A管理を実現し、発注側・受注側双方の対応品質とスピードを向上させましょう。
