新IT導入・システム開発プロジェクトでの情報提供依頼(RFI)・提案依頼(RFP)・見積依頼の方法１　RFI・RFPのタスクとマネジメント

新ITの構想・企画の後は、情報提供・提案・見積の依頼について説明します。

情報提供は行わず、既に構想段階で終わっていることもあります。今まで対応したことのない領域のITであれば、情報提供依頼を行ったほうがいいです。

ベンダーによって提供される情報レベルは様々ではありますが、何ができるかという情報がなければ、何がいいかというとっかかりの情報すらないことになります。

提案依頼と見積依頼は同時になされることが多いですが、別のこともあります。

これらは企画がまとまってからの行為となりますので、企画はベンダーに見せる前提で作られている必要があります。

もしそのような状態になっていないのであれば、もう少し考えて、見せられるようにするところから始めることになります。

新ITの情報提供依頼とは

情報とは新ITに関して、サービス内容や必要な技術、対応力等を示すものをベンダーからもらうものです。

ベンダー側は売る前提なので、情報提供を無償にて行うことが多いです。

クラウドサービスについては、特に対面での説明はなく、説明書の提供のみということもあります。

いずれにおいても、購入するかもしれないという立場で、情報を依頼することになります。

大規模なシステム開発においては、同様の技術における構築実績などの情報をもらいます。

新ITの提案依頼とは

提案依頼とはRFPとも呼ばれますが、依頼する前提でこちらの実現したいITをどのように構築するかを提案してもらいます。

購入する前提ではあるのですが、購入するとは限りません。というのは、複数のベンダーに対して同じ提案依頼をすることが多いからです。

他にも提案依頼を求めていることを断わってから、提案依頼を出します。

RFIとRFPの違いとは

RFIはあくまでの情報提供の依頼となり、RFPはITに関する提案依頼となります。

RFIの時点では、数あるものの中からどのようなことができそうか、あるいは依頼をいたら実施できそうかという探りを入れている時期です。よって、依頼するほうも依頼されるほうもそのつもりになっています。

ただし、RFIを依頼されたほうは、見込み客として認識されます。よって営業力がある会社は、必ずタイミングを見計らって、様子を伺ったり、説明会を開催したり、アプローチをしてくることでしょう。

一方、RFPは依頼をする意思表示をしています。この時点で複数社になっているにしろ、受注の可能性が大いにある状態ですので、お互いそのつもりで動くことになります。

新ITの見積依頼とは

提案依頼は金額も含んでいることが多いですが、提案時は概算となることが多いです。

ある程度の規模の発注となると、提案依頼を出しても、正確に見積もれないということで、概算として出してきます。

詳細に詰められない場合は、要件定義のみを発注して、よりやるべきことが具体化してきた段階で、再度見積もりを提示します。

見積依頼はいずれにしろ、発注することがほぼ確定した段階で実施することになります。

発注しなければいけないわけではありませんが、実務上は要員の手配もありますので、正式に実施する意思表明と捉えられます。

新ITの情報提供依頼（RFI）のタスクとマネジメント手法

情報提供依頼（RFI）は構想・企画ができてから、実現性の高い製品・サービスやベンダーを探るために依頼する時と、構想の中で実行する時とがあります。

提供された情報により、新ITに対する実現の方向性や考え方が変わることがあります。その場合は企画が変わったと捉え、構想から一部やり直す形となります。

いずれにしても、情報提供依頼としてのタスクとマネジメント手法は以下のとおりとなります。

情報提供依頼のタスク

現状を説明できるようにする

情報提供依頼をするにあたって、相手に必要な情報を提供する必要があります。

まずは、現状の状態を説明できるものを用意します

現状と言っても、現状のITすべてを説明する必要はありません。

提案をもらう範囲に限っての提供となります。機密情報もありますので、それも意識した範囲に限定すべきです。

要求を説明できるようにする

現状に対して、何がしたいのかを説明できるようにします。

何がしたいかは構想・企画として取りまとまっているはずですので、要求を準備します。

情報提供が可能なベンダーの候補を挙げる

情報提供が可能なベンダーがすぐにわかればいいですが、そうとも限りません。

どこのベンダーが的確な情報を提供してくれるのかは、問い合わせてみないとわからないところがありますので、まずは情報収集をします。

情報提供依頼をするベンダーを決める

ベンダー候補の中から情報提供依頼をするベンダーを選定します。

情報提供の段階では、何ができるのかもわかっていない状態ですので、広めの選択にはなります。

ここで情報提供から外すのは、明らかに今回の要求には答えられなさそうな相手となります。

