RFPの書き方完全ガイド｜7項目テンプレ・5ステップ・ベンダー回答例【業種別実例】

この記事の要点

• RFPは「文章の型」で書ける——目的・課題・要件・予算・評価基準には、それぞれ埋めるべき文型が決まっている
• 書き方の5ステップ: 目的整理 → 関係者ヒアリング → Must/Want/Nice to Have 分類 → 文書化 → 配布・Q&A
• 7項目テンプレートに業種別の書き分け: Webサイト・基幹システム・SaaS・マーケツールで重視項目と例文が異なる
• 受注側のRFP回答には独自の作法がある——Bid/No-Bid判断、要件対応表、価格提示、Q&A戦略までを実例で解説
• 書き方ミスのBefore/After 10例で、明日からのドラフト品質を底上げ

「RFPの意味は理解した。問題は具体的にどう書くかだ」「ベンダー側として回答するときの作法が知りたい」——RFPに関する検索ニーズは「定義」よりも「書き方の実例」と「回答テクニック」に集中しています。

本記事はRFPの概念ではなく、実際に文章を書く・回答を作ることに振り切ったハウツーガイドです。RFPの定義・RFI/RFQとの違い・AI活用ワークフローなど概論部分はRFPとは？書き方・7項目テンプレと評価マトリクス【2026年版】に譲り、本記事では「文の型」「業種別例文」「ベンダー回答の実技」に集中して20,000字超で解説します。

---

RFPの書き方は「文の型」を覚えれば誰でも書ける

多くの担当者が詰まる3つの場面

実務でRFPを書く際、担当者が最も詰まるのは次の3点です。

• 目的の言語化: 「経営課題を達成するため」のような抽象表現で止まり、ベンダーが提案の方向性を判断できない
• 要件の粒度: 「使いやすいUI」「高速」など曖昧な形容詞のまま、定量化や優先度付けができない
• 評価基準の配点: 「総合的に判断」と書いたまま、後で社内が紛糾する

これらはすべて「文の型」を持っていれば回避できます。本記事の各セクションでは、その型をテンプレート形式で提示します。

「RFP書き方の意味」とは何か——文書としての3つの責務

RFPという文書には次の3つの責務があります。書き方を語る前に、目的を整理しておきます。

1. 要件の固定化: 後工程での「言った言わない」を防ぐ
2. 比較可能性の担保: 複数ベンダーの提案を同じ土俵で評価できるようにする
3. 意思決定の透明化: 評価基準と配点を事前公開し、選定の説明責任を果たす

書き方の良し悪しは、この3つの責務をどれだけ高い解像度で果たせるかで決まります。読み手はベンダーだけでなく、社内の経営層・法務・現場でもあることを常に意識しましょう。

RFI・RFQとの違いを書き方の観点で整理

3文書の違いを「書き方の難易度」で並べると、RFI（やさしい）< RFQ（中程度）< RFP（最も難しい）です。本記事はRFPの書き方に絞って解説します。RFI/RFQの位置づけを含む全体像はRFPの定義・RFI/RFQとの違いを解説した記事を参照してください。

---

RFPの書き方5ステップ【実例・所要日数付き】

ここからは「実際に手を動かしてRFPを書く」ための5ステップを解説します。各ステップで何を書くか、所要日数、つまずきやすいポイントを実例とともに示します。

Step 1. プロジェクトの目的を「経営課題 × KPI」で言語化する（所要3〜5営業日）

最初のステップは目的の言語化です。「システムを刷新したい」のような表現はゴールではなく手段でしかありません。書く際の「文の型」は次のとおりです。

【目的の文型】
{経営課題}を解決するため、{システム/施策}によって
{定量KPI}を{期間}で達成する。

【記入例】
受注情報のサイロ化により週次経営判断が遅延している問題を解決するため、
リアルタイム受注管理基盤によって、週次クロージング期間を5営業日から
2営業日へ60%短縮することを2027年3月末までに達成する。

ポイントは「経営課題」「手段」「KPI」「期限」の4要素をすべて入れることです。1要素でも欠けると、ベンダーは提案の方向性を絞り込めません。

つまずきポイント: 「経営課題」の言語化に詰まる場合は、CEO・CFOの直近の発言や中期経営計画から引用すると素早く解像度が上がります。

Step 2. ステークホルダーに聞く——ヒアリングの設計と書き方（所要7〜10営業日）

