RFPとは企業がシステム開発を依頼する企業に対し提出する「提案依頼書」のことを指します。
RFPにどのようなシステムを・いくらで・いつまでに作ってほしいかまとめ、その内容を元にシステムベンダーが実装の提案を行います。RFPを作成することにより双方の認識を一致させ、より良い提案を受けられる点がメリットです。
本記事ではRFPとは何か、作成するメリット・デメリット、記載する内容を解説します。これからシステム開発を検討している方は、ぜひ参考にしてください。
書籍『リーダーの仮面』の図説資料をプレゼント！
株式会社識学 代表取締役社長 安藤広大の執筆した書籍「リーダーの仮面」は、結果の出せるリーダーになるために必要なテクニックをまとめたリーダーシップ本の決定版！
誰でも実践できるマネジメントの原理原則をPDF17ページにググっと凝縮！
ぜひ、DL頂き、皆さまの日々のマネジメントに生かしてください！
目次
RFPとは？
RFPとは、Request for Proposalの略称で、日本語では「提案依頼書」と訳されます。発注者（企業）が、開発者（システムベンダー）に提出するもので、発注要件などをまとめたものです。
企業が情報システムの開発や導入、業務委託などの発注先を決めるときは、初めから1社に絞るのではなく、複数の候補先から選定することが多いでしょう。このとき、各候補先から具体的な提案を得るために必要となる書類がRFPです。
記入する内容は、自社の現状と課題、システム導入の目的や達成したいこと、制約、予算、納期などが多いでしょう。
RFPの目的
RFPの目的は、発注者とシステムベンダーの認識を一致させ、状況に即した提案を引き出すことです。
もちろん、ミーティングのときにシステム要件を口頭で説明する方法があるものの、これでは、発注候補先企業の認識のズレが生じやすくなってしまうことが考えられます。
そこで、システム上必要な要件を書面上でまとめることにより、お互いの理解を一致させやすくなります。
RFPは誰が作るのか
RFPは、発注者側の情報システム部門で作成することが多いです。その場合、システムを実際に導入する部門の担当者や、経営層に要望をヒアリングして作成していきます。
仕様や書き方は特に決まりはないものの、複数人に共有しやすいようWordやPowerPointなどで作成するのが一般的です。小規模なRFPでは数ページ程度で収まりますが、大規模なシステムであればRFPだけで数百ページに及ぶこともあるため、早めの準備が必要です。
RFIとの違い
RFIとはRequest for Informationの略称で、日本語では「情報提供依頼書（情報依頼書）」といいます。RFIは、システムベンダーの基本情報や技術情報、開発実績など、情報提示を求めるための資料です。
RFPがシステムベンダーから提案を受けるために作成するのに対し、RFIはシステムベンダーの情報収集やスクリーニングを目的として作成します。
RFQとの違い
RFQとは、Request For Quotationの略称で、日本語では「見積依頼書（見積要求書）」といいます。RFQはシステムベンダーに対し、代金決定に必要な条件を明記し、見積を出してもらう際に提出する書類です。
通常は、RFPやRFIを作成した後に発行し、最後にRFQを提出して具体的な見積内容を確認する流れです。
なお、RFQはシステム開発だけでなく、既製品の購入時にも利用されます。
RFPを作成するメリット
システムに詳しい人材がいなかったり他の作業で忙しかったりすると、RFPの作成がおっくうに感じる事もありますが、システム開発をする前にRFPを作っておくことは、さまざまなメリットがあります。代表的なメリットについて、詳しく解説します。
1. 情報の伝え漏れを防ぐ
自社が求めるシステム要件を、ミーティングや電話、メールなどで各ベンダーに都度伝えることは可能です。しかし近年では、情報システムで処理が必要な業務内容は増加傾向にあり、大規模システムであればRFPが数百ページに及ぶこともあります。
それらの内容を口頭だけで説明するとなれば、当然抜け漏れも生じやすくなるでしょう。また提案を受けるために、毎回システムベンダーを集めてミーティングを開いたり電話で説明したりすれば、その分の手間もかかってしまいます。
RFPであれば、一度必要事項をまとめて作成すれば、複数のベンダーと必要事項をシステムの概要を簡単に共有することが可能です。抜け漏れも発生しないため、結果として自社が希望するより良い提案を受けやすくなります。
2. 言った・言わないなどのトラブルを予防する
口頭説明には別の問題点があります。それはシステムベンダーにより仕様の解釈が異なる恐れがある点です。必要な要件を満たしていなければ、その分を確認し、改めて提案を受ける必要もあります。
また、文章化しなければ、言った・言わないなどのトラブルに発展しやすい点にも注意しなければいけません。RFPを作成すれば、初歩的なトラブルにより優良な候補先を減らすリスクを削減することが可能です。
3. システムの比較・検討がしやすくなる
RFPを作成せず、システムベンダー側の仕様により提案を受けることになると、提案書の内容や仕様がそろっておらず、比較・検討がしづらくなってしまいます。発注先を選ぶまでの工数も想定よりかかり、システム開発自体のスケジュールに遅延が発生しかねません。
また、不要な機能があったり必要な機能がなかったりなど、問題点が選定後に発覚すれば、システム構築のやり直しも必要になるでしょう。
あらかじめRFPを作成しておけば、依頼書の内容に沿ってベンダーごとの提案を簡単に比較・検討できるためよりよい提案先を選びやすくなります。
4. 社内の情報を整理できる
RFPは、発注者側が情報を整理し、システム構築に必要な要素の理解を深められる点もメリットです。
システム開発では発注者側がシステムに詳しくないからと、イメージが曖昧なままシステムベンダーに丸投げしてしまうことも多々あります。結果として、本来の想定とは異なるシステムが出来上がってしまうことも珍しくありません。
事前にRFPを作成する工程で、発注者側でも今一度、必要な機能の整理が可能です。また、IT化の必要性やシステム全体の理解も進み、自社に本当に必要なシステム開発を依頼しやすくなります。
RFPを作成するデメリット
システム開発を依頼するときはRFPが必要とはいわれるものの、RFP作成にも時間的・人的コストが発生します。
また、RFPの提出後は追加要求を出しづらいため、RFPの作成段階で必要な要件は出し切らなければいけません。スムーズにシステムを導入するべく、RFPのデメリットについてもしっかりと理解しておきましょう。
1. 発注前の時間的コストがかかる
システム開発の初期の流れは、RFPの作成・各システムベンダーの提案の選定・契約の3つのステップです。これだけでも一般的には、3〜5カ月程度の時間がかかります。
なお、ベンダー側が提案書を作成するのに約1カ月、そこから本契約に進むまでに約1カ月程度時間がかかるといわれています。残りの1～3カ月はRFPの作成時間に見積もられていることからも、多くの時間的コストが発生すると分かるでしょう。
なお、RFPの作成にどの程度時間をかけられるかは、システムベンダーとの契約希望時期から逆算する方法もあります。
もし、3カ月でシステム開発の準備を進めたいなら、1カ月程度でRFPを作成しなければいけません。
ただ、RFPの作成ではプロジェクトチームの結成や要望の洗い出しなどやる事が多く、一般的には余裕を持って2カ月～3カ月程度作成に時間をかけるのが一般的です。
2. RFPの準備に人的コストがかかる
RFPは一般的にプロジェクトチームを結成して作成します。人数が十分かつ専業でRFPを進められれば準備も早いものの、現実的には限られた人数が社内の本業と兼任するケースが多いでしょう。
なお、プロジェクトチームでは、システム部門のスタッフだけではなく、エンドユーザー部門など、必要な部門のスタッフをバランスよくそろえる方が望ましいです。
専任でも兼任でも、プロジェクトチームを作るとなればチームメンバーの本業を別の社員が巻き取る必要も出てきます。
以上のように、時間だけでなく社内の人的コストを投じて進めなければいけません。
3. 追加要求は想定外の工数が発生する恐れがある
RFPを提出した後は修正がしづらい点もデメリットです。正確には修正は可能であるものの、当初の予算やスケジュール通りには進まなくなる可能性が高いため注意しましょう。
システムベンダーはRFPの内容を元に、1カ月程度かけて、提案書や大まかな見積を作成します。そこで、途中から要件を追加してほしいなどの依頼をすれば、当然ながら提案書のやり直しが必要です。
RFPの作成段階で必要な要素は全て出し切るようにしましょう。
RFPに記載する内容
RFPに決まった様式はなく、記載する内容もそれぞれの企業で自由に決定して問題ありません。何をしたいのか・いくらでしたいのか・いつまでにしたいのか、上記の3つのポイントを抑えると理解しやすいでしょう。
ここでは、発注者と受注者の認識を合わせるために必要な、一般的な内容を解説します。
プロジェクトの概要
RFPはあくまでも文章のため、最初に表紙・挨拶・目次を持ってくるのがビジネスマナー的にも一般的です。次に、プロジェクトの目的や主旨、システム化する業務の概要、スケジュール感など、全体像を記載します。
最初に概要をまとめることで、後々の内容が理解しやすくなります。
現状の課題と理想的なイメージ
希望するシステムの概要を伝えるためには、現在どのような状況であり、システム導入によりどのように変えていきたいかを明記すると良いでしょう。その上で、以下のようにまとめると、現在の課題と理想像が分かりやすくなります。
- システム開発に至った背景
- 現在の課題（システム化したい業務の課題）
- システム開発で達成したい内容
- 各要件に求めるゴール（予算・スケジュール・品質）
- 社内の運用予定体制
- 現行のハード・ソフト情報
特に、ゴールの共有はそれぞれの認識を一致させる上でも大切です。
提案依頼要件
提案依頼要件は、RFPの「何をしたいのか」に相当する部分です。システムに求める機能に直結する内容のため、詳細に記入しましょう。ここでは、システムの機能そのものに対する要求と、それ以外の要求に分ける書き方を紹介します。
機能要求
システムに盛り込みたい機能と不要な機能を明記します。ここがぶれると、工数が大きく変わるため、担当部門などに確認し入念に洗い出しましょう。
非機能要求
非機能要求では、システム開発時から開発後の保守まで、そのシステムに対して何をしてほしいかを明記します。例えば、以下のとおりです。
- 提案依頼範囲：開発から保守までなど依頼したい範囲を明記する。
- テスト要件：テスト環境や方法の要件を明記する。
- 移行要件：システム移行時の要件を明記する。
- 教育要件：システムの利用方法の教育が必要か明記する。
- プロジェクト体制：開発側のメンバーやマネジメント方法の希望を明記する。
システムの予算
予算はRFPの「いくらでしたいのか」に相当します。予算を明確にすれば各システムベンダーの提案を比較しやすく、金額の違いもはっきりします。
あまりにも予算が少ないと欲しい性能を搭載できない恐れもあるため、事前に相場を確認して設定するのが望ましいでしょう。
提案依頼スケジュール
RFPの「いつまでにしたいのか」に当たる部分です。発注者側で想定している提案依頼から本契約、実際の稼働時期を明記します。また、稼働までの各段階の開発フェーズを明記しても良いでしょう。
契約から運用までの納期の希望を伝えることで、システムベンダー側でも予定を立てやすく、また、見積書作成時の精度を高めることができます。
プロジェクト実施時の取り決め
最後に、特記事項に相当する内容をまとめます。契約条件や守秘義務などの法務条件の他、資料提供・貸出、画像の提供など、後々必要となる細かな事項についても取り決めをまとめましょう。
特記事項を詳細に記入すれば、契約後のトラブル防止にもつながります。
システム導入時は適切なRFPを作成しよう
RFP（提案依頼書）とは、システムベンダーから提案を受けるときに作成する書類です。
RFPの作成により、発注者・開発者双方の理解を一致させることができ、複数の提案を同じ要件から比較・検討できるようになります。結果として、より自社の希望に沿った提案を選択しやすくなる点がメリットです。
なお、RFPには決まった書き方がないため、何を・いくらで・いつまでに作りたいかを明確にしてからまとめて下さいう。自社に適したシステムを開発するためにも、適切なRFPを作成しましょう。
株式会社識学 代表取締役社長 安藤広大の執筆した書籍『数値化の鬼』が、なんと発売後 約１か月で１２万部を突破しました！
この感謝を皆様にも還元すべく、株式会社識学では、『数値化の鬼』の図解解説資料を作成いたしました！
一度書籍をお読みになった方も、まだお手元にない方もどなたでも満足いただける完成度となっています！
眺めるもヨシ、印刷して目の付くところに飾るもヨシ、使い方は自由自在！
是非、こちらからDLしてくださいね！
