■はじめに
2006年に「RFP/RFI作成時のITCとしての課題」という文章を書いた。あれから７年が経ち、RFPに対する認識もすこしは変わってきたように思う。
「RFPは提案依頼書であり、RFIは情報提供依頼書である。システム開発にあたり、自らのニーズや現状をとりまとめ、書類の形で複数のITベンダーやシステム･インテグレーターに渡す資料を言う。口頭でニーズを伝えるのとは異なるため、依頼の目的や求めている物事がハッキリし、曖昧さや人情（普段の営業付き合い）要素が排除されるため、適切で公平な競争提案を貰いやすくなる。」
７年前に書いたこの表現は今でも変わらないが、その出来不出来がRFPによってさまざまであることも変わらない。相変わらず見積やすいものもあれば、見積もりにくいものもある。
本論では、RFPと企業予算の関係を考察し、より良いRFPを作成する為の参考とするためのヒントを提示する。
■RFPは浸透したのか？
複数のベンダーに提案依頼をする際に、RFPを書くという手法は、ここ７年の間にかなり広がってきた。
それ以前は何度もIT会社の営業が客先に通い、断片的にニーズや背景を把握しながら提案を進めるという形が多かったが、最近はそれまであまり付き合いの無かったお客様からお声掛けをいただき、RFPを元に提案依頼を求められることが多くなった。逆に言えば、企業は営業マンとの親しさよりも、実利的な評価を求める傾向があり、その手段としてRFPが有効だという理解が広まりつつあるという事だろう。
いずれにせよ企業がIT化を考える場合にRFPにまとめるというスタイルは、以前に比べて一般的になってきたように体感的に感じる。
しかしRFP自体の質的な向上につながっているのかというと必ずしもそうではないようだ。RFPは、市場に出て切磋琢磨されるような性質ではないからだろうが、質が良くなっているとは思えない。むしろ、RFPが身近になるにつれ、質が落ちてきているともいえる。
何も無いところから始めるよりは良いが、提案しづらいRFPに遭遇することが多々ある。
■提案依頼事項とRFP
情報処理部門にとっては、忙しい業務の合間を縫って作成したRFPである。沢山要求したいことがあるのはよく分かる。しかしRFPというものは、提案依頼をしたあとが大切であり、その資料を基に実際に経営判断しきらないといけないものである。
残念ながら、ここ最近提示されるRFPの中には、あれもこれもと大量の依頼事項があったり、Ａの場合、Ｂの場合、Ｃの場合で条件を変えて提案せよといったパターンがある。
大量の提案するのは構わないが、２つの点を注意すべきだろう。
まず、提案を受けた後の判断ポイントをあらかじめはっきりしておく事が重要である。価格なのか、操作性なのか、短期間導入なのか、判断すべき要素が多ければ多いほど判断が難しくなり、決められなくなる。挙句の果てには「決められないので今回のIT投資は見送り」といった事態に至る。
たとえば、どのような技術やアーキテクチャで改革するのかさえ決まっていない場合がある。「社内サーバーでも良いけれど、セキュリティを考えてデータセンターでの提案も歓迎する。クラウドでも構わない。」というRFPは本当に意味があるのかと思う。
それぞれにメリットデメリットがあり、その特性がある。発注側はその特性に対しどのような評価をしており、どう判断するつもりなのか、その判断基準が十分でないのであれば、RFPに進むべきではない。このような場合は、いきなりRFPにせずに、RFIで情報を取り、どのような技術方式でどう解決すべきかを社内判断してから、あらためてRFPを発行するのが良いだろう。
二つ目は、選考方式である。どのような観点で選考するのか、だれがいつ判断するのかといったセクションが無いRFPが増えているように思う。しかしRFPにおいて、この部分は非常に重要であり、選考過程と評点が事前に明確であるということは、このプロジェクトは成功しそうだということを暗示しているようなものである。
判断ポイントが絞り込めていないRFPは、その企業内での混沌さを映しているともいえる。
■予算とRFP
企業経営が苦しい中、IT投資のための年度予算確保は情報システム部門や担当者にとっては重要なテーマである。
来期の予算取りがかかっているRFPは、開発計画の予算取りがかかっており、中身も真剣で良いものが多いのだが、社内の予算取りとRFPとが直結しているケースがある。
しかしながら、多くのRFPでは、単純にパッケージソフトを選定するのではなく、独自開発が絡むものが多い。
その場合、開発ボリュームは、プログラム本数等に直結するため、積算が非常に難しい。
ところが、RFPで集めた見積書の金額をそのまま来年度予算として計上してしまうケースがある。
システム開発には受注後に、詳しいヒアリングやエンジニアによる各種業務分析が必要であり、RFP程度の情報では精確な予算は見積もれない。通常、RFPに返答する見積額は様々な前提条件や概算で行っており、その際の見積額をそのまま来年度予算として計上するのは危険な行為と言わざるを得ない。
実際にプロジェクトが始まると、ユーザー部門からは思ってもみない要求が出てくるし、ITベンダーからは「現行システムを解析した所見積条件書では想定していなかった事象が見つかりました」といった具合に追加料金の要求が出てくる。新しい業務フローをきちんと決めず、複雑で大規模なRFPほどその傾向がある。
結果、情報システム部門の担当者は、年度予算額とこれら要求の板挟みになり、苦しむことになり、ユーザー部門にとっては不満の残るシステムとなる。
そしてITベンダーは、低予算で儲けの無いプロジェクトになってしまう。
だれも幸せにならないRFPは、結局失敗と言わざるを得ない。
RFPに注力するのも良いが、精度の高い見積や予算統制をどのように進めたらよいか、情報システム部門は「戦略」を持たなければならない。
■まとめ
提案依頼事項の質と量、選考基準と選考過程、企業内予算との関係。この３つの要素は、RFPの質を決める重要な要素であり、ＩＴベンダーはこの３点を見て、成功しやすいかどうかを感覚的に感じ取る。つまりやりたいプロジェクトなのか、できれば避けたい問題を抱えるプロジェクトなのかが透けて見えてくる。
ＩＴベンダーがやりたいプロジェクトであれば、意欲的で良い提案も出てくるであろう。
情報システム部門は、こうしたポイントに留意して、RFPを作成した頂きたいと思う。
ITコーディネータ／太田垣博嗣
