初めてでも大丈夫！【RFP】の書き方を項目ごとに解説【記載例付き】

システム開発や大規模なリプレイスを依頼する際には、自社の課題を解決できる開発パートナーを適切に選考する必要があります。その際に欠かせないのが、開発ベンダー各社に具体的な提案内容を依頼する「RFP（提案依頼書）」です。

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

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

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

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

今すぐダウンロードする

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

フォームは利用できません

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

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

今すぐダウンロードする

今回は、RFPの基本構成と、項目ごとの具体的な記載例を紹介します。各項目で押さえておきたいポイントについてもまとめていますので、ぜひ参考にしてください。

RFP（Request for Proposal：提案依頼書）とは、システム開発などの大きなプロジェクトを外部に委託する際に、さまざまな開発ベンダーから提案を募集するための文書です。発注側が目的や条件を示し、それに対して複数のベンダーが提案書を提出します。

RFPを作成することで、ベンダーに自社の要望やシステム開発を通して達成したい目的を正確に伝え、それを実現するための適切なマッチングにつながると期待できます。

大規模なシステム開発においては、工程において似たような文書や要素がいくつか登場します。
 

RFIとの違い

RFPと似たような文書に、RFI（Request for Information：情報依頼書）があります。RFPが、各ベンダーに具体的な提案を求める文書であるのに対し、RFIはRFPよりも前に各ベンダーのサービス内容や費用感を大まかに把握するために作成します。

RFIは、どのようなサービスや技術が市場に存在するか、業界の動向はどうなっているかといった、広範な情報を収集することを目的としています。まだ具体的な発注を前提としない初期調査の段階で使われ、RFP作成のための材料を集めるために活用されます。プロジェクトの規模によっては、RFIは作成されないこともあります。

RFPとRFIの詳しい違いについては、以下コラムをあわせてご覧ください。

RFQとの違い

RFP、RFIと似たような文書に、RFQ（Request for Quotation：見積依頼書）があります。RFQは、ほとんど依頼するベンダーを絞り込めた後に、主に価格や納期といった定量的な見積を依頼するための文書です。

プロジェクトの仕様がすでに明確になっており、業者間での価格や条件を比較するために使われます。RFPが「どのような提案が最適か」を検討する段階で使われるのに対し、RFQは「決まった仕様に対して、いくらでやってくれるか」を確認する段階で使われます。
 

要件定義との違い

システム開発においては、重要なフェーズとして「要件定義」があります。要件定義とは、導入するシステムの具体的な性能や実装したい機能を洗い出し、目的を実現するための詳細な設計をするフェーズです。

RFPを作成する際、自社が開発ベンダーに対して求める要求事項を記しますが、この段階で要件定義のような具体的な項目は記さないほうがよいとされています。システムの導入規模にもよりますが、RFPの時点で要件定義まで含めてしまうと、ベンダー側がパッケージをベースとした提案をしにくくなり、よい提案が出にくくなるためです。
 

RFP作成の主な流れ

RFPを作成する際は、まずシステム導入やリプレイスを通じてどのような課題を解決し、どのような業務の形を目指すのかを明確にします。導入の影響を受ける部署や担当者からヒアリングを行い、課題をまとめ、新システムに何を期待するかをはっきりさせます。

次に、案件を依頼する開発ベンダーの情報収集フェーズに入ります。各ベンダーがどのような技術・製品・ソリューション・実績を持っているかを調査することで、RFPを送付する候補を絞り込んでいきます。このとき、RFIを作成・送付することでより具体的な情報の提供を各ベンダーに求めることもあります。

開発ベンダーの情報を収集できたら、システム開発において無理な面やこだわってもよい面がわかってくるため、要望を修正しつつ、RFPを作成していきます。
 

RFPは基本的に下記の3要素から構成されています。

• 概要
• 提案依頼内容
• 選考の進め方

概要では、今回のプロジェクトの内容を説明します。プロジェクト発足の背景や課題、システム導入によって目指すゴールなどを示すことで、自社の要望を開発ベンダーへ伝えます。

提案依頼内容では、提案書に含めて欲しい内容を記します。RFPを受け取った各ベンダーは、ここを見て提案書を作成します。

選考の進め方では、提案書のどのような点を評価して開発パートナーを決めるのかを記します。
 

1. 概要

RFPの概要パートでは、具体的に下記のような項目を記載していきます。

2. 提案依頼内容

提出を依頼する提案書に盛り込んでほしい情報を記載するパートです。提案依頼内容を明確にすることで、自社にとって最適な提案を受けられる可能性が高まります。具体的な記載項目は下記のとおりです。

3. 選考の進め方

RFPへの回答となる提案書を受領後、具体的にどのような方法・スケジュールでベンダーを選定するかを記載するパートです。

評価の基準や進め方を各ベンダーが把握できれば、それに則ったよい提案を受けられる可能性が高くなります。また、発注までのスケジュールを事前に伝えておくことで、実際に契約を締結する際に双方の認識を合わせた上でスムーズに進められるようになります。

ここからは、RFPの項目ごとに記載例と記載のポイントを紹介します。実際にRFPを作成する際には、文面と押さえておくべきポイントを参考にしてください。
 

【概要】会社名・プロジェクト名（表紙）

【記載のポイント】

RFPの表紙にあたる部分です。プロジェクトの名称と発注者側の企業名を記載します。いずれも略称などは用いず、正式名称で記載しましょう。

送付先のベンダーが何に関する文書であるのか一目で判断できるように記載するのがポイントです。
 

【概要】発注者の会社情報

