RFPは提案依頼書であり、RFIは情報提供依頼書である。システム開発にあたり、自らのニーズや現状をとりまとめ、書類の形で複数のITベンダーやシステム･インテグレーターに渡す資料を言う。口頭でニーズを伝えるのとは異なるため、依頼の目的や求めている物事がハッキリし、曖昧さや人情（普段の営業付き合い）要素が排除されるため、適切で公平な競争提案を貰いやすくなる。
小職は、仕事柄、RFPを発行する立場とRFPを受け取って提案する立場の両方を経験することがある。そのときの経験からすると、提案する立場から見て良いRFP/RFIを書く人は、会って話をしても優秀であるし、提案しにくいRFP/RFIを書く人は、会って話をしてもなかなかピントが定まらない場合が多いように思う。
本論では、そのときの経験などを踏まえ、RFP/RFIを作成する際に陥りやすいモラル上の問題を指摘し、より良いRFP/RFIを作成する為の参考とするためのヒントを提示する。
■RFP/RFIが流行り始めた
ここ最近、RFPという言葉がシステム開発ベンダーの中でもかなり知名度を上げてきている。ほんの少し前であれば数億円以上の大規模なシステム開発でなければRFP/RFIといった言葉は聞かれなかったし、プログラマでもその言葉を知っている人は少なかった。こういう変化の中の一部には、システム提案を依頼するときにはRFP/RFIを書いて依頼しようという、ITコーディネーターの地道な呼びかけや活動もあるのだろう。
ただ、依頼をかけるユーザー企業や団体が純粋に自前でRFP/RFIを作成する場合はまだまだ少ないように思われる。多くの場合、RFPやRFIを書くためには相応の専門能力が必要であるため、ITコーディネータがRFP/RFI作成に携わったり、普段から出入りのあるITベンダーが作成する場合が多いように思われる。（小職もその一人である）
また、RFP/RFIを受ける側のシステムベンダーも、仮にその内容が自社でできない内容であっても、名乗りだけは上げておくという態度をとることも多い。営利活動からすれば、そういう態度をとるのは自然な話である。そして、肝心のRFPはシステムベンダーの関係会社や子会社、協力会社等の手に渡ってゆく。
一般的にRFP/RFI発行の手続きを行う場合は、依頼元と依頼先と秘密保持契約を締結してから、RFP/RFIを提示するものだが、同等の秘密保持契約を継承する限りにおいて、依頼先がさらに他に依頼することを認めているケースが多い。
実際、システムベンダーやシステムインテグレーターは、ハードウェアメーカーや、通信業者、関連ツールベンダー等に相談しながら進めなければ、納期、金額、性能保証体制などRFPに書かれている事項は満たすことができないので、これは特異なケースではない。
■RFP/RFIを受けたシステムベンダーの立場から
さて、RFP/RFIにも出来、不出来がある。もちろんユーザー企業内での現状分析の具合やRFP/RFI作成までの時間等の問題で満足に要件を固めることができない場合も多いため、内容の正確さや濃さについての出来、不出来はあっても仕方が無いと思うのだが、それ以前の問題もある。それは、RFP/RFIを貰って提案ベンダーの立場になった時に提案書を書いて提出する側の不満や苛立ちとして現れてくる。多くの場合、RFP/RFIの提出期限は２週間程度であるが、２週間で作成できる限度を超えた情報提供を依頼してくるRFP/RFIに出会うことがある。
■開発ベンダーの手法に深入りしたRFP
たとえば、「開発ソフトウェアの品質管理をどのように行って、提供製品の質を維持するのか？」という課題に関して、プロジェクト管理手法やテスト手法、使用しているツール等を事細かに記述させ提出させようとするものがある。ある程度の開示は必要であろうが、提案書を記述する側は、別のことを警戒するのである。
すなわち、このRFP/RFIが他のシステムベンダーの手によって書かれたものであるとすると、秘密保持契約があるとはいえ、事実上、こちらの手の内を他のシステムベンダーに読まれてしまっていることになってしまう。ユーザーに理解してもらうのはよいとしても、開発効率を上げるための工夫は、基本的には他社に知られたく無いことでもある。
あるいは、パッケージソフトのデータベース設計図、スキーマ構造図、エンティティ設計書を出してください、などといったRFPも存在する。ERPソフトにおいて、データベース設計は一種の知的財産であり、秘密保持契約があるとはいえ、購入するかどうかわからない人々に簡単に開示するわけにはいかない。
■矛盾したRFP
あるいは、ベンチャー企業や新規事業のシステム提案依頼で多いのが、将来計画が非常に曖昧で、どの時点の企業規模で見積もればよいのかわからないといったものである。
これらにはRFP自体に矛盾があるものも多い。
たとえば、一人１個を買うのが普通の、１個ｎ万円の商品があるとして、その伝票発生数や、営業担当の数、年間販売計画数量などが、矛盾している場合である。１営業マンが１０分に１個ずつ訪問販売してゆかなければいけない計画になっていたり、月に１０台程度販売している工作機械が、システムを導入した直後から毎月８０台ぐらい売れる計画になっているが、生産設備は現状のままで月産５０台が限度であったりという具合である。
■経営計画を考えさせようとするRFP
一見IT提案のようで、よく読むと新規事業やビジネスモデルの検討依頼のようなものもある。
通常、RFPでは、ユーザーニーズとベンダー各社が持つ技術や製品、ソリューションとのフィット＆ギャップを明確にしてゆくことにより、依頼ベンダーを絞り込んでゆくことが重要になる。
ところが、時折「あなたが持っているIT技術を使って、私たちのビジネスモデルをどう変えることができるのかを示してください」とか「ホームページを開設すれば、月商いくらぐらいになると考えられますか」といった質問が設定されていることがある。そして「そう考えた前提条件を残さず書き出しなさい」といった注意書きが載っていることが多い。
たしかに、RFP/RFIの目的のひとつとして、ユーザーが知らない画期的な手法や製品を市場から情報提供してもらうという事があるのだが、そこに裏付けを求めるべきではないだろう。
また、経営者からRFP執筆者やITコーディネータには「IT化でいくら儲かるんだ？」といった投資効果に直結した質問が降りてきて、対応しないければならない場合もあるが、その質問をRFPに記述するのは、仮に依頼元の正直な気持ちだとしても、馴染まないように思われる。
■前提条件不足のRFP
RFPを書いている現場では、時間不足、情報不足のまま見切り発車してしまうことが多い。十分なITコーディネートを受けていなかったり、社内の情報化戦略が固まっていない場合には、特にそうなりやすい。
問題は、RFPの中に提案するのに十分な情報が盛り込まれていないことである。たとえば、依頼企業・団体のIT経営成熟度に関する情報や、情報システム部門やシステムに詳しい人の能力や権限に関する記述が少ない場合がある。
たとえば、導入後のサポートやシステム運用等について見積もりを得ようとするならば、その組織のIT経営成熟度や担当者のスキル等がわからないと、なかなか提案しづらいものである。つまり、全社のシステム運用体制や会社の情報化がどのように浸透しているのかがわからないため、提案自体が非常にブレたものになる。
他にも、サービスレベル、セキュリティレベル、おおよその予算感覚などが抜け落ちていることが多い。
そして、こうした前提条件が不足しているRFPに対して、質問をすると「貴社が最適だと思う構成で提案してください」といった曖昧な逃げ口上で回答される場合や、「それでは数パターン例示してください」という場合がある。
だが、システム提案する側からすれば、まじめに数パターンを検討し、コスト算出することは難しい場合が多い。それこそ、松・竹・梅の３パターンで金額が数倍違うものを提示することになってしまう。これではRFP/RFIによって要件を整理したことにはならない。
しかし、多くの場合見積金額の根拠はかなり細かく書くことが求められている。
これでは、むしろ提案者側に重たい負担だけがのしかかってくる。
■提案依頼者と提案者の関係
RFPを受け取ったシステムベンダーの行動を考えてみよう。システムベンダーの営業としては当然仕事が欲しいから、自分の事業範囲に少しでも関係しそうな部分があれば、会社に戻りRFPを提案書作成者であるシステムエンジニアに渡すことになる。
しかし、多くの提案書作成者は、他の十分な仕事量を抱えた上で、１週間とか１０日といった限られた提案時間を与えられ、大量の資料を作成してゆかなければならない。特に優秀なシステムアナリストやシステムエンジニアには普段の仕事でも業務が集中しがちである。
ある提案では、RFP/RFIどおりに提案書を作成したら、200ページに及ぶ大作になったことがある。添付資料などをあわせると、ざっと300ページである。ところが、断るときには、電話１本である。営業が訪問しても、プロジェクトが始まって忙しいからとなかなか会えない。
このような体験を重ねてゆくと、次回RFP/RFIが提示されても、まじめに返事しようという気にはならない。
■良いRFP/RFIとは
良いRFP/RFIとは、必要十分な情報が矛盾なくコンパクトに伝えられていることは重要であるが、それが提案書作成者に気持ちよく情報開示してもらうものでなければならない。 特にシステムベンダーの選択肢が少ない地方では、良いRFP/RFIを作成してベンダーとの関係を良好に保つことも重要である。 これを踏まえたうえで、前述した良くないRFP/RFIの例に対して、どのようにすればよいかを以下に示してみたい。
■開発手法に深入りしないRFP/RFI
プロジェクト管理能力に対する不安や、システム品質に対する不安を取り除いて欲しいというスタンスで、記述することが重要である。つまり、どの程度のシステム品質やプロジェクト管理が遂行できれば不安ではないのかを提示することが重要で、そのような経験が過去どの程度あるのか、不安を除去する証明する提出資料は開発費用に含まれるのか、別途費用を払えばどのような上位オプションがあるのかを訊くようにする方が良い。
■矛盾しないRFP/RFI
RFP/RFIに矛盾が見つかると、提案書作成者はそのRFP/RFIの全ての記述が疑わしくなる。したがって、矛盾が発生しないようにチェックをすることが肝要であるが、どうしても整合性が取れない場合は、どの数字を基軸に提案を展開してゆけばいいのかを明示する必要がある。
つまり「現段階では将来の売上計画と今回のビジネスモデルおよび費用計画は必ずしも整合性を持っていません。したがって、別紙に示す費用計画を元にご検討頂き、売上計画などは参考程度にお考えください」等と、提供情報の精度に濃淡を付けるなどの工夫が必要となる。
■経営計画を与えるRFP
経営計画に関わる情報は、遮断し、決まっていないことは決まっていないと明示し、それ以上の要求は書くべきではない。
■前提条件をはっきり記載するRFP/RFI
前提条件は変動があるとしても、はっきり記載することが必要である。例えば、３年後の新規顧客数がどの程度になるかは、誰だって分からない。しかし、RFP/RFIの主目的は、同じ前提になった時にどのベンダーが一番良い提案を返してくれるかを判断するというところにあるわけであるから、３年後の新規顧客数のような数値は固定させてベンダーに提示しないといけない。同様に、セキュリティレベルは、「Pマークを取得できる程度の企業環境だと仮定し、それに相応しいセキュリティを提供すること」といった表現が考えられる。
システムの二重化や信頼性に関しても、システムコストが大きく変わる要素である。ハードウェア価格だけではなく、二重化のための特別ハードウェアや、それらを正しく起動／終了させる運用手法等も変わってくるため、RFP/RFIには必ず記載するようにする。どうしても明確な記述が出来ない場合は、「現在のシステムと同等か、やや高いレベル程度とする」といった記述等を検討する。
また、システム部門が保有するスキルに関してはできるだけ記載したほうが良い。技術者（社員、協力会社）のおおよその年代とスキル等をたとえばITSSの技術レベルで表現し、日常の業務内容や保有技術（開発言語、システム設計力など）を表にまとめ、人事異動が頻繁かどうか等を示すだけでも、運用の提案には大きく役立つ。一般従業員のパソコンスキルに関しても、社員教育を見積もりに含むのであれば、触れておいたほうが良い。
また、はっきり記載できない部分がある場合、要求する情報や提案は精度を落として提示してもらうような配慮が必要である。
■まとめ
良いRFP/RFIなのかどうかを判断する為の、絶対的な指標や客観的な測定値を設けることは難しいしコスト的にも馴染まないと思われる。もとより、世間にRFP/RFIを書き慣れたエンジニアやアナリストはまだまだ少ない。
もし、RFP/RFIを書きなれた人が近くに居ないのであれば、まずちいさなRFIを書く機会を沢山与え、RFI/RFPを書くための文書部品を書き溜める機会を作っておくと良い。最初に社内のシステム構成図や、システム部門のスキルマップなどを書いてしまえば、数年経ってもそれなりに使えるものである。
また、提案を依頼し、どこか１社に決めた後、選に漏れたベンダーを呼び、落選理由を説明すると共に、「また次回別件でRFP/RFIを提示する機会があると思うので、今回お渡ししたRFP/RFIの中で書きにくかったところがあればお教えいただきたいと思います。またもし、参考になるような他社のRFP/RFIがあれば、章立てだけでも見せていただけないでしょうか？」という依頼をしてみてはどうでしょうか？
こうしたタイミングはRFP/RFIを書く技術を磨く良いチャンスである。良いRFP/RFIには良いベンダーが付き、提案書作成者も真剣に取り組むものであるから、長期的な視点から考えても、非常に有用なミーティングになるはずである。
多くのRFP/RFIに接する機会を持っているITコーディネータは、良いRFP/RFI、悪いRFP/RFIを世に問うてゆくのも責任の一部ではないかと感じている。
ITコーディネータ／太田垣博嗣
