包丁一本さらしに巻いて

カンムでマーケティングチームがやってるユーザーインタビュー

自分達はバンドルカードというプロダクトを提供している。2016/09から提供しており、おかげさまで既に230万ダウンロードを超え、今も元気に成長中のプロダクトとなっている。めちゃくちゃ当たり前なんだけどプロダクトの改善を進めていく上で、ユーザーと向き合う事の重要性はどれだけ強調してもしたりない。自分たちのような小さいチームにおいては特にだ。

ユーザーに向き合う活動の一環として、カンムでは約2ヶ月に1回ユーザーインタビューを実施している。新型コロナの影響で大変な時期だけど、前回から電話インタビューに切り替えており今後も継続していく予定だ。今回はインタビューを実施してきた中での学び、各種文献の内容から得た学びをまとめる。

前提

「ユーザーインタビュー」という言葉、様々な定義があるが、カンムが今注力しているユーザーインタビューはデプスインタビューと言われるものが近いと思う(この領域はユーザーリサーチ、1on1、ethno、その他色々呼び名があるなぁという印象)。基本的にインタビュイー1名に対してインタビュアー1〜2名(メインインタビュアー1名、議事録1名)で行っている。電話インタビューに切り替えてからも同じ布陣で継続している。

今回重点的に書くのは「インタビュー時の技術」とする。インタビューの目的設定の妙や事前調査に関してはボリューム少なめにし、各ステージ別に役に立ちそうな書籍を提示するに留める。プロダクトのステージ/種類や流派によってインタビュー設計の上流部分は異なるが、「インタビュー時の技術」に関しては各種書籍を通して読んでも比較的一貫している為、一つ記事を書けばある程度まとめれると感じたからだ。また、インタビュー時の技術は「目的設定と実施時の技術が同じくらいレバレッジが効く事がある」というおもしろポイントがあると思っている。自分たちが想定していなかった事を丁寧に見つけていく方法というか、その予期せず見つけたものを最初から目的設定に組み込んでおくのは難しいというか。そんな点も「インタビュー時の技術」を中心に書こうと思った動機となっている。

また、UI検証/改善の為のインタビューはスコープ外とする。もちろんいくらかはオーバーラップする部分もあるとは思うんだけど、そこまで深い経験は無いので語れる領域ではない。いつかは語れるようになりたいとは思う。

インタビュー設計

インタビュー設計の肝は(1)課題定義、(2)インタビュー目的設定をこの順序できっちりやる事だと思う。つまり、今解こうとしている課題は何で、その課題はどのような問いに対する回答を得られたら解決策の優先順位が付けれるのか/策にバリエーションが出せるのか、ということ。めちゃくちゃ当たり前なんだけど、目的設定だけに注力してしまうと最後に「それで?」となってしまい想定していた課題解決方向に寄与しない情報が集まってしまう。最後の最後に極大の「それで?」に出くわすとすごい脇汗がブワって出るので賢明な各位は本当に気をつけて欲しい。

大枠は課題定義と目的設定大切ですよねなんだけど、以下自分が読んだ本別に設計方針を書く。これらは自分が本を読んでて勝手に分類しているだけなので、特に正式に流派が存在するわけではない。正式ではないが、以下の3つの本はそれぞれ方針が異なっており各フェーズ別にも参考になると思う。

Talking to Humans

まだプロダクトが世に出ていない且つプロダクトの方向性が存在する場合、「リスクの高い仮説」を検証する事に重点を置いた設計。特にプロダクトがまだ世に出ていない場合は不確実性が高く、その不確実性を可能な限り素早く減らしていこうぜという方針。「統計的有意さを得るのではなく、より良い意思決定をする為にユーザー行動のパターンを見つけよう」というフレーズが何度か出てくる。

