SQLとLooker Studioで、インタビュー対象者を定量的に観察できるようにしてみた話
お久しぶりです。バイトルの会社でPdM/UXデザイン領域をやっている田中です。
このnoteでは、「インタビューの対象者選定を定量的に行うことで、定性調査（UXリサーチ）の精度を向上する」ためのデータに適したサマリーの作成方法と、実際に作成したダッシュボードをご紹介します。
インタビューで定性調査する前に、定量的に対象を決める仕組みを作ることで施策（企画）ディレクションの打率を高め、効果量達成までの再現性を高める助けになると考えています。
はじめに
UXリサーチの常套手段といえばユーザーインタビューですが、皆さんはインタビュー対象者の選定はどのように行っているでしょうか？
僕が所属するチーム では営業活動支援（SFA）を目的としているため、インタビュー対象は営業社員の方々です。
インタビュー対象者は営業課長の方に「こんな方いませんか〜？」と聞いて紹介してもらうことが多かったです。
この選定方法だと、課長に「インタビューで部下の方のお時間を頂きますよ」という交渉を並行して行える点でとても素晴らしいのですが、リサーチ観点では落とし穴があると言えます。
これまでの対象者選定の落とし穴
課長を指名した時点で対象者がひとつの課に絞られており、その中にヒアリングするべき属性を持ったユーザーがいない可能性がある
紹介してもらえる営業社員選定が正しいかは課長の観察眼に託されており、正しい営業社員を紹介するインセンティブもないため、対象が正しかったのか不明確
インタビューする数人の話を深く掘り下げてUX設計を行う場合、この「対象者選定の落とし穴」は施策の成功率を向上させる上で大きなボトルネックになりかねません。
UXの5段階モデルでも戦略が一番最初。
インタビュー対象が変われば戦略が変わり、
戦略が変わると、当然ですが全部変わります。
「定性調査する前に、定量的に対象を決める仕組み」を造ろう
1️⃣ ユーザーの行動量を体験構造図の粒度で分解する
施策を具体的に定義していく際、一気に全てのユーザー行動を変えるのは難しいため、まずはどの範囲のユーザー行動を改善するのか絞っていきます。
絞れたら、インタビューした結果を基に、体験構造図を描いて 「現状（AS-IS）」と「理想（TO-BE）」を整理し、体験をリプレイスするUIを作成する流れで進めるのがUXデザイン→UIデザインへ進む流れとして汎用的かと思います。
では、どんなユーザーにインタビューすることで体験構造図を作成すればいいのか。
リプレイスしようとしているユーザー体験（行動）の回数が 多い/少ない ユーザーだと思います。
どんなアプリやサービスの機能でも、ニーズがあるから実装するわけで、理想的な使用回数があります。
ゆえに、理想的な使用回数を大きく超えるユーザーは、機能に対して、こんな感想を持っているはずです。
開発当初は想定していなかった用途を見出している
機能を効果的に活用する方法を見つけ出している
機能を全く使っていないユーザーは、こんな課題を感じていたりするはずですね。
機能に不満を感じている
機能の存在を認知していない（導線や広報の問題）
いずれにせよ、有益なインタビューができるユーザーとなるので、施策への戦略を考える時点でぜひ話を聞くべき人々と言えます。
以上から、インタビューの対象者を選ぶために、これからリプレイスしそうな行動の回数に関する定量データを取ると都合がよさそうですね。
2️⃣ 行動量をユーザー単位で定量的に示す
誰にインタビューするか考えるとき、一番大切な情報は「誰が」「どの行動を」「何回したか」です。
上記のような定量調査の結果があれば、「なぜ田中さんはそんなにレビューを投稿するのか」「高橋さんがレビュー機能を使わない理由は何か」、色々なパターンが想像できると思います。
その「なぜ〇〇したのか」をインタビューで解き明かしましょう。
定量調査の方法はアンケートでも良いですが、アンケートでは一定数の 適当な回答・意図解釈の齟齬・アンケートに回答するユーザー属性による偏り が発生しますね。（僕は頻繁にアンケートの不確かさで悩んでいます…笑）
ユーザー行動をトラッキングできるデータ（各種アナリティクスや行動履歴DB）を用意し、UXデザインに必要な分だけ計測できるようにしておけたら理想的です。
弊社チーム用に作成したインタビュー相手選定用ダッシュボード
話は冒頭に戻ります。
僕が所属するチームでは営業活動支援アプリを担当しています。一般にCRMと呼ばれ、簡単に言えばスマホで営業する機能が集約された営業用アプリと言えます。
このアプリのユーザーである営業社員の行動（例：電話など）の回数を定量的に可視化したいわけです。
そこで、商談結果を保存するデータベースから、特定期間の営業行動回数をユーザー名ごとに集計するダッシュボードを作成しました。
全体像は下の画像です。
作成にはLooker Studio（旧Google Data Portal）を使用しており、データベースの中身を都度SQLを書かずとも、まとまった状態で閲覧できるようになりました。
以下のようなSQLを基に、適宜テーブルを結合して作成しています。
SELECT
user_id,
COUNT(*) AS all_cnt,
COUNT(data1) AS data1_cnt,
COUNT(data2) AS data2_cnt
/* 以下省略 */
FROM "データベース名"
GROUP BY user_idインタビュー相手選定用ダッシュボードが出来るまでのデータの流れ
アプリで発生した行動がデータベースに送られ、Google Cloudに同期されたものをLooker Studioで可視化しています。
Looker StudioではGoogle Cloud以外にも、Google Analytics や Google Spreadsheetなどのデータを取り込んで可視化出来るため、幅広いプロダクトのダッシュボードを一箇所で作成できる非常に便利なサービスです。
定量調査（アンケートやアナリティクスの取得等）が難しい場合の対処法
定量調査が無理なら、5人にユーザビリティテストをして行動パターンを調べ、その中から企画を考えるためのインタビューを行う対象者を選びましょう。
インタビューを何件やるべきか、もちろん施策の規模ごとに異なりますが、UXデザイン界隈では一般論として、ユーザビリティテストを目的としたインタビューやヒアリングであれば5件やるべきとされています。
以下は、ユーザービリティテストによる課題発見割合を示したグラフです。
これによると、時間対効果が最も良いのが5件であり、「5件のユーザビリティテストは全体の8割の意見を代表する」そうです。
インタビュアー（UXリサーチャー）の慣れなどで必要回数はもっと増えそうですが、まずは5件を目安にしてみるのが無難と言えます。
まとめ
ここまで読んでくださり、ありがとうございます。
ダッシュボードを作成してみた感想としては、インタビュー結果に客観的な説得力が加わり、企画施策を作成する上で迷う場面が減ったと感じます。
今後とも長く活用できるダッシュボードになったと思いますので、今後も適宜改修や増築を行いながより使いやすい形を見つけ、チーム全体の施策が結果に繋がりやすくしていきたいです。
ブックマークがわりにスキして頂けると嬉しいです！
次回もよろしくお願いします！
おすすめ投稿 👇