これまで、RFPを受けて出された提案書の評価方法について説明してきましたが、最後に、RFPに記載した内容を用いて評価する項目を2つ紹介します。

技術的な要求要件

技術面の評価は、RFPに記述した要求に則して行います。表1を用いてイントラネット用の検索エンジンを調達するケースを考えてみましょう。

表1　技術的な要求要件の採点表の例

評価は配点に対して0点か満点かで行われるのではなく、減点による得点もあり得ます。例えば、表2の「3.自然言語サーチ」の場合、「カギカッコ付き」という条件が付けば、完全に自然言語ではないけれどもまったくできないということではないので、15点となります。

技術面の評価は、できるだけ詳細に項目を分けるとよいでしょう。そうした方が「検索エンジンは異なる方法の検索機能を列挙しているか」といった評価項目よりもわかりやすいと思います。

管理面の要求要件の評価

システム構築の場合、発注側で全面的にプロジェクトを運営、推進するのではなく、取引先に一部でも委ねる場合は管理面で評価を行うことが必要となります。表2に、管理面を評価する際の採点表の例を示したので、参考にしてください。

表2　管理面の採点表の例

本連載は主に調達側、すなわち発注者側から解説してきましたが、なかには受注側の立場の方もおられるでしょう。残念ながら発注者が求めるソリューションや改善策ではなく、RFPをそのまま焼き直したような提案書を見かけることがあります。もっとも、発注側の事情もあって、そうせざるを得ないケースもあるかもしれません。

しかし、発注者が調達案件のどこに注力してRFPを作成し、提案書をどう評価しようとしているのかを理解することで、真のニーズを引き出した効果的な提案書を作成して発注者・受注者双方にとって質のよい取引が成立するのではないかと思います。

もっとも、価格が提案書を評価する際の最重要項目の1つであることは今も昔も変わりませんが、それだけでは評価が偏ってしまいます。つまり、提案書は多様な観点から評価する必要があるわけです。

自社に必要なサービス/物品を適正な価格で調達するには、まずは自社でそれらを提供できるぐらいのスキルや知識が求められます。そうでなければ他者の提案を評価して調達することは困難です。スピードがやや緩んだ感はあるものの、IT業界の技術は変化し続けています。市場動向に目を離さず、かといって流行に流されず、着実なIT基盤を築いていただきたいと願い、調達の基本原則(表3)を掲げて、この連載を終了します。

表3　調達の基本原則

『出典:システム開発ジャーナル Vol.5(2008年7月発刊)』
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは 異なる場合があります。ご了承ください。