この本の中ではテクノロジーの粋を集めた人工羽毛枕を開発したKoshiとRobertaという2名の科学者が、エンジェル投資家Samanthaの指導を受けながら、自分たちのビジネスの背景にある「リスクの高い仮説」≒「間違うと事業計画が破綻する仮説」を定義し、実際に自分で枕を買う、枕を買いに来ている人にユーザーインタビューをする、自分たちの想定ターゲットユーザーにインタビューする、等のアクティビティを通して最初の仮説がtrueなのかfalseなのかを検証していくプロセスが描かれている。この「リスクの高い仮説」を洗い出すというのが設計部分にあたる。KoshiとRobertaの場合だと以下のような仮説を検証していくことになる。粒度としても最初ならこれくらいで良いなという感じがする。

  1. We believe that people care about sleep quality when making a pillow purchase decision.
  2. We believe that we can sell online directly to customers.
  3. We believe that our customers will be young urban professionals.
  4. We believe that our very first customers will be new graduates who need to outfit their apartments.
  5. We believe that we can sell our pillows at a high enough price to cover our costs.
  6. We believe that we can raise enough capital to cover investments in manufacturing.

時系列としてはリーン・スタートアップが先に出て、その具体的なインタビュー方法ってどうすれば良いのかっていうのを体系化したのがTalking to Humansらしい。なのでリーン・スタートアップを読むのも良いかもしれないが、インタビューに関してはTalking to Humansだけで良いかなと思う。(余談だけどTalking to Humansはタイトルのネームスペースが広いところも好きです)

ジョブ理論

顧客の意思決定プロセスを、その周囲のコンテクスト含めて全体的に把握し、ユーザーがサービス購入(big hire)しサービスを継続利用(little hire)してくれるまでのイベントや心理的/物理的変化を詳細に記したストーリーを描き出し、最終的にジョブという観点で既存サービスを捉えなおす、という方針。インタビュー前に課題定義や目的設定をきっちりやって、それに対する大まかな回答を得るというよりも、一連の意思決定プロセスを観察していくことによる、思いがけないインサイトの発見を主眼に置いているように思う。本の中では12ページに渡って「どのようなプロセスを経てコストコでマットレスを購入したか」という話が書かれているんだけど、購入タイミングからさかのぼって、どの様なイベントがあったから購入を検討し始めたのか、他に検討した選択肢は何なのか、その人の家庭事情、仕事状況含めて質問をし、プロセスの全体像を浮かび上がらせている。

このインタビューの章に限って言えば「課題定義」や「インタビュー目的設定」とかは出てこない。ジョブ理論自体がどのようなプロセスがイノベーションを加速させるか視点でできているので、既存のサービスの課題定義をしインタビュー目的設定をするというよりも、課題自体を捉え直す為にジョブという観点からサービスを見つめ直そう、その為にインタビューしようという方針だからだと思う。それはそれで一つの設計方針だと思う。

顧客起点マーケティング

ユーザーのカテゴリを未認知、認知未利用、離反、一般、ロイヤルに分割し、それぞれのカテゴリ間での体験の差分、認識の差分を確認し、そこから各セグメントを移動してもらう為にはどうしたら良いのかというアイディアを、インタビューを通して創出していく。インタビューの内容自体は各セグメント別に詳細なカスタマージャーニーを描こうという指針が提示されており、セグメント間を移動させるにはどうすれば良いかに注目したジョブ理論風インタビューっぽいなと思っている。想定していなような思いがけないフレーズ、認識、体験からこそ強いアイディアが作れるというポジションをとっているところもジョブ理論風味がある。