目的が固まったら、関係部署にヒアリングして要件を集めます。書き出すべきは「ヒアリングシート」と「ステークホルダーマップ」の2つです。

ヒアリングシートの文型

- 役職と業務範囲: {例: 営業部マネージャー、関東エリアの受注管理を統括}
- 現状の困りごと（As Is）: {例: 週次のExcel集計で毎週3時間消費している}
- 理想状態（To Be）: {例: ダッシュボードで会議直前まで最新数字を確認できる}
- ギャップを埋めるのに必要な機能: {例: 受注データの自動集計、権限管理}
- 譲れない条件: {例: モバイル閲覧、Salesforce連携}

ヒアリングの段取りは営業ヒアリングの極意で扱っている「事前準備 → 質問設計 → 記録 → 分析」のフローがそのまま使えます。

ステークホルダーマップの書き方: 「決裁者」「承認者」「実行者」「使用者」の4区分で関係者を分類し、各人の主要関心事をメモします。決裁者は予算・ROI、使用者は操作性に関心が偏るため、評価項目の重み付けに反映させます。

Step 3. 要件を Must / Want / Nice to Have に分類する（所要5〜7営業日）

集めた要件をそのまま全部書くと「Must要件50件」のような肥大化したRFPになり、対応可能なベンダーが激減します。次の文型で分類しましょう。

【分類の判断基準】
- Must: 未対応なら選定対象外（業務継続不可、法規制違反）
- Want: あれば加点（生産性向上、なくても運用可能）
- Nice to Have: 将来検討してもよい（今期は必須でない）

【記入例】
■ Must
M-01: 受注データを5分以内に全社へ反映できること
M-02: 役職別の閲覧権限を3階層以上設定できること
M-03: ISMS（ISO 27001）認証を保有していること

■ Want
W-01: モバイル端末から閲覧できること（業務時間外確認のため）
W-02: Salesforceと双方向API連携できること

■ Nice to Have
N-01: AIによる受注予測機能（将来検討）
N-02: SlackボットからのSQL風クエリ実行

Must上限ルール: Must要件は20件以内に絞ります。20件を超えるとベンダー側が要件対応表の作成だけで疲弊し、提案の独自性が削がれます。

つまずきポイント: 「これはMustかWantか」で社内が紛糾する場合は、「この要件がなくても3か月運用できるか？」と問い直してください。3か月運用できるならWantで十分です。

Step 4. RFP本体を文書化する（所要3〜5営業日）

要件が固まったら、後述の7項目テンプレートに沿って文書化します。文書化の段階で守るべき5つの「書き方の作法」は次のとおりです。

1. 「ですます調」と「である調」を混在させない: 公式文書では「である調」が一般的
2. 数値で書く: 「高速」→「ページ表示3秒以内」、「安定」→「稼働率99.9%以上」
3. 要件IDを採番する: M-01, W-01のようにIDを付けるとQ&Aやベンダー回答で参照しやすい
4. 前提条件を冒頭に明記: 「本RFPはNDA締結済みベンダーのみに開示する」など
5. 参考資料を別添化: 業務フロー図、現行システム構成図はAppendixに分離し、本体を読みやすくする

社内レビューは、業務部門 → IT部門 → 法務 → 経営層 の順で回します。各レビュアーが見るべき観点は次の表のとおりです。

Step 5. 配布とQ&A対応（配布から提出期限まで2〜3週間）

配布の作法と、配布後のQ&A対応の書き方を解説します。

配布の作法

• 配布日と提出期限を明記し、間に最低2週間（推奨3週間）を確保する
• 配布チャネルはメールよりもデジタルセールスルーム（DSR）などのアクセス権限管理が可能なツール推奨
• 各ベンダーへの配布日時を揃え、情報格差を作らない

Q&A対応の文型

質問は一括収集 → 一斉回答が鉄則です。以下のフォーマットで全ベンダーに同時公開しましょう。

| No | 質問ベンダー | 質問内容 | 回答 | 回答日 |
|----|------------|--------|------|-------|
| 01 | （非開示） | 既存システムのAPI仕様書は提供されるか | 提供可、契約後にNDAベースで開示 | 2026-06-05 |
| 02 | （非開示） | 評価基準の配点はいつ確定するか | 本RFP配布時点で確定済み（本文6.参照） | 2026-06-05 |

質問ベンダー名は伏せ、Q&A内容は全社で共有します。個別回答は情報格差を生むため厳禁です。

---

RFP7項目テンプレート【実例文・記入式】

