残りの全てを評価する

提案書の評価軸は主に5つに分けられます。


1. システム機能
2. 費用
3. 実績
4. プロジェクト計画
5. その他

この最後の「5.その他」では、何を評価するのでしょうか?

実は、ここには明確な評価項目はありません。考え方としては、1~4で評価対象としなかった全てです。

そのため、毎回、プロジェクトごとに変わります。背景やシステム特性を勘案し、評価項目を定めていきます。
 

その他の主な4つの評価項目

その他の評価項目で、主なものを4つ挙げます。

① 非機能要求
② 操作性・ユーザーインタフェース(非機能の一部)
③ 会社規模・与信
④ 付加価値

これらを解説していきます。
 

① 非機能要求

「非機能要求」とは、その言葉のとおり、「機能要求」以外の要求のこと。

業務的な要求は「要求機能一覧」に書いているので、主にシステムを支えるインフラ基盤、ハードウェア、ネットワークなどの「ハード面」と、そのシステム基盤の運用・サポートといった「ソフト面」を評価します。

ハード面では、例えばシステムの稼働率(1カ月にXX分の停止を許容する)、目標復旧水準(障害時のリカバリはXX時間以内)、性能目標(画面レスポンスはXX秒以内)、耐震性(データセンターのファシリティ基準)などがあります。

ソフト面では、セキュリティ対策、バックアップの仕組み、ハードウェアやソフトウェアの死活監視、問い合わせ受付方法、サポート時間帯などがあります。

これらの非機能要求は、「オンプレミス」の場合に大きく差がつきました。そのため、一昔前は「その他」項目ではなく、独立した大項目として、重視していました。

しかし、いまは「クラウド」が前提にあります。するとどうなるのでしょうか?

評価しても「差」がつかなくなってしまったのです。

なぜなら、どのベンダーもAWS、AZURE、GCPなどグローバルなクラウド基盤に乗せる提案をしてくるからです。あるプロジェクトでは、つい先日、3社ともAWSでの提案を受けたりしました。

これらのクラウド提案も、細かくみていけばそれぞれ特徴があり、違いもあります。しかし、水準としては、さほど変わりはありません。これらグローバル水準のクラウド業者は、どこか1つ突出したサービスをリリースしても、他が後から追い付き、追い越そうとするので「どんぐりの背比べ」です。

国内のクラウド基盤もその差を埋めるようにサービスを提供してきています。国内の大手ベンダーは、自前のクラウド基盤をもち、同じようなサービスを提供してきます。国内のクラウドサービスは、ハード面などはやや劣りますが、運用・保守の面で、きめ細かいサービスや完全日本語対応など、ソフト面のメリットを前面に打ち出して、対抗してきます。

その結果、あまり差がつかなくなります。

差がつかないから、評価する意味が薄れます。「評価項目」というよりは「前提」という位置づけになってしまいます。

ただし、銀行ATMや社会的インフラを担うサービスや公共サービスなどは、「サービスを止めないこと」が最優先されます。そのようなプロジェクトにおいては、非機能要求は死活問題となります。そのため「その他」に含めるのではなく、独立した大項目として、細かく評価していくべきでしょう。
 

② 操作性・ユーザーインタフェース(非機能の一部)

現場のエンドユーザーにとって、システムの操作性やユーザーインタフェースは重要な関心事です。正確にいえば、操作性も「非機能要求」の一部ですが、重要なので切り出して評価します。

非機能要求であっても、インフラや性能まわりは「情シス」が評価するのに対して、ユーザーインタフェースは「ユーザー」が評価するという違いもあります。

日常的に使う画面が「使いにくい」「手間がかかる」「処理が遅い」というのは、業務の効率性に大きく影響します。画面が「わかりにくい」「デザインがイマイチ」というのは、ユーザーのストレスにもなってしまいます。

ただ、操作性がいくら良くても機能がなければ意味がないので、「機能要求」よりは優先度が下がります。同等の機能だった場合に、最後の決め手が「操作性」ぐらいの位置づけではあります。

この操作性・ユーザーインタフェースですが、提案書で確認するには限界があります。なぜなら「静止画」だからです。

