ユーザーを分類するな、座標として理解せよ: テンソル思考が変えるインタビュー設計

「ユーザーを理解する」と聞いたとき、私たちは何を思い浮かべるだろうか。年齢、職業、利用頻度、困っていること。こうした情報を表に並べ、平均的な人物像を作れば、顧客の姿が見えてくるように感じる。

しかし、優れたサービスが見ているのは、平均的なユーザーではない。同じ人が、状況によって別のユーザーになるという事実である。

毎週サービスを使う人でも、新しい機能には不安を覚えるかもしれない。関心は高いのに、自分には使いこなせないと思っている人もいる。逆に、関心は薄くても、使い方さえ簡単なら定着する人もいる。

この複雑さを考えるうえで、意外に有効な比喩がある。それがテンソルだ。テンソルは単なる多次元配列ではない。複数の軸に沿ってデータを配置し、軸同士の関係や、そこに適用される演算まで扱うための考え方である。

顧客理解も同じだ。ユーザーを一枚のプロフィールに押し込めるのではなく、複数の軸が交差する空間として捉える。そのとき、インタビューは単なる意見収集ではなく、ユーザー理解のテンソルを観測する行為になる。

ペルソナは便利だが、平面になりすぎる

プロダクト開発では、しばしばユーザーを「ロイヤルユーザー」「ライトユーザー」「ノンユーザー」のように分ける。購入頻度や利用頻度による分類は、施策を考えるうえで分かりやすい。誰に話を聞くべきかを決めるにも役立つ。

問題は、その分類だけでユーザーを説明した気になってしまうことだ。

たとえば、ある収納サービスを考えてみよう。頻繁に購入するロイヤルユーザーは、サービスへの関心も高く、利用方法にも自信があるとは限らない。過去に何度も利用していても、忙しい時期には手続きが面倒に感じることがある。一方、まだ利用していないノンユーザーの中には、強い関心と高い自己効力感を持つ人がいる。きっかけさえあれば、最初の利用者になる可能性が高い。

利用頻度だけを見れば、前者は重要顧客で、後者はまだ見込みの薄い人に見える。しかし、関心と自己効力感を加えると、別の構造が現れる。

ユーザーを次の二つの軸で見てみる。

• 製品関与度、興味の強さ
• サービスを使いこなせるという自己効力感

すると、同じ「ライトユーザー」でも、少なくとも異なる状態に分かれる。

1. 関心が高く、自信もある人。利用を増やす障壁は、機能不足やタイミングかもしれない。
2. 関心は高いが、自信がない人。説明、導入支援、失敗しても戻れる設計が必要になる。
3. 関心は低いが、自信はある人。価値が伝わっていないだけで、導入は容易かもしれない。
4. 関心も自信も低い人。機能を増やすより、そもそも必要性を感じる場面を設計する必要がある。

ここで重要なのは、軸を増やせばよいという話ではない。軸の交差によって、行動の意味が変わるという点である。

利用頻度という一つの数値は、結果にすぎない。その背後には、関心、能力感、時間、経験、周囲の支援、過去の失敗などがある。頻度だけを観測すると、異なる原因から生まれた同じ結果を一つにまとめてしまう。

顧客データをテンソルとして読む

数学や機械学習で、1次元のテンソルは数値の列、2次元のテンソルは表として扱える。さらに次元を増やすと、画像のように高さ、幅、色の情報を同時に表現できる。けれども、テンソルの本質は、単に情報をたくさん詰め込めることではない。

どの軸があり、軸同士がどう関係し、どの切り口で情報を取り出すかを設計できることにある。

顧客理解に置き換えると、利用頻度は一つの軸にすぎない。そこに関心度と自己効力感を加えると、ユーザーは二次元、三次元の空間に配置される。さらに利用場面、過去の経験、意思決定者、時間的余裕などを加えれば、より高次元の状態になる。