ここからは、コピペしてすぐ使える7項目テンプレートを実例文付きで提示します。各項目について「文の型」「記入例」「NG例」「注意点」をセットで示します。

1. プロジェクト概要

【文の型】
- プロジェクト名: {一意に識別できる名称}
- 発注組織: {会社名 / 部署名}
- 期間: {要件定義開始日 〜 本番稼働日}
- 背景: {なぜこのタイミングで、なぜこの規模で必要か}
- 目的: {Step 1で固めた目的文をそのまま転記}
- 期待効果（KPI）: {定量効果3〜5個}

記入例

- プロジェクト名: 受注管理基盤刷新プロジェクト（コードネーム: Pulse）
- 発注組織: 株式会社サンプル 経営企画本部 DX推進室
- 期間: 2026年7月〜2027年3月（要件定義3か月、開発5か月、移行1か月）
- 背景: 2027年4月の上場準備に向け、月次クロージング期間の短縮が
       経営会議で必須要件として確認されている
- 目的: （Step 1の目的文を転記）
- 期待効果（KPI）:
  - 週次クロージング期間: 5営業日→2営業日（60%短縮）
  - 集計作業工数: 月12時間→月2時間（83%削減）
  - データ最新性: 1週間→5分以内

NG例: 「経営判断の高速化のため、受注管理を改善する」のように動詞だけで終わる書き方。KPIがないと、ベンダーは「どこまでやれば達成か」を判断できません。

2. 現状の課題と理想像（As Is / To Be）

【文の型】
- As Is（現状）: 業務フロー、システム構成、業務量、課題発生頻度
- To Be（理想）: 業務フロー、システム構成、定量目標
- ギャップ: As IsとTo Beの差分を箇条書きで3〜5個

記入例

■ As Is
- 営業部のExcel管理で、各支店が独自フォーマットで入力
- マネージャー3名が週次で1.5時間かけて統合・集計
- 数字確認の問い合わせが営業マネージャーへ1日10件発生

■ To Be
- 受注情報が単一のDBに格納され、全社で5分以内に最新化
- ダッシュボードで誰でも自席で最新数字を確認可能
- 問い合わせ件数を1日2件以下に削減

■ ギャップ
- 現状: フォーマット不統一 → 理想: 入力UI統一
- 現状: 集計に1.5時間 → 理想: 自動集計（ゼロ時間）
- 現状: 数字確認の属人化 → 理想: ダッシュボードでセルフサービス化

注意点: As Is は数値で書きましょう。「集計に時間がかかっている」ではなく「週1.5時間」と書くことで、ベンダーは効果試算ができるようになります。

3. 機能要件・非機能要件

機能要件はStep 3で分類済みのMust/Want/Nice to Have をそのまま記載します。非機能要件は次の8カテゴリを数値で定義します。

【非機能要件の文型】
■ 可用性: 稼働率99.9%以上（年間停止時間8.76時間以内）
■ 性能: トップページ表示2秒以内（95パーセンタイル）、
       同時アクセス500ユーザー時の応答3秒以内
■ 拡張性: ユーザー数を1年で2倍に拡張可能
■ セキュリティ: ISMS（ISO 27001）認証保有、データ暗号化（AES-256）
■ 運用性: 月次パッチ適用が業務時間外で完結する
■ 移行性: 既存システムからのデータ移行を3営業日以内で完了
■ 互換性: 主要ブラウザ最新2バージョン対応（Chrome / Safari / Edge / Firefox）
■ 保守性: ベンダー障害時の初動対応1時間以内、復旧4時間以内

NG例: 「高速で安定したシステム」「セキュリティに配慮された」のような形容詞だけの非機能要件は意味を持ちません。数値・規格・条件で書きましょう。

4. 予算・スケジュール・体制

【予算の文型】
■ 初期費用: 500〜1,000万円（要件定義 / 開発 / テスト / 移行）
■ 月額費用: 30〜80万円（保守 / SaaS利用料 / 運用代行）
■ 5年トータルコスト（TCO）の試算を依頼すること

予算はレンジで開示するのが推奨です。完全非開示にすると「100万円の案件に5,000万円の提案」のような的外れ提案が集まり、評価工数が無駄になります。

【スケジュールの文型】
- RFP配布日: 2026-06-01
- Q&A受付期限: 2026-06-12（11営業日）
- Q&A回答公開: 2026-06-17
- 提案書提出期限: 2026-06-30（配布から約4週間）
- 一次評価結果通知: 2026-07-10
- プレゼン審査: 2026-07-15〜17
- 最終選定通知: 2026-07-24
- 契約締結: 2026-08-15
- プロジェクト開始: 2026-09-01

