RFP（提案依頼書）には何を書く？作成の目的やポイント

(画像=Andrey/stock.adobe.com)

システム開発の外注は、高額な費用をかけても失敗することがあります。原因はさまざまですが、RFP（提案依頼書）のコツをつかむだけで成功率が上がるケースは少なくありません。優れたパートナーを見つけるために、RFPの作り方を確認しておきましょう。

RFP（提案依頼書）とは

RFP（Request for Proposal）とは、システムやアプリ、WEBサイトなどの製作を外注する際に、発注側がベンダー企業に提出する書類です。日本語では「提案依頼書」と呼ばれており、基本的には以下の情報が記載されています。

RFPは発注内容を決める書類なので、提出段階で契約が結ばれることはありません。RFPをもとにベンダー企業が提案書を作成し、その内容に発注側が合意をした場合に、初めて契約が成立となります。

認識のズレを防ぎ、要望を正確に伝えることを目的とした書類

RFPの作成目的は、ベンダー企業に要望を正確に伝えることです。

デジタル技術が発達した現代では、さまざまな業界で高度なシステムが求められるようになりました。そのため、RFPを提出せずに口頭のみで依頼をすると、以下のようなトラブルを招く恐れがあります。

ベンダー企業はシステム開発のプロですが、発注側の内情をすべて理解しているわけではありません。発注側の課題を予測し、そのすべてに的確な提案をすることは難しいため、RFPを通して情報提供をする必要があります。

RFPの作成者は?

RFPは基本的にベンダー企業の顧客となる発注側の企業が主体となって作成します。RFP作成は、実際にシステム開発に関わるIT部門が担うこともあれば、企業全体を代表して調達部門が担うケースもあり、企業によってさまざまです。

また、社内にシステム開発の知見を持つ人材が不足している、RFP作成のノウハウがないといった場合、RFPの作成をコンサルティング企業やSIerに外注することもあるでしょう。実際、システム開発の要件定義段階で設計工程以降のRFP作成も併せて外注する事例も見られます。

作成時に自社内でヒアリングすること

RFPを作成する際には、社内関係者へのヒアリングが欠かせません。自社内でのヒアリングにあたって重要なのは、開発したいシステムの目的、予算規模といった事項です。これらは主に経営層から情報収集を行う必要があるでしょう。

一方で、実際にシステムを扱うユーザー部門にはシステムに実装すべき機能の要件、セキュリティ基準などをヒアリングする必要があります。その他には、法務部門などに契約条件や個人情報の取扱方法などを確認するケースもあるでしょう。

RFPを作成するメリット

1.要件・要望を齟齬なく伝えられる

RFPを作成することで、システムに求められる要件、要望を明文化することができ、ベンダー企業との認識齟齬を未然に防ぐことが可能です。一方で、口頭やメールでのコミュニケーションでは、どうしても相互での認識違いや抜け漏れが発生するリスクがあるでしょう。

RFPとして明文化することで、システム開発の対象となる範囲や予算、業務内容などを双方が納得しながらプロジェクトを進めることができます。

2.複数の提案を比べられる

RFPを作成することで、複数のベンダー企業に対して提案書を依頼することができます。複数社から提案書を受け取れることから、各社の強みや弱み、価格競争力などを客観的に判断することが可能です。

また、RFPに対応するベンダー企業は競合よりも良い提案をしようとする動機が働くことから、自社にとって有利な条件を引き出せる可能性もあるでしょう。

3.トラブル防止に役立つ

RFPはシステム開発におけるトラブルの未然防止にも役立ちます。システム開発の現場では、作業範囲や予算、仕様などの認識相違によって、発注側とベンダー企業側のトラブルが発生することが多いです。認識齟齬が発生しやすい事項をRFPの形で明文化しておくことで、双方での事実確認がスムーズになり未然にトラブルの芽を摘むことができます。

4.自社を客観視し課題を見つけられる

RFPの作成を通して、自社が置かれている環境を客観視し、今後のビジネスを発展させるための課題が見つかることがあります。自社が潜在的に抱えている課題には、日常業務の中では気づけないものも多々あります。そのため、RFPの作成を通して自社のニーズを見つめ直したことで、初めて課題として認識されるケースもあるでしょう。

RFPを作成するデメリット

RFPの作成にはメリットだけではなく、デメリットもあります。それは、RFP作成には多くの労力と時間がかかることです。RFPの作成にあたっては自社の現状や課題を整理する必要があるほか、システムに求める機能や実装方法の検討など技術的な知見を要する作業も必要です。

また、先述の作業によってRFPの作成には長い時間がかかることがあります。時間がかかることで、競合他社に遅れをとる、市場の変化に適応できないといったリスクが生じることがあるでしょう。

RFPを作成しないとどうなる？

RFPの作成には一長一短がありますが、もしRFPを作成しない場合には何が起こるのでしょうか。RFPを作成しない場合に考えられるのは、認識相違によって手戻りが発生することです。

