前回ガイド記事:どう開発依頼したらいいの?の後編です。

提案依頼書(RFP)を発行し、ITベンダーからどのようなシステムを構築するか提案していただきます。ですが、その前に準備しておくことがあります。

評価基準を作る

まず評価項目配点を決めておきます。 現場担当者や役職者など複数の人間で評価しますので、例えばある項目の配点が5点であれば◎なら5点、○なら3点、×なら0点などと点数の重み付けの調整をしておきます。

打ち合わせ

これは5点、4点、3点などと得点差をあまりつけない人が出ないようにし、評価結果をはっきり出すためです。

評価項目と配点

評価項目は会社によって違いますが、例えば下記のようなものです。

実現可能性
RFP 各項目の実現度
ITベンダーの信頼度
コスト

個別に見ていきましょう。

実現可能性

優れた提案でも、構築できなければ意味がありません。技術的に実現できる内容かどうかを判断します。

ITベンダーによってはシステムエンジニアが先進的な技術に挑戦したいという気持ちから、技術的に難しいシステムを提案してくるところもあります。RFPの内容が先進的なものであれば、それでもかまいませんが、枯れた技術で構築すれば、技術的な問題でトラブルことも少なくなります。

またどれぐらいでシステムが陳腐化するか見極めも大切です。例えば以前にパソコンを使ったシステムを作成し、アプリケーションを動作させるOSがWindows98の場合、まもなくマイクロソフト社のサポートがうち切られますので(2003.6.30で打ち切り)。この後にトラブルがあった場合、色々な支障が出る可能性があります。つまり陳腐化の時期を迎えます。

いつ陳腐化するか判断は難しいですが、なるべく陳腐化する時期が遅くなるシステムが望ましいです。

RFP 各項目の実現度

実現したい要求事項をRFPに書いてITベンダーに提案を求め、出てきた提案で、実現された項目、実現されない項目をチェックします。

これは予算との兼ね合いで、たくさんのことを要求しても、それ相応の対価が無ければ実現は難しく、ITベンダー側で重要でないと判断した項目は削減してきます。

そこで最低限、実現したい項目(MUST項目)と出来れば実現したい項目(WANT項目)に分けてRFPに書いておくのも一つです。この場合、MUST項目が一つでも実現されていないと×評価を行います。

ITベンダーの信頼度

開発は長丁場になるので、その間にITベンダーが倒産するようなことがあれば大変です。財務状況などの信用情報をチェックします。

ITベンダー側の開発担当者の退職などで、スケジュールが遅れるようなこともよく発生します。そういった事態が発生した時に引継を行えるような体制か注意すべき点です。

開発プロセスがきちんと整備されているかも重要なポイントです。ISO9000シリーズを取得していたら加点するなども決めておきます。これからはCMMを取得するITベンダーも増えてきますので、レベル1なら何点、レベル2なら何点と決めておくのもよいでしょう。

ITコーディネータの資格を持つ人数や高度情報処理技術者、オラクルマスターなどのシステム構築業務に必要な資格を持っている技術者がいるかどうかもチャックします。

パッケージを使ったシステム提案の場合はパッケージメーカーとどれだけ近い関係にあるかも要チェックです。 パッケージメーカーと良好なパートナー関係にあるITベンダーであれば、パッケージそのものの変更やバグへの対応も素早くなります。

反対に関係が遠いITベンダーでは、仕様について問い合わせても返事が返るまで時間がかかったり、細かな修正に対応してもらえない等、後々、影響が出てくる場合があります。

コスト

予算内におさまっているかどうかをチェックします。 安ければよければよいというものでもありません。また構築費用だけに目を奪われず、ランニングコストがどれぐらい必要かも評価すべきです。

次は得点配点についてみていきます。