そのため、いったんは提案書の画面イメージで仮の評価をしておき、プレゼンテーションで実際のシステムデモという「動画」で確認していくことになります。

この時点では、仮評価しておき、後で評価を上書き更新していきます。
 

③ 会社規模・与信

大規模なシステムを大手のベンダーに依頼する。

このようなケースであれば、特にベンダーをどこに選定しようが問題ありません。

しかし、ニッチな業種のパッケージシステムや先進的な技術を用いたシステムなどは、ベンダーの規模が小さくなることも多い。

これらのベンダーと数ヵ月、半年、1年以上と過ごしていくことになりますが、途中で先方が倒れてしまっては、元も子もありません。

いくらユーザー側の自分たちががんばったとしても、別の次元でプロジェクトが継続できなくなってしまいます。「ベンダーが小さい」ということは、それだけでリスクがあるということです。

そのため、RFPを出したベンダーに対しては、与信チェックを行います。

本来体には小さなベンダーのみチェックすれば大丈夫ですが、念のため一律チェックする方がいいでしょう。

与信チェックを行うには、帝国データバンクや東京商工リサーチなどの信用調査会社から報告書を購入するのが確実です。

報告書には、そのベンダーの経済活動や支払い能力を「評点」として数値化されています。「定量評価」と「定性評価」を総合的に数値化しており、そういう意味では、このベンダー選定の提案評価と手法は同じです。

小さなベンダーだと、たまに信用調査を受け入れずに、評点が「予測値」となっている場合があります。そのようなベンダーは、後ろめたいことがあるのかもしれません。要注意でしょう。

信用調査の結果で、リスクが大きいと判断した場合は、追加でヒアリングしていきます。直近の財務状況やその理由を確認するなどして、慎重な判断が求められます。

ベンダーの規模が小さくなるほど、このチェックの重要性は大きくなります。
 

④ 付加価値

提案評価とは、基本的に「RFP要求に対する充足度」を評価します。

しかし、パッケージに付属している便利な機能や、ベンダーの強みをいかした提案がRFPの要求をこえて、盛り込まれてきます。

それらの提案は、過度に反応してしまうと評価の軸がぶれてしまうのでさけるべきですが、全てをスル―してしまうのももったいない。

軸がぶれない程度の配点を設けて、その中で評価していきます。

それが「付加価値」枠です。

その代表的なものが「BI」機能です。RFPで最初から要求していれば、要求機能で評価するので問題ありません。しかし、そうでない場合は、パッケージに付属しているBIなどは、「棚からぼたもち」的な魅力があります。

BIで経営に必要な分析ができるのなら、それに越したことはありません。操作性や対応可能なチャート種類などを評価していきます。

また、業界特性やシステムの目的に応じて、社員の「資格」や「免許保有数」をアピールしてくるなら、それを評価してもいいでしょう。

○○協会の理事をやっているため最新事例や最新技術に強い、なども付加価値です。グループ企業全体でそれぞれの専門家を柔軟に集められる、なども強みとしてアピールしてくることもあります。
 

細部まで評価することで説得力が生まれる

「その他」の評価は、4大評価でこぼれたものが、すべて評価対象となります。

決してウェイトが高いわけではありませんが、ベンダーの提案をあますことなく全て評価することに大きな意味があります。

きめ細かい評価結果は、それ自体に「説得力」が生まれます。

会社全体で納得のいく選定ができます。

もし、あとでプロジェクトが苦しくなったときに「誰が選んだのか?」と余計なもめ事に巻き込まれることを防ぐことにもなります。
 
 

(関連記事)
【提案評価】定量評価と定性評価をどう使いこなしていけばよいか?
【提案評価】ベンダー提案の5大評価項目とは
【提案評価その1】要求機能が最重要
【提案評価その1】要求機能のFIT率60%をどう考えるか?
【提案評価その2】費用は5年トータルで考える
【提案評価その3】実績は数と質の両方をみる
【提案評価その4】プロジェクト計画の6つの評価項目とは?

ベンダー提案評価資料の作り方(サンプル画像付き)