RFP（Request for Proposal）・提案依頼書とは？

システムの構築やリプレイスを行うときに必要不可欠な資料であるRFP。 Request for Proposalの頭文字をとった略語で、日本語に訳すと「提案依頼書」という意味合いになります。

RFPとは、依頼を発注する側の企業のIT担当者、情報システム部門担当者などが、システム構築やリプレイスを依頼する際に用意するべき書類です。 SIerやシステムベンダーに対して、自社のシステムにおいて実現していきたい業務や解決していくべき課題、今後目指していく姿、ひいてはそのために必要な要件を明確に示す書類であるRFPは、システム発注する際にはぜひとも用意しておきたい書類のひとつといえます。

RFPとよく似たビジネス用語に「RFI」というものがあります。 こちらはRequest for Informationの略です。 日本語では、「情報提供依頼書」と訳されます。RFIは、発注先の企業のSIerやベンダーに対し、その会社の情報、これまでの実績、実際に提供可能なサービスに関する情報などを提示するよう求める書類です。

どんな内容のシステム構築やリプレイスを依頼したいかという意図やイメージ、理想を説明するRFPと、案件を依頼するにあたって相手企業がこちらの求めるサービスを実現できるかどうか、その情報を得るためのRFI。 どちらも現状に即した適切なシステム提案を受けるためには欠かせない書類です。 ただ必要になるタイミングには違いがあり、主にRFIは第一次選考の際に、そしてRFPは第二次選考の際に用意すべき書類としているケースが多いようです。 企業情報やこれまでの実績、提供できるサービスに関する情報などはほとんどの場合、当該企業の公式webサイトなどから得ることができるため、RFIは用意せず省略している企業もあります。

RFPの意義、メリット・デメリットとは？

RFPを用意するとなると、システム提案依頼を発注するための準備に手間や時間、人手をある程度割くことになります。 そのコストをかけてでもRFPを用意する価値があるのかどうか、RFPを省略して発注するケースとRFPを用意して発注するケースのメリット・デメリットをそれぞれ比べてみましょう。

RFPがない場合のメリット

• 発注準備にかかる手間や時間、人手などのコストを少なく抑えられる。

RFPがない場合のデメリット

• 自社がどのようなシステム要件を求めているのかがSIerやベンダーに正しく伝わらない。
• 複数のSIerやベンダーがそれぞれ異なる形でシステム要件を解釈する可能性が生まれる。

その結果として実際に受けるシステム提案の観点・着目点が統一されずバラバラになり、システムの比較や選定が困難になってしまう。

• 発注内容に関して伝え漏れが発生しやすくなり、システム提案の内容に不足が生じるリスクが高くなる。
• RFPを作成する機会が失われることにより自社システムの現状を正しく把握するきっかけがなくなり、自社システムが持っている課題を完全に抽出するのが難しくなる。
• 自社システムの今後あるべき姿、目指す将来像があいまいかつ共有できないままの状態でシステム選定を進めることになるリスクが出てくる。

RFPがある場合のメリット

• 自社が求めているシステム要件を、発注先企業のSIerやベンダーに適切に伝えられる。
• 求めているシステム要件が共有できているので、SIerやベンダーの選定の際も比較すべき項目が明確になり正しく選定できる。
• RFPを準備する過程で、自社システムの現状を把握し、課題を洗い出すことができる。
• 自社システムが将来どうありたいか、その明確なイメージやビジョンを社内、SIer、ベンダーと共有することができる。

RFPがある場合のデメリット

• 発注前の作業にかかる労力や時間等のコストが増えてしまう。

双方のメリットとデメリットを見比べてみると、発注前の作業に労力をかけてRFPを用意することで、その後のシステム提案までの過程がとてもスムーズかつ効率的に進められるということがわかります。 経験が豊富で実力のあるSIerやベンダーに依頼できたとしても、適切なRPFがなければ現在の自社システムの抱える課題を発見してもらえないかもしれません。 しっかりしたRPFを作成しておけば、自社スタッフでは気がつけなかった課題を指摘してもらえることもあります。 現状抱えている課題の解決に向けてもっとも適切なシステム提案を受けるためには、RPFの作成はとても大切な工程なのです。

要件定義との違いは？

システム開発発注の際に用意する書類のひとつに、「要件定義書」というものがあります。 要件定義書は、システムを開発するプロジェクトにおいて、機能要件・非機能要件等、後の工程で必要になる情報が記載されている書類です。 要件定義はシステム設計の基本となる情報なので、基本的にはRFPよりも詳細な内容となります。 SIerやベンダーに対しどのようなシステムが必要か説明し、その実現につながるシステム提案を引き出すために用意されるRFPとは若干異なる内容の書類ではありますが、重なっている部分も多いです。

RFPと要件定義の決定的な違いは、書類としての目的にあります。 RFPの目的は「適切なベンダーを選定しシステムの設計・開発を行うこと」。 それに対して、要件定義の目的は「システム開発において要求する仕様を業務上の観点から定義すること」です。 記載される情報自体は重なる部分が多いですが、書類を用意する目的に大きな違いがあるため、実際の内容はきちんと区別するようにしましょう。

RFP策定の流れ・構成要素

RFPの策定は、導入・リプレイスするシステムが全社のシステムの中でどのような位置を占めているのかをしっかり確認するところからはじまります。 他のシステムへの影響が大きいと予測される場合、今後の経営やIT戦略なども加味して考えていく必要があります。 まずはプロジェクトが自社の中でどのような位置づけにあるかを確認した後、自社が今後目指していく方向性をふまえたシステム計画と合わせRFPを策定し、システム内容の確定・構築…というプロセスで進めていくことになります。

最後に、RFPを構成する基本的な要素についてご紹介します。 具体的にどのような内容が掲載されているか上手くイメージできないという方は、ぜひ参考にしてみてください。

・提案依頼の概要 プロジェクトの全体的なイメージを伝えます。

・提案依頼に関する手続き スケジュールや予算等の条件に関する項目です。

・提案依頼の内容 希望する提案の内容や範囲を伝えます。

・プロジェクト実施の際の各種取り決め プロジェクトを実行する体制、場所、各種費用負担などについての項目です。

・現行システムの課題と理想的なイメージ 現在のシステムが抱える課題（As Is）と、理想的なイメージ（To Be）を記載する項目です。 イメージ図等を用いてわかりやすく伝えることもあります。

・機能要求、非機能要求 どのような機能・非機能が必要か記載する項目です。

・設計や開発、テスト要求 設計、開発、テストと、各段階において必要な条件に関する項目です。

・移行や教育要求 システムを実際に移行するときの内容や教育に関する条件についての項目です。

置かれている状況や目的によって構成要素が変わることはありますが、まずはこれらの項目をRFP策定の際の参考にしてみてください。