【体制の文型（発注側）】
- プロジェクトオーナー: 経営企画本部長
- PM: DX推進室 室長
- 業務代表: 営業企画部 部長 / 経理部 部長
- IT代表: 情報システム部 課長
- 評価委員: 上記5名 + 経営層オブザーバー2名

【体制の文型（ベンダー要望）】
- 提案ベンダーにアサインを依頼する役割:
  - PM（同業界10年以上の経験者）
  - テックリード
  - 業務コンサルタント
  - 移行リード
- アサイン体制図の提出を必須とする

5. 提案依頼事項

【文の型】
- 提案書のページ数: 30〜50ページ（Appendix除く）
- 必須記載事項:
  1. エグゼクティブサマリー（2ページ以内）
  2. 課題理解と提案アプローチ
  3. 機能対応表（要件ID別の対応可否）
  4. システム構成図
  5. プロジェクト推進体制
  6. スケジュール（マイルストーン別）
  7. 見積（初期 / 月額 / 5年TCO）
  8. 類似実績3件以上（同業種・同規模優先）
  9. リスクと対策
- 提案書フォーマット: PDF（Word / PowerPoint 添付可）
- 提出方法: 専用URL（DSR）へのアップロード
- ファイルサイズ上限: 1ファイル30MB

提案書のページ数と必須記載事項を指定すると、ベンダー間の比較が圧倒的に楽になります。自由フォーマットにすると、評価工数が3倍に膨らみます。

6. 評価基準と選考プロセス

【評価項目と配点の例（基幹システム導入）】
| 評価項目 | 配点 | 評価観点 |
|---------|------|---------|
| 技術力・実現性 | 30 | 要件充足度、技術選定の妥当性、PoC実施可否 |
| 費用 | 20 | 初期費用、5年TCO、コスト構造の透明性 |
| 実績・信頼性 | 25 | 同業種・同規模の導入数、顧客満足度、財務健全性 |
| 推進体制 | 15 | PM経験、業界知見、リソースの厚み |
| 提案の独自性 | 5 | 課題解決の創意工夫、付加価値 |
| 保守・サポート | 5 | SLA水準、対応時間帯、エスカレーション体制 |
| 合計 | 100 | |

評価項目と配点はRFP配布時点で確定・公開します。後出しは公平性を損ね、ベンダーからのクレームに発展します。詳細な評価マトリクスの作り方はRFP評価マトリクスの作り方と実テンプレートで解説しています。

7. 制約条件・前提条件

【文の型】
■ 既存システム連携: SalesforceとのAPI連携必須、認証はSAML 2.0
■ データ保管リージョン: 国内リージョン必須（海外リージョン不可）
■ 法規制: 個人情報保護法、（金融・医療系の場合は）業界別ガイドライン
■ NDA: ベンダーは事前にNDA締結が必要
■ 知財: 開発成果物の著作権は発注側に帰属、再委託は事前承認制
■ 社内承認: 取締役会承認が必要なため、契約締結まで2か月の手続き期間あり
■ 提供前提資料:
  - 既存システム構成図（NDA締結後に開示）
  - 業務フロー図（公開可）
  - 過去2年分の月次受注データ（NDA + マスキング）

制約条件を事前に共有しないと、対応不可能なベンダーが提案準備に時間を浪費し、関係性が悪化します。早めに開示することは双方にメリットがあります。

---

【業種別】RFPの書き方サンプル文【4業種】

業種ごとに「実際に書くべき文の中身」は大きく異なります。以下、4業種について「最も重要な要件項目」と「実例文」を提示します。

業種別の重視項目マトリクス（早見表）は業種別RFPの違い早見表で確認できます。本記事では「実例文」に絞って解説します。

A. Webサイト制作のRFP書き方サンプル

■ 1. プロジェクト概要
- プロジェクト名: コーポレートサイト全面リニューアル
- 目的: 採用応募数を月50件→100件へ倍増させるため、
       採用LP・社員インタビュー記事の動線を強化したコーポレートサイトを構築する
- 期待効果: 採用応募CV率2.0%以上、Core Web Vitals 全項目グリーン