ある程度セグメントを分けられた方がやりやすい為、プロダクトリリース後しばらくしてからの方がフィットしそうだが、ロイヤル/一般/離反だけでも実体験としてはかなり学びがあるので、リリース直後くらいからでも十分実戦投入できると感じる。この設計方針はかなり強いなと思っていて、セグメント作る→各セグメント別にインタビューするというプロセスがとても汎用的に出来ているので恐らくどの現場に行っても一発目は速度重視してこれで様子を見る、というのが出来る。そこで得た学びを課題定義に活かし、次のサイクルに入るみたいな事ができるので、何をやったら良いかわからんとなっている人はとにかくこの本に書かれている事を読み込みつつ実行しつつ、参考文献を全部買って、巻末付録のExcelをイジって更にあと10回読み込んで、そして実行してみて欲しい。実行しながら読むと脳に染みます。

ここまでのまとめ

どの本も「ユーザーインタビュー」だけに絞って書いているわけではなく、あくまでプロセスの一部としてのインタビューという位置づけで書かれている。よって、それぞれの方針に沿ってユーザーインタビューが運用される。

各自自分が置かれている状況に合うと思う方針で設計し、目的に合うような質問項目を考えて欲しい。ジョブ理論風にやろうと思うと課題定義、目的設定は明確にしなくても良いのかという感じにもなるんだけど、自分は「ある程度は」課題定義と目的設定はした方が良いと思う。理由はクソシンプルで、燦然と輝くダイヤのようなユーザーインサイトはそんなサクッと見つからないからだ。世の中に溢れてる成功譚に惑わされず、泥臭く細かくでも重要な問いとそれに対する確度の高い解答を積み上げていくべきだと思う。

その「ある程度」はN1分析が前提としているセグメント別の経験/認知の差でも良いし、ビジネスが寄って立つべき重要な仮説でも良いし、データ見てたら発見した特徴的な挙動をするユーザーの心理でも良いし、エゴサで見つけた何気ないユーザーのつぶやきの深層心理でも良い。これら問いに対する答えを得ることと、ユーザーの意思決定プロセスを立体的に理解し、新しいジョブの観点でサービスを捉えていく事はコンフリクトしない。

あと顧客起点マーケティングは10回読んだ方が良い。

インタビュー技術

ここまで到達するのに時間かかってしまった。最初に参考にした書籍を紹介する。

この中で最も実践的だと思ったのは The Mom Test だ。Startup School 2019でも紹介されており、この記事自体も良かったんだけど本の内容もかなり良いので是非読んで欲しい。

以下の内容はこれら読んだ本の中に繰り返し出てくるパターン、自分が実際にインタビューする中で大切だなと思ったポイントをまとめた。これが全てかと言われるとまぁ全くそんなことは無いと思うし、むしろ「こういうポイントもあるよ」というのがあったら教えて欲しい。ユーザーインタビューフレンドが欲しい。

「教えてもらう」「あなたの行動に興味がある」という姿勢を徹底する

まずは完全に当たり前だけど、大前提としてユーザーから色んな事を教えてもらうんだという姿勢を必ず持ってインタビューに臨むこと。自分もインタビュー受けたことはあるのですが、適当にやってると伝わってしまう。可能な限り事前連絡、日程調整含めて齟齬のないよう丁寧に連絡を取り合い、当日を迎えた際はまずはお時間を取って頂きありがとうございます!から始めるのが良いと思う。

自分のプロダクトの話は必要最低限に留め、とにかく聞く

やってしまいがちなのがインタビューと称したプロダクトのピッチ。インタビュー受けてる人もこれは良い事言ってあげないとあかんかなぁという気持ちになってポジティブな事を言ってしまう圧力がかかる。新機能の調査等で「こういう機能あったらどうですか?」という質問をしてしまうと、未来の話xポジティブなフィードバックを渡したいバイアスがかかっているのでインタビュイー自身がインタビュワーもしたことがある、プロダクトを作ったことある等の経験がないと適切な情報を得るのは難しい。

最終的な解決方法(プロダクト)の話はどうしても未来の話になってしまいインタビュイー自身も自分の発言への確信度が下がるので、あくまでも過去に経験した内容からその人が持っている課題、背景について詳しくなる事を目的とするのが良いと思う。

事前に質問事項は作るが一問一答は避ける

