RFP（提案依頼書）の書き方｜制作会社・ベンダー選定で外さないための項目とテンプレート
制作会社やシステムベンダーを選ぶ場面で、「上がってきたものが想定と違う」「各社の見積の前提がバラバラで比較にならない」といった事態は珍しくありません。その多くは、依頼内容を文書化しないまま提案を求めてしまうことに原因があります。それを防ぐための文書がRFP（提案依頼書）です。この記事では、RFPとは何かという基本から、RFI・見積依頼書との違い、記載すべき項目、そのまま流用できるテンプレートまでを整理します。
RFP（提案依頼書）とは
RFPとは「Request For Proposal」の略で、日本語では提案依頼書と訳されます。発注者が、システム開発・Webサイト制作・広告運用などの外部委託にあたって、候補となる企業に「こういう課題を、こういう条件で解決したい。どう実現するか提案してほしい」と依頼するための文書です。
ここで押さえておきたいのは、RFPは仕様書ではないという点です。RFPが定義するのは「解決したい課題」と「満たすべき条件」であり、「どう作るか」という手段は提案側に委ねます。手段まで細かく指定してしまうと、ベンダーが持つ知見やより良い代替案を引き出せなくなり、RFPを出す意味が薄れてしまいます。
RFPが必要になる場面
- コーポレートサイトやサービスサイトのリニューアル
- 基幹システム、SFA／CRM、MAツールの導入・刷新
- 広告運用やコンテンツ制作のパートナー切り替え
- 複数社を比較して選定する必要があるとき（コンペ形式）
- 発注金額が大きく、社内稟議で選定理由の説明が求められるとき
逆に、発注先がすでに決まっていて金額も小さい単発業務であれば、正式なRFPまで整えず、簡易な依頼メモで足りるケースもあります。RFPは作成にも評価にも工数がかかるため、案件の規模と比較の必要性で判断してください。
RFI・見積依頼書・要件定義書との違い
RFPと混同されやすい文書がいくつかあります。目的と登場するタイミングで整理すると分かりやすくなります。
- RFI（情報提供依頼書）：候補企業を絞り込む前段階の文書。実績、体制、対応可能な範囲、概算費用感などの情報提供を求めます。市場にどんな選択肢があるか把握したい段階で使います。
- RFP（提案依頼書）：絞り込んだ数社に対し、課題解決の方法・体制・スケジュール・費用を含めた提案を依頼します。
- RFQ（見積依頼書）：やることが完全に固まっている前提で、価格を比較するための文書。提案の余地はほぼありません。
- 要件定義書：発注先が決まった後、契約に基づいて「何を作るか」を確定させる文書。多くの場合ベンダー側が作成し、発注者が承認します。
流れとしては、RFI → RFP → 選定 → 契約 → 要件定義、という順序になります。RFPの段階で要件定義書レベルの精度を求める必要はありません。
RFPを作成する4つのメリット
1. 提案が同じ土俵に乗る
条件を揃えずに提案を求めると、A社は保守費込み、B社は初期構築のみ、といった具合に前提が食い違い、価格も内容も比較できなくなります。RFPで前提を明示すれば、提案は同じ条件下で並べられます。
2. 社内の要求が整理される
RFPを書く過程では、関係部署の要望を集めて優先順位をつける作業が必ず発生します。この作業自体が、社内で曖昧なままだった目的や譲れない条件を可視化してくれます。
3. 認識のズレによる手戻りを防げる
プロジェクト後半で発覚する「聞いていない」「含まれていると思っていた」というトラブルは、スコープが文書化されていないことが原因です。RFPは、契約後の認識合わせの土台としても機能します。
4. 選定理由を説明できる
評価基準を事前に定めたRFPがあれば、「なぜこの会社を選んだのか」を稟議や監査の場で客観的に説明できます。属人的な判断に見えない選定プロセスは、社内の合意形成を大きく楽にします。
RFPに記載すべき11の項目
業種やプロジェクトの性質を問わず、おおむね次の11項目を押さえておけば提案依頼書として成立します。
1. プロジェクトの背景と目的
なぜ今このプロジェクトに取り組むのか、達成したい状態は何かを書きます。「サイトを新しくしたい」ではなく「問い合わせ件数を月30件から60件に増やしたい」のように、目指す成果まで書くと提案の質が変わります。自社の事業概要や体制も簡潔に添えます。
2. 現状の課題
現行システムやサイトの構成、運用フロー、実績データ（アクセス数、処理件数、工数など）と、そこで起きている問題を具体的に記載します。数値と事実で書くほど、提案側は的確な打ち手を出せます。
3. 依頼したい業務範囲（スコープ）
依頼する範囲と、依頼しない範囲の両方を書くのがポイントです。「原稿・写真は自社で用意」「保守は別契約」のように境界を明示しておくと、後の追加費用トラブルを避けられます。
4. 要件（機能要件・非機能要件）
必要な機能（機能要件）に加えて、性能、セキュリティ、可用性、対応ブラウザ、アクセシビリティ、既存システムとの連携といった非機能要件も忘れずに記載します。それぞれに「必須」「推奨」「任意」の区分をつけると、予算に応じた提案の幅が生まれます。
5. 成果物と納品形態
何が納品されれば完了とみなすかを定義します。デザインデータ、ソースコード、設計書、マニュアル、著作権・ソースコードの帰属など、後から揉めやすい部分ほど先に書いておきます。
6. スケジュール
公開・稼働の希望日と、動かせない制約（キャンペーン開始日、既存契約の満了日など）を書きます。制約が明確なら、提案側は実現可能性を踏まえた工程を組めます。
7. 予算
上限額または想定レンジを提示します。初期費用と運用費用を分けて示すと、比較しやすい見積が返ってきます。予算を隠すと、実現不可能な提案や過剰な提案が混ざり、比較工数が無駄に増えます。
8. 体制と役割分担
自社側の担当者と意思決定者、稼働可能な工数、会議の頻度などを示します。発注側がどれだけ動けるかによって、ベンダーが提案すべき進め方は変わります。
9. 提案してほしい内容と提出物
提案書に含めてほしい項目（実現方針、体制図、スケジュール、見積内訳、類似実績、リスクと対策など）を列挙します。目次レベルで指定すると、各社の提案書が同じ構成で揃い、比較が一気に楽になります。
10. 選定基準と評価方法
何を、どの重みで評価するかを事前に開示します。たとえば「課題理解と提案内容40点、実績・体制25点、費用25点、運用サポート10点」といった配点です。基準を先に公開しておくと、提案の焦点が定まり、社内の評価もぶれません。
11. 提出方法・スケジュール・問い合わせ窓口
提出期限、提出先、ファイル形式、質問受付期間と回答日、プレゼンテーションの有無と日程、選定結果の通知時期を記載します。秘密保持の扱いについても一言添えておきます。
そのまま使えるRFPテンプレート
以下の構成をそのまま見出しとして使い、各項目を埋めていけばRFPとして機能します。A4で10〜20ページ程度が目安です。
- 表紙（案件名／発行日／発行部署／担当者）
- はじめに（本書の目的、取り扱いの注意、秘密保持）
- 自社紹介（事業概要、組織、関連サービス）
- プロジェクトの背景と目的（達成したい成果・KPI）
- 現状と課題（現行環境、実績データ、問題点）
- 依頼範囲（対象範囲と対象外範囲）
- 要件一覧（機能要件／非機能要件、必須・推奨・任意の区分）
- 成果物と権利の帰属
- スケジュール（マイルストーンと制約条件）
- 予算（初期費用／運用費用、上限またはレンジ）
- 体制と役割分担（自社側・委託先側）
- 提案依頼事項（提案書に含めてほしい項目一覧）
- 選定方法（評価項目と配点、選定プロセス）
- 提出要領（期限、形式、提出先、質問受付、プレゼン日程）
- 補足資料（現行サイト構成図、画面一覧、データ定義など）
RFP作成から選定までの5ステップ
ステップ1：社内ヒアリングで要求を洗い出す
利用部門、情報システム部門、経営層など、関わる立場ごとに困りごとと期待を集めます。この段階では取捨選択せず、まず全部出し切るのがコツです。
ステップ2：要求に優先順位をつける
集めた要求を「必須（これがないと導入する意味がない）」「推奨（あると効果が上がる）」「任意（余力があれば）」に仕分けます。すべてを必須にしてしまうと、予算内で収まる提案が返ってこなくなります。
ステップ3：RFPを執筆し、社内承認を得る
前章の構成に沿って書き上げ、配布前に決裁者の合意を取っておきます。提案を受け取ってから前提が覆るのが、最も避けたい事態です。
ステップ4：候補企業へ配布し、質疑応答期間を設ける
質問は書面で受け付け、回答は全社に共有するのが公平です。この質疑応答で出てくる質問の内容自体が、RFPの不足箇所を教えてくれます。
ステップ5：評価表で採点し、選定する
RFPで公開した配点に沿って、複数名で個別に採点してから議論します。先に議論すると声の大きい意見に引きずられるため、採点を先に済ませるのが定石です。
RFPで失敗しないための5つの注意点
- 手段を指定しすぎない：「このCMSで」「この構成で」と決め打ちすると、より適した選択肢が提案されなくなります。制約がある場合はその理由も添えます。
- 曖昧な形容詞を避ける：「使いやすく」「モダンに」では評価できません。「3クリック以内で申込完了」「主要動線でスマートフォン表示3秒以内」のように、判断できる基準に落とします。
- 依頼社数を絞る：提案作成にはベンダー側にも相応の工数がかかります。3〜5社程度が現実的で、それ以上は評価する側の負担も膨らみます。
- 十分な提案期間を取る：配布から提出まで2〜4週間は確保します。短すぎると、使い回しのテンプレート提案しか集まりません。
- 評価基準を後出ししない：提案を見てから基準を決めると、選定の説明責任を果たせません。配点は必ず配布前に固めます。
RFPに関するよくある質問
予算は開示すべきですか
開示を推奨します。「安く抑えたいから隠す」という発想は理解できますが、実際には予算感の合わない提案が混ざって比較が難しくなるだけです。上限を示したうえで、その範囲内での最善案を求めるほうが、結果的に良い提案が集まります。
RFPの分量はどのくらいが適切ですか
A4で10〜20ページ程度が一般的です。ただし分量より、判断に必要な情報が揃っているかが重要です。詳細な画面一覧やデータ定義は本文に詰め込まず、別添資料に分けると読みやすくなります。
要件が固まっていない段階でもRFPは出せますか
出せます。むしろRFPは、要件が完全に固まる前に「解決したい課題」を提示して知恵を借りる文書です。固まっていない部分は「未確定」と明記し、その領域についての提案も歓迎する旨を書いておくと、建設的な提案が返ってきます。
選定に漏れた企業への連絡は必要ですか
必要です。工数をかけて提案してもらった以上、結果は速やかに通知し、可能な範囲で理由も伝えます。丁寧な対応は自社の評判につながり、次回以降のコンペで良い会社に参加してもらえるかどうかを左右します。
まとめ
RFP（提案依頼書）は、外部パートナーに「解決したい課題」と「満たすべき条件」を伝え、比較可能な提案を集めるための文書です。背景と目的、課題、スコープ、要件、予算、評価基準という骨格を押さえれば、形式にこだわらなくても十分に機能します。
作成の手間は決して小さくありませんが、その過程で社内の要求が整理され、選定後の手戻りが減ることを考えれば、投じる価値のある工数です。まずは本記事のテンプレート構成をたたき台に、自社の案件に合わせて項目を足し引きするところから始めてみてください。