■ 2. As Is / To Be
- As Is: WordPressベース、表示速度3秒超、モバイル離脱率65%
- To Be: Headless CMS化、LCP 2.5秒以内、モバイル離脱率40%以下
- ギャップ: 表示速度、編集者の更新負荷、SEO評価の低下

■ 3. 主要要件（抜粋）
- Must:
  - 既存ドメインのSEO評価を維持する移行設計
  - WCAG 2.1 AA準拠
  - 編集者2名が毎週20記事を更新できるCMS UX
- Want:
  - A/Bテスト機能（採用LPでの活用想定）
  - 多言語対応（日英2言語）
- Nice to Have:
  - AIによる記事タイトル最適化提案

■ 4. 評価基準（参考配点）
- デザイン制作実績: 30 / 技術実装力: 20 / SEO移行設計: 20 /
  保守体制: 15 / 費用: 15

Web制作の書き方ポイント

• 「モダンな」「使いやすい」など曖昧な形容詞を避け、参考サイトURLと「ここが良い」のポイントを3〜5本明示
• 公開日から逆算したマイルストーン（要件定義 / デザインカンプ / コーディング / テスト / 公開）を提示
• 写真・動画素材の提供範囲を明確化（自社提供 / 制作会社手配 / ストック素材活用）

B. 基幹システム（ERP/会計）のRFP書き方サンプル

■ 1. プロジェクト概要
- 目的: 5社グループ会計の連結クロージング期間を15日→7日へ短縮し、
       IR向け月次開示のタイムリーディスクロージャー要件を満たす
- 期待効果: 連結クロージング7日以内、内部統制監査指摘ゼロ

■ 3. 主要要件（抜粋）
- Must:
  - IFRS 16対応（リース会計）
  - J-SOX対応、内部統制ログ7年保管
  - 連結会計（5社、共通会計コード）
  - SOC 2 Type 2 認証保有
- Want:
  - 為替予約管理機能
  - AIによる仕訳推測（補助科目レベル）
- Nice to Have:
  - 海外子会社展開（将来の北米進出を見据えて）

■ 4. 業務量
- 月次仕訳件数: 平均3万件、月末3日間で6万件
- 同時利用ユーザー数: ピーク時60名（経理部 + 各事業部経理担当）
- データ移行範囲: 過去5年分の仕訳、勘定科目、補助科目

■ 5. 評価基準（参考配点）
- 業務適合性（フィットギャップ）: 30 / 5年TCO: 20 /
  類似実績（同業種・同規模）: 25 / 保守SLA: 15 / 移行計画: 10

基幹システムの書き方ポイント

• 業務プロセスは部署単位ではなく「機能単位」で記載（「営業部」ではなく「受注計上→請求→入金消込」）
• 5年トータルコスト（TCO）の試算を依頼。初期費用だけで判断しない
• 並行稼働期間中の二重コストと、ベンダー側のサポート体制を必ず確認する

C. SaaS選定（CRM/MA等）のRFP書き方サンプル

■ 1. プロジェクト概要
- 目的: 営業部120名のSFA浸透率を40%→90%へ向上させ、
       商談データに基づく予実精度を月次±5%以内に高める
- 期待効果: SFA入力率90%以上、予実乖離±5%以内

■ 3. 主要要件（抜粋）
- Must:
  - SAML 2.0 SSO、SCIMプロビジョニング
  - Salesforce / HubSpotとのネイティブ連携（双方向）
  - 国内リージョンデータ保管、データ持ち出しポリシー開示
  - SOC 2 Type 2 認証
- Want:
  - モバイルアプリで90%以上の機能カバー（外勤営業のため）
  - AI議事録機能（Zoom / Google Meet 連携）
- Nice to Have:
  - 商談録音の感情分析

■ 5. 評価基準（参考配点）
- 標準機能フィット: 25 / 連携・拡張性: 20 / セキュリティ認証: 15 /
  価格・契約形態: 20 / カスタマーサクセス体制: 15 / 既存顧客の継続率: 5

SaaSの書き方ポイント

• SaaSは「導入してから3か月で評価」が現実的。導入後の伴走支援（カスタマーサクセス）の体制を明示的に依頼
• 既存顧客の継続率（NRR）、ARR成長率、IRレポートなどから企業の安定性を評価
• 価格はライセンス費用だけでなく、データ容量、API呼び出し回数、追加モジュールの体系を求める

D. マーケティングツール選定のRFP書き方サンプル

■ 1. プロジェクト概要
- 目的: メールマーケティングのROIを2.5倍に向上させるため、
       行動ベースセグメント配信とA/Bテスト基盤を整備する
