作る前の調査

ラクス Advent Calendar 2018の12日目です。箸休めとして、コードを書かない系の記事です。普段はUIデザイナーやスクラムのPOをやっています。

デザイン開発に入る前のリサーチについて、ここに書いてあることはだいたい本を読んで調べたり、試行錯誤したり、いろんなスライドを探れば書いてあることが多いですが、よく考えていることを忙しい人のためにザクッとメモしてみました。

作るものが決まっていない中で、何を確認するか

さて、何からヒアリングしよう。何をヒアリングするか？をきちんと整理しておくのが大事。
課題を特定する？まずはユーザーの行動を理解する？
検証？アンケートよりも直接ヒアリングしたほうが良い？

確認したいことを事前に整理しておくようなフェーズでのヒアリングなのか、
まずは課題を知りたい、というフェーズなのかによって聞き方も違ってきます。

何かを作ったり計画するときに、「１.調査　→　2.分析　→　3.つくる　→　4.検証　」の基本的な流れを意識することが大事。今回の話は、1.理解のフェーズ。

デザインのダブルダイヤモンドでいうところのDiscoverのフェーズ。理解よりもまずは調査、調査、調査。
課題を特定するためには定性調査と定量調査、両方をしっかり行うことが必要だけど、なにもないところからスタートする場合はユーザーの実態の調査が不可欠。
今回は主にtoB向けサービスを作る場合の、検討フェーズでの定性調査の話をしたいと思います。

---

1.大前提

ユーザーにヒアリングできる状態をまずは作る。ユーザーを見つける。
ユーザーがいない場合は課題があるかわからないのでとにかく見つける。

2.準備について

工数上の都合、一回のMTGで済ませないといけない場合が多いのがツライけど、できればまとめてやるのではなく個別に、段階的にMTGをする。複数人でグループインタビューをすると一人の意見に流されることが多い。
事前にヒアリング項目を整理しておく。
- 話しやすくなるように飴ちゃんでも用意しておく。
- 笑顔で話す。真顔でグイグイ来られると、聞かれる方はつらい。
- 確認したいことを明確にしておく。後でチームに展開できるような情報が集められるかが重要。

3.ユーザーの困っていることを見つける

まずは利用状況、普段の行動を確認することがなにより大事。

• どんな感情が起きているか
• 問題が起こったときにどうやって回避するか
• こういうものがあったら便利そう、ということは考えない、聞かない
• 事細かく、具体的に行動を聞く。または再現・実行してもらう。

基本は、現状の業務の内容をヒアリング。
ホワイトボードや模造紙、コピー用紙等に可視化しながら、時間軸、気にしていること、等をとにかく書き出して行くと、聞かれている方も思い出しやすくなる。

「○○のときの状況を細かく教えてください」
「朝、出社してから帰るまでの流れを教えてください」
というくらいのざっくり質問でもコチラが知らないこと、気がついていないことをたくさん知ることができる。
逆に、仮説と質問項目がきちんと用意されている状態だと、新たな発見がなにもないまま時間が過ぎてしまう場合もあるので注意。

インタビュー時は常に、確証バイアスに注意。ここは、批判的な思考で第三者がチェックすると良いかも。こうすれば防げる、というのはなかなか難しい。

4.ヒアリング内容の記録と分析

ヒアリングの場ではできるだけ聞くことに徹して、あとで分解して整理するのが良い。

• ポストイットに書きだしてみる（ただし時間がかかるのと、場所が確保しづらいのでけっこう難しい）
• 面倒なら、まずはエクセルに発言を１行ずつ分けて記録
• １行に１発言。内容が少しでも変わった場合は別の行に書く。

ということはつまり、一人でインタビュー、ヒアリングをするのは避けたほうが良い。
記帳役がいるとすごく楽。録音しても良いが聞き返す時間がない場合が多い（涙）。

5.聞き手の感想は記入せず、できるだけ実際に発言した内容そのままを記録する

デザイナーやエンジニアがヒアリングする場合、作ることを想定して聞いてしまうのでつい、「発言に対する要約された回答」を記入してしまう。それだと後で整理するときに困るので避ける。「つまりこういうこと」は、後で考える。

できるだけ「発言そのもの」を記録しておく。
インタビューはここでおしまい。
あとは自分の席にもどって発言内容を整理する。

6.記録した言葉を評価する。

• ポジティブかネガティブか
• 「課題」か「良い点」か
• 求めている価値は何か？　一番重要なのはコレ。

ひととおり業務を確認したあとで、本当に求めているのはどういう状態？というのを整理する。
ヒアリングしながら確認するよりも、あとで整理したほうが良い。

ユーザーがあれこれ言うけど本当かどうかわからない、作ってみたけどコレジャナイと言われた、みたいな例をよく聞くが、そういう場合はここをすっ飛ばしている場合が多い。
会社として、チームとしてどういう価値を提供するのか？はビジネス上のメリット・デメリットも含むのでコチラが総合的に判断して決めないといけない。
調査やヒアリングに振り回されがちなチームはこのあたりの整理にじっくり時間をかけてみるのが吉。

できればKAカード作る。面倒、時間が無い、として作れない場合でも、同等の内容を整理する。
※KAカードについてはこちらの記事中を参照

発言から作るべき機能をそのまま考えるのではなく、「それってどんな価値？」「それって何が問題？」と整理することが必須。
書き出したら次のステップへ。

7.分類、グループ化して課題の全体像を整理

書き出した情報をグループ化して整理する。

• 記録した言葉を分解して、価値、課題をグルーピングする。
• グルーピングした情報に優先度をつける。

ここまで整理すると、バリュープロポジションマップが作れるようになっているはず。
（チーム内で共通認識がとれているならわざわざ作らなくても良い）

価値を抽出して優先度・重要度をつけて、そこからしっかりと解決策を考え出していく。

分析の勘所

本来は分析と分類、優先度づけは複数人で行うのが理想だが、開発の都合上一人でやる場合もあるはず。
そういうときに、結論に対して異論が出たときのことを考えると思考の経緯は残しておいたほうが良いし、分解して整理することで全体の印象ではなく、事実に基づいた結論が導き出しやすくなる。

なれるまでは価値を書き出してみるのが難しいと感じるが、駄目でも良いのでとりあえず書き出す。
それをきっかけにして周りの優秀な人たちがちゃんと突っ込んでくれる。
駄目でも良いのでとにかく分析して議論。

8.抽出された仮説を補う情報を集める

価値を抽出して、実現すると良さそうなものが浮かび上がってきたらそれらを並べて
重要なものをプロダクトバックログでも、RFPでも、とにかく機能に落とし込む。
優先度が整理されていることが重要。

その上で、定性調査だけでは理解できないことを他の方法で穴埋め。

• 定量調査もする
• 競合調査もする

アンチパターン

その場で「それってこういうことですか？」と確認

やり方としてはシンプルだが、けっこう失敗することが多い。ちなみに自分はよく言ってしまいます。
こちらから「それってこういうことですか？」と確認すると、半分くらいあっていたら「はい」と答えてしまう。
「それはなんのためにやるのですか？」みたいに聞き直す。
わかっているつもりでも、想像で判断しない。

---

手法に惑わされたり、どうしよう？と悩みまくるより、まずは自分たちの理解が足りているか？を軸にしてしっかりとユーザーの理解を進めましょう。

という感じでまとまりのない文章ですが、調査時に考えることを書き出してみました。
誰かの参考になれば幸いです。