ITproの読者で「RFP（提案依頼書）」という言葉を知らない人は少ないだろう。それだけ，RFPが市民権を得た結果と言える。しかし，RFPの活用が広がる一方で，悲鳴を上げているベンダー担当者も増えているように感じてならない。悲鳴を上げているのは，コンペによって競争にさらされているからではない。“ひどいRFP”によって不当な提案を強いられたり，迷走プロジェクトに巻き込まれたりしているケースが目立つからである。

　現場ではいったい何が起きているのか。記者は5月某日，RFPの読み手であるベンダー担当者3人を招いて，覆面座談会を開いた。テーマは「現場に蔓延する“ひどいRFP”」。すると，実際に出くわした“ひどいRFP”が，次から次へと挙がった。以下では，その典型パターンをいくつか紹介しよう。

ケース（1）　担当者の思いだけで記述

　一つめは，担当者の“思い”だけがRFPに書かれていたケースである。大手メーカーでRFPの評価を担当するAさんはある時，目的に「決算処理の迅速化」と書かれているのに，なぜか要求の一番に「24時間365日稼働」とあるRFPに遭遇した。なぜこのような要求が出てくるのか分からない。Aさんはそのことを尋ねると「これで提案してくれ」の一点張り。
　納得しないまま提案書を作成したが，それはムダな作業に終わった。RFPに書かれた内容は，RFP作成者が信頼性の高いシステムを目指して自分の思いだけで記述したもの。目的に書かれた「決算処理の迅速化」は，中期IT計画で示された投資目的を引用したものだった。つまり，本来の目的に即した要求にはなっておらず，RFPの内容も上層部と合意できていなかったのだ。結局，高い信頼性など必要なく，手間をかけた提案書は再度作り直しとなった。

ケース（2）　現行機能を「保証」せよ

　二つめは，外資系コンサルティング会社に勤めるBさんの話だ。Bさんは，最もひどい例として，「保証」や「迅速」「柔軟」といった，あいまいなキーワードが潜むRFPを挙げる。

　Bさんは以前，「新規システムは現行システムのユーザー・インタフェース（UI）を踏襲する」というRFPを受け取った。現行システムのUIとは何かとRFP作成者に聞いても明確な答えがない。Bさんはこうした要求（現行機能の保証）を鵜呑みにすると，次から次へと追加機能が出てきて赤字プロジェクトになることを知っていた。そこで現行システムの調査費用が必要だと告げると，そんな予算はないと跳ね返された。結局，今後の付き合いもあることから，ほぼ無償で現行機能の調査をする羽目になった。

ケース（3）　画面ばかりがびっしり

　三つめは，きちんと書かれているように見えて，実は使い物にならなかった例である。前出・Aさんは「最近見た中で困ったのは，画面だけがやたらと詳しく書かれていて，ロジックやDBのことには全く触れられていないケース」と話す。ならばUIのことは書かれているかと見てみると，帳票類は一切なかった。これでは提案も見積もりもできない。Aさんは「情報が全然ないのはやはり困る。せめて機能名や帳票名を挙げた一覧表のようなものがあるだけでも，ずいぶん違うんだけど」と，ぼやくのが精一杯だ。

ケース（4）　口頭による提案依頼

　最後は口頭による提案依頼。もちろんこれはRFPではないが，メモや口頭による提案依頼を「RFP」とするケースはまだまだある。こうした場面によく出くわすというユーザー系SIのCさんは，実際にあったあきれたケースををこう振り返る。

　「ある企業では，競合他社が導入したシステムの紹介記事を指して『これと同じものを提案してくれ』と，複数社に要求していた。システム導入の目的や背景など全く分からない。憶測で提案できないので，時間をかけてヒアリングや現状調査を進めることになった」。

受注側も協力してRFPの質を高める

　みなさんの周りには，もっとひどいRFPがあるかもしれない。こうした状況が生まれるのは，声高にRFPの活用を促す側がいるのに対し，現場ではRFPをきちんと作成するスキルが追いついていないからだろう（最初からきちんと作る気がない場合は別として）。それだけに，発注側は受注側を迷わせないよう，RFPの作り方や伝え方をマスターする必要がある。

　それと同時に，受注側もRFPの“行間”を読み，RFPの質を高めるための助言をする必要がある。RFPの不備は，要件定義や設計の段階で補うこともできる。だがそれでは，RFPの質はいつまでたっても上がらない。RFPの不備は，多くのRFPの読み手でもあるベンダーのエンジニアのほうが見えるものである。

　RFPのメリットは多岐にわたる。発注側にとっては「評価の基準が明確になるので，発注先の選定がしやすくなる」「発注に対する恣意的/政治的な要素を排除するので，適正な価格でシステムを導入できる」「当初から利用部門の協力を得るので，システムの出来がよくなる」といったメリットがある。一方の受注側は「システムの目的が明確になるので，的を射た提案をしやすくなる」「要求への責任や合意事項が明確になるので，手戻りのリスクが減る」「これまで取引の無かった企業とパートナー関係を結ぶチャンスが生まれる」といったメリットがある。こうしたメリットを両者が享受するためにも，今まさに多くのエンジニアがRFPの質を高める取り組みを始める時期にきているのではないか。

　なお，日経SYSTEMSの7月号では，「RFPの作り方，伝え方」と題して，RFPを作成し，それを正しく伝えるうえでの問題点や解決策などを，現場の実例とともに紹介している。ぜひ参考にしてほしい。