ベンダーに依頼する

相手を選んだら、ベンダーに情報提供依頼をします。

ベンダーにはITとしての実現方法について情報提供をしてもらうことになります。

守秘義務契約を結ぶ

ベンダーに情報を提供してもらうにあたり、こちらからの情報を提供する必要があります。
その内容は企業の機密情報と言えるものです。

まだ実現に至っていないですが、これから検討しているということですら、機密情報と言えます。
よってまだ取引が発生してはいないですが、守秘義務契約を結ぶのが無難です。

ベンダーより情報を受ける

ベンダーより情報を受けたら、その内容を確認していきます。

複数のベンダーより情報提供を受けますので、今後ン付き合い方を意識して見ていきます。

情報提供は通常は金銭のやり取りは発生しません。あくまでもベンダー側の営業行為の一つとしての対応と解釈します。

そういう事情もあり、情報がかなりプアな可能性もあります。

逆に営業担当がかなり前のめりで積極的になってしまうこともあります。

ここではあくまでこちらの欲しい情報であるかを確認します。

情報を評価する

提供された情報は各社様々と思います。

基本的にはITでの実現方法という技術的な面を中心とした、情報収集になります。よってその観点で評価します。

全般的な評価観点としては、会社そのものの情報・実績、該当サービスの実績・業務合致度、価格、支援体制（直接対応できるか、対応できるベンダーを紹介できるか）、将来性等の情報を収集し、複数社に依頼しているのであれは、比較評価を行います。

追加問い合わせを行う

各社横並びで評価していくと、いいところと、いまいちなところが出てくるはずです。

技術的な観点で、思いつかなかった実現方法が提供されるかもしれません。

その際は、他の会社でもできないか問い合わせることもあります。

ベンダーによってはあまり情報を出してこないこともありますが、こちらとしては情報収集段階ですので、できるだけ多く収集できるようにしたいです。

情報提供依頼のマネジメント

情報提供依頼に関しては、依頼してもらうだけなので、マネジメントというものがあるのか、という話はあります。

ただ、いつかはやりたい、という感じで取り組んでいるよりも、目標があって取り組んでいる方のほうが圧倒的に多いと思いますので、目標に向けたスピード感に合うマネジメントは必要です。

検討可能時期を決める

マネジメントすることはあまり多くはないかもしれませんが、この後、IT導入・システム開発の計画を具体的に立てていくと考えると、導入までの全体スケジュール目標から考えて、今の情報提供にどのくらいの期間を充てられるかを検討します。

特に情報提供を受けてから内容を検討する時期をどのくらい取るかが重要です。

依頼の内容・方法に関わらず、相手がどのようなレベルの情報を出してくるかの問題なので、その後のアクションとボリュームの見極めは難しいところではあります。

検討していると２，３週間はすぐに経ってしまいますので、期限感はタイトすぎないよう予め計画しておく必要があります。

依頼時期、回答時期を決める

全体時期を決めたら、依頼時期と回答時期を決めます。

依頼時期とは、自分が依頼するまでの準備から発信の期間です。

ベンダーの候補を決めるところも準備に含まれますので、その探索時期も含めて計画することになります。

回答に関しては、相手の準備が必要なものと不要なものがありますので、それに応じて期間を確保しておきます。

一番長そうなところを先に取り組んでおくということで、期間を有効に使うことができます。

依頼内容準備の進捗を計る

依頼内容については、依頼先検討と合わせて、情報収集しながら検討していくことになります。

従って、始めからタスクボリュームがわかっているわけではないのですが、おおよその依頼先は検討しておき、依頼のタスクボリュームを想定します。

それと実行する期間とを組み合わせて、進捗を計ることになります。

回答期限管理をする

依頼先に対して、回答時期はバラバラになります。

回答期限を設けているとしても、手間がかかるケースの場合は、期限は守られない可能性はあります。
情報提供の段階では、完全なる営業行為であるため、相手にとって当方が顧客になるか不明確な場合は、後回しになってしまいます。

そのような可能性を含めて、期限管理を行っていきます。

その間に、どのような観点を重視して評価していくのかを決めておくことで、その後の段取りはスムーズにいけます。

評価段取りを計る

評価の段取りは予め決めておきたいところですが、出てこないとわからないところはあります。

よって、出てきたものを検討する期間をとっておき、さらに相手に問い合わせする期間と回答期間も含めて予め計画しておきます。

計画に対して、進捗度合いを見て、問題があれば対処していくことになります。

もし依頼に対する回答がなければ、対象から外すという決断も必要となってきます。