【記載のポイント】

発注側企業の基本情報を記載するパートです。開発会社が依頼元について調査する手間を省くことが主な目的のため、可能な限り詳細な情報を記載しておくことをおすすめします。
 

【概要】プロジェクト概要

【記載のポイント】

概要には、プロジェクトの全体像を記載します。RFP自体の位置づけや記載項目をここにまとめて提示しておくのも1つの方法です。
 

【概要】プロジェクトの背景

【記載のポイント】

プロジェクトが発足した経緯を記載することにより、プロジェクトの位置づけや現在の状況を共有するためのパートです。詳細な課題については後述する「現状の課題」に記載するため、ここでは簡潔に経緯のみ記載するだけで構いません。
 

【概要】現状の課題

【記載のポイント】

発注側企業が現状何に困っているのか、何を解決したいのかを記載します。複雑な業務フローを記載する必要がある際には、図示するのも1つの方法です。
 

【概要】目的・ゴール

【記載のポイント】

プロジェクトを通じて達成したい目的やゴールを記載し、受注側企業と共有するためのパートです。定量的な目標が記載できる場合には、できるだけ具体的に記載するのがポイントです。
 

【概要】現行のシステム環境

【記載のポイント】

プロジェクトに直接関係するシステム・アプリケーションはもちろん、直接は関係しないものも含めてすべて記載するようにします。そうすることで、周辺アプリケーションも巻き込んだ提案をもらえる可能性があります。
 

【概要】現行の使用機器

【記載のポイント】

新しく導入するシステムを実際に動かす環境を伝えるパートとなるため、スペックまで詳しく記載します。
 

【提案依頼内容】開発体制と役割

【記載のポイント】

具体的な開発体制と、携わる方々の役割を受注側企業に記載してもらうためのパートです。

とくにプロジェクトマネージャーは円滑な開発を実現する上で重要なポイントとなるため、具体的な経歴や実績を記載してもらうことをおすすめします。
 

【提案依頼内容】稼働時期・スケジュール

【記載のポイント】

プロジェクト全体のスケジュールと、開発フェーズごとのスケジュール概要を伝えてもらうよう依頼するためのパートです。スケジュールの全体像と詳細な進行予定の両面から確認できるように依頼しましょう。
 

【提案依頼内容】機能要件

【記載のポイント】

システムに必須の機能を伝えるためのパートです。のちのち追加の機能を要望することのないよう、抜け漏れなく記載する必要があります。
 

【提案依頼内容】非機能要件

【記載のポイント】

機能要件以外の要望事項を記載するためのパートです。セキュリティや操作性など、機能要件には含まれないものの必須の要件を整理して記載しましょう。
 

【提案依頼内容】成果物

【記載のポイント】

開発するシステムはもちろん、一緒に納品されるマニュアルなどのドキュメントも含め、どのような形で納品されるかを双方ですり合わせるための項目です。

納品される成果物の内容や形式によって、新システムの運用体制に影響することもあります。
 

【提案依頼内容】運用体制

【記載のポイント】

システムは開発して終わりではなく、その後もスムーズに運用できることが求められます。

保守やサポートを継続的に依頼する場合も、段階的に社内運用へ切り替えていく場合も、開発ベンダー側の具体的な運用体制を記載してもらうようにします。
 

【提案依頼内容】費用

【記載のポイント】

RFPと提案書のやり取りの段階で詳細の見積もりを取るわけではありませんが、費用の概算を提示してもらうことで費用対効果の検討ができるようになります。

自社が想定している予算を示しつつ、これを超える場合は柔軟に交渉できることを示し、各ベンダーができる最大の提案を引き出せるようにします。
 

【提案依頼内容】その他の要件

【記載のポイント】

機能要件・非機能要件に該当しない要望事項がある場合には、「その他の要件」の項目を用意して記載するとよいでしょう。ベンダーからの報告方法や報告頻度などが該当します。
 

【提案依頼内容】契約事項

【記載のポイント】

契約に関する事項を事前に提示してもらうためのパートです。

口頭でのやり取りや曖昧な約束はトラブルの温床になりかねません。契約関連の事項については、必ず書面での提出を求めることが大切です。
 

【選考の進め方】日程

【記載のポイント】

いつまでに何が実施されるのかを明示することにより、提案手続きを円滑に進めるためのパートです。

日程に関する問い合わせが頻発しないよう、RFP公開からプロジェクト開始までのスケジュールをできるだけ細かく記載する必要があります。
 

【選考の進め方】提案書の送付先

【記載のポイント】

各ベンダーが提案書の提出手順で迷わないよう、データ形式や送付先、送付方法について指定します。

データのメール添付は外部からの傍受などセキュリティリスクが懸念されるため、セキュアな環境でデータのやり取りができる外部サービスの利用がおすすめです。
 

【選考の進め方】評価基準

【記載のポイント】

実際にRFPを作成する前に、社内で提案書の評価基準を決めておき、RFPにも記載するようにします。

評価基準を決めておくことで自社内でも認識の相違が生まれにくくなり、各ベンダーにおいても提案内容を考えやすく、また選考に対して納得感を持ってもらうことができます。
 

RFPには多くの記載事項があるため、各項目を記載する目的や、受注側企業に伝えるべき要点を押さえておくことが重要です。開発会社が提案書を作成する際に必要な情報が漏れなく記載されたRFPを発行することで、自社の要望に即した提案を受けやすくなるでしょう。

今回紹介した記載例と記載のポイントを参考に、自社が要望を正確に伝わるRFPを作成してください。