「とにかく聞く」となるとやってしまいがちなのが、事前に作った質問項目を一問一答形式で解答してもらうインタビュー。しかし、一問一答やるだけならアンケート取れば良く、わざわざユーザーインタビューをする必要はない。インタビューのメリットは1つの回答を得て、それに対してまた質問できるところ、複数の回答を組合わせた際に浮かび上がる疑問点をその場で質問できるところなので一問一答形式だけに終始するのは避けたい。

もちろん基礎的な情報は一問一答で問題ないし、まずは簡単に回答できる内容から聞いていくのが良いと思う。ただし、回答の背景にあるコンテクスト、その時の比較対象、その前に何をしてたか、誰からどういう情報を得ていたのか、等を知る事がユーザーインタビューにおいてはより重要。

そういう情報をどうやって深掘りのしていくのが良いのか、というのは自分も最初よくわからなかった。コツは大きく3つあんなと思ってて「過去の具体的な出来事の経緯を細かく教えてもらう」「理由の深掘りは間接的にやる」「聞いた内容の理解を確認して進める」というのが結構役に立つ。順番に説明する。

過去の具体的な出来事の経緯を細かく教えてもらう

まず、未来に対する質問の回答はほぼ当てにならんと思った方が良い。「この機能があったらこのプロダクトを使いますか?」に対してのYes/Noの確度かなり低い。それよりも「この課題がマジでツライ。ツラすぎてめちゃくちゃググったんだけど今こういうワークアラウンドしかない。」とかの方が確度高い。実際に行動するコストを払ってるということはそれだけ重要だという事だから。だからまずはなるべく過去の話にフォーカスする。自分の質問の時制が常に過去形になっているかチェックするくらい意識して丁度いいと思う。

過去形にしつつもう一つ追加で意識したいのが「過去の特定の体験の話」にまでトピックを絞るという事だ。過去の話でもジェネリックな感想は言えてしまう。「確かに嫌だと思った」は過去形だけど、いつ発生した、どのような体験で、その体験に至るまでにどのような意思決定をしてきたのか、というのを深掘るには少しとっかかりが足りない。

ここで便利なのが「体験の有無」「体験の頻度」「直近の体験」の順に繰り出す一連の質問だ。例えば「豆苗を育てた事ありますか?」「どれくらいの頻度で豆苗を育てますか?」「直近で豆苗を育てたのはいつですか?」と聞いていくと直近の豆苗育成体験まで頻度を確認しながらたどり着ける。特定の1回の豆苗育成経験は、過去の豆苗育成経験一般ではなく、その時育てた豆苗はどの料理に利用したのか、どれくらい育つまで待ったのか、その時家庭内で豆苗に水をやるのは誰だったのか、その時家庭内で発生した豆苗を起点としたコミュニケーションって何かあったか、等一気に具体的に聞ける事が増える。これが豆苗育成経験一般になってしまうと「そうですね、豚肉と炒める事が多いかもしれないです」で止まってしまう。

自分たちのプロダクトの場合であれば「バンドルカードは使いすぎないから良いんですよね」というフレーズが会話の中に入ったら必ず「前回使いすぎてないな!と思った時の事を教えて下さい」「逆に前回使いすぎてしまったな、と思った時のことを教えて下さい」という質問をする。そうすることで、その人が一体どういう状態にあると「使いすぎていない」と感じるのかを深掘りできる。

事象(豆苗の育成)一般に対する感想、イメージもざっくり聞く分には良いのだけど、特定の事象(前回育てた豆苗)はやはりユーザー側も思い出しながら話してくれるので確度が高い話をしやすいし、その具体的な話の中にこそ「おぉーーなるほどぉ」というものがありがちだな、と思う。

理由の深掘りは間接的にやる