もちろん、調査票に無限の質問を追加すればよいわけではない。次元を増やしすぎると、データは豊かになるが、意思決定は鈍くなる。大切なのは、サービスの行動を変える軸だけを選ぶことだ。

たとえば、利用頻度と関心度だけでは、初回利用の障壁を説明できないかもしれない。そこに自己効力感を加えることで、「知らない」のか、「知っているが自分には無理だと思っている」のかを区別できる。二つのユーザーは、同じ未利用者でも必要とする設計がまったく違う。

前者には発見しやすいメッセージが有効だ。後者には、手順の簡略化、具体的な成功例、試しても損をしない導線が効く。

この違いを見落とすと、企業は「もっと認知を高めよう」「もっと機能を説明しよう」と、同じ施策を全員に配る。しかし、問題が関心ではなく自己効力感にあるなら、情報量を増やすほど相手を疲れさせる可能性がある。

ユーザーの問題は、情報不足ではなく、行動可能性の不足であることがある。

この視点に立つと、ユーザーインタビューの目的も変わる。意見を集めるのではなく、ユーザーがどの座標にいるのか、その座標がなぜ形成されたのかを理解するのである。

インタビューは平均を作るためではなく、状態遷移を発見するためにある

ユーザー調査でありがちな失敗は、発言を平均化することだ。「多くの人が便利だと言った」「半数が価格を気にしている」といった結論は、報告書には書きやすい。しかし、平均値はしばしば最も重要な違いを消してしまう。

本当に知りたいのは、ユーザーが現在どこにいるかだけではない。何が起きれば、別の座標へ移動するのかである。

関心が高く自己効力感が低い人が、利用に至るには何が必要か。実際の利用者に、最初に不安だったこと、途中で諦めそうになったこと、誰かに相談したか、どの瞬間に「これならできる」と思ったかを聞く。ここで得られるのは、満足度の点数ではなく、状態が変化する条件である。

反対に、ロイヤルユーザーにも「なぜ使い続けているか」だけを聞いてはいけない。使わなくなりそうだった瞬間や、別の方法に戻りかけた場面を聞くべきだ。継続は、強い愛着の結果とは限らない。単に代替手段を探す時間がないだけかもしれない。

このため、インタビュー対象者は利用頻度だけで選ばない方がよい。少なくとも、次のような組み合わせを意識すると、状態遷移が見えやすくなる。

• 利用頻度は高いが、関心が低い人
• 利用頻度は低いが、関心が高い人
• 関心は高いが、自己効力感が低い人
• 関心も自己効力感も高いのに、利用していない人
• 以前は使っていたが、現在は離れている人

最後の二つは特に重要だ。行動と心理が一致していない場所には、サービスの隠れた摩擦がある。関心が高いのに未利用なら、価格、信頼、手続き、タイミングのどれかが妨げているかもしれない。自己効力感が高いのに使わないなら、サービスが解く課題の優先順位が低い可能性がある。

このような「不一致」を探すことは、テンソルの中で値が急に変化する場所を探すことに似ている。そこには、改善の余地が密集している。

軸を増やすより、組み合わせに意味を与える

高次元で考えると、調査は複雑になる。だからこそ、すべてを数値化しようとしてはいけない。実務では、三つの操作を使い分けるとよい。

第一は、切り出すことだ。全ユーザーを一つの集団として扱わず、「関心が高く、自己効力感が低い人」のように断面を取り出す。その断面に対して、具体的なメッセージや導線を設計する。

第二は、比較することだ。同じ関心度でも、利用頻度が異なる人を比較する。同じ頻度でも、継続理由が異なる人を比較する。差分を見ると、行動を分けている条件が浮かび上がる。

第三は、変化を追うことだ。同じ人を時間の中で観察し、関心や自己効力感がどう動いたかを見る。ユーザー理解を静止画から動画へ変えるのである。

