RFP（提案依頼書）とは？テンプレートや作成の流れを専門家が解説

RFP（提案依頼書）とは

　RFP（提案依頼書：Request for Proposal）とは、解決すべき課題をまとめて、外部のベンダーやサービスプロバイダーから解決策の提案を得るための書類のことです。

　提案依頼書には、プロジェクトの概要や目的、要件、評価基準などを明記し、受け取った企業は、その内容に基づいて提案書を作成します。複数のベンダーから提出された提案書を基に選定すると、効率よくベンダーを選定できます。

　業務システムのアプリやWebサイトなどを調達する場合は、開発して納品されたら終わりというわけではありません。

　開発した後、その納品物を使い続ける間、保守・運用業務など長期的な取引となります。この一連の流れを、SLCP（ソフトウェア・ライフ・サイクル・プロセス）と言います。

　SLCPのなかでも、企画から要件定義に移る際のベンダー選定は非常に重要です。もし選定がうまくいかなかった場合、後に続くシステム開発や保守・運用において大きなトラブルに出くわしかねません。そうした事態にならないように作成する書類が提案依頼書です。

RFP（提案依頼書）を作る目的

　提案依頼書を作る目的は、ベンダーに対して開発や制作したいことを伝え、提案資料を得ることです。プロジェクトの目的や要求事項を的確に伝えることで、ベンダーは依頼者の背景を汲んだ提案書を作成できるようになります。

　また、複数のベンダーに対して同一の提案依頼書を配布することで、同一条件の提案依頼書を求められるため、複数のベンダーの提案書を評価しやすくなるメリットがあります。

RFI（情報提供依頼書）との違い

　情報提供依頼書とは、ベンダーやサービスプロバイダーから情報を収集するための文書のことです。英語では、「Request for Information」となり、略称の「RFI」とも呼ばれます。必要なシステムの要望、計画、構想などをまとめたシステム企画を基に、技術的な実現性（フィジビリティ）の調査や、費用の規模感、どのような実現方法が考えられるのかなどの情報を収集します。

　提案依頼書との違いは、情報提供依頼書が具体的な解決策の提案を求めるのに対し、情報提供依頼書はあくまで情報収集が目的であり、提案内容の詳細は求められません。以下のRFIとRFPの関係図で示したように、「具体的に実現可能な提案を求められる提案依頼書」を作成するために用意されるものです。

　情報提供依頼書によって得る情報には、自社の重要な経営計画のほか、ベンダー側の重要なノウハウなどの機密情報を含むことがあるため、一般的に秘密保持契約（NDA）を締結します。

要件定義書との違い

　要件定義書とは、選定したベンダーと共に、具体的に開発するシステム要件の合意事項（必要な機能や性能など）を明確に記述した文書のことです。

　一方、提案依頼書は、ベンダーを選定するために、まだ具体的な解決策が決まっていない要求事項をまとめた書類です。

　したがって、要件定義書は時間的に提案依頼書よりも後に作成されるものとなります。

RFP（提案依頼書）を作成する際のポイント

　次に、提案依頼書を作成する際のポイントを紹介します。

プロジェクトの背景と目的・スコープを明確に記述する

　当該システム導入が必要となった背景、導入の目的、提案が必要なスコープ（プロジェクトの対象）を矛盾なくまとめます。

　提案企業は背景と目的・スコープを正しく把握することで、プロジェクトが解決すべき課題をより正確に提案できます。

要求事項を具体的かつ簡潔にまとめる

　提案の要求事項を具体的かつ簡潔にまとめるように心がけましょう。それにより、提案企業がプロジェクトのニーズを正確に把握できるようになり、適切な提案のみを集められるようになります。また、最終的な成果物の品質の向上も見込めます。

提案評価基準を明確に設定する

　提案評価基準を明確に設定することで、期待どおりの提案を受けやすくなります。

　さらに、各提案書を評価の観点ごとで比較できるようになり、選定にかかる時間や労力を削減できます。評価シートにまとめて、複数の評価者によって総合的に漏れやダブりなく評価できるようにもなります。

提案期限や連絡先を記載する

　提案書を提出する期限や、フォーマット、必要書類など指定があれば明記します。また、選考スケジュールや選考後プロジェクトの想定開始日など、選考後のスケジュールも記載します。資料の提出だけでなく説明も必要な場合は、日程の期間などを明記することが大切です。

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

　ここでは、提案依頼書のテンプレートを紹介します。自社で作成する際の参考にしてください。

依頼の概要

　提案依頼書の目的を簡潔に記載します。例えば、「顧客管理システムの改変に関するプロジェクト」などのシステム改修や、「サイトリニューアル」などが挙げられます。

