RFPにおける「Request」とは？提案依頼書の基本を解説

システムの開発やリプレイスに際して、委託先の開発会社に自社の要望を正確に伝える必要があります。このとき発行するのがRFP（Request for Proposal）です。

提案依頼書（RFP）テンプレート

マーケティングオートメーション用ソフトウェアベンダー選定のために必要な確認事項が整理されたテンプレート

• リード管理ソリューション選定時の検討質問項目を確認
• マーケティング自動化効果の要因を検討
• 自社の課題を理解して解決策を提供してくれるベンダーを選ぶ

今すぐ無料ダウンロードする 詳しく見る 今すぐ無料ダウンロードする

今すぐダウンロードする

全てのフィールドが必須です。

ダウンロードの準備ができました

下記のボタンよりダウンロードいただけます。

今すぐダウンロードする

今回は、RFPの軸となる「Request」の意味やRFPを作成する目的についてわかりやすく解説します。要望事項を漏れなく記載するために必要な項目も挙げていますので、ぜひ参考にしてください。

RFPにおける「Request」の内容を理解するには、そもそもRFPとは何かを正確に把握する必要があります。RFPの意味や作成する目的について整理しておきましょう。
 

発注企業が業務委託の際に作成する「提案依頼書」

RFPは「提案依頼書」と訳されるとおり、発注側企業が委託先の候補となる企業に自社の課題や開発目的、希望するシステム要件などを伝え、具体的な提案を依頼するための文書です。

システム開発と一口に言っても、システムの用途や解決したい課題、必要としている機能などは発注企業ごとにさまざまです。自社が必要としているシステムを開発するとともに、不要な機能や性能が実装されて開発コストがかさむことのないよう、要望を正確に伝える必要があります。事前にRFPを発行し、開発会社に共有しておくのはこのためです。
 

RFPを作成する目的

RFPを作成する最終的な目的は、実際に発注すべき開発会社を適切に選定することにあります。発注側企業が求めているシステムを正確に把握していなければ、受注側企業は適切な提案ができません。そこで「どのような提案をしてほしいか」を伝え、共有しておく必要があります。

RFPで示された要望に沿って、各開発会社は提案書を作成します。受領した提案書を元に開発会社を選定し、正式に発注する開発会社を決定するのがRFP発行後の基本的な流れです。
 

RFPは誰が発行する？

RFPは発注側企業の要望を伝えることを目的とした文書のため、発行するのは発注側の企業です。RFPを受領した開発会社が不明点などを質問し、発注側企業とやり取りを重ねながら提案書を作成する場合はあるものの、基本的には発注側企業がイニシアチブを取って進める必要があります。

ただし、RFPに漏れや不備があった場合、適切な提案が受けられないだけでなく、開発が始まってから認識の食い違いや追加の要望が発生するおそれがあります。十分な作成ノウハウが自社にない場合には、RFPを外注して作成支援を受けるのも1つの方法です。
 

RFPにおける「Request」とは、具体的に何を指しているのでしょうか。抜けや漏れのない提案依頼書を作成するために、必要な記載項目を確認しておきましょう。
 

開発体制と役割

開発プロジェクトをどのような体制で進めるのか、携わるメンバーはそれぞれどのような役割を果たすのかを提案書に記載してもらう必要があります。とくにプロジェクトマネージャーの力量は円滑なプロジェクトの進行や成果物の質に大きく影響するケースが多いことから、実績や経歴などを具体的に記載してもらうことが重要です。

メンバーに関しては、受注前の段階で決定していないことも想定されます。この場合、提案書には役割のみ記載してもらい、メンバーは「未定」と記載するなど、具体的な記載方法を伝えておくことが大切です。
 

稼働時期・スケジュール

発注側企業が希望する稼働開始時期を記載します。これを元に受注側企業がスケジュールを組み、提案書に記載するという流れです。

提案書には、要件定義や開発工程、テスト運用なども含めて詳細なスケジュールを記載してもらうことが重要です。週単位でスケジュールの記載を依頼するなど、いつまでに何を完了するのかが確認できる記載方法を指定しておく必要があります。
 

予算

発注側企業が想定している予算を記載します。プロジェクトの具体的な予算のほか、予算に含まれる範囲を明示することが大切です。

受注側企業は基本的にはRFPで提示された予算の範囲内で費用を設定し、提案書に記載します。発注先の決定後、より詳細な見積もりを依頼する際には、RFQ（Request for quotation：見積依頼書）を発行するケースも少なくありません。RFPは発注先の決定前（選定段階）で発行するのに対して、RFQは発注先決定後に発行する点が大きな違いです。
 

機能要件

システムに実装する必要がある機能や、実現したいことを具体的に記載します。RFPに記載された機能要件に漏れや不備があると、提案書の受領後に追加の要望をせざるを得なくなり、費用や納期に影響が及ぶ可能性も否定できません。必要とする機能を漏れなく詳細に記載することによって、こうした認識の齟齬を防ぐことが大切です。
 

非機能要件

機能要件に含まれない事項は、非機能要件として記載します。希望する拡張性やセキュリティ要件、操作性に関する要望などは、非機能要件に記載しておくべき要望事項の一例です。

ただし、非機能要件とはいえ「使いやすいUI」などの曖昧な表現は避けたほうがよいでしょう。何をもって「使いやすい」と考えるかは、発注側と受注側で捉え方が異なる可能性があります。たとえば、「エラー発生時にはエラーメッセージを表示する」といったように、具体的に何を実現したいのかを明確に記載するのがポイントです。
 

その他の要件

機能要件・非機能要件のどちらにも該当しない要望がある場合には、「その他の要件」の項目に記載します。たとえば、プロジェクト進捗状況の報告を求める頻度や、システムの操作研修などに関する要望などは、その他の要件に記載すべき事柄の一例です。

とくにシステムをリプレイスする際には、現行のシステムからどのようにデータを移行するのかを詳細に決めておく必要があります。開発会社に依頼したい作業内容やデータの形式など、事前に共有するべき情報を記載しておくことが大切です。
 

RFPにおける「Request」を正しく理解するには、RFPが果たす役割や発行する目的を正確に把握しておくことが重要です。各開発会社はRFPにて示された要望事項にもとづいて提案書を作成するため、抜けや漏れのないよう要望を伝える必要があります。今回紹介したRequestの項目を参考に、自社の要望が正確に伝わるRFPを作成しましょう。