お役立ち記事

RFP（提案依頼書）とは？

RFPとは、企業がシステムの開発などを行う際に、開発会社に対して「こういうシステムを作りたいので、最適な提案をしてください」と依頼するための文書のことです。「Request for Proposal」の略で、「提案依頼書」と訳されます。

RFPに盛り込む内容は、システム開発に至った背景や課題、求めるゴール、システムに盛り込みたい機能、納期、予算など多岐にわたりますが、要は「開発会社から良い提案をもらうために、必要な情報を正確に伝える」ことが趣旨となります。

提案を依頼された開発会社は、そのRFPに基づき具体的な提案内容を作成します。

なぜRFPが必要なのか？

最適な開発会社を選定するため

RFPは、最適な開発会社を選定するために作成するものです。

最適な開発会社を選定するには、候補となる会社数社から提案をもらい、内容を比較検討した上で決めるのがいいでしょう。

そのためには、各開発会社に発注側企業の要望を等しく理解してもらい、同じ条件のもと提案を出してもらう必要があります。

RFPは、発注側と各開発会社の共通認識となる文書であり、提案内容を作成するための軸や指針となるものなのです。

仮にRFPを作成せずに開発会社に提案を依頼したらどうなる？

発注側企業の要求が正しく伝わらず、各社独自の認識で提案をされてしまう可能性があります。また、伝え漏れも発生し、提案内容に不足が生じることもあるでしょう。見積もり金額に影響が出ることも予想されます。

そうなると、各社からの提案を比較検討することが難しくなってしまいます。

RFPは、社内関係者の合意形成プロセスの結果である

RFPには、もう一つ重要な側面があります。

それは、RFPの作成は社内の合意をとりながら進めなくてはいけないということです。

実際にシステムを利用する現場、システムを売る営業、情報システム部門、社長……、会社によって異なるとは思いますが、一つのシステムを開発するとなった場合、さまざまな関係者との調整が必要になるでしょう。

RFPを作成したら、社内の関係者にレビューしてもらい、合意をとる。その上で開発会社に提案を依頼するというのが、正しい順序となります。

つまり、RFPは社内関係者の合意形成プロセスの結果であるということです。

仮に社内合意のとれていないRFPを用いて開発会社の選定に進んでしまうと、どのような問題が起きるのか？

以下のような事態を引き起こす可能性があります。

• システムの要件について関連部署から不満の声が上がり、調整に多大な時間を要した上、RFPを作り直すことになる
• 発注担当者が社内関係者からの信頼を失い、その後の協力をしてもらいにくくなってしまう
• 社内調整に余分な時間が掛かり、スケジュールに遅れが生じる
• スケジュールの遅れにより、開発会社の選定に時間を掛けることができなくなってしまう。結果、最適な選定ができなくなる

こうした事態を避け、時間のロスなくスムーズにプロジェクトを進めるためにも、RFPは正しい順序で作成しましょう。

RFPの作り方・記載する項目

次に、RFPの作り方と、記載すべき項目について解説します。 まず、RFP作成にあたっては、「開発会社から良い提案をもらうために、必要な情報を正確に伝える」ことを意識しましょう。 RFPには、次のようなことを盛り込んでいきます。

1. 開発したいシステムの概要（背景、課題）

システム開発をすることになった背景や、自社が抱えている課題を記載します。業界特有の背景や課題があれば、その情報も併せて明記しておくといいでしょう。

開発会社が高い解像度で発注側企業の課題を理解できるよう、できるだけ詳しく記載しておくことをおすすめします。

2. 目的・ゴール

システムを開発する目的と、それによって達成したいゴールを記載します。 1.で記載した課題を、このシステムによってどう解決するのか。それが目的になります。ゴールは、目的の先にある「成果」と言ってもいいでしょう。

例えば、開発するものが自社のECサイトだった場合、「売上◯％アップ」というようなゴール設定をします。

可能な限り具体的な数字を盛り込んだゴール設定をすると、リリース後の効果検証がしやすくなります。

3. システムを利用するターゲット

システムを利用するターゲット層を記載しておくと、システム利用の解像度が上がるため、開発会社はより効果の高い提案をしやすくなります。ペルソナ（ターゲットをさらに詳細まで掘り下げた人物像）がすでに決まっている場合は、その情報ももれなく記載しておくようにしましょう。

4. 競合・類似サイト

競合となるWebサイトやシステムなどがある場合は、その情報も記載しておくといいでしょう。具体的な参考事例があると、開発会社は競合分析ができ、より良い提案がしやすくなります。

5. 提案依頼の範囲

開発会社に提案を依頼する範囲を明記します。つまり、どこからどこまでを開発会社が担うのか、ということです。これを記載することによって、各開発会社の提案範囲を揃えることができ、比較検討の精度を高めることにつながります。