- 期待効果: メール経由CVR 0.8%→2.0%、配信工数 月40h→15h

■ 3. 主要要件（抜粋）
- Must:
  - 月間配信数500万通、ピーク時1日100万通の配信耐性
  - RFM・行動履歴ベースのセグメント条件保存
  - 特定電子メール法・特定商取引法・GDPR対応
- Want:
  - 件名最適化AI、配信時間最適化AI
  - SalesforceとのリードスコアAPI連携
- Nice to Have:
  - LINE公式アカウント・SMS統合配信

■ 5. 評価基準（参考配点）
- 配信規模・到達率: 25 / セグメント機能: 20 / 効果測定機能: 15 /
  価格（CPM・固定費の組み合わせ）: 20 / 連携API: 10 / 教育体制: 10

マーケティングツールの書き方ポイント

• 配信数が多い場合は「配信単価（CPM）」「保守費」「サポート対応時間」のトータルコストで評価
• 競合のマーケティングツールとの連携可否（例: Adobe Experience CloudとSalesforce Marketing Cloud）も確認
• 成果報酬型と固定料金型の見積を並行で取得して比較

---

RFP回答の書き方【受注側・ベンダー視点】

ここからはRFPを「受け取る」ベンダー側（受注側）の書き方を解説します。「RFP 回答」というキーワードで検索する読者の多くは、営業担当者・提案責任者・営業企画担当です。Loopio社の2025年調査によると、一般的なチームのRFP勝率は平均39%、累積長期ベンチマークでは45%です（Loopio, RFP Statistics & Win Rates）。回答の作法を磨くことで、この勝率を5〜10ポイント引き上げることが可能です。

Step 1. Bid / No-Bid 判断——勝てる案件にだけ提案する

すべてのRFPに対応する必要はありません。受領から72時間以内に次の5軸で判断します。

MarketingProfsの調査によると、B2B購買者の16%は「すでに発注先を決めている状態」でRFPを発行しています（MarketingProfs, 2026）。**選定スケジュールが不自然に短い・要件が特定ベンダーの仕様に偏っている・Q&Aへの回答が形式的、の3点が揃ったら「アリバイRFP」**の可能性が高く、撤退を検討すべきです。

Step 2. 要件対応表の書き方——4段階で誠実に回答する

要件IDごとに対応可否を明示します。「対応可能」を多用するより、正直に4段階で書くほうが信頼を得られます。

【要件対応表の文型】
| 要件ID | 要件概要 | 対応可否 | 補足 | 該当機能・実績 |
|--------|---------|---------|------|---------------|
| M-01 | 受注データ5分以内反映 | ◎完全対応 | 標準で1分以内 | データ同期エンジンXX |
| M-02 | 3階層の閲覧権限 | ○対応 | 標準は2階層、カスタムで3階層対応 | 同種カスタマイズ実績5件 |
| M-03 | ISMS認証 | ◎完全対応 | ISO 27001 + SOC2 Type 2 | 認証書添付 |
| W-01 | モバイル閲覧 | ○対応 | iOS/Android アプリ提供 | App Store評価4.6 |
| W-02 | Salesforce連携 | △条件付対応 | 標準コネクタは片方向、双方向は要追加開発（+300万円） | 双方向連携実績3件 |
| N-01 | AI受注予測 | ×非対応 | 2027年Q3ロードマップに記載 | 共同PoC可能 |

4段階記号の使い分け

• ◎ 完全対応: 標準機能で対応、追加費用なし
• ○ 対応: 標準機能で対応、または軽微なカスタマイズで対応
• △ 条件付対応: 追加費用・追加開発が必要、または代替案あり
• × 非対応: 現時点で対応不可、ただしロードマップや代替提案を併記

書き方の禁じ手: すべて「○」で埋める、対応不可を「△」で誤魔化す——これらは導入後のトラブルを招き、再受注の道を絶ちます。

Step 3. 提案書本体の構成——勝てる7セクション

要件対応表だけでは差別化できません。提案書は次の7セクション構成で書きます。

1. エグゼクティブサマリー（2ページ以内）
   - 課題理解 / 提案コア / 期待効果 / 投資額 / リスク と対策
2. 課題理解と仮説（3〜5ページ）
   - RFP要件の背景にある経営課題への解釈
   - 業界トレンド・ベンチマーク
