【嘘を見抜く技術】ベンダーが持ってくる「都合のいい○×比較表」を論破する

～その表、誰が作ったんですか？～

製品選定のプレゼンで、必ずと言っていいほど出てくるスライドがあります。
そう、「競合比較表」です。

縦軸に機能一覧、横軸に競合他社（A社、B社）。
そして提案しているベンダーの列には、誇らしげにすべての項目に「青い◯（または二重丸）」が並び、競合他社の列には無慈悲な「×」や「△」が並んでいます。

私はこの表を見るたびに思います。
「そんなわけあるか」と。

世界的なシェアを持つ競合製品が、そんなに「×」だらけのポンコツなわけがありません。
この表は、そのベンダーが「自社が勝てる土俵（機能）」だけをピックアップして作った、極めて偏ったプロパガンダです。

この表を信じて製品を選定すると、導入後に必ず後悔します。
「機能はあるけど、使いにくすぎて運用に乗らない」
「×になっていた競合製品の方が、実は今の環境に合っていた」

本記事では、この歪んだ比較表を論破し、本当の実力を暴くための「嘘を見抜く技術」を伝授します。

Phase 1：その「○」の定義は何ですか？

比較表の「○（機能あり）」は、あくまで「スペックシート上にその機能が存在する」という意味でしかありません。
情シスにとって重要なのは「あるかどうか」ではなく、「現場で使えるかどうか（Usability）」です。

例えば「ログ検索機能：○」となっていたとします。
しかし実態は、「専用の構文（クエリ）を覚えないと検索できない」かもしれません。
あるいは、「検索結果が出るのに5分かかる」かもしれません。

▼ こう質問してください

「この機能の『設定画面』のスクリーンショットを見せてください」
「この機能を使って、実際にログを調査するデモ動画はありますか？」

GUI（管理画面）を見せるのを渋り、カタログスペックだけで語ろうとする場合、その「○」は「あるにはあるが、使い物にならない（実質×）」と判断すべきです。

ベンダーは権威が大好きです。
「ガートナーのマジック・クアドラントでリーダーに選ばれました！」と胸を張ります。

確かに「リーダー」であることは素晴らしいですが、それは「あなた（日本の中堅企業）にとってベストである」こととイコールではありません。

グローバルリーダー製品の多くは、大企業向けに作られています。

「リーダーかどうか」ではなく、「自社の規模（身の丈）に合っているか」で判断してください。
時には、ニッチなプレイヤーの方が、あなたの痒い所に手が届く場合があります。

相手が作った土俵（比較表）に乗るから負けるのです。
土俵は自分で作りましょう。

ベンダーのフォーマットに記入させるのではなく、こちらが用意した「ユースケース（シナリオ）」を投げつけ、それに対する回答で比較するのです。

▼ ZTR流・簡易RFP（提案依頼書）の例

シナリオ1： 「社員が誤ってフィッシングメールのリンクを踏んだ時、管理者はどの画面でそれを検知し、何クリックで端末を隔離できますか？」

シナリオ2： 「VPN障害が発生した際、ユーザーはどのような手順で代替経路に接続しますか？マニュアル不要で直感的に操作できますか？」

これに対して、「機能Aで対応可能」といった一言回答ではなく、「具体的な手順」を書かせてください。
これで初めて、製品ごとの「解像度の高い比較」が可能になります。

最後に、営業担当者の誠実さをテストする最強の質問があります。

情シス担当者

御社製品が、競合他社に比べて『負けている点（苦手なこと）』を3つ教えてください。

完璧な製品など存在しません。必ず弱点はあります。
「UIが少し古い」「レポート機能が弱い」「価格が高い」……。

信頼できるパートナーなら、これらを正直に話してくれた上で、「その代わり、検知精度は最強です」と提案してくれます。

逆に、「ありません！全てにおいて勝っています！」と答える営業担当者は、自社製品を理解していないか、あなたを騙そうとしているかのどちらかです。

「弱点」を知ることは、導入後のトラブル回避に直結します。
ネガティブな情報を隠すベンダーとは、付き合ってはいけません。

比較表は、あくまでベンダーの「広告」です。
そんな紙切れ一枚で、会社の命運を左右するセキュリティ製品を選んではいけません。

自分の目で見て（デモ）、自分の手で触って（PoC）、自分の頭で考えた（シナリオ検証）結果だけを信じてください。

嘘を見抜き、ノイズを排除し、本当に必要な「武器」を選び取る。
それもまた、参謀（情シス）の重要な任務です。

「そもそも、自社にどんな機能が必要なのか、要件定義ができない……」
そう悩む方は、製品を見る前に「設計図」を描く必要があります。

設計思想を学ぶなら：
守るべき資産（Crown Jewels）を定義し、そこから逆算して必要な機能を洗い出す。
その設計プロセスを物語で解説した
👉【物語連載】Vol.3 設計編：「なんとなく」を許さないアーキテクチャ
を読んでください。
要件を整理するなら：
Kindle書籍の特典
👉 DAAS資産棚卸しシート（Excel）
を活用し、「何を守るために、どんな道具が必要か」を可視化してください。