RFPの作成を初めて担当する方にとっては、何をどのように記入すればよいのかわからず、難しい業務に感じられるかもしれません。そうしたとき、フォーマットやテンプレートからのアプローチが役立ちます。ここでは、すぐに使えるフォーマットを提供すると共に、RFPを作成する際の手がかりとなる基本事項を解説します。
RFP作成はフォーマットを使用するのがおすすめ
RFP（提案依頼書）は、企業がシステムなどを発注するうえで、ベンダーやSIerに提案を依頼する文書です。「何を、いくらで、いつまでにお願いしたいのか」といった要件を明確に示すことで、より自社のニーズに合った提案を受けやすくなります。
とはいえ、RFPは書かなければならない項目が多く、書き方によっては要望が伝わらない不明瞭な文書となります。不出来なRFPは意図しないシステムの提案や見積金額の高騰を招き、システム導入の失敗にもつながりかねません。
他社の課題解決に寄与したシステムが自社においても機能するとは限らないため、導入後に後悔をしないよう、RFP作成に力を入れることが大切です。そこで、RFPの作成に不慣れなうちは、フォーマットを使用するのがおすすめです。フォーマットを活用すれば、必要な項目の抜け漏れなどを防げて、受注側に仕様や要件が適切に伝わるRFPの作成につながります。
実務で使えるRFPフォーマット
使いやすいRFPのフォーマットとしては、Oracle社によるものと、ITコーディネータ協会によるものが挙げられます。
1. クラウドERP「NetSuite」のOracle社が公開しているRFP
Oracle社が公開しているものは、システムの中でもERPを導入する場合に向けたRFPサンプルです。RFPを初めて作成する場合は、単にフォーマットを利用するだけでなく、サンプルを参照しつつ作成するとスムーズです。
Oracle社は国内外4万社以上の企業にクラウドERPを導入している実績があり、そのノウハウが活かされたRFPは非常に有用性の高いものとなっています。構成は他のシステム導入やプロジェクトにも流用可能なので、ぜひ活用してみてください。
RFP(提案依頼書)サンプル新統合基幹システム導入プロジェクト提案依頼書
2. ITコーディネータ協会が公開するRFPの見本
経済産業省が推進している民間資格のひとつに「ITコーディネータ」があります。その資格認定を行う特定NPO法人、ITコーディネータ協会（ITCA）もRFPのサンプルを公開しています。
RFPおよびSLA（サービスレベル目標の合意文書）の見本として公開されているのは、以下の2つです。これらは具体的なケース企業を想定して書かれているため、使用する際には自社の要件に合わせて適宜読み替える必要があります。提案依頼内容や開発・運用の規模、導入までの期間などに応じ、項目の追加や削除をしてください。
参照先：【開発委託用】本ドキュメントは開発委託用RFP見本です。
参照先：【運用委託用】本ドキュメントは運用委託用RFP見本です。
そもそもRFPとは?
RFPとは「Request for Proposal」の略であり、日本語では「提案依頼書」と呼ばれる文書を指します。企業がシステムの開発やリプレイスなどを外注する場合に、ベンダーやSIerに対して、自社の課題、欠かせない要件、実現したい目標などを示します。
似た用語としてRFIがあります。こちらは「Request for Information」の略で、日本語では「情報提供依頼書」と呼ばれます。発注先の会社情報や実績、提供可能なサービスの概要を把握するための文書です。RFIによって発注先の候補となる会社から製品やサービスなどの一般的な情報提供を受け、RFPでは自社が求める仕様や要件を記載することで具体的な提案を引き出すわけです。
RFP作成の目的
そもそもRFPを作成するのは、自社にとって良い提案を受けるためです。ここでの「良い提案」とは、システム導入などを検討している自社の問題や導入背景をベンダーやSIerに汲み取ってもらえる提案を指します。すなわち、自社（システムなどの導入企業）の問題をどういった方法で解決するのか、導入企業の立場に寄り添った具体的な提案です。
発注者の状況を分析したうえで、それに基づく機能要件の添削などの提案まであると、受注者と発注者の齟齬が生じにくくなります。場合によっては、導入するシステムが期待以上の効果を発揮してくれるかもしれません。
RFP作成時に必ず押さえるべきポイント
良い提案を誘発するRFPの作成にあたっては、最低限明示しておくべき以下の要件があります。
- 提案の依頼をする背景や目的
- 提案を求める範囲と機能
- 提案の具体的内容と提出物
提案依頼の背景・目的
システムなどの導入を決断した背景や、導入目的、自社の課題などの記載は欠かせません。求めている機能や開発の要件を書くだけでは、RFPとして不十分です。発注側の考える機能が、課題解決に最適だとは限らないからです。
発注側は通常、受注側と比べて導入すべきシステムに関する知識や経験が乏しい傾向にあります。課題解決はシステム導入の目的であり、想定する機能は手段です。提案依頼の背景や目的が詳細に記されていれば、受注側は目的と手段のズレに気付き、「こういったパッケージを利用したほうがよい」といった追加の提案ができるかもしれません。一方、そうした情報がなければ、課題を解決できるシステム提案につながらない可能性が高まります。
自社に最適な提案がなされるように、認識している課題を率直に示すことが重要です。
提案範囲 (スコープ)・機能の要件
「何を依頼するのか」だけでなく「どこまで依頼するのか」がわかるように記述することも大切です。システムの開発を依頼したい場合でも、発注者によって関わってほしい工程や役割はさまざまです。
要件を定義するところからリリースまでをお願いしたいのか、その後の保守や運用を担ってほしいのか、データ移行は誰が担当するのかといった点を記載すると、受注者としても提案すべき内容の範囲が明確になります。これは無駄な提案を防ぎ、コストを抑えることにもつながります。
また、無駄を防ぐという観点からは、機能の要件なども明確にしておくのがおすすめです。
提案の内容・提出物
求めている提案の内容や提出物の明確化も重要です。何を求めるのかが不明確なRFPでは、ベンダーやSIerからの提案内容や提出物にぶれが生じやすくなります。そうすると複数の企業にRFPを提出して検討する場合に、企業ごとで提案内容が大幅に異なり、比較検討が困難となりかねません。
RFPの目的を達成するためには、「最良の提案を受注者から引き出すためにはどのような情報を伝えたらよいのか」といった点に想像力を働かせて記述する必要があります。
まとめ
ITシステムの導入に詳しくない人がRFPの作成を担当する場合は、フォーマットの使用をおすすめします。RFPには記述しなければならない項目が多くあり、経験の少ない担当者にとっては難しく感じられるものです。また、項目に不足があると、ベンダーやSIerから思うような提案が引き出せません。
自社にとって最良の提案を引き出すためにも、システム導入経験の豊富な企業などが用意してくれているフォーマットを賢く活用しましょう。