　提案依頼書の目的は、プロジェクトやサービス開発にあたり、複数の事業者や専門家から最適な提案を募ることです。これにより、最適なパートナーを選びやすくなり、プロジェクトの成功確率を高めることが期待できます。

プロジェクトの背景

　プロジェクトの背景では、解決すべき課題の原因となったことを記載します。事業環境の変化や課題意識を明確に記載します。このあとに明示する課題やトラブルの背後にある問題やニーズを理解させることが目的です。

　また、プロジェクトが始まる前の現状を説明することで、提案企業がプロジェクトの目的や必要性を把握しやすくなります。現行のシステムや運用方法、現在の課題に対処するために試みた現在までの取り組みとその結果などを述べると、より望ましいでしょう。

　解決すべき課題が、外部環境の変化などに起因する場合は、市場調査やユーザー調査、業界動向などの情報を用いて、具体的な背景を示してください。

プロジェクトの目的

　プロジェクトの目的をベンダーに示します。この際には、プロジェクトの目的が背景で示された内容と適切に対応するようにします。プロジェクトの背景と目的を整合させることで、ベンダーから適切な提案を得られやすくなります。

会社概要

　自社の会社概要などをまとめます。資本金や従業員数、サービスの概要、事業内容を記載します。

プロジェクトのゴール

　本プロジェクトで目的を達成するために何を行いたいのか、プロジェクトのゴールを明記します。プロジェクトのゴールでは、達成するための具体的な目標を定量的な指標（KGI）で示すことで、提案企業がどのような成果を目指すべきかが明確になります。目標は、達成可能で測定できるものに設定することが望ましいでしょう。

解決すべき課題

　解決しなくてはならない課題を明記します。解決すべき課題を漏れなく記載してください。このとき、プロジェクトの背景と整合させることで、課題の根本原因が明確になり、的を得た提案を受けやすくなります。

　また、それぞれの課題の優先順位を明示するようにします。それにより、重要度に応じた解決策を考慮しやすくなり、効果的なリソース配分の提案が可能になります。

　課題解決の条件を定量的に提示できる場合は、達成すべきKPIなどの目標を具体的に数字で示します。ただし、プロジェクトの目的で設定したKGIと、解決すべき個々の課題のKPIと整合性をとるようにしましょう。数字で示すことでベンダーに課題感が具体的に伝わります。

①前提条件

　システムを利用する自社の運用体制や、システムを動作させる環境など前提条件をまとめます。本プロジェクトで開発するシステムが外部の既存システムと連携しなくてはならない場合など、提案の前提条件として記載します。

　さらに、プロジェクトに関与する社内外の関係者（経営層、部署、メンバー、主な取引先など）の立場や役割、期待を明確にすることで、ベンダーの理解が進み、適切な提案を行いやすくなります。またコンプライアンス上、必ず満たすべき要件がある場合はその機能などを明記してください。

②機能要求

　機能要求について、提案してほしいことを記載します。解決すべき課題を補足するような最低限満たすべき機能や、機能の概要をまとめます。機能要求は「必要な機能」「画面構成・UIUX」「デザイン」「データ連携」「管理機能」などに区分できます。これらの各項目ごとに提案してほしい内容をまとめましょう。

③非機能要求

　非機能要求について、提案してほしいことを記載します。非機能要求とは、セキュリティや運用・保守体制など、ユーザーや利用するうえで満たすべきシステム要求を指します。

　非機能要求では「セキュリティ」「運用保守性」のほか、「可用性（障害対応）」「性能・拡張性」「移項性」「環境（サーバー・インフラ）」などに区分できます。

④オプション提案について

　このセクションは必須ではなく、追加で提案してもらいたい機能がある場合に記載します。プロジェクトの主要な提案に加えて、オプションとして求める機能を明記します。例えば、課題解決や目標達成に有益であるがスコープから外れる提案、または機能要求・非機能要求と異なる代替手段の提案などが挙げられます。

スコープ

　このセクションでは、プロジェクトで達成したい目的を実現するための提案依頼範囲を記載します。

　例えば、Webのリニューアルを依頼する場合、以下のような内容について整理します。

• システムの詳細設計
• デザインも必要か
• 実装までを依頼するのか
• サーバー、バックエンド含む開発まで依頼するのか
• 脆弱性診断などセキュリティや運用保守体制も含めるのか
• 対象となるサイトは指定のドメイン配下すべてのページか

　依頼範囲が不明瞭であると、各社からの提案のレベル感が大きくぶれてしまい、選定が難しくなるので、依頼範囲はできる限り詳細に書くようにしましょう。