RFPによってシステム開発の要件、前提条件が共有されていない場合、発注側とベンダー企業側の双方で認識が異なった状態で提案が行われることがあります。このとき出された提案が発注側の意に沿わない場合、提案書の作成からやり直しとなりコストと時間の両面で大きな無駄が発生するでしょう。

このような手戻りのリスクを考えると多少時間とコストがかかったとしても、RFPを実施したほうがよいといえるでしょう。どうしても自社のリソースでは実施できない場合は、RFPそのものを外注して行うという選択肢もあります。

RFPを作成するタイミング

RFP作成までの流れ

RFP作成においては、まず自社が抱える課題、ビジネス環境などを考慮してどのようなシステムを開発したいのかを明確にする作業を行います。

自社がシステムに求める要求事項が明確になった後は、候補となるベンダー企業をリストアップします。このとき、いくつかの企業にシステム開発の対応可否を確認する、RFI（※後述）を通して各社の強みや対応可能な範囲について確認を実施することもあるでしょう。

ここまでの作業で得られた情報を元にして、候補となる企業を絞り込み、RFP作成の作業に入ります。

RFP提出後の流れ

候補となる企業にRFPを提出した後は、各社に対してRFPの詳細に関する説明会を実施します。この説明会はオリエンテーションと呼ばれることが一般的です。

オリエンテーションから一定の期間をおいて、各社からRFPに対する提案書を提出してもらい、これらの内容を比較検討して最終的には1社に絞り込みます。この際、選定基準や重視するポイントについては自社内で事前に検討しておくことが重要です。

絞り込まれた1社のベンダー企業に対して、選定結果の内示を行うとともに作業範囲や契約内容の調整を開始します。

RFP（提案依頼書）のフォーマットは？一般的な記載内容

RFPに決まったフォーマットはありませんが、内容に不備があると完成イメージの共有ができません。ベンダー企業の負担を和らげるためにも、一般的な記載内容を押さえておきましょう。

1.発注内容の大枠となる「システム概要」

まずはシステムを開発するにあたって、発注側が抱えている課題や背景、目的などを記載します。また、発注側はRFPをもとに提案書を作成してもらう立場なので、できれば冒頭に簡単な挨拶文を記載しておきましょう。

現状で抱えている課題や運用体制、予算などは、具体的な数値を盛り込むことが重要です。例えば、「○○部△△課の5名が使用予定」「○億△△万円を上限予算とする」のように明記すると、ベンダー企業がイメージをつかみやすくなるため、後に受け取る提案書もより具体化されます。

2.提案書の内容を指定する「提案依頼事項」

提案依頼事項は、ベンダー企業が作成する提案書の内容を指定する項目です。発注内容によって記載すべきものが異なるため、以下では一例を紹介します。

RFPを受け取ったベンダー企業は、提案依頼事項をもとに提案書を作成します。つまり、この事項に書かれていない情報は記載されない可能性があるため、共有が必須となる情報は必ず盛り込んでおきましょう。

3.参加資格やスケジュールをまとめた「提案手続き」

提案手続きの方法や流れについても、RFPで示しておく必要があります。どのような情報が必要になるのか、以下で例を見ていきましょう。

提案書の採否にあたってプレゼンテーションなどを開催する場合は、その日程や参加条件も明記しておきましょう。また、開催当日に用意できる機器（パソコンやプロジェクターなど）を記載しておくと、ベンダー企業の負担を減らせます。

また、採否にあたって複数の選考がある場合や、各選考の通過企業数などが決まっている場合は、その旨も記載しておくと親切です。

4.対象企業を明確にした「システム開発条件」

システムに関する条件は複雑なケースが多いので、RFPの分かりやすい箇所にまとめて記載しましょう。開発期間のほか、品質保証基準やセキュリティ面、権利関係についても明記することが重要です。

RFPを通した発注では、自社課題などの機密情報を共有することがあります。もし外部に漏れると、競争力や信頼性などを損なうリスクがあるため、契約事項には「機密保持」に関する内容も記載しておきましょう。

RFP（提案依頼書）を作成するときのポイント

RFPは外部に共有する書類であるため、読み手（ベンダー企業）の立場で作成することが重要です。また、万全の準備をしておかないと、ベンダー企業への要望や方針を誤ってしまうリスクもあります。

以下ではRFPを作成するときのポイントをまとめたので、作業を始める前に確認しておきましょう。

全社的なプロジェクトとして方向性を考える

優秀なベンダー企業を見つけても、システム開発が必ず成功するとは限りません。特にRFPを介したシステム開発は、両社の協力によって進めていく形となるため、発注側も綿密なプランを立てる必要があります。

特に意識しておきたい点は、新しいシステムと既存システムの連携です。既存システムへの影響が大きいケースでは、関係部門や経営層に対してヒアリングを行い、全社的なプロジェクトとして方向性を考えます。この工程が大規模になりそうな場合は、独立したプロセス（※ITグランドデザインと呼ばれる）として取り組むことも検討しましょう。

