RFP（提案依頼書）に必要な20項目と書き方を解説

RFP（提案依頼書）とは、発注先の候補となる開発会社に提案書の作成を依頼し、発注先を選定することを目的に作成される文書のことです。発注先を適切に選定するには、RFPに記載すべき項目を漏れなく盛り込んでおかなくてはなりません。

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

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

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

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

今すぐダウンロードする

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

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

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

今すぐダウンロードする

今回はRFPに必要な20項目と、各項目の書き方を紹介します。漏れのないRFPを作成する上で、ぜひ役立ててください。

RFPの基本構成は下記のとおりです。

【RFPの基本構成】

大項目ごとに見た場合、下記の目的を達成できるように記載する必要があります。

• 概要：プロジェクトの全体像やシステム開発の背景を開発会社に伝える。
• 提案要件：提案書に盛り込んでほしい情報を開発会社に伝える。
• 選考方法：開発会社の選定方法や選定スケジュールを伝える。

次章より、各項目の記載事項と書き方を見ていきましょう。

「概要」には主に発注企業の現状と、プロジェクトが何を目指しているのかを記載します。
 

プロジェクトの背景・現状の課題

プロジェクトが発足した経緯を簡潔に記載します。プロジェクトの位置づけや発注企業の現状を開発会社に理解してもらい、共通認識を形成しておくことが主な目的です。あわせて、発注企業が現状何に困っているのか、何を解決したいのかを記載しましょう。
 

ゴール・目標

プロジェクトを通じて達成したいゴールや目標を記載します。システムを開発・導入した結果、どのような状態になっているのが理想であるのかを伝えることが主な目的です。定量的な目標値などを記載できるようであれば、できるだけ具体的に記載しましょう。
 

予算

発注企業が想定している予算を記載します。予算を明示し、その範囲内で開発費用を設定してもらうことが主な目的です。開発費用のみの予算であるのか、その後の保守運用も含めた予算であるのかなど、予算の範囲についても明記しておく必要があります。
 

スケジュール

発注企業が想定している本稼働日や、提示してほしいスケジュールの単位を記載します。スケジュールの全体像と詳細な進行予定の両面を開発会社に提示してもらうことにより、現実的な開発スケジュールが想定されているかどうかを確認しやすくなるでしょう。
 

対象部署

開発するシステムを使用する予定の部門やユーザー数を記載します。ユーザーの対象範囲を開発会社との間で共有することで、システムの規模や運用体制に関する共通認識を形成することが主な目的です。将来的にユーザー数が増える見込みがどの程度あるかなど、必要な拡張性に関わる部分についても記載しましょう。
 

運用体制

システム稼働後の運用体制について記載します。システム管理者のほか、バックアップ体制や出力されるデータの取り扱いなどについても明示しておくことが大切です。具体的な運用体制を伝えることにより、稼働後の状況を想定した上でシステムを開発しやすくなります。
 

現状の資産

現在使用しているシステムのうち、新たに開発するシステムと関連するものを記載します。現状運用しているハードウェア、ソフトウェアの具体的な名称や型番、バージョンなどを記載しましょう。システムの連携が必要な場合は、とくに重要な情報といえます。
 

「提案要件」は、提案書に盛り込んでほしい情報を記載するパートです。RFPの本題にあたるこのパートには、下記の10項目を記載します。
 

提案を希望する範囲

開発会社に提案を依頼したい範囲を記載します。たとえば、システム開発のみでよいのか、運用や保守も含めて依頼したいのかによって、開発会社が提案書に盛り込むべき項目は大きく変わるからです。
 

希望納品物

ソースコードをどのような方法で受け渡しするのか、必要な成果物は何かを記載します。要件定義書や基本／詳細設計書のほか、操作マニュアルや社内研修用資料なども希望する場合には、RFPにその旨を記載しておくことが大切です。
 

開発言語・手法

使用するプログラミング言語やデータベースなどを指定する場合には、RFPにその旨を記載しておく必要があります。開発したシステムを発注企業が自社でメンテナンスする場合には、とくに注意が必要なポイントです。自社のセキュリティ要件も考慮した上で、記載事項を決定しましょう。
 

機能要件

システムに搭載すべき必須の機能を記載します。のちに追加の機能を要望することになると、開発に要する期間やコストが膨張しがちです。必要な機能を明確にし、抜け漏れなく記載しましょう。
 

非機能要件

機能要件に含まれない要望事項を記載します。セキュリティ要件や操作性、パフォーマンスなどに関する要望がある場合には、機能要件とは切り分けて伝えることが大切です。将来的にシステムをカスタマイズする可能性がある場合には、拡張性についても記載しておきましょう。
 

テスト要件

システムをテストする際に必須の項目や進め方がある場合には、RFPに明記しておく必要があります。テスト仕様書やテスト結果、証跡などを要望する際には、前述の「希望納品物」にも必要な成果物として追記しておきましょう。
 

移行要件

現行のシステムから移行するにあたり、移行方法などを提案してほしい場合にはその旨を記載します。前述の「現状の資産」と対応する形で、どのシステムを移行する予定であるのかを明確に伝えることが大切です。
 

運用保守

運用や保守に関する要望事項を記載します。運用保守も含めて開発会社に委託する際には、前述の「提案を希望する範囲」にもその旨を明記しておきましょう。発注企業が想定している委託の範囲と、開発会社の認識にずれが生じるのを防ぐ必要があります。
 

教育・研修

システムを使用・運用するメンバーに対する教育や研修の実施を要望したい場合には、具体的な範囲や実施事項を記載します。必要な資料のみ提出を要望するのか、教育・研修の実施も含めて依頼したいのかを明確にして記載することが大切です。
 

ベンダーの体制

開発に携わるメンバーや組織体制、プロジェクトマネージャーなどを具体的に記載してもらうよう要望します。再委託を予定しているようであれば、再委託先についても明記してもらうことで、開発の実態をより判断しやすくなるでしょう。
 

「選定方法」は、開発会社から提案書を受領した後の工程について記載するパートです。選考のスケジュールや提案書の提出先・期日、評価基準などを記載します。
 

選考スケジュール

RFP公開後の選考日程を記載します。選考結果の通知はいつの予定であるか、開発会社側が把握できるように明確な日付を伝えることが大切です。スケジュールに不明確な点があると、RFP送付後に問い合わせが頻発する原因となるため注意してください。
 

提出先・締切

提案書をいつまでに提出してもらいたいか、誰に宛てて送付してほしいのかを記載します。提出先の部門名と担当者名、メールアドレスを記載しておくとよいでしょう。締切を過ぎて提出された提案書については、選考対象外となる旨も明記しておくことをおすすめします。
 

評価基準

発注企業が想定している評価基準を記載します。評価基準を明確に伝えておくことにより、開発会社は発注企業の意図をくんだ提案をしやすくなるからです。要件に対する適合性が評価の軸になることを記載した上で、自社がとくに重視するポイントを記載していくとよいでしょう。
 

RFPに記載すべき項目は多岐にわたるため、必要な項目を押さえておくことが大切です。今回紹介した20項目をRFPの骨組みとして使用し、肉付けをしていくイメージで作成を進めるとよいでしょう。下記の記事ではRFPの基本構成に沿ったテンプレートも用意していますので、ぜひご活用ください。