RFP(提案依頼書)の書き方・記載項目を徹底解説!作成の目的や提示タイミング、準備やポイントも
目次[非表示]
- 1.RFP(提案依頼書)とは
- 1.1.RFP(提案依頼書)を作成する目的
- 1.2.RFI(情報提供依頼書)との違い
- 1.3.要件定義書との違い
- 2.RFP(提案依頼書)を提示するタイミング
- 3.RFP作成前に必ず行うべきこと
- 4.RFP(提案依頼書)の書き方・記載項目
- 4.1.現状抱えている課題
- 4.2.目的・ゴール
- 4.3.システム構築の対象範囲
- 4.4.要求事項
- 4.5.オプションの提案
- 4.6.開発体制・役割
- 4.7.システムの本稼働時期
- 5.RFPを作成する際のポイント
- 5.1.評価シートもあわせて作成する
- 5.2.必要十分な項目に絞って作成する
- 5.3.RFPに詳しい専門家にチェックしてもらう
- 6.まとめ
RFP(提案依頼書)とは
RFP(正式名称:Request For Proposal)とは、提案依頼書を意味します。企業が新しいシステムやサービスなどの導入を考えているとき、具体的な実現方法やコストなどについて、複数のベンダーに提案を求める際に用いる文書のことです。
通常、RFPには、現状抱えている課題や目的・ゴール、システム構築の対象範囲、要求事項などの情報が詳細に記載されます。このRFPの記載内容を踏まえて、ベンダー側は自社のサービス・製品がクライアントのニーズにどのように適合し、価値を提供できるかを示します。
RFP(提案依頼書)を作成する目的
RFPを作成する目的は、以下の3つです。
目的 |
概要 |
ニーズの明確化 |
RFPの作成にあたって、依頼側は自身の要望や必要な要件を明確にすることが求められる。 |
比較・評価の基準設定 |
RFPには、提案に対する評価基準も記載される。 |
適切なパートナー探し |
RFPを作成し、それを複数ベンダーに送付することで、自社の要望に最も適したベンダーを選択できる。 |
RFPを作成し自社の要望を具体的に伝えることで、システム規模がマッチしない提案を防いだり、要求と異なるシステムが開発されることを避けたりできます。
RFI(情報提供依頼書)との違い
RFPとRFI(Request for Information:情報提供依頼書)は、ビジネス上のコミュニケーションツールとしてよく使用されますが、その目的と使用方法には明確な違いがあります。
RFPは、特定のプロジェクトや製品に関する提案を求める文書です。新しいシステムやサービスを導入する意思があるが、どのベンダーが最適かを判断するための比較材料を提供するために使用されます。そのため、RFPには、プロジェクトの目標、スケジュール、バジェット、評価基準など具体的な要件が詳細に記載されます。
これに対して、RFIはベンダーから必要な情報を収集するための文書で、主としてマーケットリサーチやベンダー選定の初期段階で使用されます。RFIでは、RFPのように具体的なプロジェクトの詳細は必ずしも含まれず、比較的広範で一般的な質問が記載されます。
RFPとRFIは似たような言葉ですが、その内容と目的はかなり異なります。
また提示する順番は、
RFIの提示 → RFPを提示するベンダーを絞る → RFPの提示 → 導入ベンダーの決定
となります。
要件定義書との違い
要件定義書とは、新しいシステム・サービスを導入する際、その対象となるものが達成すべき内容や発揮すべき性能などをまとめた文書です。RFPとは違い、要件定義書はベンダー側により作成されます。
要件定義書では、以下のような事項が明確に記載されます。
- なぜシステム・サービスを開発するのか?
- 開発にどのような技術を用いるのか?
- どのような機能を実装するのか?
■関連記事:
RFP(提案依頼書)を提示するタイミング
RFPは、ベンダーによる要件定義の作成前や、設計・開発を開始する前のタイミングで提示するのが一般的です。プロジェクトの性質によって適したタイミングは異なりますが、開発依頼を検討するタイミングでRFPを作り始めると、その後のプロセスがスムーズに進みやすいです。
RFPの作成は思った以上に時間と手間がかかるため、早めに取り組むことをおすすめします。余裕をもって取り組むことで、必要な情報を集めたり、問題を明確にしたりする時間を確保でき、結果的により質の高い提案を受けられるようになります。
RFP(提案依頼書)の提示とベンダー選定フロー
RFPの提示からベンダー選定までの流れは、一般的に以下のスケジュールで進められます。
- RFPの提示・公開
- RFPの内容に対する質問受付
- 質問に対する回答
- ベンダー側による提案・見積の提出
- 提案のプレゼン
- 提案内容に対する質疑応答
- 選定結果の通知・公表
RFPには、上記の各ステップの期間・期限を明記します。
■関連記事:
RFP作成前に必ず行うべきこと
ここからは、RFP作成前に必ず行っておくべきことを2点ピックアップし、解説します。
プロジェクト担当者からのヒアリングで仕様を定めておく
RFP(要求提案書)を作成する前に、必要な情報を収集するためにプロジェクト担当者と面談を行い、資料の作成を依頼しましょう。
面談の中で、プロジェクト担当者からさまざまな視点の意見が出てくることがありますが、その全てを整理しまとめることが、RFP作成者の重要な役割となります。
つまり、RFP作成者は単純に文書を作成するだけでなく、情報を集めて異なる視点の意見を平準化し、全体の視点で最適な要求を明らかにするコーディネーターとしての役割も果たすのです。
以下に、プロジェクト担当者ごとの主なヒアリング・依頼事項をまとめます。
ポジション |
主なヒアリング・依頼事項 |
経営陣 |
|
マーケティング部門 |
|
営業部門 |
|
情報システム部門 |
|
■関連記事:
ベンダーの選定基準を明確にしておく
ベンダーを選ぶ際は、「どのような会社とプロジェクトを進めたいのか」を事前に明確にしましょう。プロジェクトを成功させるために欠かせないベンダーの特徴を決めておくことで、該当するプロジェクトに適した会社をスムーズに選定することが可能です。
明確な基準を作っておくことは、ベンダーが決定された後に社内から不満が出るのを防ぐ効果もあります。評価の指標をまとめたシートをコンペ開始前に作っておき、それにもとづいて点数を付けて選定する方法も有効です。
RFP(提案依頼書)の書き方・記載項目
ここからは、RFPの具体的な書き方について、順番に解説します。
現状抱えている課題
システム開発を進める際には、現在抱えている課題を明確に記載します。記載する際は簡潔に、なるべく箇条書きで列挙すると見やすくなります。
課題の記載例は、以下のとおりです。
- 営業活動を支える情報が十分に提供されていない
- 企業のブランド力が弱い
- Webサイトの社内での運用性が低い
もしもアンケート結果やユーザビリティ調査のデータ・外部の意見など課題を裏付ける資料がある場合は、それも添付して提供しましょう。
目的・ゴール
課題を踏まえ、システム開発の目的・ゴールを明記します。
目的・ゴールの記載例は以下のとおりです。
- ユーザーにとって使いやすいシステムを構築する
- サービスの認知度を高める
- 採用活動を強化する
目的がぼやけているシステム開発は成功しませんので、全てのプロジェクトチームメンバーが同じ方向を見て進められるよう、目的をはっきりさせましょう。
システム構築の対象範囲
「システム開発の範囲はどこからどこまでなのか?」「システム開発が対象とする範囲と対象外の範囲の区別はどこにあるのか?」といった観点から対象範囲を詳しく記載します。
以下は、対象範囲の記載例です。
- Webサイトの設計・デザイン・HTMLコーディング
- システムの要件定義・設計開発
- 公開後の運用・保守
対象範囲が不明確だと、各社の提案内容にばらつきが出てしまいます。それを防ぐために、対象範囲は可能な限り詳しく書くことを心掛けましょう。
要求事項
システムで必要となる機能(例:会員登録、クーポンやポイントの提供、商品の購入やサービスの申し込み、決済、データベースとの連携など)を具体的に書き出します。また、システムの性能や非機能的な要素についても明示しましょう。
機能要件の詳細は、契約後の要件定義段階で開発会社と共に詰めますが、RFPにも機能面の要求事項を記載しておくと、各提案者からの提案がより具体的になり、品質の向上につながります。
オプションの提案
プロジェクトでは必須とはいえないものの、「予算に余裕があるならやってみたいこと」や「将来的に必要になる可能性があること」をオプションの提案として記載することも可能です。
オプションの提案の記載例は以下のとおりです。
- Webサイトへの集客戦略
- マーケティング情報の収集と活用
この項目もプロジェクトの選定基準の一つになる可能性があるため、将来必要になる可能性があると思われる提案は積極的にリストアップしましょう。
開発体制・役割
ベンダーの開発・運営体制について、特別な要望がある場合に記載しましょう。記載する際は「依頼側の役割は何か?」「ベンダー側に期待する役割や体制は何か?」という観点で考えてみてください。
開発体制・役割の記載例は以下のとおりです。
- 開発には最低4人(プロジェクトマネージャー1名を含む)のチームを組んでいただきたい
- 外部のパートナーを使う場合は、その組織図を文書で提出してください
システムの本稼働時期
プロジェクトの開始日とあわせて、システムの本稼働時期(例:Webサイトの公開を予定する日)について、可能な範囲で具体的なスケジュールを明記しましょう。
公開日が変更できない特定のイベント(例えば、製品の発売日やキャンペーン開始日など)に連動している場合、それも明記しておきましょう。これにより、プロジェクトが始まってからのスケジュールの遅れを避けることが可能です。
RFPを作成する際のポイント
最後に、プロジェクトの成功に向けてRFPを作成する際に留意しておくポイントを3つ解説します。
評価シートもあわせて作成する
RFPの作成と同時に、提案評価用のチェックリストやスコアシートも作っておきましょう。RFPを作成する際には、その評価シートを意識することが重要です。
どのような作業量が見込まれ、どの範囲まで依頼できるのかなどの項目を評価基準として設定しておくことで、複数のベンダーを横並びに比較評価するのに役立ちます。
必要十分な項目に絞って作成する
RFPを作成する際は、プロジェクトの主要な課題や目標に絞って記載することを心がけましょう。不必要な詳細は省くことで、ベンダーに重要なメッセージが伝わりやすくなります。
必要十分な項目に絞って記載することで、RFPの作成が迅速に進むだけでなく、提案をする各ベンダーにとっても「どのポイントを重視して提案すればよいか」が理解しやすくなります。
RFPに詳しい専門家にチェックしてもらう
RFPを完成させたら、すぐにベンダーに送付するのではなく、第三者の視点を活用することをおすすめします。自社のニーズに最も適したシステムを開発できるパートナーを見つけるためには、RFPの質が重要です。
例えば、外部のアドバイザーに一度内容を確認してもらうと良いでしょう。これにより、曖昧な表現がないか確認できます。
■関連記事:
まとめ
RFPは自社の要望を明確に伝え、多数のベンダーから最適な提案を引き出すための重要なツールです。
ベンダーに対して重視すべきポイントを効率的に伝達するためにも、RFPの作成方法を理解した上で、必要かつ十分な項目に絞って作成することが重要です。
RFPを作成する目的は、自社に最適なベンダーを見つけ出すことです。もしもベンダー選びに悩んだら、開発実績が豊富な企業に見積りや具体的な相談を行うことをおすすめします。
ラボ型開発がおすすめ!
ラボ型開発では発注者専任のチームを編成し、固定金額で一定期間システム開発を行います。
オフショア開発で多く取り入れられている開発法ですが、 請負型開発に比べ柔軟性があり、契約期間内であれば何度でも修正や追加が行える、追加料金が発生しないなど様々なメリットがあります。
ラボ型開発を上手く進めるためには、最適な依頼先を選ぶことも大切です。自社が求めるコミュニケーション力、技術力に対応できる委託先かどうか判断し、確認することが必要です。
コウェルはお客様の課題やご検討状況に応じて、オフショア開発におけるラボ型開発やラボ型によるシステム開発をうまく進めるようご提案やご支援をいたします。
システム化・業務改善の提案からインフラ構築、システム開発、ソフトウェアテストサービス、その後の運用・保守までワンストップで対応が可能です。
ソフトウェア開発をご検討されている皆様、ぜひ一度ご相談ください。
■関連記事:
なお、コウェルに関する詳細資料は以下でダウンロードすることが可能です。
このほか、弊社の具体的なサービスや導入事例については以下をご覧ください。
コウェルのサービスメニュー>>>
コウェルは、日本とベトナムから世界中のお客さまへ高品質なソフトウェアテスト・品質保証・オフショア開発サービスを提供しています。
コウェルの開発導入事例>>>
コウェルは情報通信、金融、流通・小売サービス、医療・ヘルスケアなど、さまざまな業界のお客様の導入を支援しています。