新ITの提案依頼（RFP）のタスクとマネジメント手法

新ITの提案依頼（RFP）のタスク

提案依頼は、情報提供依頼をした先からするのが普通ですが、その他提案を依頼する先が出てきたのであれば、それはそれで候補に入れて活動していきます。

提案依頼は、情報提供とは違い、提案をしてもらうという行為が発生します。そして、その後発注する候補になることが前提です。

よって、本当に発注する可能性のあるところにだけ、依頼をするようにします。

また、依頼するからには提案できる内容になっていないといけません。それなりの準備をして依頼することになります。

提案依頼でのタスクはこのようになります。

依頼する要求を決める

何をしたいか、という要求については少なくとも最初に決めていないと依頼できません。

企画段階で要求が固まっているのであれば、その内容を持って要求とすればいいです。

要求においては、今の仕事に対して新たにやるべきことを決めていると思いますが、今やっていることも要求に入れておかないと、漏れがでますので注意願います。

提案依頼先候補を決める

提案依頼先は、情報提供依頼先の中から、候補となり得る情報を出してきた先から選ぶことになるでしょう。

ただし、情報提供依頼をしていなくても、既に取引のある先などで候補があれば入れることもあります。

実現のためのITに求めるものを決める

要求に対しての実現方法は提案してもらうことになりますが、何を求めているかは決めておいた方がいいでしょう。

提案されても、求めるものとずれてしまっていては、お互い困ることになります。

情報の連携や共有を求めるのか、分析できることを求めるのか、またその際の分析切り口は、スピードを求めるのか、正確さを求めるのか、答えを出してほしいのかといった観点で、求めるものをできるだけ具体的にしていきたいです。

新ITに切り替える方法を決める

要求はあらたなITへの要求です。

現状から新たな環境へ切り替えるのはとても重要な観点です。というので、新たなITを導入するにしても、仕事は継続しており、どこかで切り替える必要があるからです。

エンドユーザ発想では、見た目自然に切り替わるようなこともありますが、大抵裏ではものすごい切り替えが起きています。

提案内容に影響しますので、決められるのであれば決めたいところです。

スケジュールを決める

いつどうしたいかが決まっているのであれば、それの要求となります。

いつでもいい、ということもひょっとしたらあるかもしれませんが、少なくともいつまで、という要求はあると思いますので、提案依頼内容に含めます。

なおスケジュールがタイトなのは、受ける側からするとリスクです。

リスクは金額に跳ねますので、依頼する側としては、スケジュールに余裕があるに越したことはありません。

予算を決める

予算感は提案時に聞かれることもあるでしょう。

そうすると予算ぎりぎりに普通は出してきます。

ただ、提案する側が桁を勘違いして提案することもあるかもしません。

なので、ある程度は予算感をいうこともあるでしょう。

予算は、いくらまで出せるかということになります。

IT化にあたっては、その効果が明瞭に出せればいいですが、そうとも限らないことがあります。

ITの全体の予算は売上の1~２％が多いケースです。

ただし、これは全体の予算ですので、これから導入しようとしているITは全体の中でどのくらいの売り上げ寄与なのかを想定し、いくら出せるかを決めることになるでしょう。

提案先を決める

提案内容が決まってきたら、提案先を候補の中から決めます。

候補は多ければ多くの提案の中から選べるということなりますが、多ければ多いほどよいというものでもありません。

その後の選定に苦労するのと、提案にはそれなりに工数もコストもかかりますので、依頼する可能性の低いところには、提案依頼を求めるべきではありません。

3~５社が普通ではないでしょうか。

提案依頼書を作成する

提案依頼書は提案内容をまとめた文書です。

文書にて依頼し、正式に受け取るのが普通です。

提案依頼内容は、先に述べた要求内容や切替方法、スケジュール、予算といったものになります。
予算は、見せ方がケースバイケースになります。

提案依頼内容に加えて、提案をいつどのように回答するかといったルールを提示します。

回答に対して、選定結果をいつ伝えるかというスケジュールも提示します。

提案先に提案依頼書を提示する

提案先に提案依頼書を提示することになりますが、提示方法は様々です。

説明をしてから提示するということもありますし、ただ渡すこともあります。

普通は説明が必要となります。

説明するにあたっても、説明会という形にして複数相手先を一堂に会して行うケースもあれば、一人ひとりに説明するケースもあります。

提案の評価基準を決める

提案が回答されてきたら、評価することなります。

その際の評価基準を決めておきます。

ただ、提案が出てこないことには比較項目が出せないということもあるかもしませんので、仮に決めるということになるかもしれません。

