「RFPって何を書いたら良いの？」という相談をいまだに受けるので、忘れないうちに、ざっとまとめておきます。以外とネットでも、実践的な説明はないらしい。本当だろうか。

そもそも RFP というのは Request For Proposal の略で、日本語にすると「提案依頼書」というらしいんだけれども、名前がバズワードっぽいのがいかんと思うわけです。RFPだとかITベンダーだとか横文字が並ぶと、みんな急に身構えて、何を書いて良いか分からなくなってしまうらしいんですが、普通に社内で稟議通すときと同じようにオリエンすれば十分だったりしますし、最もミニマムなものだと子供の「おつかいリスト」レベルで事足りたりします。

以下に記載すると良いかもしれない項目を箇条書きにしますが、すべてを網羅しなければいけないものではないと、私は考えています。むしろすべて書かないでください。制約条件が増えれば増えるほど、ベンダーからの提案の幅は狭まってしまい、「コンペしたけど、どこも代わり映えしないんだけど、結局どこが良いんですかね？」みたいな話になるし、そんな状態になってから相談されても困るんですよね、という。

RFPに記載すると良さそうな項目

このなかでマストなものと、そうでないものを切り分けて提示することが肝要。マストなものが複数ある場合、そのなかで優先順位を付けてあげるべし。

• 目的・背景
• 対象の業務と仕事の規模
• 必要な機能
• システム条件
• 利用環境
• サービスレベル（SLA）
• 検収条件
• 調達先の制約
• 予算・支払条件
• 契約・法務関連
• 納期・スケジュール
• 運用・保守要件

RFPというのは、発注側にとってはベンダーの提案をいかに引き出すかがかかっているドキュメントで、ベンダー側にとっては発注側が真に求めている価値を図り、提案内容を研ぎすますための材料になるドキュメントであるべきだと思っています。

という点から、個人的には目的と背景が一番重要だと思っていて、なるべくここを丁寧に仕上げて欲しいと思っています。提案の「向こう側」をすり合わせることで、クォリティが変わります。経験則として。

余談ですが、私はまともなRFPをもらったことがありません。やりたいことの方向性だけは決まっていて、あとは予算と納期がかろうじて設定されているのみ。それがA4用紙に５行くらい、申し訳なさそうに書いてある紙だけを渡されて、そこからスタートするみたいな話ばっかりでした。私が中小企業向けのソリューションばっかり担当だったのもあると思いますが。仕方ないので、上記の項目をヒアリングして補っていました。つまり、上記リストは、最初に先方に出してもらっていたらラクできたなーという視点で考えたものです。

上記の RFP に記載すべき目次リストは、システム開発におけるアイテムではあるものの、少しカスタマイズすれば、他用途にもそのまま使えると思います。たとえば、フワッとしがちな、デザイン系の発注に効力を発揮したりします。

ツッコミ大歓迎です。抜け漏れ、教えてください。

関連記事

SIer が業績悪化しているのに何も変わらない