RFPの書き方|テンプレートより「なぜ作るか」を伝える
RFPとは
RFP(Request for Proposal)は「提案依頼書」と訳される文書です。システム開発を外部の開発会社(ベンダー)に依頼する際に、自社の状況や要望をまとめて伝えるために作成します。
RFPを受け取ったベンダーは、その内容をもとに提案書や見積もりを作成します。複数のベンダーに同じRFPを渡すことで、提案内容を比較し、自社に合ったパートナーを選定できるようになります。
似た文書として「RFI(情報提供依頼書)」や「RFQ(見積依頼書)」がありますが、それぞれ役割が異なります。RFIは検討初期にベンダーの情報を広く集めるためのもの、RFQは仕様が固まった段階で価格を確認するためのものです。RFPはその中間に位置し、具体的な提案を依頼する段階で使用します。
RFPを作成する目的
RFPを作成する目的は、委託先ベンダーの選定を正しく行うことにあります。
そのために必要なのが、自社の課題・目的・実現したいことを整理し、言語化するプロセスです。この整理ができていれば、ベンダーとの認識が揃いやすくなり、複数の提案を同じ基準で比較できるようになります。
RFPがないまま各社に個別で相談すると、前提条件がバラバラになり、どの提案が自社に合っているのか判断しづらくなってしまいます。
RFPは「ベンダーのための書類」ではなく、「正しいベンダー選定のための自社の整理」と捉えると、作成の意義が明確になるのではないでしょうか。
なお、RFP作成に入る前の企画段階で課題や目的を整理する方法については、「サービスデザインのフレームワーク – ビジネスプランを具現化する方法」も参考になるかと思います。
RFPで伝えるべきこと
本質を明確にする ― 背景・動機・望む結果
RFPで最も大切なのは、なぜこのシステムが必要なのか、どういう結果を望んでいるのかを具体的に伝えることです。
「どんな機能がほしいか」を伝えることも大事ですが、それだけでは開発会社は「言われた通りに作る」ことしかできません。一方、背景や動機、望む結果がしっかり伝わっていれば、開発会社は「その目的を達成するなら、こういう機能構成の方が良いのでは」「この部分は別のアプローチもあります」といった提案ができるようになります。
たとえば「予約システムがほしい」という依頼でも、その背景が「電話対応の負荷を減らしたい」のか「顧客データを蓄積してマーケティングに活かしたい」のかで、提案の方向性は変わります。さらに言えば、「なぜ電話対応の負荷を減らしたいのか」まで掘り下げることが大切です。社員の残業を減らして働きやすい環境を作りたいのか、新規事業に人員を割けるようにしたいのか。その先にある目的まで伝えることで、開発会社はより本質的な提案ができるようになります。
本質を言語化することで、開発会社がより適切な提案をしやすくなります。
機能・仕様を具体的に考える
一方で、機能や仕様を具体的に考えることも重要です。
「この画面ではこういう操作ができるようにしたい」「このデータはこういう形式で出力したい」といった具体的な要望を整理する過程で、「自分たちは本当に何を実現したいのか」が明確になることがあります。
つまり、本質を考えることと機能・仕様を考えることは対立するものではなく、行き来しながら整理していくプロセスです。本質を軸に持ちながら機能・仕様を具体化していくことで、RFPの精度が高まります。
機能を考える際には、ユーザーにとっての使いやすさも重要な観点です。「アプリの離脱を最小限に抑えるユーザビリティの考え方」では、ユーザー視点での設計について解説していますので、あわせてご覧ください。
選定すべきベンダーは理解力と提案力
同じRFPを複数のベンダーに渡したとき、本質をどれだけ理解し、提案に反映できるかで差が出ます。
書かれた内容をそのまま見積もるベンダーもいれば、背景を汲み取って「こうした方がいいのでは」と提案してくるベンダーもいます。後者のようなベンダーは、プロジェクト開始後のコミュニケーションもスムーズになりやすいと考えられます。
RFPに本質をしっかり書くことは、ベンダーの理解力・提案力を見極める材料にもなります。
RFPに記載する項目
RFPに決まったフォーマットはありませんが、一般的に以下の項目を含めることが多いです。
| 項目 | 内容 |
|---|---|
| 会社概要 | 自社の事業内容、規模、組織体制など |
| プロジェクトの背景・課題 | なぜこのシステムが必要になったのか |
| 目的・望む結果 | システム導入によって何を実現したいのか |
| 対象範囲(スコープ) | 何を依頼し、何を依頼しないのか |
| 機能要件 | 必要な機能の一覧 |
| 非機能要件 | セキュリティ、可用性、拡張性など機能以外の要件 |
| 保守・運用体制 | リリース後の保守や運用の期待値 |
| スケジュール | 希望する稼働時期、主要なマイルストーン |
| 予算 | 想定している予算の範囲 |
| 評価基準 | 提案を評価する際に重視するポイント |
| 提案の形式・提出期限 | 提出物の内容、期限、質問の受付方法 |
弊社でも、大手電力会社の新規事業向け予約システムや、人材系企業のグローバル向けマッチングプラットフォームなど、さまざまなプロジェクトに携わってきました。その経験から言えるのは、「対象範囲」の認識がズレると、後から大きな手戻りにつながりやすいということです。予約機能だけなのか、決済まで含むのか、リリース後の保守も依頼するのか。こうした境界を明確にしておくことが大切です。
なお、非機能要件のうちセキュリティについては、「新規事業のアプリセキュリティ入門|”リリースと成長”を止めないための3ステップ」で詳しく解説しています。
作成時に意識したいこと
項目を埋めるだけでなく、以下の点を意識するとより伝わりやすいRFPになります。
予算やスケジュールは現実的な範囲で明示する
「まず見積もりを見てから」という気持ちもあるかもしれませんが、予算感がまったくわからない状態では、ベンダーも適切な提案がしづらくなります。概算でも構わないので、想定している範囲を示しておくと、提案の精度が上がります。
「対象外」も書いておく
何を依頼するかだけでなく、何を依頼しないのかも明記しておくと、認識のズレを防げます。「既存システムとの連携は対象外」「マニュアル作成は自社で行う」など、境界を明確にしておくことをお勧めします。
社内用語になっていないか確認する
自社では当たり前に使っている言葉が、社外には通じないことがあります。業界特有の用語や社内システムの名称などは、補足説明を加えるか、一般的な表現に置き換えると親切です。
まとめ
RFPは、テンプレートを埋めることがゴールではありません。
大切なのは、「自社が何を実現したいのか」という本質を整理し、言語化することです。背景・動機・望む結果がしっかり伝われば、開発会社から良い提案が出てきやすくなります。そして、その提案の質を見ることで、自社に合ったパートナーを見極めることができます。
形式に囚われすぎず、まずは「なぜこのシステムが必要なのか」を言葉にするところから始めてみてはいかがでしょうか。
