ユーザー調査を実施するための地味だけど効果的な取り組み

うまくハマらないユーザー調査

ユーザー調査という言葉を聞くと、どういうイメージを頭に思い浮かべますか？

数週間のインタビューと観察。実施するための入念な準備期間。数十ページにも及ぶ調査レポートなどを想像する人は少なくありません。本格的な調査が必要な場合はありますが、早く動かなければならないプロダクト開発の文脈では現実味がありません。例えば以下の理由で調査をしない（できていない）現場をたまに見かけます。

• アジャイルのような早いサイクルで成果物を作り続けるプロセスに、調査がうまくマッチしない場合がある
• 特にスクラム開発は調査・デザインとの相性が悪い場合がある
• プロセスに調査ができる人が参加していない場合がある
• 時間とお金がかかるというイメージが強すぎて手が付けられない
• 調査・プロダクト開発それぞれがもつ有益な情報が見えにくい

調査には「長くじっくり実施して、きちんとしたレポートを作る」という先入観が付きまといますが、それだけが調査の姿ではありません。『調査』というフェイズを設けるのではなく、今の開発プロセスの中でどういう調査（手法）が実践できるか考えたほうが取り組みやすくなります。

調査を取り入れるための対策

きちんとした調査をしなくても、調査ゼロより圧倒的に良いです。議論がまとまらないときの拠り所になりますし、周りから「もっと知りたい」という声が出てきます。以下は私も実践している小さな調査を始め方や、共有するための手段です。

先回りの計画を立てる

スクラム開発は早く成果物を作り上げるのに適したプロセスですが、抜本的な課題解決を考える時間をとるのが難しいです。例えば、1 週間のスプリントという短いサイクルでは、実装のためのデザイン（見た目）を作ることが最優先になります。つまり「そもそもこれはユーザーの文脈に合った情報の見せ方なのか」など根底から見直して設計する時間がありません。

スクラム開発は計画なしにいきなりスタートはありません。きちんと計画された上でスプリントという短いサイクルが区切られるので、ある程度先読みすることができます。次に来るスプリントの準備に備えて、そこで必要になるデータを事前に集めたり、ちょっとした調査をする時間を確保するようにします。

テンプレートを作る

調査は準備が重要と言われますが、そこに多くの時間を費やさなければいけなくて始められない場合があります。また、「自分がやらなければいけない」という先入観に迫られると負担が大きくなるだけでなく、周りを巻き込んだ調査の実現が遠のいてしまいます。

台本や記録方法を書き出してテンプレート化しておくと、他の方も調査が始めやすくなります。数をこなさなければ、なかなか上手になれないですし自信もつきません。調査したことがある人がリードするにしても、やり方・考え方を書き出しておけば調査をする敷居が下がっていきます。

アクセスしやすい場所で共有する

調査が遠い存在になってしまう原因は、文字通り遠いところにあるからだと思っています。PowerPoint などで作られた資料が、深い階層のフォルダのなかに眠っているのであれば見られないのも当然です。遠い存在になると、調査をする意味も薄れてきますし、ユーザーの声に触れる機会も少なくなっていきます。

Chatwork や Slack のようなコミュニケーションツールでユーザーの声を配信するような仕組みを作ったり、Google Analytics のような感覚で調査データに触れることができるサービスを使うのも手段です。また、デザインドキュメントで参照して、調査データに触れる機会を設ける場合もあります。「見ておいてください」ではなく「ココがポイントなんです」と指をさして調査のことを知ってもらうと良いでしょう。

視覚化は貪欲になる

ペルソナやカスタマージャーニーを作って、調査データに触れてもらう（身近に感じてもらう）ようにする場合があります。しかし、参考書に書かれている表現方法をそのまま使えば伝わるのかというとそうではなく、プロジェクトによって表現方法を変えるのがほとんどです。視覚化の目的も違えば、分かりやすいと感じる見た目も様々です。もちろん、まったく違う表現手段を選ぶこともあります。

何か作ってもうまく伝わらなかったということはよくあります。伝え方が悪かったのはありますが、表現方法が適していない場合も少なくありません。ペルソナにしても背景をしっかり説明したものから、ポスターのような漠然としたイメージを優先したものまで作って、受け入れられる表現を探すことがあります。ひとつ作って失敗したから諦めるのではなく、「次はこういう表現はどうだろうか」と模索してみてください。

まとめ

調査ができる環境を作るのは簡単ではないでし、組織特有の課題があります。時間はかかりますが、中長期的な視点でみるとプロダクト開発のコストカットになりますし、デザイナー・開発者も自信をもって仕事に取り組むことができます。

調査というフェイズをもたなくても、開発プロセスの中に調査ができるタイミングが幾つか隠れています。最近は調査というプロジェクトをもつことより、細く・長く調査データと向き合えるタイミングを作るのに興味があります。勢いを失わないための対策は、常に気になる存在、目に入る状態をどう設計するかにかかっていると改めて思いました。