既存システムへの影響が小さいケースでは、新しいシステムと現状の課題を確認すれば問題ありません。優秀なベンダー企業を見つけても、システム開発が必ず成功するとは限りません。特にRFPを介したシステム開発は、両社の協力によって進めていく形となるため、発注側も綿密なプランを立てる必要があります。 広い範囲にヒアリングを行う必要はありませんが、新しいシステムの役割や効果は明確にしてください。

定量的な数値目標を設定する

理想的なシステムを開発してもらうには、ベンダー企業に明確な目的を伝える必要があります。例えば、「業務効率を改善したい」「人件費を減らしたい」といった抽象的な目標では、システムの細かい仕様まで突き詰められません。

ベンダー企業はあくまで外部の発注先なので、RFPには定量的な数値目標を記載しましょう。「労働生産率を〇％向上したい」のように数値を盛り込むだけで、発注側の意図は伝わりやすくなります。

同じタイミングで評価資料も作成する

評価資料とは、ベンダー会社の提案書を採点するための書類です。RFPと並行して作成すると、「自社が何を重視しているのか」や「不要な条件はないか」などを整理できます。

評価資料にも決まったフォーマットはないため、項目ごとの○×表や点数表のように簡単なもので構いません。発注先を絞るプロセスにも役立つので、RFPと同じタイミングで作成しておきましょう。

判断に迷っている部分も記載しておく

RFPは契約書類ではないため、不明点は曖昧な内容を記載しても問題ありません。課題を解決できる技術や仕組みが分からなくても、定量的な目標値さえ記載しておけば、具体策を提案してもらえる可能性があります。

そのため、RFPには判断に迷っている部分も記載しておきましょう。ほかにもデザイン面のイメージや競合サービスなど、システム設計に役立つものは積極的に共有する姿勢が重要です。

RFP（提案依頼書）のテンプレート・サンプル例

ここまでの内容を踏まえて、以下ではRFPのテンプレート・サンプル例を紹介します。なお、適したRFPは企業によって異なるため、カスタマイズや微調整をしながら自社仕様にブラッシュアップしてください。

上記はあくまで簡易的なテンプレート・サンプル例なので、必要に応じて挨拶文や項目などを増やしましょう。

RFP（提案依頼書）とほかの用語の違い

発注企業とベンダー企業は、ほかにもさまざまな書類をやり取りすることがあります。RFPと混同しやすい書類もあるので、類似用語との違いを整理しておきましょう。

ベンダー企業の情報開示を要請する「RFI」

RFI（Request for Information）は、ベンダー企業に対して会社情報の提示を求める書類です。日本語では「情報提供依頼書」と呼ばれており、ベンダー側が提供できるシステムや実績などが記載されることもあります。

候補先に複数のベンダー企業がいる場合は、以下のような流れで発注先を決めることがあります。

基本的には「RFI→RFP」の流れでやり取りされるため、RFIは一次選考、RFPは二次選考としての意味をもっています。

発注側が要望を伝える「要求定義書」

要求定義書は、発注側がシステム開発の要望をまとめる書類です。指示書のような役割を担っており、ベンダー企業はこの書類の内容をもとにシステム要件などを突き詰めます。

RFPと違って技術的な内容は含まれませんが、発注側の要望をベンダー企業に伝えるために欠かせない書類です。

完成イメージをすり合わせる「要件定義書」

要件定義書は、ベンダー企業が開発するシステムの要件を記載して、発注側に提出する書類です。認識のすり合わせが主な目的であり、専門家ではない発注側が見ても理解できる内容にまとめられています。

近年になって増えてきたアジャイル開発（※）では、要求定義書を要件定義書に落とし込む作業を何度も繰り返し、一つの製品やシステムを開発します。

（※）開発とリリースを繰り返して、細かいフィードバックを重ねながら製品開発をする手法のこと。

RFQとは見積もり依頼書

RFPやRFIと似た用語にRFQ(Request For Quotation)があります。RFQとは日本語に訳すと「見積もり依頼書」です。RFPはベンダー企業各社からシステム開発に必要な提案を受けることが目的ですが、RFQではシステム開発にかかるコストだけに絞って情報提供を求める点が大きく異なります。

RFQは一般的にRFPを実施する時間がない場合や、取り急ぎコストだけを把握したい際に使われる手法です。RFQは提案書の作成を求めないことから、RFPよりも早期にコストに関する情報が得られ、ベンダー企業の絞り込みもしやすくなるでしょう。

自社の課題やゴールが明確なRFPを作成しよう

システム開発を外注する企業にとって、RFPは重要な役割をもつ書類です。要望を正確に伝えることが目的なので、可能な部分は定量的なデータを用いて、自社の課題やゴールが分かりやすいRFPを作成しましょう。

また、いくら優秀なベンダー企業が見つかっても、システム開発が成功するかは分かりません。少しでも成功率を上げるために、RFP以外の書類でも積極的な情報提供を心がけてください。

【注目コンテンツ】
・DX・ESGの具体的な取り組みを紹介！専門家インタビュー
・DX人材は社内にあり！リコーに学ぶ技術者リスキリングの重要性
・サービタイゼーションによる付加価値の創造と競争力の強化