システム開発を外注するとき、ベンダーから自社に合った提案を引き出せるかどうかは、最初に渡すRFP（提案依頼書）の出来でほぼ決まります。とはいえ「RFPって何を書けばいいの？」「要件定義とどう違うの？」と手が止まってしまう発注担当者は本当に多いです。
私が発注側のお手伝いをする現場でも、RFPの書き方が分からないまま口頭やメールで依頼してしまい、各社の提案がばらばらで比較できない、という相談をよく受けます。RFPは特別な書類ではなく、目的と目次構成さえ押さえれば、初めてでも十分に書けます。
この記事では、システム開発のRFPの書き方を、書く目的と目次構成、章ごとのサンプル文、テンプレートの考え方、そしてよくある失敗まで一通り整理します。読み終えたとき、自社のRFPを自分の手で書き始められる状態を目指します。
この記事のポイント
- RFPは発注側が課題と要望を伝え、ベンダーから比較できる提案を引き出すための文書
- 目次は「概要・要求事項・選定の進め方」の3ブロックに整理すると書きやすい
- 要件定義はベンダー決定後に作る別物で、RFPは選定前に渡す依頼書
- 章ごとのサンプル文を土台に、自社の課題と優先順位を具体的に書き込むのがコツ
目次
RFPの書き方の基本と目次構成・記載項目
RFPの書き方は、いきなり文章を書き始めるより先に「何のために書くのか」と「どんな構成で書くのか」を押さえると、ぐっと迷いが減ります。まずはRFPの目的と、目次構成・記載項目の全体像から整理していきます。
RFP（提案依頼書）とは｜書く目的と必要性
RFPは「Request for Proposal」の略で、日本語では「提案依頼書」と訳します。自社の課題を解決するシステムを開発してもらうために、発注側がベンダーやSIerに対して「何に困っていて、どんなシステムを、どんな条件で作ってほしいか」を伝え、提案を依頼する文書です。
発注側は、検討している複数のベンダーへ同じRFPを配ります。ベンダーはRFPをもとに、解決策・システム構成・費用・スケジュールなどを提案書としてまとめ、発注側はその提案を見比べて依頼先を選びます。つまりRFPは「提案を引き出すための共通のものさし」です。
極端に言えば、RFPがなくてもシステム開発は依頼できます。ただRFPがないと、各社が前提を勝手に推測して提案するため、見積もりの範囲も金額もばらばらになり、横並びで比較できなくなります。私の感覚では、RFPを書くこと自体が「自社が本当に解決したい課題は何か」を社内で言語化する作業になり、ここで要望が整理される効果のほうが大きいくらいです。
RFPを書く目的を整理すると、次の3つになります。
- 自社の課題と要望を、誰が読んでも同じ理解になる形でベンダーに伝える
- 各社の提案を同じ土俵で比較し、選定の根拠を残す
- 発注後の認識のズレや「言った・言わない」のトラブルを未然に防ぐ
RFPと要件定義・RFI／RFQ・提案書の違い
RFPは似た書類と混同されやすいので、ここで違いをはっきりさせておきます。特に「要件定義書」と「提案書」との取り違えは、現場でもよく見かけます。
| 書類 | 作る人 | 作るタイミング | 目的 |
|---|---|---|---|
| RFP（提案依頼書） | 発注側 | ベンダー選定前 | 課題と要望を伝え提案を引き出す |
| RFI（情報提供依頼書） | 発注側 | RFPの前 | 各社の実績や技術情報を集める |
| RFQ（見積依頼書） | 発注側 | 提案内容が固まった後 | 条件をそろえて費用を依頼する |
| 提案書 | ベンダー側 | RFPを受け取った後 | RFPへの回答として解決策を示す |
| 要件定義書 | 主にベンダー側 | 発注先の決定後 | 作る機能や性能を詳細に確定する |
要件定義書とRFPの一番の違いは、作るタイミングです。RFPはベンダーを選ぶ前に渡す依頼書で、要件定義書は発注先が決まった後に、開発する機能や性能を具体的に固めるための仕様書です。RFPでは「実現したいこと」を要求として書き、要件定義では「どう作るか」まで踏み込む、という棲み分けになります。要件定義の進め方そのものは要件定義の進め方を発注側目線で解説した記事で詳しく扱っているので、発注後の流れもあわせて押さえておくと安心です。
また、情報収集のためのRFIや、費用だけを依頼するRFQと混同すると、RFPに書く粒度を誤ります。RFI・RFQとRFPをどの順番で使い分けるかはRFI・RFQ・RFPの違いと使い分けを整理した記事にまとめているので、自社がいまどの段階かを確認してから書き始めると無駄がありません。
RFPを書く前の社内調整と優先順位
RFPの書き方で意外と抜けやすいのが、文章を書く前の社内調整です。RFPはベンダーに渡す文書ですが、実際には社内の期待値をそろえる文書でもあります。事業部、情シス、現場担当、決裁者の間で目的や優先順位がずれたまま書くと、RFPの中で「全部やりたい」「でも予算は抑えたい」という矛盾が出ます。
書き始める前に、最低限そろえておきたい前提は次の4つです。
- 今回のプロジェクトで最も解決したい課題は何か
- 必須要件と、できれば実現したい歓迎要件は何か
- 予算感・希望納期・社内の意思決定期限はどこまで出せるか
- 価格、実績、提案力、体制など、何を重視して選ぶか
特に、要求事項は「必須」と「歓迎」に分けておくと提案を比較しやすくなります。すべてを必須にすると、ベンダーは現実的な代替案を出しにくくなり、逆にすべてを曖昧にすると、各社の提案範囲がばらばらになります。RFPを書く前に社内で優先順位を決めておくことが、結果的に書き方の迷いを減らします。
RFPの目次構成と記載項目の一覧
RFPの目次は、大きく「概要」「要求事項」「選定の進め方」の3ブロックに分けて考えると整理しやすいです。代表的な目次構成と記載項目をまとめると、次のようになります。
| 大項目 | 記載する内容 |
|---|---|
| はじめに | 依頼の趣旨、強調したい点、機密保持（NDA）の取り扱い |
| 会社概要 | 事業内容、組織体制、関連サービスの概要 |
| プロジェクト概要 | 背景、現状の課題、システム化の目的、達成したい目標 |
| システム化方針 | 現行システムの全体図と利用状況、主要課題、新システムの方針 |
| 要求事項 | 機能要件、非機能要件（セキュリティ・保守運用など）、その他要望 |
| 契約事項 | 体制、作業場所、費用負担、知的財産権などの取り決め |
| 提案依頼内容 | 提案してほしい対象範囲、提案書に含めてほしい項目 |
| 今後のスケジュール | 提案書の回答期限、選考フロー、決定時期 |
| 参考資料 | 現行画面、業務フロー図など必要に応じて添付 |
すべてを完璧に埋めようとする必要はありません。大切なのは、最重要項目である「プロジェクト概要（＝何を解決したいか）」と「要求事項（＝何を満たしてほしいか）」を具体的に書くことです。ここが曖昧だと、いくら他の項目を整えても提案の質は上がりません。逆にこの2項目さえ明確なら、他は最低限でもベンダーは提案の方向性をつかめます。
RFP作成の進め方と回答期限・選定フロー
RFPは書いて終わりではなく、配ってから選定までの進め方までを設計しておくと、後半で慌てません。一般的な進め方は次の流れです。
- RFPを作成し、検討中のベンダー数社へ同時に配布する
- ベンダーからの質疑を受け付け、回答は全社へ共有する
- 提案書とおおまかな見積もりを受領する
- 書類選考で数社（目安3社程度）に絞り込む
- プレゼンテーションを実施し、評価基準にそって採点する
- 発注先を決定し、各社へ結果を通知する
進め方で特に注意したいのが、提案書の回答期限です。配布から提出まで、最低でも2〜3週間は確保しましょう。期間が短いと、ベンダーは無難で当たり障りのない提案しか出せず、本来引き出せたはずの工夫が削られてしまいます。質疑への回答を一社だけに返すと公平性を欠くため、質問と回答はすべての参加社へ共有するのが原則です。
あわせて、RFPの段階で「何を基準に選ぶか」を決めておくと、提案が出そろってから迷いません。価格だけでなく、課題理解の深さ、提案の具体性、体制や実績などを評価軸にし、点数化できる形にしておくのがおすすめです。配布後に集まった提案を横並びで採点するときは、ベンダー選定比較表テンプレート（10カテゴリ100項目）のような採点フォーマットを用意しておくと、感覚ではなく根拠で選べます。選定そのものの進め方はベンダー選定の進め方を解説した記事も参考にしてください。
RFPの書き方をサンプル文と注意点で実践
ここからは、実際のRFPの書き方を章ごとのサンプル文で見ていきます。以下はWebサイトリニューアルを例にした文例です。自社の状況に置き換え、課題と優先順位を具体的に書き込んでいけば、初めてでも形になります。
「はじめに」「プロジェクト概要」のサンプル文
「はじめに」では、依頼の趣旨と、機密情報の取り扱い（NDA）を簡潔に伝えます。最初に強調しておきたい前提があれば、ここに書いておきましょう。
| 弊社Webサイトのリニューアルにあたり、本依頼書に基づく具体的なご提案をお願いいたします。本書には貴社にご提案いただく際の参考となるよう、弊社の現状と要望を記載しております。記載内容は、別途締結する秘密保持契約（NDA）に基づき慎重にお取り扱いください。 |
「プロジェクト概要」では、リニューアルに至った背景と現状の課題、システム化の目的を書きます。同じ課題でも、背景によって最適な解決策は変わるため、ベンダーが提案の方向性を判断できるよう、ここはできるだけ具体的に書きます。
| 弊社の現行サイトは情報の更新に手間がかかり、製品・サービス紹介ページがほとんど更新できていません。その結果、注力したい営業内容とサイトの内容にズレが生じています。今回のリニューアルでは「◯◯サービス」の認知度・集客の向上を最優先とし、ターゲット層へ適切に情報を届けられるサイトの構築を目指します。 |
「システム化方針」「要求事項」のサンプル文
「システム化方針」では、現行システムの構成と利用状況、抱えている課題、そして新システムで目指す方針を書きます。現行を継続するのか刷新するのかも、ここで明示しておきます。
| 現行システムは◯◯を採用し、利用者は約◯名、対象は全◯拠点です。リニューアル後も現行基盤の継続利用を想定しています。ただし、現状はHTMLの知識がないと更新できず、社内で対応できる担当が限られている点が課題です。誰でも更新できる運用への改善もあわせてご提案ください。 |
RFPで最も重要な「要求事項」では、機能要件・非機能要件・その他要望を分けて書きます。すべてを細かく指定する必要はありませんが、外せない条件は明確にしておきましょう。
| 本プロジェクトで想定する要求事項は以下のとおりです。 ・機能要件：問い合わせ管理、コンテンツ更新、アクセス解析連携 ・非機能要件：バックアップ、セキュリティ、保守運用体制 ・その他：公開後の運用定着支援、クラウド環境での構築 上記を前提に、実現方法や優先順位については貴社のご提案を歓迎します。 |
「提案依頼内容」「スケジュール」のサンプル文
「提案依頼内容」では、提案してほしい対象範囲と、提案書に必ず含めてほしい項目を指定します。範囲を明示しないと、各社の見積もり前提がばらつき比較できなくなるため、対象内・対象外をはっきり分けて書きます。
| 提案対象は以下のとおりです。 ・コーポレートサイト（約200ページ） ・広告用ランディングページ（5ページ） ※会員サイトは今回のリニューアル対象外です。 ご提案には、企業情報・サービス内容・成果物（納品物）一覧・概算費用・オプション提案（SEOや集客施策など）を含めてください。 |
「今後のスケジュール」では、選考の流れと各期日を書きます。回答期限を明示し、ベンダーが準備期間を確保できるようにします。
| 選考スケジュールは以下を予定しています。 ・オリエンテーション：◯月◯日 ・質疑応答の受付期限：◯月◯日 ・提案書提出期限：◯月◯日（必着） ・一次審査（書類）：◯月◯日〜◯日 ・二次審査（プレゼン）：◯月◯日〜◯日 ・最終結果通知：◯月◯日（予定） |
「評価基準」「ベンダー要件」のサンプル文
RFPでは、提案書に何を書いてほしいかだけでなく、発注側がどの基準で選ぶかも書いておくと、ベンダーの提案精度が上がります。評価基準が見えないRFPは、各社が価格を下げる方向に寄りやすく、課題理解や体制の違いが比較しにくくなります。
評価基準を書くときは、重視する観点と配点の目安をセットで示します。厳密な点数表まで出せない場合でも、価格だけで決めないことは明記しておきましょう。
| 本提案では、価格だけでなく、以下の観点を総合的に評価します。 ・課題理解と提案方針：30% ・機能要件・非機能要件への対応方針：25% ・プロジェクト体制と類似実績：20% ・費用の妥当性と見積もりの透明性：15% ・保守運用・改善提案：10% 上記の観点を踏まえ、貴社が特に強みを発揮できる領域を具体的にご提案ください。 |
あわせて、ベンダーに求める条件も書いておくと、提案の前提がそろいます。たとえば、同業界の実績を必須にするのか、クラウド移行の経験を重視するのか、公開後の保守まで任せたいのかで、候補にすべき会社は変わります。
| 提案にあたっては、以下の情報を含めてください。 ・本プロジェクトと近い規模・業種の開発実績 ・プロジェクトマネージャーおよび主要メンバーの役割 ・要件定義から公開後の保守運用までの支援範囲 ・再委託の有無と、再委託する場合の管理方法 ・想定されるリスクと、その回避策 なお、すべての条件を満たすことを必須とはしません。代替案がある場合は、その理由と前提条件もあわせて記載してください。 |
このように書いておくと、ベンダー側も「何を評価されるのか」を理解したうえで提案できます。発注側も、提案書を受け取ったあとで評価軸を後付けせずに済むため、社内説明や稟議の根拠を作りやすくなります。
RFPテンプレートの使い方と作成時の注意点
ゼロから書くのが不安なら、世の中に公開されているRFPのテンプレートや雛形（Word・パワポ形式など）を下敷きにするのが近道です。ただし、テンプレートはあくまで「項目の抜け漏れを防ぐチェック表」として使うのがコツです。空欄を埋めるだけで満足してしまうと、どの会社にも当てはまる当たり障りのないRFPになり、提案の質も平凡になります。
テンプレートを使うときの注意点は次のとおりです。
- 自社の課題と優先順位は、テンプレートの定型文を消して自分の言葉で書き直す
- 使わない項目は無理に埋めず、思い切って削る（情報過多も比較を難しくする）
- 固有名詞・数値・期日は、テンプレートのサンプルのまま残さず必ず自社の値に置き換える
テンプレートに沿って項目をそろえたうえで、最重要の「プロジェクト概要」と「要求事項」だけは時間をかけて具体化する。この配分を意識すると、形式は整っているのに中身は薄い、という失敗を避けられます。
RFPでよくある失敗とその防ぎ方
最後に、RFPでつまずきやすい失敗と、その防ぎ方を整理します。私が現場で見てきたものを中心に挙げます。
- 要望を詰め込みすぎてゴールがぼやけ、各社の提案も焦点を欠いた
- 逆に要望が抽象的すぎて、各社の提案がばらばらになり比較できなかった
- 回答期限を短く設定しすぎて、踏み込んだ提案が集まらなかった
- 評価基準を決めずに進め、最後は声の大きさや価格だけで決めてしまった
- 納品物や知的財産権の取り決めが曖昧で、後から必要なデータを受け取れなかった
これらの多くは「最重要の課題を一つに絞る」「誰が読んでも同じ理解になる文章にする」「期限と評価基準を先に決める」の3点を意識すれば防げます。RFPの失敗は、最悪の場合プロジェクトの延期や追加費用に直結します。書き上げたら、社内の別の人に読んでもらい、要望が誤解なく伝わるかを確認してから配布しましょう。
RFPを書く過程で出てくる疑問もまとめておきます。
- Q. RFPのテンプレートはそのまま使っても大丈夫ですか？
- A. 項目の抜け漏れを防ぐ下敷きとしては有効です。ただしサンプル文や定型文をそのまま残すと、自社の課題が伝わらず提案が平凡になります。プロジェクト概要と要求事項は必ず自分の言葉で書き直してください。
- Q. RFPの回答期限はどのくらい設けるべきですか？
- A. 配布から提案書提出まで、最低でも2〜3週間が目安です。期間が短いとベンダーは無難な提案しか出せません。質疑応答の期間も別途設け、回答は全社へ公平に共有しましょう。
- Q. RFPと提案書はどちらが先に作るものですか？
- A. RFPは発注側が先に作って配る依頼書、提案書はそれを受け取ったベンダーが回答として作るものです。発注側が書くのはRFPで、提案書は受け取って比較する側になります。
