ベンダーに自分の要求を伝えられるか？ベンダーの力を引き出せるか？妥当な金額で発注できるか？トラブルの芽は摘んであるか？それは“RFP（提案依頼書）の作り方”にかかっている。「プロジェクトが失敗したのは，ベンダー選びを間違えたから」。そんな苦い経験を繰り返さないための，“良いベンダーと出会う”技術を事例から明らかにする。

　今度こそ良いベンダーと一緒にシステムを作りたい――そんな思いから，複数のベンダーに提案を募る開発案件が増えてきた。

　学習塾の京進は，かつて馴染みのベンダーから納入されたシステムの品質が悪く，苦労した。この苦い経験から，5月に稼働させた「スクールワン顧客対応システム」では，ベンダー選定時に細心の注意を払った。この案件では，アプリケーション開発に加えて，全社システム基盤の整備も視野に入れていたため，絶対に失敗できなかった。

　7社をピックアップし，RFPを発行して提案を募った。担当した情報企画部 開発設計課長 清水多津雄氏にとって，きちんとしたRFPを作ってベンダーを選ぶのは初めてのことだった。

　「RFP説明会での態度から，受け取った提案書の体裁や内容，質疑応答の内容，プレゼンテーションの参加メンバーまで，それぞれのベンダーをつぶさに見た。製品の売り込みに終始するような提案書を提出してくるベンダーもあれば，RFPの不備を指摘するほど深く読み込んでくれたベンダーもあった。このようなプロセスを経たことで，各社のスタンスや特徴がよく分かり，最終的に納得のいくベンダーと契約できた」（清水氏）。

　 清水氏が作成したRFPとは「Request for Proposal（提案依頼書）」の略で，ベンダーからの提案を募る行為や，提案を引き出すためのドキュメントを指す。これ自体は昔からある概念だが，これまでベンダー選定の現場で利用されることは意外に少なかった。

　コンサルタントのプロ・アクシス代表取締役堀田正隆氏は「複数のベンダーから同時に提案を募る際には，ユーザーが自分の考えを整理してベンダーに伝える必要がある。RFPは，そのための有効な道具だ。プロジェクトの期間やコストを考えるベースにもなる。後で“言った，言わない”ともめないためにも，早い段階で要求をドキュメント化しておくことは重要」と，そのメリットを強調する。

三越が経験した苦労

　三越の尾方晃氏（業務部システム統括担当ゼネラルマネジャー）も，RFPに基づきベンダーを選ぶことが必要だと感じるようになってきた一人。その背景を尾方氏は次のように語る。「特定のベンダーとばかり付き合っていると，競争原理が働かない。システムもブラックボックス化してしまう」。

　尾方氏はPOSシステムの再構築に当たり，ベンダー5社に対してRFPを発行した。しかし，結果として書き方に問題があり，その後の提案書評価で苦労した。「提案書を集めたところ，あるベンダーはPOS端末側だけの見積もりを出してきたのに対し，別のベンダーはサーバー側まで含めた見積もりになっていた」。これでは比較しようがないため，見積もりの範囲を明示し，改めて各社に対してプレゼンテーションを依頼することになった。三越がこれまでに作成したRFPはPOSシステムを含めて5通。「回を重ねるごとに，RFPの精度が少しずつ上がってきた」（尾方氏）。

　いざRFPを作ろうとしても「何をどう準備したらいいか分からない」（日教販 執行役員 管理部 部長 増澤富男氏）というユーザーは少なくない。要件をまとめるまで2カ月の猶予しかなかった増澤氏は，コンサルタントの協力を得て，実質3週間でRFPをまとめ上げた。

　RFPには，決まった作り方がない。要件定義まで済ませた後に，より早く安く作るための提案を募るケースもあれば，要件があいまいな状態でどのようにシステム化すればいいかといった部分までベンダーの提案力に期待するケースもある。両者では，RFPの作り方はまるで違ってくる。

　日教販のRFP作成を支援したイントリーグ代表取締役の永井昭弘氏は「IT業界は歴史が浅いので，業務システムのRFPなどは書き方がばらばら」と言う。現状は，正しいと思う方法を，事例を積み重ねながら，洗練させていく段階にある（図1）。

図1●ベンダーを選べないユーザーの悩み

永和システムの悩み

　ダメなRFPは，その“読者”であるベンダーを悩ませる。何通ものRFPに接してきた永和システムマネジメントの中村武氏（サービスプロバイディング事業部 営業部 コンサルティングセールス 担当部長）は「提案や見積もりがしにくいRFPがある」と不満を漏らす。次のような例がその典型だ。

　「既存システムの機能を拡張する案件を手掛けたことがある。ところが，そのRFPには，既存システムのハードウエア・スペックも，アプリケーションの仕様も書かれていなかった。しかも，仕様を調査するための時間はほとんどなかった」（中村氏）。

　そのしわ寄せは要件定義など後工程で表面化する。これはそのままプロジェクトを遅延させたり，赤字をもたらしたりするリスク要因となる。ユーザーにとって，いいことは何もない。

　本来なら「使用目的や開発目標，開発の対象，利用したい技術や製品，SLA，セキュリティ・ポリシー，想定アクセス数などの情報がRFPに書かれているとありがたい」（中村氏）。

　ダメなのはRFPの内容だけではない。ベンダー選定のプロセスにも問題がある。野村総合研究所の河村雄大氏（上級システムエンジニア 証券システム二部）が経験したある案件では，なんと1年もの間，ベンダーを選ぶことさえできなかったという。

　「ある金融機関のコンペに参加したが，ユーザーは当社とは別のベンダーを選定した。しかし最初のベンダーと契約面で折り合いが付かなかったらしく，しばらくしてから当社に話が来た。提案時から時間が経っていたので，提案の内容や金額を書き直して改めてユーザーに提出したが，それでは話が違うということでまた破談になった」。　この時は，提案書に有効期限があった。それをユーザーが知らなかったか，軽視したことが問題となった。

　「ベンダー選定のスケジュールを決めずに，とりあえずRFPを作成し，提案プレゼンテーションを受けるだけのユーザーも多い。そういうユーザーに限って，いたずらに交渉を繰り返し，スケジュールが延びてしまうようだ」（アイル 取締役 ソリューション営業部 ビジネスデザイナー 串戸一浩氏）。

　せっかく力のあるベンダーと接触しても，これではその力を引き出すことが期待できない。その結果，金額の安さや口先のうまさでしか判断できず，本当に良いベンダーと出会うことにはつながらない(図2）。

図2●提案できないベンダーの悩み

正しい選択は力を引き出すことから

　RFP作成のコンサルティングを手掛けるビーコンITの木村哲氏（コンサルティング部長 チーフコンサルタント）は「今，ユーザーとベンダーの関係が二極化している」と指摘する（図3）。眼の肥えたユーザーは力のあるベンダーを選び，発注下手なユーザーは力のないベンダーに取り入られる。良いベンダーと出会えるかどうかは，正しい見積もりやレベルの高い提案を引き出せるかどうかにかかっている。

図3●発注下手なユーザーは力のないベンダーとしか巡り会えない 発注上手になるための条件は(1)提案しやすいRFPを作ることと，(2)評価しやすいプロセスを作ること