相見積もりは有効な手段か?

IT導入において、「提案を受けたが見積金額が妥当かどうか分からない」というのはよく聞く話です。

妥当かどうかわからないが相見積もりを取り、極端に差異がなければ「まずまず妥当なところだろう」と判断しているケースが多いようです。

では、相見積もりというのは見積金額を評価するために有効な手段なのでしょうか?

見積が有効なケースとは

機械や道具などの設備購入であれば、購入する明細がはっきりしているので、相見積もりというのは有効な手段です。

この点から考えると、パソコンやパッケージソフトなどの最初から価格が決まっているものを購入する場合において相見積もりは有効と言えます。

しかし、自社独自のソフトウェアの開発を依頼する場合は話が違ってきます。

ソフトウェアの開発を依頼する場合は依頼する企業がソフトウェアの仕様を提示しますが、この仕様の解釈によって開発する内容が異なり、それが開発費用を左右する要因になってくるからです。

このため、見積金額が高いといっても、高くなった原因が「仕様を過大に読み取った場合」、「過去の経験から要求された仕様にはリスクが存在することを認識している場合」等もあり、見積金額が高すぎてもそれが不適切ではないこともあります。

適正な価格を引き出すためには

相見積もりによってITベンダーを評価するには、どのITベンダーが読んでも同じように解釈できる仕様書を作成することが求められます。

しかし、ITベンダーの中には専門的な知識を持ち、提案を求めたこと以上のシステムを構築できるベンダーも存在します。このようなケースでは、誤解のない仕様書を提示するよりも、各ITベンダーのノウハウを引き出すような、ある程度幅を持たせた仕様書を提示した方が効果的と言えます。

このような場合は提案金額が高いかどうかよりも、費用他効果が優れているかが評価のポイントになります。

提案を依頼する企業としては、どちらのパターンで提案を依頼するのか方針をはっきりさせたうえで、仕様書や提案依頼書を提示することが求められます。

失敗事例にみるRFP作成のポイント~2.社内プロジェクトの構成

RFPを作成する場合、提案依頼を行う側は社内プロジェクトを設けるのが一般的ですが、ここではIT部門のみならず、業務部門や調達部門が参画することが好ましいといわれています。

IT部門や契約調達する部門だけでなく、実際にシステムの利用・運用に関わる部門が新たなシステム導入に参画するのは好ましいことですが、多くの部門が集まりながら、その効果を享受できないケースもあります。

効果が得られないばかりか、システム化のポイントがずれてしまったり、作業が遅延したりというデメリットの方が大きくなることもあります。

多部門が集まる意義は?

RFP作成において複数部門が集まりプロジェクトを構成する意味は、情報システムに関連する多様な部門・多様な階層が抱えている課題・問題点、意見・要望を集めることにあります。

しかし、このようなプロジェクトを構成したにもかかわらずシステム稼働後に問題が出る原因としては、部門のトップは集まっているが「現場の要望が吸い上げられていないケース」や、「部門間で調整する際に適切な判断を行えなかったケース」が挙げられます。

それぞれの部門長が集まっているものの、各部門内の意見集約が不十分であるために単なる「部門長」の意見交換で終わり、最終的には「ITベンダーにお任せ」となることもあります。また、ある程度、部門の意見を持ち寄ったケースでも、プロジェクト内で適切な調整(解決策の策定)ができず、新たな情報システムに適切な機能を盛り込めなかったという事もあります。

特に、組織が大規模化するとこのようなことが発生しやすくなるので、これを回避するためには部門長の資質の問題とみるのではなく、RFP作成プロジェクトの仕組みで解決を図ることが重要です。

 

失敗事例にみるRFP作成のポイント~1.必要性の確認

情報システムの導入やシステム開発を行うにあたり、発注先のベンダー企業に対してユーザ企業から提案を依頼する文書がRFP(Request For Proposal:提案依頼書)と言われています。この文書の必要性が訴えられ徐々に浸透してきてはいるものの、実効性のあるRFPを作成するのは難しいようです。

なぜRFPが必要か

RFPとはユーザ企業からベンダー企業に対して提案を依頼するもので、そこにはシステムに求める機能や契約の条件などを記載します。

「システム構築や業務委託の場合は、どのような場合でもRFPは必要である」という意見もある一方、「専門的なことは分からないので、細かいことはベンダーを選定してから決めてもよいだろう」という意見を聞くこともあります。

まさにその通りで、私は後者の意見に賛成です。

決めなくてよいこと、後から何とでも出来ることであれば、無理にRFPに仕立て上げる必要はないのです。提案を受ける前、または、契約を締結する前に決めなければリスクが大きくなる事項や、後から変更できない事項が想定させる場合にRFPを作成すればよいのです。

RFPを必ず作成するという企業の場合、RFPのテンプレートが用意され、それをすべて満たしていなければベンダー企業に対してRFPを発行することができないルールになっている事例も見受けられます。

このため、決めなくてもよいことを無理にRFP作成段階で規定してしまったために「使わなくてもよい機能」を実装したり、「名目上は整っているが、実態として使えない機能」になっているケースも散見されます。

RFP作成の必要性を再考する

システム開発の工程では「要件定義」で業務要件・システム要件を確定します。このような工程がありながら、なぜ、RFPを作成しなければならないのでしょうか。

初めてRFPを作成する場合はそこまで考えて作られているはずなのですが、RFP発行を繰り返しているうちに「RFPを作成する」という作業自体がルーチンワークになってしまい、そのに記載する項目も助長なものが混在してくることがあります。

提案を依頼するシステムの特性によって、提案依頼する内容も項目も変わってきて当然なのですが、しっかりした企業ほどこのような状態に陥ることがあるように思います。

RFPを作成する前に、「なぜ、作成するのか」、「どのような効果を求めるのか」という事を再考することが大切です。