たとえば、初回利用後のユーザーに、利用前と利用後で「自分にもできる」という感覚がどう変わったかを聞く。サービスの価値が高くても、自己効力感が下がっているなら、体験には見えない負債が残っている。逆に、関心がそれほど高くなくても、自己効力感が上がれば、習慣化の入口に立っている可能性がある。

ここから、プロダクト改善の優先順位も導ける。

• 関心を高める問題なら、価値の見せ方を変える
• 自己効力感を高める問題なら、最初の成功体験を設計する
• 両方が高いのに行動しないなら、手続きや価格などの摩擦を減らす
• 利用後に関心が下がるなら、期待と実体験のずれを修正する

つまり、ユーザーセグメントは広告配信のためだけに存在するのではない。サービスが次に何を変えるべきかを決める診断図として使うのである。

良い質問は、ユーザーを分類するのではなく、自分の認識を壊す

インタビューで「このサービスに興味がありますか」「使いこなせると思いますか」と直接尋ねるだけでは、きれいな自己評価しか集まらないことがある。実際の行動と語られた意識の間には、しばしば差があるからだ。

そこで、抽象的な評価を具体的な経験に戻す。

「最後に使おうと思ったのはいつですか」 「そのとき、最初に何をしましたか」 「どの場面で止まりましたか」 「誰かに聞くという選択肢はありましたか」 「もし今日もう一度使うなら、何が変わっていれば始められますか」

こうした質問は、関心や自己効力感を直接測るだけでなく、その背後にある出来事を明らかにする。意識を尋ねることと、意識が形成された場面を尋ねることは違う。

さらに、調査者は自分の仮説を検証するだけでなく、分類軸そのものを疑う必要がある。関心度と自己効力感は有効な軸だが、あるサービスでは「他者からの承認」や「失敗したときの損失感」の方が行動を左右するかもしれない。

テンソルという考え方の価値は、最初から正しい次元を知っていることではない。観測を重ねながら、どの軸の組み合わせが現実の違いを説明するかを発見することにある。

Key Takeaways

1. ユーザーを一つの属性で分類しない 利用頻度だけでなく、関心度と自己効力感を組み合わせ、同じ行動の背後にある異なる原因を見分ける。

2. 「未利用者」を一枚岩として扱わない 無関心な人と、関心はあるが自信がない人では、必要な施策が異なる。認知施策と導入支援を混同しない。

3. 平均ではなく、不一致を探す 関心が高いのに使わない人、頻繁に使うのに推奨しない人など、意識と行動がずれる場所から摩擦を見つける。

4. インタビューでは状態の変化を聞く 「なぜ使いますか」だけでなく、「いつ使おうと思い、どこで止まり、何があれば進めたか」を尋ねる。

5. 調査結果を分類表で終わらせない 各セグメントについて、どの軸を動かせば行動が変わるのかを記述する。ユーザー理解を施策に変換するには、状態遷移の仮説が必要である。

ユーザーは属性ではなく、動く座標である

ユーザーを理解するとは、名前のついたペルソナを作ることではない。人を固定的なタイプに閉じ込めず、関心、自信、経験、状況が交差する場所として見ることだ。

テンソルは、データを多次元にするための便利な容器ではない。それは、単独の数値では見えない関係を扱うための思考法である。同じように、ユーザーインタビューの価値は、発言を大量に集めることではない。発言の背後にある軸を見つけ、軸同士の交差点で何が起きているかを理解することにある。

明日の調査で、誰かを「ロイヤルユーザー」や「ノンユーザー」と呼びたくなったら、もう一つ質問を加えてみよう。その人は、どの座標にいるのか。そして、何が起きれば別の座標へ移るのか。

優れたサービスは、ユーザーを正確に分類するサービスではない。ユーザーが望む方向へ移動できるよう、座標空間そのものを設計するサービスである。

この見方を採用すると、顧客理解は名簿作りから地図作りへ変わる。そして本当に価値があるのは、地図にユーザーを置くことではない。その人が次の一歩を踏み出せる道まで描くことなのである。