インタビューしていると「それはなぜですか?」と聞きたくなるシーンがめちゃくちゃ多い。「なぜですか?」と聞くと「うーーーん」ってなってむにゃっとした回答返ってくる事が多いと感じている。不動産購入とかになるとインパクトがデカイのでMECEに整理された選択肢と意思決定を促進する3x2の比較軸が出てくるのかもしれない。でも日常の、なんで豆苗買ったのかって結構「うーーーん」で終わる印象がある。

自分の生活を振り返りながら、色んな方のお話を聞いていると、そもそも日常の細かい意思決定にそこまでコストは割いてないというのは実感としてある。システム1で足りるならシステム1で良い。理由の説明はシステム2が担当する領域の為、システム1である程度ざっくり決めているのに理由を聞かれるとそのタイミングからシステム2が起動して説明をでっち上げてしまうなぁという気がする。大きな理由が無いと自分が思っている行動に対して理由を聞かれると、どうしても論理的に筋の通ったもの、社会的に良いとされるものが選択されやすくなるという実感がある。

しかし、その行動の中にも何某かの因果というかプロセスのパターンを探すことこそが大切だと思う。そういう見つけにくいところにこそ大企業がまだ攻めきれいない領域が存在していると思う。明確に解が存在する負なのであれば、圧倒的な物量で制圧可能なので小さいチームには分が悪い。

で、どうやって切り込むかという話なんだけど、「なぜですか?」という問いはもう少し具体的で且つ理由を直接問わない質問方法に変換できる事が多い。例えば「なんでそう思うんですか?」→「そう思うようになったきっかけはなんですか?」という変換。これは理由ではなく過去の特定事象を回答に持ってくる事でとりあえずの回答難易度を下げる方法。もちろんここで回答に出てきた具体的な事象を更に深掘りしていく。「なんでそれに決めたんですか?」→「どういうものと比較してました?」という変換。これは決定時に検討した具体的な比較対象を教えてもらうことで間接的に何が決定要因になったのか探る法方。「なんでそれをやってるんですか?」→「それができなくなると困る事ってあります?」という変換。これも最初のパターンと似ているんだけど継続している理由の説明を、なくなったら困る事の列挙に変換している。

「なんで?」を使わずに因果を深ぼる方法は奥が深く、自分もまだ研究の道半ばなんだけど、パターンをある程度覚えて少し慣れれば結構いける。可能なかぎり変換した質問を利用することでなるべくバイアスを減らした具体的な事象を聞き、それを真の理由を考えるヒントにする事でユーザーに対する理解はさらに一歩先進むと思う。

ただ、これも程度問題なので「なぜですか」を完全に禁止するものではない。本当にマジで謎だなと思ったら「それはなんでですかね〜」と聞いても良いと思う。

聞いた事の理解を確認する

3つ挙げたうちの最後のコツはコレ。あまり技術はいらないけど愚直に実行すれば明確に効果があるコスパが良いコツ。インタビューでは質問と回答のキャッチボールを繰り返して、ユーザーが語ったことを理解し、繋ぎ合わせて、プロセスやカスタマージャーニー全体としての理解を深めないといけない。理解を確認しようとする姿勢、回答内容を記憶しておき関連する質問の際に交えて話すみたいなのは信頼関係を構築する為にもポジティブに働く。

具体的には、ある程度長めの回答を受けたら「〜という事ですか?」という感じで解答してくれたことをリフレーズして確認する。これは自分の理解があっているかを確認する+相手に聞いてますよという事をちゃんと伝えるサインの役割も果たす。理解が間違っている場合、ユーザーはちゃんと指摘してくれるのでなるべくわからない状態のまま先に進まない事。

インタビューは前の質問から派生する質問を適切に繰り出す必要がある。それがインタビューの最大のメリットと言っても良い。よって、インタビュー中にユーザーに対する理解を積み上げなければいけない。なので回答の正確な理解はとても重要。わからなかったら「今の部分少し理解ができていないのでもう少し詳しくおしえてください」と言って説明してもらう癖がつくくらいでちょうどよいと思う。インタビューの終わりには意思決定プロセスとその人が置かれていた状況をそらで言えるくらい脳に刻みつけ、少しでも派生で疑問に思うことがあれば再度質問できるようになるとかなり強い。

