競合とは、必ずしも同じカテゴリーの他社製品とは限りません。スプレッドシートやアシスタント、あるいはすでに定着している習慣がニーズを十分に満たしていれば、新しいツールがそこに取って代わるのは困難です。競合分析は、「現状維持（何もしないこと）」も含めたそうした代替手段の全体像を理解することから始まります。

競合分析とは、ある課題に対して代替ソリューションがどのようにアプローチしているかを体系的に検証することです。下したい意思決定に応じて、ポジショニング、価格設定、機能、あるいは特定のタスクを実行する際の体験などを比較します。単に競合がリリースしたものをすべて集めるのではなく、チームが実際に行動を起こせる問いに答えを出すものでなければなりません。

機能の背景にある「体験」を比較する

機能リストを見れば、2つの製品がともにエクスポート機能を備えていることは確認できます。しかし、ユーザーがその機能を見つけられるか、設定オプションを理解できるか、出力されたファイルを実際に活用できるかまでは分かりません。エキスパートレビューを行えばそうした細部を検証できますし、競合ユーザビリティ調査を実施すれば、複数の製品でユーザーが同等のタスクに取り組む様子を観察できます。この調査アプローチについては、ニールセン・ノーマン・グループによる競合ユーザビリティ評価ガイドで詳しく解説されています。

タスクやアカウントの設定は、現実に即した条件を選びましょう。すべてが整ったデモアカウントを使うと、初期状態から使い始めた製品よりも使い勝手が良く見えてしまうことがあります。また、ツールへの慣れもパフォーマンスに影響を与えるため、参加者の利用経験を記録し、製品を体験してもらう順序を慎重に設計してください。

例えば、予約サービスの比較であれば、決済完了後に予約内容を変更するといったタスクを設定するのが適切かもしれません。最初の予約画面だけを見ていては、体験の重要な部分を見落としてしまいます。これは価格設定の比較にも同じことが言えます。単に最も安い見出し価格を見るのではなく、顧客が実際に購入する必要のあるプランやオプションで比較しましょう。

「事実（観察）」と「推測」を切り分ける

発見事項については、情報源、日付、調査条件を必ず記録しておきましょう。公開ページの情報は「その機能が宣伝されている」ことの根拠にはなりますが、その機能がどれほど安定して動作するかを証明するものではありません。アクセスが制限されて確認できない場合は、見当たらない機能を「存在しない」と決めつけるのではなく、未確認事項として明記してください。

顧客へのヒアリングも新たな視点をもたらしてくれます。受注・失注分析（Win/Loss分析）を行えば、買い手がどんな代替案をなぜ検討したのかが見えてきますし、コンテキスト調査（文脈的質問法）を行えば、一見分かりにくい回避策が日々の実際の業務にどのように組み込まれているかが分かります。こうした発見によって、比較対象そのものが見直されることもあります。

分析から得られた成果は、チームが選択肢を理解したり、検証すべき問いを見極めたりするのに役立つはずです。競合のデザインは「誰かがそれを作る決断をした」という証拠にはなりますが、それがうまく機能していることや、自社のユーザーに適していることを証明するものではありません。あるパターンを取り入れる前に、それがどのようなニーズに応えているのかを精査し、自社の解決策を検証しましょう。競合調査は、単に真似をしてロードマップを狭めるためではなく、課題に対するチームの理解を深めるために使ってこそ、最大の価値を発揮します。