RFP（Request for Proposal）は「提案依頼書」と呼ばれ、外部のベンダーに対してソリューションの提案を求める公式な文書のことで、発注者側が作成するべきドキュメントの１つです。
ここでいう「提案」とは発注者側が企画構想フェーズで決定したTOBEを実現できる解決策を各ベンダーが提示したものを指します。
当記事ではRFPを作成する目的や記載するべき内容について解説します。
RFPを作成するメリット
RFPは基本的に発注者側が作成するため、それなりの負荷がかかりますが、作成することで様々なメリットを得ることができます。
- TOBE業務を複数のベンダーに対して説明する際の労力を大幅に削減できる
- 伝達漏れやミスを防ぐことができる
- 発注者側の内部でTOBE業務の最終合意を形成する
- 発注後のベンダーとの認識齟齬に対して、発注者側の言い分の証拠になる
このようにRFPを作成することで、トータルの負荷はむしろ減ると言えます。
ただし、作成には専門的な知識が必要だったり、ある程度決まった目次というものがあるため、どのように作成すればいいか分からない場合は、外部のコンサルタントにサポートしてもらうことも１つの手段です。
（当記事でもRFPの作成方法について解説しているため、参考にしてください。）
RFPに記載するべき内容
RFPには記載するべきアジェンダがある程度決まっています。
ここでは上図に記載しているRFPの目次の例をベースに、それぞれの項目で記載するべき内容を解説します。
提案依頼の趣旨
まず最初に自社の事業内容や事業規模などを理解してもらうために会社概要を用意します。
主に以下のような項目を整理して記載します。
- 社名
- 業態
- 支店数や工場数
- 商品数
- 生産量
- データの種類
- システムユーザー数
もう１つはプロジェクトが発足した背景と目的を記載します。
今の事業にどういう問題があり、このプロジェクトを通して何を解決したいのかを概要レベルで説明出来るように用意しておきましょう。
ベンダーとしても、最終的にはこの目的を達成させられるソリューションは何かを考えて提案してくるため、非常に重要なポイントになります。
提案の業務・システム対象範囲
続いては、提案の対象範囲を業務視点とシステム視点で明示してきます。
まず、業務視点での対象範囲について一番分かり易いのは部署単位で区切ることです。自社が総合商社であれば、何を扱っている部署が対象となるのか、工場であればどこの工場が対象となるのか等、部署を切り口に提案対象範囲を明示していきます。
もしくは販売、購買、在庫、人事、会計などの業務の単位で限ることも有効です。
システム視点での対象範囲は自社のシステム構成図を基に、今回のプロジェクトで対象となるシステムに色付けをしていきます。財務会計系のシステムが対象となるのであれば、債券・債務管理システムや固定資産管理システム等もあるため、対象となるシステムが分かるように印をつけていきましょう。
もう１つの視点としては、活動の範囲を明示することです。
求めている提案の範囲は要件定義から開発、テストまで含まれるのか、その他のデータ移行や業務移行なども含まれるのかといった、システム導入における活動のどこまでの範囲を提案してほしいのかを明示することで、ベンダーから出てくる提案の精度が上がってきます。
業務・システム要求事項
続いては、業務で実現したいことやシステムに求める機能について整理した内容を載せていきます。
RFPの作成を始める前に、現状業務の整理・分析と、あるべき姿を反映させた新業務の設計作業を行います。
ここでは、そこで作業した内容をベンダーに説明できるように分かりやすく纏めていきます。
以下の順で説明できるようにRFPを作成しましょう
- 現状業務
- 現状業務の課題
- 新たに設計した新業務
- 新業務を実現するために求めるシステム機能・非機能要件
非機能要件については以下のような内容を決められる範囲で記載していきます。
- 構築する環境はクラウド(もしくはオンプレミス)
- システム利用ユーザー〇〇人が問題なく使えるスペック
- データ件数〇〇件が問題なく処理できるスペック
- 24時間365日の稼働が求められる
提案における前提条件
ここでは希望する稼働時期や接続が必要になる他システムの情報、システムの利用者数など、実際に導入を始める際の前提となる事項を明記していきます。
前提条件の記載だけに限った話ではありませんが、前提条件をどれだけ正確にかかるかにやって、ベンダーが出してくる提案書の精度が変わってきます。
例えば希望稼働時期ですが、システム導入の知識が全く無い状態で、実現性の低い無理なスケジュールでRFPを作成してしまうと、ベンダーとしてはお断りをするか、要員を多く確保するために費用が高額になったりしてしまいます。
実現可能性の高い稼働時期をベンダーから提案してくれる場合もありますが、RFPを配布したすべてのベンダーがそうしてくれるとは限りません。せっかく良いベンダーだったとしても、こういうところでリスクを感じ辞退してしまうベンダーも出てきてしまうため、希望稼働時期の記載は慎重になるべきところの1つです。
上記の例は極端な例ですが、自分たちの課題を解決するための提案を正しくベンダーからしてもらうためには、前提条件の記載は漏れなく正確に記載する必要があります。
提案依頼事項
続いてはベンダーに提案してほしい項目を明記していきます。ベンダーが作成する提案書の目次とその説明書きを作るイメージです。
提案依頼事項を明記する理由としては、ベンダーがそれぞれ異なる目次で提出してくると、内容をチェックするときに時間がかかったり、平等に評価することができなくなる可能性があるためです。
主に以下のような内容をベンダーに提案してもらうようにしましょう。
・提案内容
以下のような内容を纏め、提案の全貌が把握可能な記載をしてもらう。
・ベンダー理解（RFPを受けてどのように理解したか）
・実現事項
・競合パッケージ製品との優位性
・パートナーとするメリットやポイント
・導入事例紹介
提案ソリューションにおける実績を複数、具体的な事例として提示してもらう。
特に同じ業界への導入実績や導入に当たり苦労した事項及びその解決方法について説明してもらう。
・パッケージ特性
パッケージ導入による提案の場合は、パッケージ製品の特徴や拡張性などを説明してもらう。
また、他システムとの連携の容易性なども重要になるため、連携実績のある他システムを説明してもらう。
・システム構成
システム構成の概要図や業務・機能構成を明示してもらう。
また、自社で調達が必要になりそうなものがあれば、予め確認できるよう記載してもらうようにしましょう。
・プロジェクトスケジュール
RFPで提示したスケジュールを踏まえて、ベンダーが考える導入スケジュールを提案してもらう。
スケジュールの中にはマイルストーンや自社が関わると想定される時期なども明記してもらうようにしましょう。
・体制・役割
ベンダー側の体制や役割を明示してもらう。
特に窓口となる担当者やプロジェクトマネージャーはコミュニケーションを多くとることになるため、誰になるのかを確認できるように明記してもらいましょう。
また、プロジェクトマネージャーは技術的なスキルだけでなく、管理スキルも重要となります。
プロジェクトマネージャーとなる人物のプロジェクト経験を記載してもらえるとより安心です。
・費用
導入にかかる費用（イニシャルコスト）と保守にかかる費用（ランニングコスト）を明記してもらう。
各社から送られてくる見積もりの明細を読み解く時間を省くために、見積書の明細はベンダーが発行したものではなく、自分たちで予めフォーマットを用意しておき、そこに入力してもらうようにしましょう。
プロジェクトの規模によっては上記の他にも、システムの構築方針やテスト方針、移行方針などの提案もしてもらう必要があります。
自分たちのプロジェクトの目的を達成させるためには何が必要かを考えて、提案項目を検討していきましょう。
提案手続き
最後にRFPに関する質問を受ける際の問い合わせ方法や窓口について案内をします。
他にもRFP送付以降の選考のスケジュールやデモ実施の有無など、ベンダーを実際に決めるまでの流れを明示します。
ここでのポイントとしては、提案書をプレゼンテーションしてもらう際に営業担当者だけではなくプロジェクトマネージャーにも同席してもらうよう案内を出しましょう。
実際にプロジェクトを進めていくときに多く関わるのは営業担当者ではなくプロジェクトマネージャーです。
プロジェクトマネージャーの人柄やスキルを正確にとらえるためにも、プレゼンテーションに同席してもらうことは重要になります。
まとめ
ここまでRFPに記載するべき事項を説明しました。
- 提案依頼の趣旨
- 提案の業務・システム対象範囲
- 業務・システム要求事項
- 提案における前提条件
- 提案依頼事項
- 提案手続き
RPFに記載するべき事項はシステム導入プロジェクトの専門的な知識が求められる部分があります。
また、RFP作成の前に現状分析した結果や新しい業務設計について整理した内容を、分かり易く載せる必要もあるため、それなりの労力がかかります。
しかし、ベンダー選定の精度を上げたり、自分たちの要求事項の認識を合わせる効果もあるため、外部のシステム導入コンサルタントなどもうまく使いながら、作成していくようにしましょう。