沈黙は有効活用する

自分はまだこれ苦手なんだけど、こちらが質問した後インタビュイー側が少しの間沈黙することがある。この沈黙が気まずくて自分は助け舟みたいなのを出して間を埋めようとしてしまう癖があるんだけど、これは良くない。インタビュイーが黙ってしまうケースは大体2パターンで「思い出そうとしている」か「自分の回答をまとめている」。この際に気まずいからといってこちら側から何か発言してしまとそれに引っ張られた回答になってしまいがちだなと感じる。

沈黙は怖いのはわかるが数秒程度ならぐっとこらえて待つのが良いと思う。

インタビュー後

今回も長くなってしまった。インタビュー後も大切なポイントがいくつかあるので書く。

最初に定義した目的設定に対する進捗はあったか

これを毎回インタビュー完了後に少しでも考え、目的達成できなさそうならその後に続くインタビューに備えて質問項目を調整していく必要がある。インタビューマジで疲れる。なんか脳がずっと動いてる感じなので直後は何もやりたいくないんだけどコレだけ少し考えて完了するのは大事だなと思う。

録音をききなおし、感想戦を行う

ユーザーインタビューは基本録音をおすすめする。インタビューの内容をチームで共有したり正確さを担保したり、という部分はもちろんあるんだけど、何よりインタビュワーの感想戦をするのにも役に立つ。「あぁここめっちゃ理由聞いちゃってますわ….もう少し間接的に聞けたかもしれない……」「あ、ここ沈黙してる時に助け舟出してますね」「この質問ちょっと誘導してない?」等。インタビューは技術なので常に振り返りがあり、順次改善されるべきだと思うので是非感想戦してください。

その他

電話インタビューについて

あとコレ、前回から全部電話インタビューに切り替えた。ものの本には「対面で感じられる微妙な機微こそがユーザーインタビューのうんちゃら」という話が書いてあったりするのだけど、自分はそういうものが全くわからないので、こと自分に関しては電話でも全然問題ねぇなと思っている。むしろユーザーさんに移動時間取ってもらわなくても良いし、会社のオフィスに来れる方というバイアスも削除できるし、全然コレの方が良いんじゃね?と思っている。

Web動画会議ツール使わないのか、という話もあるんだけど、電話は誰でもすぐ使えてめちゃくちゃ安定しているので全く不満はない。電話すごい。

まとめ

自分がユーザーインタビューに向き合ってきて学んだ事を書いた。最初にも書いたけどユーザーインタビューは課題定義、目的設定と同じくらいその場のインタビュー技術が大切という意味が分かっていただけたら幸い。当時の自分と同じように「向き合うったって、どうやって向き合えば良いんだ…」と思っている人のとっかかりになれば嬉しい。ガンガン向き合って、絶対最高のプロダクトを作っていきましょう。

一緒にやりませんか

ユーザーと向き合う姿勢/技術はカンムの強みの一つとして今後もゴリゴリに磨き上げていきたいと思っている。が、いかんせん自分(achiku)の経験はまだまだ足りておらず、このプロセス自体もより良く出来る部分がたくさんあると思う。

インタビュー以外にも今は競合環境調査を3ヶ月に1度実施、ユーザーアンケートを2ヶ月に1回程度実施、定量データをSQL実行して取ってきて制作サイドとユーザーの特徴的な動きに関して議論、施策立案、みたいなことをチームでやっているのですが、コレはプロダクト作る上でめちゃくちゃおもしろいと思います。

めちゃくちゃおもしろいと思うのですが、応募あんまり無いのでチャンスです。連絡ください。リモート茶しましょう!