RFP（Request for Proposal）とは提案依頼書のことです。発注企業がシステム開発などの業務委託を行う際に作成する書類です。候補となる委託先企業に自社の課題や開発目的、システム要件などを正しく伝え、具体的な提案を依頼するために必要不可欠です。本記事では、RFPに関する基礎知識や実際の書き方の手順を解説します。また、サンプルとなるテンプレートも用意しましたので、RFP作成の際はぜひ活用してみてください。
➡︎【資料ダウンロード】サンプルテンプレート付きRFP書き方マニュアル
目次
RFPとは
RFP（Request for Proposal）とは提案依頼書のことです。発注企業がシステム開発などの業務委託を行う際に作成する書類です。候補となる委託先企業に自社の課題や開発目的、システム要件などを正しく伝え、具体的な提案を依頼するために必要不可欠です。いくつかの選定先企業がある場合、同じRFPで具体的な提案を依頼できるので、委託先決定の際にスムーズに検討することが可能です。
RFPを作成する意義
ではなぜ、RFPが必要なのでしょうか。それは、実現したい開発に向け、最適な提案を得るためです。発注企業と開発企業との認識の齟齬は、開発における一番の不安要素です。開発企業においては、発注企業の現状や課題の認識(As is)、目的や今後の方向性(To be)の把握は重要です。「何を」、「どうやって」、「いくらで」、「いつまでに」、といった共通認識を持つことは、互いに認識の齟齬をなくし、開発をスムーズに進める上で重要です。
RFP作成は発注者側
RFPを作成するのは発注企業になります。具体的には情報システム部門の担当者やプロジェクトマネージャーが作成します。また、自社内でRFPの作成が難しい場合は作成支援を外注する場合もあります。システムを導入検討する際には、システムや業務の関係者でプロジェクトを立ち上げることが多いため、そのプロジェクトメンバーでRFPの内容を作成・確認します。
「RFI」と「RFQ」との違い
RFPと混同しやすい用語として、「RFI」という用語があります。RFI（Request For Information）とは、「情報提供依頼書」のことを指します。この情報提供依頼書とは、企業が製品・サービスの導入や業務委託を計画する際にSIerやベンダーに対して、会社の基本情報や実績、技術情報、製品情報などの提示を求める際に出す依頼書のことです。
また、「RFQ（Request For Quotation）」とは「見積依頼書」のことを指します。
システム要件が明確になると、システム化に要する費用の情報が必要となるため、その費用を把握するための文書が「見積依頼書」となります。
それぞれの作成順は「RFI」→「RFP」→「RFQ」となりますが、RFPにRFQが含まれている場合もあります。
➡︎【資料ダウンロード】サンプルテンプレート付きRFP書き方マニュアル
RFPを作成するメリット・デメリット
RFPを作成する具体的なメリット、デメリットにはどういったものがあるでしょうか。
RFPを作成する意義の項でも触れましたが、よりくわしくメリットについて触れたいと思います。またデメリットに関しても確認しましょう。
RFPを作成するメリット
RFPを作成するメリットについては以下の5点が挙げられます。
①正確な情報を伝えることができる
RFPを作成することで、正確な情報を伝えることができます。というのも、発注企業側でRFPが用意されておらず、開発企業に対してシステム開発の要望を口頭で伝えると、認識の齟齬が生じる恐れがあります。問題が発覚した段階で軌道修正するにも時間も労力もかかるため、お互いにとって大変なストレスとなるでしょう。
しかし、RFPがあればそういったリスクを軽減できます。また、明文化されたRFPによって、経営層への社内合意がとりやすくなるでしょう。
②比較検討しやすい
RFPがあれば、各開発企業からの提案に大きなブレがなくなります。必要な機能要件が満たされているかなど、横並びで比較検討がしやすい点が挙げられます。
というのも、RFPなど明確な要求定義がない状態で提案依頼を行うと、各社の見積もり金額や工期に大きな差異が発生する場合があります。したがって、発注企業側の前提と開発企業各社が思い描いている前提に乖離があることに気づき、コンペのやり直しになるケースも多いです。
③より良い提案を受けられる
仮に発注企業側でシステムやテクノロジーの専門的知識に乏しい場合も、要求の概要を文書化することで、要求に適した最新の技術を提案してもらえたり、要求を満たした上で、さらに付加価値のあるより良いシステムが提案される可能性が生まれます。
④複数社に同時に依頼できる
統一されたRFPという文書があれば、複数社に対して同時に提案依頼ができるため、非常に効率が良いと言えます。都度、各社ごとに打ち合わせを実施せず、候補先の企業を集めて説明会を行うこともRFPがあるからこそ可能です。仮に個別に打ち合わせが発生しても、RFPに基づいて進行できるため、非効率的な打ち合わせを減らすことができます。
⑤スケジュールや納期が適切か確認できる
社内で想定していた納期や作業スケジュールに無理がないかどうかを確認できます。場合によっては、納期の見直しやスケジュールの再検討が必要になることでしょう。
また、RFQ(見積依頼書)も依頼した場合、設定していた予算が適切かどうか確認できます。あらかじめ予算を伝えても問題はないですが、予算は明示せず、複数社に依頼することで予算の妥当性を判断することも可能です。
| ◆予算の記載は意見が分かれる◆ RFPに予算を記載すべきかどうかは、意見が分かれます。 予算を記載しないメリットは、金額面での競争原理が働きやすいことに加え、 制約の無い状態での提案が期待できること。 要求した機能をすべて実現した場合にいくら必要か知りたい場合、予算を記載すると、 それが制約になってしまって、機能や信頼性が削られた提案をされてしまう可能性があります。 予算を記載するメリットは、すべての提案が予算を大きく上回ってしまうリスクを回避できること。 また、同じような金額の提案が並ぶことにより、提案内容に集中して比較しやすくなることが挙げられます。 予算を記載しないデメリットは、提案の金額に開きが生じてしまうこと。 倍以上の格差が出ることは珍しくなく、基幹システムを刷新した場合は 数十億円差が出る場合もあります。 |
⑥案件の確度がわかり開発企業側も取り組みやすい
RFPが用意されていることは、提案を依頼される開発企業側にとっても安心材料になります。というのも、開発企業における提案コストも無償ではありません。実際は予算取りも案件化もまだこれからという情報収集目的の場合、ケースによっては提案が辞退されることもあり得ます。
➡︎【資料ダウンロード】サンプルテンプレート付きRFP書き方マニュアル
RFPを作成するデメリット
RFPを作成するデメリットは、ほとんどないと言っても過言ではないですが、強いて挙げるなら以下の2点が考えられます。
①開発企業によっては敬遠される場合も
受託開発企業側からすると、RFPがしっかりしている会社は、お堅い企業といった印象を受けるケースもあります。自社の実績や経験が不足していると考える開発企業の中にはRFPを要求する企業を敬遠する場合があります。
②作成工数がかかる
RFPは要件を詳細に記載する必要があるため、特に、初めてRFPを書く人や、システムの知識に乏しい人では、RFPを作成する際の抑えておくべきポイントや書き方の手順に慣れるまで大きな負担になり、作成工数がかかるでしょう。
しかし、より良いシステムを構築するためのRFP作成は、自社のニーズに合ったシステムを開発してもらうために欠かすことのできない工程です。
以降の章で、RFP作成のステップやRFPに記載する内容等を紹介いたしますので参考にしてみてください。
➡︎【資料ダウンロード】サンプルテンプレート付きRFP書き方マニュアル
RFP作成のステップ
ここからは、RFP作成のステップを紹介いたします。まずは一般的なシステム開発の依頼の流れを確認しましょう。
RFP作成までの流れ
１：課題発見、システム導入の目的設定
自社の課題の発見や新規企画などシステムを導入する目的を設定します。
２：社内での現状確認
RFPを作成する前に、まずは社内での情報の洗い出しや共有が求められます。
特に開発するシステムが基幹システムなど自社にとって大きな位置づけとなるものの場合、予算だけでなく、自社のDX戦略や他部署へ与える影響など横断的に考慮しなければいけません。ときには社内でヒアリングやミーティングを行い、全社的にシステムの希望要件をまとめる必要があります。
このプロセスを飛ばしてしまうと、現行のシステムとうまく連携できなかったり、システム導入後にトラブルになったりするケースがあるでしょう。
３：システム開発企業（ベンダー）の情報収集、選定（RFI）
候補となるシステム開発会社をリサーチします。そこで、ある程度候補を絞り込んだら開発企業へのヒアリング、またはRFIを通じて情報提供を依頼します。
４：RFP作成、提出
社内での情報収集や候補先のシステム開発企業を絞り込んだら、RFPを作成します。記載内容の詳細は後述します。RFPを提出後、発注企業は各システム開発企業に対してRFPの内容を説明し、システム開発企業からの質問に回答します。説明会は、一般的にオリエンテーションと呼ばれることがあります。
５：委託先企業選定のための評価基準の設定
RFP作成と同時に、委託先企業を選定するために評価基準を設定します。
自社が求めるミッションへの理解やゴール認識の一致など各項目を作り、点数を配分すると評価が明確になり、わかりやすいでしょう。
| ◆TIPS◆評価基準を設ける際のヒント どのような観点で点数化し評価するのかは難しいものです。 考え方のヒント10のうち4つを以下に紹介します。その他のヒントは下記DL資料にございますので ぜひダウンロードしてみてください。 ➡︎【資料ダウンロード】サンプルテンプレート付きRFP書き方マニュアル ①RFPで提示した与件を理解していることが提案資料から読み取れる └ベンダーが与件の共通認識を持っており、自社と認識の齟齬がないか ②与件に対し、提案に網羅性があるか └自社が提示している要求に対して、網羅的な回答がある ③各提案項目についても熟慮されていて、論理的な回答があるか ④自社の考えているQCDS（品質・コスト・納期・スコープ）の優先順位と、提案がマッチしているか 作成のフロー詳細やポイント、評価基準設定のヒントは下記マニュアルに記載があります。 |
➡︎【資料ダウンロード】サンプルテンプレート付きRFP書き方マニュアル
６：開発企業からの提案、プレゼンテーション
候補先の複数の企業から提案書や見積書を提示してもらいます。必要に応じて、プレゼンテーションやコンペティションを実施します。
７：委託先企業の決定、システム内容の決定
プレゼンテーションやコンペティションを実施し、設定した評価基準に基づき判断します。委託する開発企業が決定したら、提案書の調整などを行い契約を締結します。
８：システム開発開始
契約締結した開発企業と十分な意思共有と要件定義の整理が済んだら、いよいよシステム開発に着手します。
➡︎【資料ダウンロード】サンプルテンプレート付きRFP書き方マニュアル
RFPに記載する内容
RFPに記載する内容について、決まりはないですが、概ね下記のような内容で記載されることが多いです。
●プロジェクトの目的・概要
提案依頼書の目的を説明するページです。このシステムを導入したい目的や、プロジェクトの目的を記載します。
例：商品の魅力を伝えるUI/UXデザインの優れたサイトを開発する
●プロジェクトの背景
経営的課題や業務効率化の課題など、システムを導入することになった背景や経緯を説明するページです。同時に、システム構築・導入で解決したい現状の課題を説明する場合もあります。
●委託までのスケジュール
どのような日程で提案・選定スケジュールが進んでいくのかを提示します。
提案書の締め切りなどを明示し、依頼した提案書がスムーズに集まるようにしましょう。
●プロジェクトのゴール（目標）詳細
プロジェクトにおける達成したいゴール（目標）を示します。目的や背景からブレイクダウンし、目標を書き出しましょう。
例：会員獲得数〇％アップ/顧客単価昨対比〇％アップ
●委託の範囲（スコープ）
開発企業に対し、提案を依頼したい委託の範囲を説明するページです。「機器の購入から開発まで依頼したい」「システム開発だけを依頼したい」など、委託の範囲を明確に説明しましょう。範囲を箇条書きやプロジェクト全体の概念図等でまとめると、わかりやすくなります。
●提案依頼の概要(要件定義)
開発企業に提案してほしい内容 (機能要件) やその範囲を明確に伝えます。また、性能や可用性、セキュリティなど必要とする機能面以外の要件 (非機能要件) も書き込みます。文字通り、機能以外のすべての要件を指します。
●会社情報
自社の取扱商品や業種、販売形態などの情報を説明するページです。箇条書きで記載して問題ありません。自社の紹介資料があれば、別途RFPに添付してもOKです。
●システム構成
自社が現在使用しているシステムの構成図や、システムの概要を説明します。構成図が複雑で作成が難しい場合はシステムパッケージ（既存の製品版システム）の名前を説明しても構いません。システム名の明示を避けたい場合は顧客管理システムなど一般名称で記載することも可能です。
●対象プラットフォーム/開発言語
対象のブラウザなど希望のプラットフォームがあれば記載しましょう。開発言語についても指定があればあらかじめ記載しておくとスムーズです。
RFPを１から作成するのは難しいといった際は作成支援も行っている開発企業もあるので問い合わせてみましょう。
各社、テンプレート毎に記載されている内容が異なる場合があります。記載項目や構成に決まりはありませんので、必要に応じて活用してみてください。
➡︎【資料ダウンロード】サンプルテンプレート付きRFP書き方マニュアル
RFPを作成するうえでの注意事項
ここまでRFPに記載する内容をみてきましたが、作成時の注意事項についても確認してみましょう。
システムに期待していることは全て記載し、抜け漏れを防ぐ
システムを開発するにあたって、希望する要件は全て記載しましょう。純粋な機能要件だけではなく、障害時のサポート体制、データのバックアップや機能拡張の際の対応方法等も抜け漏れのないようにしましょう。
使いこなせるか実態に即した要求をする
システム担当者が単独で作成した場合に起こりがちですが、実際の現場の業務フローを考慮できていない機能要件を要求しないようにしましょう。せっかく新しくシステムを開発するので、必要そうな機能はすべて搭載したくなりますが、現場の運用と乖離した要件は避けたいところです。管理工数の短縮や効率化を目指すつもりが、かえって入力工数が増えたり、機能が複雑でマニュアルを毎回確認しないと使いこなせないといった事態に陥ってしまうと本末転倒です。エンドユーザー向けのシステムでも同様です。ターゲットユーザーが使いこなせないオーバースペックなシステムはかえって評価を下げかねません。
RFP提出後の追加要求は避けましょう
RFP提出後の追加要求は避けましょう。というのも、盛り込んだ要件によって、提案される費用や納期も変わります。RFP提出後に要件等が変わってしまうと、開発企業側でアサインする人員体制や当初のスケジュールからの変更、見積りの出し直しなど、新たな工数がかかります。自社としても再度の稟議やスケジュールの再考など２度手間になるので避けましょう。とはいえ、新規事業などビジネスモデルの構築や市場調査に不安な場合は、短サイクルでPDCAを回してブラッシュアップできるアジャイル開発が可能な開発企業へ打診するのも一手です。
★アジャイル開発について詳しくはこちら
➡︎【資料ダウンロード】サンプルテンプレート付きRFP書き方マニュアル
まとめ：RFPを作成し、手戻りのないベンダー選定をしよう
RFPは、開発企業にシステム開発を委託する際に必須のフローではありません。しかし、本記事で解説したようにRFPがあると、自社内での事業イメージの把握や整理に非常に役に立ちます。また、言語化・文書化することによって開発企業側へ齟齬なく自社の課題、システム開発目的、ゴールを伝えることができます。
一度作成してみれば、作成の勘所が掴めますし、記載が必要な項目や会社情報など、基本的な情報は、汎用性があるので自社のテンプレートとして活用できます。それでも不安な場合は、開発企業からRFPのテンプレートを取り寄せたり、作成方法のレクチャーを依頼してみてはいかがでしょうか。開発企業側が知りたい情報の落とし込み方など開発企業からの視点でアドバイスが可能です。
➡︎【資料ダウンロード】サンプルテンプレート付きRFP書き方マニュアル
デジタルトランスフォーメーションを検討している企業ご担当者様へ
モンスターラボは、2200件以上のサービス・プロダクト開発の実績から得られたデジタル領域の知見を活かし、企業のDX推進戦略をあらゆる面からサポートいたします。
ご提案・お見積もりの段階から、デジタル領域の知見を持つコンサルタントをアサイン。新規事業の立ち上げ・既存事業の変革などのビジネス戦略を上流工程からサポートいたします。
開発プロジェクトでは、UXリサーチ・設計、UIデザイン、ブランド開発、デジタルプロダクト開発、グロースハックまでの全行程をワンストップで提供。
モンスターラボが提供するサポートの詳しい概要は、下記のボタンから資料をダウンロードしてください。
直近のイベント
記事の作成者・監修者
モンスターラボ DXブログ編集部
関連記事
