データ分析とインタビューは組み合わせてこそなんぼである

デザイン思考あるいはデザインリサーチについてよく誤解されがちなことのひとつに「デザイン思考やデザインリサーチでは質的調査のみに取り組む」と思われている事があります。デザインリサーチの目的は機会探索と仮説検証であるということは以前、下記のnoteで説明したとおりですが、手法については必ずしも質的調査に限るものではありません。

デザインリサーチャが質的調査を大切にするのは間違いありませんが、必ずしも質的調査のみを行うわけではなく、リサーチの目的に応じて柔軟にリサーチプロセスを設計します。そしてひとつの手法だけでリサーチが完結することは稀でしょう。デザインリサーチの手法には様々なものがありますが、この手法だけを実施すればどのようなケースであっても対応できると言った事はほとんどないため、多くの場合はプロジェクトのゴールやフェーズに応じていくつかの手法を組み合わリサーチを遂行します。そしてその際には質的調査、量的調査の両方を組み合わせる事が一般的です。

例えばあるプロダクトの持つ機能Aについて今後の方向性を検討する際のことを考えてみましょう。ログデータを見るとほとんど使われていないことがわかったとします。この機能についてチームで話し合いの機会を持ったところ「使われてない機能をメンテナンスするのはコストが掛かるし、いっその事削除してしまってはどうか？」という声が上がる一方で「この機能はユーザーにとって有益であるが認知が足りてないために使われてないだけである」という声もありました。

おそらく、勘の良い方であればお気づきだと思うのですが、ログデータからでは、どちらの意見が正しいのかを判断する事はできません。似た状況はプロダクトを開発・運用する中で頻繁に遭遇します。機能Aの企画段階からあらかじめ懸念を持っていたのであれば、これらをログデータから判別できるようにUIをデザインする場合もありますが、実際にはリリース後の運用フェーズで新たに検証したくなる場合のほうが多いでしょう。

上記シチュエーションで取りえるソリューションは色々あります。例えば、機能の認知度合や必要性についてオンラインでサーベイを行うこともできますし、ユーザーテストを行いユーザーがプロダクトを使用する様子を観察したり、あるいは使用後にインタビューを行う方法も考えられます。オンラインサーベイでは、多くのユーザーの声を簡単に集めることができる一方で個別のユーザーの行動まで細かく知ることはできません。ユーザーテストの場合はどうしてもNが小さくなってしまいますが、各ユーザーの行動を細かく知ることができます。どのような状況でどのようにプロダクトを使っているためにこの機能の存在に気がついた/あるいは気が付かなかったなど。

別の例として、質的調査で得られた知見がどの程度一般的なのかを検証したいケースも存在するでしょう。例えば、ユーザテストを行った際に、ある画面で操作ミスをするユーザーの存在に気がついたとします。

この操作ミスについて、そのユーザーがたまたまそういった操作をしてしまったのか、あるいは多くのユーザーが同じような操作をしてしまっているのかを知るためには、ログデータの分析が有効であることは述べるまでもないでしょう。最近のプロダクトであればAWS Elastice Searchにログデータを格納している事も多いでしょうから、検索で引っ張ってきても良いですし、S3からログデータをダウンロードしてきて、pythonなどで必要なデータを抽出しても良いです。こうすることで、得られた仮説がどの程度妥当性があるのかを検討する事ができます。もちろん状況によっては質的調査で得られた知見に対して各種検定手法を用いて説明することもできなくはないでしょうが、可能であるならログデータに語らせたほうが説得力を持つのではないかと思います。

このように質的調査、量的調査はどちらが良い悪いというものではありません。デザインリサーチャはそれぞれの長所短所を理解したうえで、柔軟に組み合わせることによって価値あるインサイトとし、プロダクト改善に取り組む必要があります。

とはいえ実際問題として、自分でコードを書いてデータ分析までできるデザインリサーチャは多くはないでしょうから、プロダクト開発と平行してデザインリサーチに取り組むためにはエンジニアとデザインリサーチャが協働してリサーチに取り組む必要があります。理想としては開発スプリントの中にリサーチプロセスを埋め込む事かもしれませんが、それが難しい場合エンジニアのポジションや、タスク設定などで工夫が必要になるかもしれません。