RFI・RFPとは何か | システム導入検討のエッセンス（１）

イントロダクション

情シスをやっていると、見積依頼や注文を行うことが多いです。

パソコンの更新やキーボード、マウス、モニタ等の周辺機器の購入や、携帯電話の追加導入、ソフトのユーザーライセンスやクラウドサービスの利用者ID追加等、大なり小なり何かを購入しています。
会社として必要なものなので購入しているのですが、間接部門は稼ぎもしないのにお金を使うだけ、と見られるのも仕方ないと思えるくらいに件数が多いです。

自分自身の感覚がおかしくならないように、経費扱いになる少額物品であっても極力決裁をもらってから購入するように心がけています。

最初から買うものがわかっているものは、製品・サービスの選定や手続きをほぼ独力で進められますが、新たに大規模なシステムやサービスを導入するとなると全く別の話です。

情シスにとって大規模調達は非常に稀です。企業・団体の規模にもよるかもしれませんが、所謂システム更新のスパンである５年に１度、10年に１度の大イベントです。
それだけ間隔が空きますから、調達方法を社内の誰も知らないなんてこともあります。

今回は調達にあたって作成する文書であるRFI、RFPについて、その内容と書くときに気を付けるべきことをお話していきたいと思います。

前職では業務系パッケージのプリセールスや提案書の作成もやっており、RFIやRFPは書く側ではなく受けとる側として数多く見てきたので、ここは得意分野です。
実際にRFIやRFPが必要な大規模案件でなくても、考え方を身に着けておくことでベンダーとの認識の齟齬を少なくしながら調達を進めることができるようになります。

そもそもRFI・RFPとは

RFI：情報提供依頼書（Request For Information）

RFIは、簡単に言えばベンダーに「こんなことやりたいんだけど、御社の製品やソリューションを紹介してくれません？」と問い合わせるためのものです。

導入したい製品、受けたいサービスが単純で明確であればこちらでも判断できるのですが、複雑で大規模な要件の場合どの製品が適合するのか、どういう組み合わせが可能なのか調査・検討を行う必要があります。
可能な限り調査しておくに越したことはありませんが、規模感や費用感は公開されている情報だけではなかなか調査が難しいです。

例えば生産管理や受発注の統合管理を行うERPや、営業の顧客管理・案件管理を行うCRM、マーケティングツールであるMA等、それぞれのカテゴリで数多くの製品やサービスが提供されています。
しかし自社の業務に適合でき、価格帯が想定内であり、保守やサポートまで含めたサービスが充足しているのはどの製品かということになると、かなりの情報を収集しなければいけません。

法人向けの製品・サービスは個人向けと比べて客観的な情報がなかなか出回りません。それでも情報や評判が漏れ聞こえてくるものは、よほどに素晴らしい製品か、よほどに粗悪・悪質な製品のどちらかでしょう。

ユーザー側が必死に情報収集するより、「餅は餅屋」でベンダーに情報提供を依頼するのがRFIです。

RFIを受けたベンダーは、要求された内容を実現することができる製品やソリューションの情報を提供してきます。要求事項が全て達成できていれば文句は無いのですが、難しい要件は代替手段だったり別調達で検討等の提案がされてきます。
それが製品による差の問題もありますし、こちらの要求が法外で、そんなものを達成できるベンダーは存在しないということもあるかもしれません。

そうならないために、ベンダーに依頼するとはいいながらも一般的に調べられる範囲の情報は収集しておきましょう。

RFP：提案依頼書（Request For Proposal）

RFIで一通り情報を収集して「こういうことならできそうなのか」がわかったところで、実際に導入に向けた細かな要件を整理して、ベンダーに提案を依頼するのがRFPです。

有体に言ってしまえば見積依頼です。

PFIの時点で候補から外れるベンダーも出てくるので、ある程度要件に適合できそうなベンダーだけに送付して、提案を受けます。

何故RFIやRFPが必要なのか

ベンダーに「こんなことしたいんだけど、どうやったらできる？」を問い合わせる時に、達成したい主目的以外の部分が端折られてしまい、結果的に言ったことはできているけど運用に耐えられない、ということが発生するかもしれません。

例えば「クラウド型のERPを調達したい」という要求に対して、伝えた要件は達成しているけどメンテナンスで頻繁に停止したり、クライアントPCの性能要件があり社内に導入されているパソコンではほとんど動作しない等の問題が発生するかもしれない、ということです。

調達に際して主目的以外の部分も含めて漏れなく要件伝えられるように整理して伝えるための共通的な枠組みがRFIやRFPです。

漏れなく要件が伝えられたほうが、適合した製品やサービスにたどり着きやすいですし、ベンダーも判断しやすくなり、より理想としていたものに近いものにたどり着けるようになります。

つまりRFIやRFPが必要なのは、「多数の製品やサービスから自力で適合したものを選定するのが困難で、主目的以外の要件が多数あるような調達」＝大規模案件になりやすいのです。

大規模じゃなくても考え方は大切

大規模案件ではありませんが、身近なところだとパソコンの調達で考えてみます。
パソコンに求める要件を簡単に書き出してみました。

主目的が「Windows10のA4ノート10台調達したい」とすると、「種類」と「ソフト（OS）」と「数量」は明確ですが、「性能」や「インターフェース」や「周辺機器」や「保守・保証」が明らかになっていません。

調達先が決まっていれば「他の要件は前回調達した内容と同じ」という指定は可能ですが、広く調達先を募るのであればそれぞれの情報が必要になります。

パソコンだって色んなメーカーのものがあって、その全てを使って比べてみることは難しいですし、主目的以外の要件が多数あります。

だからといって実際にRFIやRFPは書きません。数百台単位の大規模調達であればコンペくらいはするかもしれませんが、「パソコン」という製品が明確であり、多数あるといっても要件も具体的です。
要件の実現方法に検討の余地があまりない（メーカーの違いや保証の手厚さくらい）ものについては、初めから具体的な要件で調達すれば良いのです。

しかし要件を漏れなく検討する、という考え方はどんな規模の調達でも必要だと思います。
調達の際には、対象となる製品やサービスが一般的に提供する内容を項目化して、何を求めるのか、何はこだわらないのかを整理した上で、製品・サービスを比較・検討するようにしましょう。
気付いていないだけで検討が漏れているものがあるかもしれません。

ちなみに私はノートパソコンをリースした時に、マウスを付けるのを忘れたことがあります…。

中締め

フォーマットは提供しません

今回はRFI・RFPとは何か、何故RFIやRFPが必要なのかという話から、基本的な考え方についてお話しました。次回からいよいよRFIに記載すべき要件についてお話します。

念のため前置きしておきますが、当ブログではRFIやRFPのフォーマットの提供は想定していません。
形や体裁を整えるだけであれば、フォーマットはそこらじゅうに転がっています。

あくまでRFI・RFPの理解を深めるための解説になりますのでご了承ください。

RFI・RFP／プロジェクト管理関連の記事を纏めています。