3. 提案アプローチ（5〜10ページ）
   - ソリューション概要、技術選定理由
   - 競合との差別化ポイント
4. 機能対応表 + 主要機能のスクリーンショット
5. プロジェクト推進計画（5ページ）
   - スケジュール、マイルストーン、体制図、リスク管理
6. 投資額と効果試算（3ページ）
   - 初期 / 月額 / 5年TCO、ROI試算、回収期間
7. 類似実績と推薦コメント（3〜5ページ）
   - 同業種・同規模の事例3件以上、可能なら推薦者連絡先

エグゼクティブサマリーが命: 評価委員の多くはサマリーしか読みません。「課題理解 → 提案コア → 期待効果 → 投資額 → リスク」の5要素を2ページに凝縮します。

Step 4. 価格提示の作法——「比較されやすい構造」で書く

価格は次の3形式に分解して提示します。発注側が比較しやすい構造で書くことが信頼につながります。

■ 初期費用
- 要件定義: XXX万円
- 設計・開発: XXX万円
- データ移行: XXX万円
- テスト・受入: XXX万円
- 教育・トレーニング: XXX万円
- 初期費用合計: XXX万円

■ 月額費用
- SaaS利用料: XX万円（ユーザー60名想定）
- 標準保守: XX万円
- 月額合計: XX万円

■ 5年トータルコスト（TCO）
- 1年目: XXX万円（初期 + 月額×12）
- 2〜5年目: 各 XXX万円（月額×12 + 年次保守）
- 5年TCO合計: X,XXX万円

■ オプション費用（参考）
- 追加カスタマイズ単価: XX万円/人日
- 追加トレーニング: XX万円/回
- 24/365保守へのアップグレード: +XX万円/月

禁じ手: 「一式 1,500万円」のような丸めた見積。比較不可能になり、評価で不利になります。

Step 5. Q&A戦略——質問は「課題理解の深さ」を見せる場

Q&A期間中の質問は、単なる情報収集ではなく自社の理解度をアピールする機会です。

【良い質問の文型】
RFP本文 X.X章において「Y」とのご記載がありますが、
これは「{解釈A}」または「{解釈B}」のどちらを意図されていますでしょうか。
解釈により提案アプローチが {Aの場合: ZZ / Bの場合: WW} と
変わるため、確認させてください。

【悪い質問】
- 「貴社のシステム構成を教えてください」（RFPに書いてある内容）
- 「予算はいくらですか」（無条件に聞くと品がない）
- 「他にどんなベンダーが提案していますか」（聞いてはいけない）

良い質問を1〜3問投げることで、評価委員に「このベンダーは深く考えている」という印象を残せます。

Step 6. プレゼン審査の組み立て

提案書通過後はプレゼン審査です。45〜60分の中で次の構成が王道です。

- 0〜5分: 自社紹介（最小限）+ 評価委員への問いかけ
- 5〜20分: 課題理解と仮説のすり合わせ（インタラクティブ）
- 20〜40分: 提案アプローチのデモまたは具体例
- 40〜50分: スケジュール・体制・投資額
- 50〜60分: 質疑応答

勝率を上げる小技: プレゼン冒頭で「本日のゴールは、貴社の課題に対して我々の提案が最適か判断いただくことです。途中で違うと感じたら遠慮なく止めてください」と宣言すると、評価委員との心理的距離が縮まります。

エンタープライズ案件ではMEDDICフレームワークを活用し、意思決定プロセス・経済的購買者・決定基準を把握した上で提案を組み立てると勝率が上がります。ソリューション営業のアプローチも、RFPの要件を顧客の商談プロセスと紐づけて理解する際に有効です。

Step 7. 落選時のリカバリ——次に勝つための学習

落選通知を受け取ったら、必ず次の3点を確認します。

• スコアサマリーの開示依頼: 自社スコアと上位のスコア差を可能な範囲で教えてもらう
• 講評の聞き取り: 何が決め手だったか、自社に欠けていたのは何か
• 次回機会の打診: 次のRFPでも声をかけてもらえるよう関係を維持

Responsive社が2025年7月にB2Bバイヤー350名を対象に実施した調査によると、B2B購買者の81%がベンダーのRFP回答は最終意思決定に「非常に大きい」または「極めて大きい」影響を与えると回答しています（Responsive, "Inside the Buyer's Mind", 2025年7月調査）。落選しても回答品質は評価されているため、次の機会で逆転は十分可能です。

---

RFP書き方ミスのBefore / After 10例