　特にWebやアプリの場合、システム周りとの連携が必要です。また、社内の情報システム部門が担当する範囲も少なからず入ってくる場合は、情報システム部門にレビューをもらいつつ、できるだけ細かく記入するようにします。

スケジュール

　プロジェクトに締め切りや大まかなスケジュールがある場合に記載しましょう。例えば、システムの納品を半年後や1年後を想定しているのか、また、予定されるマイルストーン（中間目標地点）を明示します。提案書にはスケジュール概要が必要なので、現時点で把握しているスケジュールをできるだけ詳細に記述します。図表や箇条書きなど、キックオフ日程やリリース日などの主要マイルストーンを列挙する形でも構いません。

予算

　このセクションでは、見積もりの提示方法を明記します。イニシャル費用とランニング費用に分け、内訳がわかるように依頼します。

　予算を「上限なしで適切な見積もりを求める」とする提案依頼書も存在しますが、予算の明記が望ましいでしょう。なぜなら、プロジェクトの目的や課題が明確であっても、リスクや体制によって費用が大きく変わるからです。予算を明示することで、費用対効果や品質を担保した提案をフラットに評価できます。

　費用感が全く予想できない場合は、情報提供依頼書を先に提示して費用感を把握し、想定する費用対効果を考慮して予算を設定することをおすすめします。

提案書について

　プロジェクトについての要求内容と、提案書など提出物について記載します。

①提出物について

　このセクションでは提案依頼書の回答として納品する提案書について記載します。例えば以下のようなドキュメントの提出を求めます。

• 提案書
• 会社概要、実績
• スケジュール
• 体制図
• 概算見積書（イニシャルコストとランニングコスト）

②選考スケジュール

　提案書の提出期限のほかに、受領後の想定スケジュールを記載します。

　主に以下の項目の日程を記載します。

　説明会の参加日やプレゼンテーションの日程など予約が必要な場合は、その手続き方法などを記載します。

③評価基準

　提案書をどのような基準で評価するのか、QCDの観点で記載します。QCDとは、品質（Quality）、コスト（Cost）、納期（Delivery）のことです。記載例は以下のとおりです。

• 提案物の品質：提案内容について
• 提案物のコスト：開発費、保守費、運用費など提案内容に対して妥当性
• 提案書のスケジュール

④契約について

　提案依頼書を進めるうえで、機密保持契約など事前に締結すべき事項があればその旨を記載します。

RFP（提案依頼書）を作成して委託先を選定するまでの流れ

　ここでは、RFP（提案依頼書）を作成して委託先を選定するまでの流れを解説します。

システム企画書を作成する

　システムで解決すべき課題の方針をシステム企画書にまとめます。プロジェクトの目的や背景、要求事項、期間、予算など方針を明記します。これらの情報を整理し、文書にまとめることで、プロジェクトの全体像が把握しやすくなります。その後の関係者間での認識合わせや、情報提供依頼書や提案依頼書を作成する際の基礎にもなります。

RFI（情報提供依頼書）を作成して情報収集する

　情報提供依頼書を作成する際には、調査対象となるベンダーやサービスに関する質問項目をリストアップします。質問項目は、技術力、実績、サポート体制、価格帯など、プロジェクト遂行に必要な情報に焦点を当てます。情報提供依頼書を送付し、回答を受け取ったら、得られた情報を整理・分析し、提案依頼書の作成やベンダー選定の参考にします。

RFP（提案依頼書）を作成して提案を集める

　提案依頼書を作成する際には、システム企画書や情報提供依頼書で得た情報を基に、プロジェクトの目的や要求事項・要件を明確に記載します。また、スケジュール、評価基準、提案書の提出方法や締め切りなどを設定し、ベンダーに伝えます。作成した提案依頼書をベンダーに送付し、提案を受け取ったら、評価の準備に移ります。

提案資料を評価して委託先を選定する

　提案資料を評価する際には、提案依頼書で設定した評価基準に従って、各提案を比較・検討します。評価基準は、事前に作成した評価シートやチェックリストを使用して、客観的かつ公平な評価ができるようにします。評価結果を基に、最も適切なベンダーを選定し、契約を締結してください。選定結果は、関係者に報告し、プロジェクトの進め方や期待する成果を共有します。

RFP（提案依頼書）は要求事項を簡潔にまとめることが重要

　複数のベンダーから提案書を集める場合、提案依頼書をあらかじめ作成することで、そのあとのタスクを非常にスムーズに進められるでしょう。

　特に、専門的な知識を要するシステム開発部門などを社内に持たない場合、提案依頼書の作成をコンサルタントに伴走・チェックをしてもらいながら作成すると、結果的に開発コストをおさえられます。ぜひ本記事をうまく活用しながら、提案依頼書を作成していきましょう。