調達時：RFPとベンダー選定の基準作り―あいまいな基準から納得できる結論は出ない！（第3回）

RFPは、自社とベンダーの責任関係を決めるインプットになる文書

　さて、自分たちがやりたいことを実現する参考情報は前回のRFIによって集めることができました。そして、集めた情報を基にして、ロングリストからショートリストの絞り込みができています。次にやることは、自分たちが提案してほしいことを具体的な内容で資料にまとめあげ、それをショートリストに名前が残っているベンダーへ送ることです。このとき、ベンダーへ送る資料のことを提案依頼書、またはRFP(Request For Proposal)と呼びます。 　

 RFPはシステムの実装内容だけでなく、自社とベンダーの責任関係を決めるインプットになる文書であり、曖昧な表現や適切性に欠ける責任関係を記してしまえば、そのまま契約内容に跳ね返ってきます。私が知っているあるITシステム開発のプロジェクトでは、システム稼働後の責任範囲が曖昧だったために想定外の費用増をユーザー企業は強いられましたし、別のアウトソーシングプロジェクトでは、逆にユーザー企業が曖昧な契約を盾にしてベンダー側が大赤字になる程の要員追加を余儀なくされていました。

　こうした痛みをユーザー側とベンダー側の双方が経験しなくても済むには、委託範囲をお互いがよく理解していなければなりません。また、何がベンダーからユーザーへ引き継がれ、どういった体制・スケジュールの下でそれが行われるかも明確にする必要があります。

　その他、提案にあたってのルールを明記し、それらが提案依頼事項としてベンダーへ提示されているなら、あなたが期待した形でベンダーは提案することができるでしょう。 　

　結論として、RFPには次のような章構成を含めましょう。 　

　サンプルとして、ITコーディネーター協会が発行する開発と運用保守RFPを参照すると良いかと思います。ベンダーはこのフォーマットに慣れ親しんでいますから、似たような形でRFPを示すことでベンダー側の提案負荷を減らすこともできますし、検討漏れを未然に防ぐことも期待できます。

　ここからは各内容を見ていきます。