最終更新日：2024年8月2日
近年DX化が進み、システムを導入して自社の業務改善を図る企業が増えています。
しかし、「システム開発に詳しくない」という理由で発注側が受け身になり、ベンダーに何もかも任せきりにした結果、両者の間で認識のズレが生じてシステム導入が失敗に終わるケースも少なくありません。
そこで重要になるのがRFP（提案依頼書）の作成であり、トラブルなくシステム開発を成功させるために必要不可欠なものになります。
今回は、RFPについてよく知らない方や、ベンダーの選定に向けてRFPを初めて作成することになった方向けに、RFPの概要やメリット、RFI・要件定義書との違い、作成までの流れ、作成時のポイントなどについて解説していきます。
なお、「RFPを自社だけで作成するのは難しい・・・」と感じる企業担当者様向けに、当社では情シス支援サービス「ION」を行っております。お困りの方はぜひ一度ご相談ください。
目次
１．RFP（提案依頼書）とは？
RFPとは「Request for Proposal」の略で、日本語では「提案依頼書」を意味します。
発注側企業がベンダーに対して自社の考え・要望を示し、新しいシステムの具体的な提案を依頼するために作成する文書です。
発注側企業が現状抱えている課題や導入目的、システムに求める内容などをベンダーと共有し、お互いの認識統一を図り、ニーズに合った最適な提案をベンダーから引き出す役割を持っています。
RFPを作成する目的
RFPを作成する目的は、「発注側企業がベンダーに対し、自社の課題や実現したいこと、システムに求める要件を漏れなく正確に伝え、お互いの認識をすり合わせるため」です。
RFPを作成せずに口頭で情報を共有したり、書面の内容が不明瞭だったりすると、自社の意図や要望がベンダーに対して十分に伝わらず、発注側のニーズに合った提案を受けられない可能性があります。
ベンダーはシステム開発のプロですが、発注側の内情をすべて理解しているわけではないため、RFPを通して現状の課題（As-Is）や目的・今後の方向性（To-Be）を明確に伝えることで、双方の認識のズレや不足が生じるリスクを最小限に抑え、発注側が期待する通りのシステムを導入することができます。
RFPの作成者は誰か？
RFPは基本的に、システム開発を依頼する側、つまり発注側企業が主体となって作成するものです。
一般的には、社内システム全般を司る発注側企業の情報システム部門が、現場部門の業務担当者や経営層など、各関係者にヒアリングを行いながら作成を行います。
ただし、社内にシステム開発の知見を持つ人材が不足している、RFP作成のノウハウが無いなどの理由で、自力でRFPを作成することが難しい場合は、外部のコンサルティング企業やSIerに作成支援を依頼することもあります。
２．RFI・RFQ・要件定義書との違い
RFI（情報提供依頼書）
RFPとよく似た用語に「RFI（Request for Information）」がありますが、これは日本語で「情報提供依頼書」と訳され、発注側企業がベンダーに対して、会社情報や開発実績、技術・製品情報の提示を求める書類のことを指します。
通常RFPの前に作成するもので、一般に公開されているWebサイトや会社パンフレットでは得られない情報提供を受けることができます。
基本的には「RFI→RFP」の流れでやり取りされるため、RFIは一次選考のための書類、RFPは二次選考のための書類、と使い分けるケースが多くなっています。
なお、RFIについては以下の記事でも詳しく解説しておりますので、よろしければぜひご一読ください。
さらに、発注側から提供する情報やベンダーから提供される情報が、競合他社には知られたくない企業秘密に当たる場合は、第三者への漏えいを防ぐために、必要に応じてNDA（機密保持契約）を締結しておくと安心です。
RFQ（見積依頼書）
また、RFPと混同しやすい用語として「RFQ（Request For Quotation）」がありますが、これは日本語で「見積依頼書」と訳され、発注側企業がベンダーに対して、システム開発に要する費用の見積もり額やその内訳を提示するよう依頼する書類のことを指します。
システムに求める要件が明確にならないと見積もり額も算出できないため、通常RFPの後に作成する書類ですが、RFQの作成を省略し、RFPの中に見積もり依頼を含めてしまうケースもあります。
要件定義書
要件定義書とは、システム化に際し発注側が提示したさまざまな要望を実現するために、必要なシステムの機能や性能は何かをまとめたものです。一般的に、ベンダーの支援を受けながら発注側企業が作成します。
どちらも発注側とベンダーの認識をそろえ、システム開発をスムーズに進めるために必要不可欠な書類ですが、RFPと要件定義書の主な違いは「利用されるフェーズ」と「目的」にあります。
RFPは、「複数のベンダー候補から自社に合った具体的な提案を引き出し、最終的に適切なベンダー1社を選定すること」を目的としています。
「発注先のベンダーを正式に決定する前」に活用される書類です。
一方、要件定義書は「発注側の要望をどの程度実現できるか、技術的な観点を交えて整理し、システムを設計・開発する際の土台にすること」を目的としています。
「発注先のベンダーが正式に決まった後」に活用される書類です。
なお、要件定義に関してもっと理解を深めたい方は、こちらの記事も併せてご参照ください。
３．RFPのメリット
次に、RFPがなぜ必要なのか、6つのメリットについて見ていきましょう。
自社の要望をベンダーへ正確に伝えられる
RFP作成における最大のメリットは、自社の要望をベンダーに対して適切に伝えられることです。
口頭だけの説明では要件の抜け漏れや認識相違が発生し、ベンダーから見当違いの提案を受ける可能性が高くなります。提案内容の軌道修正をするにも余分な時間や労力がかかり、お互いにとって大変なストレスとなってしまうでしょう。
RFPを事前に用意しておくことで、自社の課題や将来像を踏まえた満足のいく提案を受けることができ、その後のシステム開発もスムーズに進みます。
自社の課題を冷静に見つめ直すきっかけになる
RFPを作成するには、「何のためにシステムを導入するのか？」「システムを使ってどんな課題を解決したいのか？」という根本的な部分を明らかにする必要があるため、自社の現状を見直す良い機会になります。
自社課題の抽出を進めていくうちに、今まで気づかなかった課題にも気づくことができるかもしれません。
また、しっかりとしたRFPがあれば、発注側だけでは洗い出しきれなかった課題をベンダーから指摘してもらえることもあるため、RFPの作成は自社の現状把握や課題発見、将来像の明確化に大いに役立つといえます。
ベンダー各社からの提案を効率良く評価・比較できる
RFPが無いと、発注先の候補となるすべてのベンダーに自社の意図や要望を口頭で説明しなければならず、説明が各社で食い違ったり、ベンダー側で異なる意味に解釈されてしまったりして各社バラバラな提案となり、評価が非常に難しくなります。
複数のベンダーに同じ内容のRFPを出すことで、各ベンダーからの提案に大きなブレがなくなり、提案内容の比較をスムーズに行い、自社に合った最適なベンダーを見極めやすくなります。
トラブル発生防止になる
システム開発の場面では、曖昧な要求や口約束、認識の違いなどを原因としたトラブルが発生するケースが少なくありません。
例えば、発注側は「要件をきちんと伝えたのに完成したシステムが思っていたものと違う」、ベンダー側は「発注側の要望通りシステムを作った」と主張し、意見が平行線を辿って訴訟に発展するケースがあります。
ひとたび訴訟に発展してしまうと、解決までには何年もかかり、発注側・ベンダー側ともに大きなダメージを受けることになります。
RFPを作成して要件を明確にしておくことで、こうしたトラブルの発生を未然に防ぐことができます。
想定スケジュールが適切か確認できる
RFPを作成することで、社内で想定していたシステム開発スケジュールや納期に無理がないかどうかを確認できます。
RFQも作成する場合、発注側で設定していた予算の妥当性も判断できます。
もしプロジェクトの進行に無理があると判明した場合には、予算・納期の見直しやスケジュールの再検討が必要になります。
ベンダー側も提案作業に取り組みやすい
RFPがあれば、提案を依頼されるベンダー側にとっても安心材料になると言えます。
ベンダーからすると、提案作業1つとっても多大な時間と労力がかかるため、RFP無しでシステム化の目的や要求内容も不明瞭なまま提案を依頼した場合、割に合わないと感じ提案を辞退されてしまう可能性もあります。
RFPにより、自社の現状や課題、システムに求める内容などが整理されていれば、少なくとも単なる情報収集目的ではなく、真剣にシステム導入を検討しているという意思がベンダーに伝わるため、より質の高い提案を受けられることが期待できます。
４．RFPに必要な項目
RFPには特に決まったフォーマットはありませんが、「全体の概要」「提案依頼内容」「選定の進め方」の3つを軸として作成することが多いです。
ここでは、3つの基本構成に沿ってRFPに最低限記載が必要な項目について列挙していきます。
なお、項目ごとに具体的にどのような内容を記載する必要があるのか、書き方を詳しく知りたい方は、こちらの記事も併せてご参照ください。
全体の概要
今回の依頼目的や背景、自社が抱える現状の課題、目指すべきゴール、現行のシステム構成など、プロジェクトの全体像を伝える部分です。
提案依頼内容
ベンダーに対し、提案書に盛り込んでほしい情報を伝える部分です。
選定の進め方
選定スケジュールや提案書の提出先、提出期限、評価基準など、RFPの提出後にどのような手順でベンダーの選定を進めるか示す部分です。
５．RFP作成の手順
RFPの作成までに必要なステップと、RFP提出後のベンダー選定までの流れは次の通りです。
RFP作成までの流れ
まずは、RFPの作成までに必要なステップをご紹介します。
①プロジェクトチームの編成
RFPの作成にあたっては、プロジェクト担当者1人だけで進めず、RFP対応専任チームを編成することが望ましいです。
各部門の要望をRFPに漏れなく反映し、システム導入後のミスマッチによる社内トラブルを回避するためにも、情報システム部門や実際にシステムを利用する業務担当者を中心に、複数メンバーでプロジェクトを進めましょう。
なお、チームを編成する際は、プロジェクト全体のマネジメントを担うプロジェクトマネージャー（PM）と、経営的な視点から意思決定を行うプロジェクトオーナーを優先的に決めておくのもポイントです。
②現状の課題洗い出し
次に、現時点での課題を徹底的に洗い出します。
部署や役職によって抱えている課題はそれぞれ異なるため、経営層、マネジメント層、現場部門など、社内のさまざまな立場の人にヒアリングを行い、どのような課題があるのか、優先的に解決すべき課題は何か、認識をすり合わせましょう。
現行業務において今何に困っており、どの課題から率先して取り組むべきか明確にすることで、システムに必要な機能が何なのか見えてくるため、より目的に沿ったシステムを導入できるようになります。
【課題例】
- 手作業が多く、ヒューマンエラーが多発している
- 情報が1ヵ所に集約されておらず、作業効率が悪い
- 既存システムの性能が低く、処理に時間がかかる
- 業務プロセスの変更に伴い、既存システムで不足する機能が出てきた
③システム導入目的の明確化
社内で現状課題の洗い出しができたら、その内容に基づきシステム導入の目的を明確にしましょう。
導入目的が曖昧なままだと、せっかく導入したシステムが使われないまま放置されかねないため、「なぜそのシステムを開発するのか？」「システムを活用して何を成し遂げたいのか？」をしっかりと言語化し、システム開発の軸がブレないよう、プロジェクトメンバーの間で認識を共有しておくことが大切です。
④RFIによるベンダーの情報収集
課題の洗い出しや導入目的の設定ができたら、次はRFIをベンダー10社ほどに提出し、製品・サービスに関する情報を幅広く収集します。
RFIの回答内容を見て、自社の目的に合わないベンダーや想定と大きく異なったベンダーを発注先の候補から除外していき、次のRFPを送付するベンダーを3～5社程度に絞り込みます。
⑤システムに対する要求内容の具体化
社内関係各所からのヒアリング内容やRFIで収集した情報をもとに、「この業務のこの課題をこの機能で解決したい」など、課題解決に向けてシステムに求める機能や性能、成果物のイメージなどを具体化してまとめていきます。
プロジェクトの予算やスケジュールの都合上、基本的にすべての要求内容を一気に実現するのは難しいため、「必ず実現したいもの」「できれば実現したいもの」と優先順位を付けながら整理していくのがポイントです。
⑥評価基準の設定
RFPの作成と同時に、ベンダー各社からの提案内容を比較するための評価基準を設定します。
発注側である自社が、何を重視しどのような観点でベンダーを評価・選定するのか、RFPにあらかじめ明記しておくことで、ベンダーの提案レベル向上が見込めます。
⑦RFPの作成・提出
発注先の候補となるベンダーを絞り込んだら、本格的にRFPの作成に移ります。
ここまでの内容を踏まえ、現状の課題や実現したいこと、プロジェクトの目的、システムに求める要件などを社外の人間にも明確に伝わるようドキュメント化し、ベンダーへ提出します。
場合によっては、見積額の提示を依頼するRFQを作成・提出することもあります。
RFP提出後の流れ
次に、RFP提出後の流れをご紹介します。
⑧提案書の比較・評価
ベンダーからRFPに対する提案書を受け取ったら、設定した評価基準に沿って提案内容を比較・評価します。
評価の際は、客観的かつ公平な評価が行えるよう、評価シートやチェックリストを使用することが多いです。
なお、場合によっては提案内容に関してベンダー側のプロジェクトマネージャー（PM）候補にプレゼンテーションを実施してもらい、その力量や人となりを見極めて評価の参考にすることもあります。
⑨発注先ベンダーの決定・契約の締結
その後、提案書およびプレゼンテーションの評価結果や見積額の妥当性をもとに、最終的な発注先ベンダーを決定します。
選定結果は関係各所へ報告のうえ、ベンダーと提案内容の調整を済ませた後、契約の締結を行います。
６．RFP作成時のポイント
ここからは、RFPを作成するときに注意したい8つのポイントをご紹介します。
プロジェクトの目的・ゴールを明確にする
システム導入の目的やゴールを明確にしないままプロジェクトを進めると、後になって、
- スケジュールが大幅に遅延した
- 想定以上に開発費用がかかった
- バグが頻発してシステムが使い物にならない
- せっかく導入したのに全然使われないシステムになってしまった
などのトラブルが発生するリスクが高くなります。
RFPを通して発注側とベンダー側の双方が目的・ゴールを共有し認識を合わせておくことで、開発が行き詰まった時に当初の目的に立ち返り、柔軟に軌道修正を図ることができます。
特に、「システムを使って何を実現したいのか？」「どのような課題を解決したいのか？」という本質的な部分は必ず明らかにしておきましょう。
さまざまな立場の人から意見を集めて抜け漏れを防ぐ
部署や役職によってそれぞれシステムに対する要求内容は異なることから、RFPを作成する際は、経営層、マネジメント層、現場部門など、社内のさまざまな立場の人から意見を出してもらうことが大切です。
情報システム部門が独断でRFPの作成を進めてしまうと、思わぬ抜け漏れや各部門とのニーズのギャップが生じ、せっかくシステムを導入しても現場で定着せず、失敗に終わってしまう可能性が高くなります。
要件に抜け漏れがないか、他に検討すべき項目はないか、関連部署の担当者と話し合いながらRFPをブラッシュアップしていきましょう。
特に、実際にシステムを利用する現場部門の担当者に、RFP作成段階からプロジェクトに参画してもらうことで、現場にプロジェクトへの責任や当事者意識が生まれ、その後の工程で協力体制を組みやすくなります。
最初から完璧を目指さない
RFPは、ベンダーに対し発注側の意図や要望を正確に伝え、ベンダーから良い提案をもらって後のシステム開発をスムーズに進めるための「手段」であり、最初から完璧なものを作ろうとする必要はありません。
抜け漏れの無い完璧なRFPを作ろうとするあまり、RFPの作成そのものが目的になってしまえば本末転倒ですので、「RFPは相互理解を深めるための手段」と割り切り、ベンダーとのやり取りを何度か繰り返しながら、徐々にブラッシュアップしていくものと考えましょう。
システムに期待することはすべて記載する
RFPには、システムに対し期待していること、希望する要件をすべて記載するようにします。「書かれていない」ことを原因とした追加コストの発生やスケジュール遅延などのトラブルを防ぐためです。
システムに実装してほしい機能（＝機能要件）だけでなく、障害発生時のサポート体制、データのバックアップ、セキュリティなど、機能以外に関する事柄（＝非機能要件）についても、抜け漏れなく記載しておくことがポイントです。
ただし、希望する要件をすべて同列に扱うと、要点が定まらず曖昧なRFPになってしまうため、「必ず実現したいもの」「できれば実現したいもの」と優先順位を付けながら記載していきましょう。
RFP提出後の追加要求は避ける
RFPを提出した後に、追加で要件を出すことは避けましょう。
ベンダーはRFPをもとに提案書や見積書を作成するため、後から要件が増えてしまうと、スケジュールの再調整や提案書・見積書の修正が必要になって余分な工数がかかり、プロジェクトの遅延につながります。
発注側としても、再稟議やスケジュールの再考など二度手間になってしまうので、RFPを提出する前には、必要と思われる要件がすべて記載されているか、社内で慎重に確認しておく必要があります。
過剰な要求は記載しない
RFPには、システムに期待していることを抜け漏れなく記載することが大切ですが、自社に見合わないオーバースペックな要件を記載することは避けましょう。
あまり現実的とはいえない過剰な要求を行うと、ベンダーから想定を大きく超える見積金額が提示され、プロジェクトが早速頓挫してしまう可能性があります。
RFPに要件を盛り込む際は、本当に必要な内容なのか、実現可能性があるのかを吟味したうえで、現実的な内容を記載するようにしましょう。
同じタイミングで評価基準も作成する
RFPの作成と同時に、ベンダーからの提案書を採点するための客観的な評価基準を作成しておくことも重要です。
事前に明確な評価基準を作成し、RFPに明記しておくことで、ベンダーから自社に合ったより質の高い提案を引き出せるようになるほか、発注先のベンダーが正式に決定した後に、社内から不満が出るのを防ぐ効果もあります。
評価の方法としては、「ベンダーの能力・実績は十分か？」「スケジュールや見積金額が妥当か？」など、評価ポイントをまとめたシートやチェックリストを作成し、点数を付けながらベンダー候補を横並びに評価していくことで、自社に合った最適なベンダーをスムーズに選定することができます。
なお、具体的な評価項目の例を知りたい方は、こちらの記事もぜひご参照ください。
スケジュール感・予算感を明確に記載する
RFPには、ベンダーの選定スケジュールやシステム構築の期間、システムの本稼働時期など、自社で想定している大まかなスケジュールを記載しておきましょう。
スケジュール感が曖昧だと、ベンダーはプロジェクトの人員体制や見積もりを出しにくくなってしまいます。
予算については、RFPに明示すべきか否か意見が分かれることが多いものの、金銭的に無理のない範囲でプロジェクトを進めるためにも、なるべく記載した方が良いでしょう。
予算を提示する際には、以下のように解決したい課題の優先順位にしたがって、「松竹梅」の提案をベンダーにお願いしてみるのも効果的です。
- 松：解決したい課題だけでなく、自社で気づいていない課題も含めて解決する提案
- 竹：自社で気づいている課題をすべて解決する提案
- 梅：優先度が低い課題の解決については視野に入れない場合の提案
７．困った時は専門家に相談しよう
「RFP作成に関して具体的なアドバイスが欲しい」
「RFPに必要な情報を抜け漏れなく盛り込めているか不安・・・」
「各社から提案を受けた後、自社に見合ったベンダーを選定したい」
・・・など、RFPの作成やベンダーの選定に関してお悩みではありませんか？
コンピュータマネジメントでは、40年以上にわたり蓄積されたIT企業としてのノウハウを生かし、お客様を作業主体とした「伴走型」でのRFP作成支援を行っております。
RFP作成が初めての方や不慣れな方はもちろん、システム開発の外注先選びでお困りの方も、ぜひ一度当社へお気軽にご相談ください。
８．まとめ －期待通りのシステムを導入するなら、RFP作成は欠かせない
いかがでしたでしょうか？
RFPを発注側企業が主体的に作成し、現状の課題や実現したいこと、システムに求める要件をベンダーに漏れなく正確に伝え、お互いの認識をすり合わせることこそが、システム導入を成功させるための何よりの近道です。
今回ご紹介した内容をもとに早速RFPを作成して、ベンダー各社からより優れた提案を引き出し、その後のベンダー選定やシステム開発工程をスムーズに進めましょう。
また、RFPには具体的にどのような内容を記載する必要があるのか、書き方を詳しく知りたい方向けに、雛形としてすぐに使えるRFPのWordサンプルもご用意しておりますので、ぜひご活用ください。
なお、自社だけでRFPの作成を完結するのが難しいという企業様向けに、当社では情シス支援サービス「ION」を行っております。
以下リンクより情シス支援サービス「ION」に関する資料を無料でダウンロードすることができますので、興味のある方はぜひチェックしてみてください。
お電話・FAXでのお問い合わせはこちら
03-5828-7501
03-5830-2910
【受付時間】平日 9:00~18:00
フォームでのお問い合わせはこちら
この記事を書いた人
Y.M（マーケティング室）
2020年に株式会社コンピュータマネジメントに新卒入社。
CPサイトのリニューアルに携わりつつ、会社としては初のブログを創設した。
現在は「情シス支援」をテーマに、月3本ペースでブログ更新を継続中。
