『今』、ITプロジェクトを成功させたい

と思っている人の為の Webインテグレーター細川です。 

発注側のみなさんは、開発会社などにつくってほしいものを依頼する時、どうしていますか？

いわゆるRFP(提案依頼書)を自分たちで作成して、渡していますか？

ITの受託業界において、プロジェクトが失敗する要因の1つに、
『RFPをちゃんとつくってないので、「つくりたいもの」が受託側に伝わっていない』
というのがあります。

RFPには、業界標準のフォーマットみたいなものが存在しないので、企業によってその内容は様々です。

何十ページのRFPもあれば、 1枚っぺらのRFPもあったります。
何十ページのRFPさえあればプロジェクトが成功するか、といえばそういうわけでもなさそうです。 

ではこのRFP、いったい何のためにつくるのでしょうか？

RFPは提案依頼書なので、発注企業が受託側に提案してもらうための資料であることは明白です。

当然そこには見積りも発生します。

そして、ほとんどが「請負契約」を前提にしています。

請負を前提に提案してもらうわけですから、当然「完成品」を定義している必要があります。

というわけで、RFPとは、

「完成品を定義した資料」

というわけです。

完成品が定義されているので、受託側はその完成品をどのように開発するか、見積りとセットで提案する、というわけですね。

・・・・・

ITの受託業界がこのようなRFPを前提にしていたら、

きっと失敗するプロジェクトはないでしょうね(笑)

実際には、RFPが「完成品を定義したもの」であることはほとんどありません。

一部には、

「発注側がRFPを作成するスキルを持っていないから、そもそもプロジェクトが失敗するのだ」

という議論もあることにはあります。

が、果たして本当にそうでしょうか？

僕は、

「日本の発注側企業にRFPを作成するスキルがない」

のではなく、

そもそも

「完成品を定義したRFPなんて誰にもつくれない」

んだと思っています。

既に存在する業務を細かいレベルでプロセス化できる、

とか、

一度開発したシステムの完全な焼き直し、

とかであれば、完成品を定義したRFPを作成することもできるでしょう。

しかし、新規事業や新サービス、既存サービスのリニューアルなど、特にコンシューマー(一般消費者)向けのWebシステムにおいて、

未来を予測してモノをつくる必要があるビジネスにおいては、

「完成品を定義」することなんて不可能なんです。

だから、「ちゃんとしたRFP(＝完成品を定義したRFP)」をつくるのではなく、どのようなビジネス(サービス)を提供したいのかを言語化して、数枚でもいいので資料化して受託側に渡す。

当然、それは「完成品を定義」したものではないので、請負契約を前提とした(見積りをセットにした)提案を求めるのではなく、自分たち(発注側企業)が目指しているビジネス(サービス)を、 受託企業がちゃんと理解できるように伝えて、それを受託企業がどのように実現してくれるかを提案してもらえばよいのです。