6. 予算

開発予算の上限を記載します。システム開発は、開発のプロセスや体制、使用する技術によって、金額が大きく変わります。そのため、上限を設定しないと開発会社ごとで見積り金額にバラつきが生じてしまい、結果として比較検討を難しくしてしまう可能性があります。

上限を設定して、その中で提案をしてもらうようにしましょう。

7. スケジュール

記載すべきスケジュールは、2つあります。

一つは、開発完了の期限。「◯◯年◯◯月◯◯日頃までに開発完了」というように記載しておきます。開発会社はこの期限から逆算して全体の開発スケジュールを組み立てます。

もう一つは、開発会社の選定スケジュールです。一般的には以下の工程で選定を行いますので、それぞれの日程・期日を設定しておきましょう。

RFPの公開
RFPに対する質問受付
RFPへの回答
提案書および見積書提出
提案プレゼンテーション
提案内容に対する質問と回答
選定結果の通知

8. 機能要件

機能要件とは、システムに搭載する機能や処理などのことをいいます。例えばECサイトなら商品検索、決済、クーポン付与の機能、求人システムなら応募機能やスカウト機能など、サービスによってさまざまな機能が搭載されているかと思います。

そうした機能要件を洗い出して記載しておきます。社内関係者から情報を集めリストアップしましょう。「こんな機能、実現できるのかな」というようなものでも、とりあえず盛り込んでおくようにします。

ただ、この段階で出したすべての機能要件がすべてシステムに実装されるとは限りません。詳しい機能要件は、開発会社選定後の「要件定義」で、発注側企業と開発会社がすり合わせの上、決めていくものだからです。

しかしながら、RFPの段階ではとにかく漏れのないように記載することが重要です。

機能としてどういうものをつけたらいいのかわからない場合は「こういうことを実現したい」と抽象的に記載しておくのでもかまいません。それをもとに開発会社が提案をしてくれます。

9. 非機能要件

非機能要件とは何でしょうか。わかりやすい例を挙げてみましょう。

「画面上のチャットボットに質問を入力して送信すると、その答えがチャットで返ってくる」→機能要件

質問を送ってから「20秒」以内にチャットボットの回答を表示させる→非機能要件

つまり、非機能要件とは、機能以外のすべての要件のこと。

性能は、どれくらいのものにするのか。 セキュリティ対策はどうするか。 拡張性は、どれくらい持たせておくのか。 古いシステムを新しいシステムに入れ替えるときは、どのようにするか。

このようなシステムを支える要素に関しても、要望を記載しておく必要があります。

IPA（独立行政法人情報処理推進機構）が定義する「非機能要求グレード」に基づき、記載してみましょう。

10. インフラ要件

システムを稼働させるサーバーやドメイン（Webアプリの場合）を、自社で用意するのか、開発会社側に用意してもらうのかをあらかじめ記載しておきます。

開発会社にサーバーを用意してもらう場合は、必要なスペックなどについても記載しておくのが望ましいです。ただ、専門知識が必要となる部分のため、わかる範囲で記載すれば大丈夫です。

11. 納品物

発注先の開発会社から納品してもらう成果物を明記しておきましょう。

システム開発の場合、一般的な納品物は以下となります。

システム一式
要件定義書
仕様書
ワイヤーフレーム
設定・操作マニュアル

このほか、デザインデータなどもあれば、納品物として指定しておくことをおすすめします。

12. 契約条件・対応窓口

システムの著作権や機密情報の取り扱い、瑕疵担保責任、検収、支払い条件などについても明記しておきます。

開発会社の問い合わせを受ける窓口と連絡先も記載しておきましょう。

今回のまとめ

ここまでRFPの必要性や記載すべき項目などについて解説してきました。 かなり難しそうだと心配になってしまった方もいるのではないでしょうか。

RFPのテンプレートをネットで検索すると、Wordファイルで30ページ以上もあるような無料サンプルがたくさん見つかります。そのページ数を見ただけで、げんなりしてしまう方がいらっしゃるかもしれません。

しかし、フォーマットにとらわれる必要はありません。

「目的・ゴールを忘れないこと」「社内の合意をとりながら進めること」をしっかりと押さえておきながら、ここでお伝えした内容を、まずはかしこまらずに書き出してみることをおすすめします。

豊富な実績を持つ開発会社であれば、RFPをいろいろな観点で見ることができます。情報として足りない点があればヒアリングして理解を深めながら進めてくれたり、出された機能要件が本当に必要かどうかを見極めて提案してくれたりもします。良い開発会社を見つけるために、RFPを作成しましょう！

次回は、開発会社の選び方についてお伝えします。