少なくとも評価基準として入れるべき項目は、要求充足度、コスト、納期、会社信用度、実績、推進体制、といったところです。

仮に同じ内容でであったらコストが安いほうがいいということになりそうですが、実績や推進体制も考慮しないと、安かろう、悪かろうという結果になり兼ねません。

提案依頼の回答を得る

説明時に設定したルールに従って、回答を得ることになります。

回答内容に過不足がないことを確認し、評価に移ります。

提案の評価をする

各社の提案に対して、評価を行います。

評価基準は予めある程度決めていますが、出てきたものを見たら比較すべき項目が出てくることはあります。

要求充足度については特に精査が必要です。

実現できることに対して、強弱があります。

魅力的な機能がある場合もあれば、一応できるというレベルのこともあります。

提案の際に、検討するための期間が必要という提案になっている時もあります。

その提案は提案を一部出してきていないことになるので、却下候補と思われるかもしませんが、なぜそのように言ってきているかは、よく考えたほうがいいです。

ただ単に、今時間を割くことのできる人がいないだけかもしれませんし、こちらからの要求提示が不十分なことも考えられます。

もし聞くに値するのであれば、今一度提案依頼を見直すこともあり得ます。

発注先を決定する

提案の評価を行ったら、発注先が決定されることになります。

発注先が決定したら、落選した人たちに通知します。

発注先とは、今後の契約等について取り進めることになります。

新ITの提案依頼（RFP）のマネジメント

提案により決定するまでの期間をその後の構築・導入全体の期間から想定する

ITの構築や導入については時期が決まっていることがあります。

そのために提案依頼をして、発注先を選定しているのであれば、可能な期間は決まってくるはずです。
導入するのはまだ先のことなので、心持ち余裕があるように振舞ってしまいがちですが、意外と余裕がないこともよくあります。

従って、全体の中でどのくらいの期間を掛けて実施すべきかを決めておきます。

提案依頼書から提案評価・決定まで掛けられる時間と総想定時間から期間を想定する

期間を一旦決めたとしても、誰がどのくらいの時間を投入できるかという問題があります。

この仕事だけをやれるということはよほどの大きな案件でないとないため、大抵は何かをやりながら実施していることでしょう。

そうであれば、実際投入できる時間を踏まえて期間を取っておかないと、必ず遅れるということになってしまいます。

前提的な期限との兼ね合いでもって、期間を精査していくことになります。

提案書の回答に掛かる期間と評価・決定の期間を想定する

期間に関しては、自分だけでは決められないことがあります。提案依頼に対する回答の期間は相手に寄ります。

案件の大きさにもよりますが、2週間から1カ月は普通にかかります。

状況にもよりますが、2カ月くらいかかるケースもあります。

しかし、相手にばかり合わせてもいられないため、ある程度は相手を考慮しつつ、スケジュールを提示することなります。

期間を計画し、予定どおりかどうかを定期的に確認する

提案依頼書作成、提示、受領、評価、選定といったステップごとにスケジュールを計画します。

計画に対して、状況を確認していくことになります。

5社提案依頼しているのであれば、5社の状況がどうなっているのかを把握し、もし1社のみ遅れていたらどうするのか等対策を考えます。

予定どおりに進んでいなかったら、決定までの期間に影響するかを確認する

全体的に遅れてしまったら、決定時期に影響するかを確認します。

決定時期が遅れてしまうと全体の期間に影響することになります。

決定の時期の制約が強い案件であれば、どこかで間に合わせるようにしなくてはいけません。

再計画もしくは時間を充てること等により対処を行う

もし予定より大幅に遅延してしまっていたら、再度計画するか、時間を増やして計画どおりに進められるようにするかの判断を行います。

期間を延ばしていいケースもありますので、その際はスケジュール変更となります。

引き続き定期的に確認する

再計画を行った場合は、引き続き定期的に見直した計画に対して問題ないかを確認していきます。

提案の回答が想定でなかったら、計画を見直す

一連の活動の中で肝心の提案内容について、問題がある場合もあります。

想定していた内容で提案されていないということは、ゴールに達することはできません。

何かに問題があったということなります。

問題	想定される原因
提案内容にかなりのばらつきがある	依頼方法に不明瞭な部分があった
提案内容が満たされていない	要求の提示が不十分であった
一部の提案が出されない	依頼先の問題

このように当方か先方に原因があり、提案内容が想定外になっています。

よって、どの原因かによって、対処をする必要があります。

当方の要求からやり直すのであれば、かなりの手戻りということになります。