RFPでは不十分?

んなRFPですが、例え完璧なRFPを作成したとしてもまだまだ多くのリスクを含んでいます。
なぜなら、一般的なRFPは概要のレベルであり、システムへの要件については圧倒的に情報量が不足しているからです。

パソコン、カーナビ、車や住宅に至るまで、あらゆるものについて、購入してから「こんなはずでは...」と思った事はありませんか?

このような問題の多くは「自分がそれ(購入対象)をどのように活用することになるのか」の想像力不足が原因です。利用シーンのイメージ不足により製品仕様のチェックが甘くなってしまうのです。一度、過去に起こった失敗購入を思い出し、その原因を考えてみて下さい。


ここは重要な点なので分かりやすい例を書きますが、たとえば住宅を建てる際に

「土地は50坪、2階建てで駐車場が1つあって、4LDKの注文住宅を建てて欲しいので提案してください」

というレベルの提案依頼(システムの世界で言えばRFP)を建築業者に伝えたとするとどうでしょう?

建築業者としては、この程度の情報で図面まで起こしても無駄になる可能性がありますので、カタログを数パターン用意するくらいが関の山です。
このレベルのやりとりで業者を決定し、「このカタログと同じような家を建ててください」と言える人はいるでしょうか?
答えは明らかに、NOです。
本来は家族構成からはじまり、自分達の理想の生活をイメージして業者に相談する必要があるでしょう。
しかし、驚くことにシステム業界で行われているRFPによるベンダー選定・発注は簡単な要望に対してカタログと見積を入手し業者を決めている程度のものなのです。

当社を設立した目的は、このいい加減なやりとりで不幸になっている発注者と開発者が本当に多く、なんとかしたいと思ったからです!

RFPは本来「システムの要求を伝えるもの」というよりは、あくまで「ベンダーを選定するためのもの」です。
にもかかわらずこの段階で製造の契約までしてしまうケースが多々あるのが現状です。

繰り返し言いますが、RFPと提案書のやり取りだけでは明らかに情報量が不足しています。
一般的な取引の感覚では決して契約して良いレベルではありません。RFPと提案書を交換した段階での契約は避けて下さい。

契約をすべき正しい段階は「要件定義(及び要求定義)」と呼ばれる、もう一段階細かく約束内容を決定する段階を置いてからです(次々項で説明)。

要件定義 RFP