ITコーディネーターの活躍の結果なのか世間の潮流なのかわからないが、最近システムベンダーの立場で、RFP/RFI（提案依頼書、情報提供依頼書）を受け取って提案書を書く機会が増えた。複雑なシステムの場合には、RFPを受け取ったシステムベンダーから「このパートに、おたくの製品使えそうだから、そこのところを書いて欲しい」といった孫受け依頼や、「とりあえず名乗りは上げたんだけど、うちじゃできないので、考えてみて！」と丸投げのような依頼もある。

逆にお客様サイドに立って、RFP/RFIのような位置付けの資料を書いてベンダーに渡すことも増えた。

こういった資料は書くのに結構骨が折れる。システムの内容がわかっていたとしてもそれを文章に表現することはなかなか難しい。実際のシステム案件で書いたり読んだりしてゆかないと、書くセンスというか要領はなかなか身についてゆかないものである。他のシステム開発技術と同様に、RFP/RFIの作成技量というのも徐々にシビアになってゆくのだろう。

最近ちょっと困り者なのが、RFP/RFIを名目に、ノウハウを全部吐き出せと言わんばかりの無責任な提案依頼書だ。RFP/RFIを発行する最大の目的は、ユーザーニーズを書面にあらわして、複数のベンダーから意識のズレの少ない提案を貰うというところにある。次に、副次的な要素として、ユーザーが知らない画期的な手法や製品があった場合にそれを積極的に活用する為にベンダーに対して情報を求め、知見を得るという目的がある。

したがって、ユーザーニーズとベンダー各社が持つ技術や製品、ソリューションとのフィット＆ギャップを見るのが重要なはずなのだが、時折「あなたが持っているIT技術を使って、私たちのビジネスモデルをどう変えることができるのかを示してください」とか「そのシステムのデータベース設計図、スキーマ構造図、エンティティ設計書を出してください」などと堂々と依頼してRFP/RFIに出会うことがある。たいていは、どこかのシステムベンダー等がユーザーの代理で作成した資料だ。

こういうRFP/RFIを受け取ると、提案する側の私のテンションは一気に冷めてしまう。

ITコーディネータのプロセスガイドラインの中では、RFP/RFIの発行は、経営戦略・ビジネスモデルに関する社内コミットメントが済んだ後に、それを実現するための手法リサーチや協業ベンダーの発掘のために行うことになている。ところが、情報収集といいながらビジネスモデルの検証や有効性を問うというのはどういうことだろうか。

エンティティ設計書を提出して、はたしてそれを評価する人材がユーザーや、ユーザーの代理となっているシステムベンダーに居るのだろうか。もちろん居る場合もあるのだろうが、実際には少ない。短い時間の中で、そんな資料をしっかり理解する時間は無いはずだ。むしろ、システムベンダーからすれば知財の流出に他ならない。

提出した資料はユーザーの手に渡り、秘密保持契約を締結しているとはいえ、ユーザが関与している他のシステムベンダーが閲覧することは間違いない。

もちろん、こちらとしては仕事が欲しいから、できるだけの情報は提供しようと思うのだが、１週間とか１０日といった限られた提案時間の中で、大量の資料を提出させるのははたして意味があるのかと感じることがある。

もうひとつ、「腹立たしいRFP」がある。こちらは書かれていることにではなく、書かれていないことにである。その会社のIT経営の成熟度に関する情報が非常に少ないということがある。たとえば、導入後のサポートやシステム運用等について沢山記述するよう要請される場合があるのだが、ユーザーのIT経営成熟度がわからないと、なかなか提案しづらい場合がある。

たとえばRFPでも、ある程度ターゲット製品が予想されている場合、その製品と自社の開発要件との適合性を見る場合や、その製品の販売代理店として確かな力量があるのかを見極める場合のRFPと、世間にどんな製品があるのかを把握したい場合になげるRFPとは、書き方も変えてゆかなければならない。

後者の場合などは、運用体制や会社の情報化がどのように浸透しているのかがわからないと、提案は非常にブレたものになる。これが書きにくいというのであれば、いきなりRFPをどーんと発行するのではなく、数回にわたってRFIを発行し、消化できる程度の整理された情報を得つつ、競合各社の営業ともある程度仲良くなってゆきながら最終的にRFPを発行するようなやりかたも考えるべきであろう。

今は未だ世間にRFPを書きなれたエンジニアやアナリストは少ない。
多くのRFPに接する機会を持っているITコーディネータは、良いRFP、悪いRFPを世に問うてゆくのも責任の一部ではないかと感じている。

ITコーディネータ／太田垣博嗣