書き方の品質を一段引き上げるための、Before/After集です。

1. 目的の書き方

Before: 「受注管理システムを刷新する」
After: 「週次クロージング期間を5営業日→2営業日へ60%短縮し、2027年4月の上場準備要件を満たす」

2. 要件の書き方

Before: 「使いやすいUI」
After: 「業務未経験者が30分のトレーニングで主要操作を完了できるUI」

3. 非機能要件の書き方

Before: 「高速で安定したシステム」
After: 「LCP 2.5秒以内、稼働率99.9%以上（年間停止8.76時間以内）」

4. 予算の書き方

Before: 予算は非開示
After: 「初期500〜1,000万円、月額30〜80万円のレンジ。確定後の調整可能性あり」

5. 評価基準の書き方

Before: 「総合的に判断します」
After: 配点表を明示「技術力30 / 費用25 / 実績20 / 体制15 / 独自性10」

6. スケジュールの書き方

Before: 「秋ごろまでに導入」
After: 「契約2026-08-15、要件定義開始2026-09-01、本番稼働2027-03-31」

7. 体制の書き方

Before: 「適切な体制で対応してください」
After: 「PM（同業界10年以上）/ テックリード / 業務コンサルタント / 移行リード のアサインを必須」

8. Q&Aの書き方

Before: 「不明点はメールで問い合わせください」
After: 「Q&Aは2026-06-12までに専用フォームで受付、全質問への回答を2026-06-17に全社へ一斉公開」

9. 制約条件の書き方

Before: （何も書かない）
After: 「データ保管リージョン国内必須、Salesforce API連携必須、NDA事前締結必須」

10. 結果通知の書き方

Before: 「選定結果は採用ベンダーにのみ通知」
After: 「全ベンダーにスコアサマリーと講評を提供。落選理由のフィードバック面談も実施可」

---

よくある質問（FAQ）

---

DSRでRFP関連資料を一元管理する

RFPの配布と提案書受領をメール添付で行うと、版管理の煩雑化・容量制限・送信エラーが頻発します。デジタルセールスルーム（DSR）を活用すると次のメリットがあります。

• 発注側: RFP原本・Q&A集・補足資料を1つのURLで管理。提案書受領も同URLで一元化。閲覧トラッキングで各ベンダーの検討状況を可視化
• 受注側: 提案書・要件対応表・参考事例・スクリーンショット集をまとめ、評価委員ごとのアクセス権限を制御。閲覧ログから「どの章にどれだけ時間をかけたか」が分かり、フォロー戦略に活用

ツール選定の観点はデジタルセールスルーム比較と提案書共有ツール選定ガイドで解説しています。

---

まとめ：今日からRFPを書き始めるための行動チェックリスト

RFPの書き方は「文の型」を覚えれば誰でも書けます。発注側・受注側それぞれの行動チェックリストを示します。

発注側：今週やる

1. プロジェクトの目的を「 × × 」の文型で1文に書く
2. ステークホルダーを5〜10名特定し、ヒアリング日程を確保する
3. 本記事の7項目テンプレートを GoogleDocs / Notion / Confluence にコピーし、目次だけ仮で埋める

発注側：今月やる

1. ヒアリング結果をMust/Want/Nice to Haveの3分類で記録する（Must 20件以内）
2. 評価マトリクスを「経営層・現場・情シスの三者投票」で組み立てる
3. 業務担当・IT・法務・経営の社内レビューを完了させる
4. 配布先ベンダー3〜5社を確定する

受注側：今週やる

1. 受領中のRFPを5軸のBid/No-Bid判断にかける（関係性 / 要件適合 / 収益性 / 工数対効果 / 戦略的価値）
2. Go判断の案件について、要件対応表のドラフトを72時間以内に作成する
3. Q&Aで投げる「課題理解の質問」を1〜3問用意する

受注側：提出前の最終チェック

• エグゼクティブサマリー（2ページ以内）で5要素（課題理解 / 提案コア / 期待効果 / 投資額 / リスク）を網羅できているか
• 要件対応表の「○」率が90%を超えていないか（誇張の疑いを持たれる）
• 価格を「初期 / 月額 / 5年TCO / オプション」の4段に分解できているか
• 類似実績3件以上、同業種・同規模の事例を含めているか

質の高いRFPは、発注側にとってプロジェクトの成否を、受注側にとって受注確率を大きく左右します。本記事のテンプレートと文例を起点に、まずは1案件、書き始めてみてください。