ベンダー評価とは

規律ある評価は3つの部分で構成されます。製品を見る前に要件を定義すること、各ベンダーから比較可能な根拠を収集すること、そして印象ではなく要件に対して採点することです。

順序が重要です。デモの予約から始めるチームは、最初に見た製品に要件が引きずられます。ベンダーは自社の強みを「あなたのニーズ」だと感じさせることに非常に長けています。先に要件を（できれば重み付きで）書くことが、後の比較を意味あるものにします。

コストがかかるのは比較可能な根拠の収集です。ベンダーは異なる形式で回答し、異なる単位（座席単位、月額、件数）で見積り、セキュリティ質問票への回答の深さも異なります。これを揃える作業が労力の大部分であり、同時に人間の判断を最も必要としない部分です。だからこそ自動化の対象になります。構造化されたエージェント間のやり取りは、全ベンダーに同じ形式で同じ質問をするため、最初から比較可能な回答を生み出します。

人間が担うべきこと：トレードオフの検討、ベンダーの信頼性の判断、条件交渉、そして意思決定の責任。

評価の6段階

本格的な評価は通常6つの段階を通ります。どれかを飛ばすと、後工程での手戻りとして表面化します。第1に要件定義——何ができる必要があるか、何と連携する必要があるか、何は譲れないか。第2にロングリスト——誰かが特定の製品に惚れ込む前に、妥当な候補をすべて洗い出します。第3に構造化された情報収集——RFI・RFP を出し、セキュリティ質問票と見積依頼を送るのがここです。第4にデモ——ただしベンダーのデモ台本ではなく、自社のシナリオに沿って実施します。第5に最終候補2〜3社へのPoC——自社のデータで検証します。第6に採点と、社内承認を通すための説明文書の作成です。

チームが見積りを誤りがちなのは最後の段階です。多くの組織——とりわけ稟議で関係部署を順に回す日本ではほぼ例外なく——意思決定は評価会議の場では行われません。後からその文書を読む人が決めます。成果物から判断の筋道を再構成できない評価は、分析がどれだけ優れていてもそこで止まります。

評価基準に含めるべきもの

スコアカードの項目はおおむね共通します。書き出した要件に対する機能適合性、表示ライセンス価格ではなく総所有コスト（TCO）、既存システムとの連携、セキュリティとコンプライアンスの体制、導入・移行の工数、サポート条件とエスカレーション経路、そしてベンダーの存続性——3年後もその会社が存在し、その製品に投資し続けているか。

このうち2つは慣習的に軽視されます。総所有コストは料金ページの座席単価に置き換えられがちで、導入・教育・連携開発・そして将来の乗り換えコストが抜け落ちます。移行工数は契約後に発覚します——過去データが使える形式でエクスポートできないと分かるのは、たいてい署名の後です。

自分をごまかさない採点

重み付け採点が標準です。点数を見る前に各基準へ重みを割り当て、各ベンダーを採点し、掛け合わせます。規律は「前に」という一語に尽きます。点数が出そろってから決めた重みは、すでに抱いていた選好を確実に再現し、その上に客観性を装う算術を被せるだけです。

数字に意味を持たせるには2つの習慣が要ります。各スコアの隣に根拠を残すこと——読み手が数字を信じるのではなく筋道を検証できるようにします。そして譲れない条件は、重みの大きい基準ではなく合否ゲートとして扱うこと。必須のコンプライアンス要件を満たせないベンダーは減点ではなく除外すべきです。そうしないと、他の項目の高得点が押し通してしまいます。