最近またRFP（提案依頼書）に関する引き合いが増えてきているように感じる。システム調達のやり方を見なおしてきちんと仕様を決め、評価ポイントを定めた上で提案を受けるというのは、これまでのなぁなぁな調達を改めて透明化する面では効果があり良いことだと思うが、そのやり方がわからないので教えて欲しいという相談も多い。

　ただこうした相談の際に勘違いをしている発注者が非常に多いので訂正しておきたいが、RFP（提案依頼書）を発行すれば必ずシステム開発コストが安くなるというのは間違いだ。提案依頼の為には要求仕様を固めてそれに対する見積もりを貰うわけだが、この要求仕様の固め方や提示の仕方によっては単にパッケージソフトを購入するよりも高くなるケースがありうる。

　一番多いのは固めた要求仕様に合致するパッケージがなくその差をカスタマイズ開発してそのコストが高額になるケースだが、他にも仕様を固める際に想定データ量を多めに見積もりすぎて身の丈にあわないシステムを購入したケース。システムの信頼性やBCPの項目で、システムコストに疎い経営層からの「絶対に落ちないシステムにしろ！」「システムが止まっても業務に差し障りがないように」という安易な発言をそのままうけて要求仕様としてしまい馬鹿げた品質のシステム提案を受けるケースなどをよく見る。
　もちろんこうした提案を受けてそのまま高額なシステムを購入するのは稀だが、たいてい再提案や再見積もりになって無駄な時間を費やしたり途中に何度も提示仕様を変更したために全体のつじつまが合わなくなる、あるいは実は初期の段階で落としてしまった提案が実は最適なことにあとから気づいたが戻せなかったなど最終的にひどい調達になることは多い。

　こういう失敗をしないためにはやはり専門家のアドバイスを受けるのが良いのだが、事情によってそれが無理なときはせめて提案依頼には以下のいくつかのアプローチの違いがあってそれぞれで依頼内容が異なることに注意してRFP（提案依頼書）を書くと良い。

　まずひとつめとして、業務にパッケージシステムを合わせるのかパッケージに業務を合わせるのかで仕様の書き方が異なることを頭に入れたほうが良い。前者の場合は実現する必要のある機能についてはできるだけ仕様を細かく記載する必要があるし、その他にも欲しい機能やあれば良い機能についても記載することもある。実現できるレベルに差が出そうなときは達成レベルなどを提示しても良いだろう。
　これに対して後者の場合は必須の機能を書き出してその有無（あるいは実現レベル）のチェックで評価を実施する。あとは基本的には価格での比較だ。必須機能以外の機能に目を奪われるとコスト増や無駄なカスタマイズを招く。

　ちなみに提案依頼のアプローチにはもう一つ、最も安いものを探すアプローチと最も良いものを探すアプローチがある。前者の場合仕様を詳細に提示して最も安いものを選ぶのに対し後者の場合は予め上限金額もベンダーに提示しそのなかで最も内容の良いものを選ぶのだが、当然これによってもRFP（提案依頼書）の書き方は異なってくる。

　なにより一番大事なのは、提案依頼から提案選考、提案先決定までの一連の流れの中で今回の調達はどういうコンセプトでどんなアプローチで行うかを一貫して行うことだ。調達の始めにこのあたりを良く考えてきちんと決めて置かないでぐだぐだになる調達のいかに多いことか・・

===当ブログ過去の関連エントリー

• RFIとRFPの違い
• 「提案しろ」という台詞を逃げに使うのは良くない
• 提案力と呼ばずに適用力と呼べばどうか
• 要件は“現行と同等”です って・・・

» 続きを読む