カナリーでは、不確実性の高い機能を精度高くリリースしていくために「リサーチスプリント」という探索サイクルを回しています。
これは、何か具体的な施策案があって行うリサーチではなく、そもそも事業として何をすべきか？を判断しやすくするために、1週間で事業判断につながる問いに対してリサーチを行う取り組みです。
私たちは、ユーザーの声をプロダクトづくりに反映していくことができなければ、本当の意味で求められるtoCプロダクトをつくることは難しいだろうと考えています。
そのために、事業の根幹的な意思決定から、ユーザーの声を活用できるようにしていく仕組みがリサーチスプリントです。今回は具体的にこの仕組みの内容をまとめてみます。
私たちが運営する、不動産情報アプリ「カナリー(CANARY)」は、非常に多くのユーザーが活用してくれているtoC向けのアプリです。
カナリーは多くの方に活用されるようになってきていて、これからさらにサービスとしての価値の拡大に取り組んでいくことが必要な事業フェーズです。
そのため、開発チーム全体で施策数を増やしていきたいなと思っていたのですが、実際は施策を出せる人が限られてしまっている現状がありました。
カナリーのデザイナーチームでは、その原因はユーザーの声がオープンになっていないことにあるのではないかと考えていました。
toCサービスによくある状況かと思いますが、当時、カナリーの運営はユーザーとの接点をあまり持てていませんでした。アプリストアのレビューなどはもちろん全て目を通していますが、レビューを書いてくれる方はユーザーの中でも限定的です。
プロダクトマネージャーは、2ヶ月に1度ほど数名のユーザーに話を聞きに行っていましたが、それも「気になったら聞きに行く」くらいの不定期のアクションです。
さらに、その時のインタビュー動画や、議事録は残っているものの、他のmtgの議事録の中に埋もれていってしまう、いわば「使いきりのリサーチ」になっており、ユーザーの声を引用しづらい状況となっていました。
結果として、開発チームとしてユーザーの声は重要だという認識はもちろんあるものの、施策の意思決定などにおいては主観で会話されているような場面が多く見られていました。メンバーから施策案が出てくることもあまり起こりません。
その問題の解決として、まずはプロダクトマネージャーとデザイナーの間で、ユーザーの声を頻度高く収集しつつ、事業の意思決定に活用されている状態を目指して、仕組みづくりに取り組みはじめました。
最終的には、開発チーム全体でユーザーの声を活用している状態をつくることを目指します。
そのためには「ユーザーの声を活用することで、良いことが起こる」という学習を組織にしてもらう必要があります。
ひとたび、ユーザーの声を集めることで事業がより推進されることが組織に伝われば、各所でユーザーの声を集めたいという動きが起こり出します。そのための最初のアクションをどこから始めるのかを考えていました。
そこで運用し始めたのが「リサーチスプリント」です。
これは、プロダクトマネージャーと一緒に定めた事業的な関心ごと (イシュー) に対して、1週間でデザイナーがインタビューをもとにインサイトを抽出してくるサイクルです。
リサーチスプリントは、3つのステップに分解して実施しています。
- イシューの決定
- 事業的な悩みや困りごとをプロダクトマネージャーと一緒に抽出し、このスプリントで調査するべき項目を決める
- インタビューからインサイトを抽出
- イシューに対して、適切な対象にインタビューを実施しインサイトをまとめる
- イシューに対してのリサーチ結果を共有
- イシューを前に進められるようなインサイトをまとめて、プロダクトマネージャーに共有する
この取り組みは「実施決定している機能の根拠づけ」ではなく「事業的な判断を促す」ことを目的としています。
事業判断のために知るべきことを明確にし、そこに必要なインサイトを集めてきて、判断を促していけるようにする。これがリサーチスプリントで行っていることです。
情報の扱い方としては「イシューデータベース」「リサーチデータベース」「インタビューデータベース」の3つのデータベースを用意して、優先度の高いイシューから毎週リサーチ項目を設定し、そこに向けて各種リサーチを行い、イシューへの答えを出していくことを繰り返します。
詳しくそれぞれのステップの運用方法についてまとめます。
まず最初のステップは「イシューの決定」です。
毎週、プロダクトマネージャーとデザイナーで「イシュー検討mtg」というミーティングを行い、事業的に気になることや、調査すると良さそうだと思っていることを洗い出し、Notionのデータベースにイシューリストとして蓄積しています。
例えば「上京のために引っ越す人に対する顧客体験戦略」という事業的な戦略に対して、「上京のために引っ越す人の現状のお部屋探しの流れとは？」「土地勘がない人のお部屋探しにはどんな課題があるのか？」といった不明確な点を洗い出しています。
イシューについて会話することでプロダクトマネージャーとデザイナー間の脳内をすり合わせながら、動機的に優先度を決め、今週リサーチすべき項目を決定します。
次のステップでは「1週間でインサイト抽出」を行います。
今スプリントで取り組むイシューに対して、適切な調査対象を決めてリサーチを実施します。適切な情報が集まるのであればインタビューでもデスクトップリサーチでも良く、あくまでイシューを前に進める「判断材料」が集まることが重要だと考えています。
インタビュアーを集める方法としては、現在はuniiリサーチを使っています。(これも、イシューに対して適切な対象が集まるチャネルであれば、集め方は何でも良いと考えています。)
一つひとつのインタビュー情報は、インサイト・サマリー・発話記録の3項目に分けて整理・蓄積します。これらを組み合わせて分析を行い、最終的なインサイトとしてまとめてプロダクトマネージャーに共有します。
全てのインタビュー情報は、一つのデータベースで管理しています。他のmtgの議事録などと混ざらないので、もし今後インタビュー自体の生データを見返したい時があれば掘り起こしやすくなっています。
スプリントの最後に「イシューに対するリサーチ結果を共有」するステップを設けます。
リサーチデータベースのリサーチ項目に対して、リサーチ結果をまとめていきます。まとめている情報は「インサイト」「ネクストアクション」の2つです。
ここで、この期間で見つかったすべてのインサイトを書き込むことはしません。あくまでイシューを進めることが一番重要なので、イシューに対して有効なインサイトだけ整理してまとめておきます。それ以外のインサイトは別の場所で整理しています。
意思決定を促すことが大事なので、場合によっては、インサイトに加えて、施策案のプロトタイプを合わせて共有する場合もあります。
これを、プロダクトマネージャーとの週1の「イシュー検討mtg」に持ち込み、ディスカッションを行います。結果として、もう少し調査したい項目が明確になり、イシューを細かくした上で、追加で調査が行われる場合もあります。
このようなフローがリサーチスプリントの全貌です。
このサイクルを回していった結果、デザイナーとプロダクトマネージャーの間で、インサイトを中心に会話することが自然と起こるようになりました。プロダクトマネージャーからも「戦略・機能案に対して、やるやらないの判断がしやすくなった」ということを言ってもらえています。
実際に、リサーチスプリントをもとに貯まったインサイトは「37つ」も生まれていて、新しく「8つ」の施策が走り出しています。
また、組織全体としても、ユーザーの声を事業に活用していく土壌が整いつつあります。
例えば、以前はインタビューも1回ずつ稟議をかける必要がありましたが、リサーチスプリントを回し始めるタイミングで、月ごとのリサーチ予算がすでに確保できている状態になっています。
開発メンバーもインタビューに同席するようになったり、施策推進のためにはユーザーの声の活用が必要だという理解が少しずつ普及しています。
これから不確実性の高い新たな価値追加に取り組んでいくことが増えるだろうカナリーで、このようにユーザーの声をベースに意思決定しようという文化が醸成されていることは、ポジティブな状況だと思っています。
今回のような取り組みの先には「ユーザーと共創しながらプロダクトをつくれている状態」があるだろうと考えています。
toCプロダクトであるカナリーを成功させるには、ユーザーの声を取り入れる必要があります。競合との機能差を埋めていくような開発ももちろん重要ですが、本当にユーザーが求めている方向に向けて機能を開発していく。そのためには、リサーチスプリントのように、ユーザーの声を事業全体の意思決定に活用していける仕組みが必要不可欠です。
このような取り組みがカナリー全体に広がるためには「リサーチがあったからこそ物事が進んだ」という経験をどれだけ得てもらうかが大事だと思います。今回の取り組みでそのような文化醸成が少し進みましたが、今後はさらに組織としてのユーザーの声の活用を加速させていきたく思っています。
デザイナーチームとして、今後もユーザーと向き合った開発プロセスのデザインに取り組んでいきます。