実施したUXリサーチを改善につながる形で管理する「カスタマーインサイトリポジトリ」とは

UXリサーチで得たフィードバックや問い合わせ窓口によせられた要望など、ユーザーからの声はプロダクトを磨き、事業を成長させる上で欠かせません。これらの情報は時間と共に増えていくため、管理の仕方が課題になります。

集めたユーザーの声をきちんと改善につながる形で管理するために「カスタマーインサイトリポジトリ」というフレームがあります。本記事では、現場にカスタマーインサイトリポジトリを導入するための、考え方や運用方法についてご紹介します。

カスタマーインサイトリポジトリが解決する課題

「ユーザーからのフィードバックはたくさん集まってくるものの、どのように機能へ反映させるべきかわからない」

「いつもなにかしらの施策は打っているが、成果に繋がるものになっているか自信がもてないまま取り組んでいる」

「ユーザーの要望通りに改善したつもりが、ユーザーが離れる原因になってしまった」

事業開発の現場にいる方、プロダクト開発に関わっている方であれば、一度はこういった問題に遭遇したことがあるのではないでしょうか。

特にPMF後は、ユーザーやユースケースが多様化し、集まるフィードバックの量は膨大になり、要望も複雑化します。そうした場合には、1つひとつの要望に対して改善したとしても、その改善が別のユースケースを阻害する要因につながってしまいます。そもそも要望すべてに対応していては時間がいくらあっても足りません。

ユーザーのフィードバックはどれも価値のあるものです。しかし、肝心なことは、「誰のどんな課題を解決するか」にあります。自動車を普及させた立役者、ヘンリー・フォード氏の「もし顧客に、彼らの望むものを聞いていたら、彼らは『もっと速い馬が欲しい」と答えていただろう。』という言葉にあるように、顧客の要望をそのまま形にするだけでは、良いサービスをつくることはできません。

ユーザーからいただいた声を一段抽象化し、ユーザーが抱える課題はなにか、それを解決する方法はなにかを考える際に役立つフレームが「カスタマーインサイトリポジトリ」です。

ユーザーからの声を管理するカスタマーインサイトリポジトリとは？

カスタマーインサイトリポジトリとは、ユーザーから集めたフィードバックや要望を得られた仮説と紐づけた形で管理しておくフレームです。

カスタマーインサイトリポジトリは、以下の3つの階層からなります。

1.モデル：カスタマージャーニーマップやペルソナなど仮説を統合したもの

2.仮説：サービスがもつ「顧客」「課題」「解決策」に関する仮説

3.リサーチデータ：ユーザーから集めたフィードバックや要望そのもの

仮説はモデルと紐付けられ、リサーチデータは仮説と紐付けられる形で管理されます。

それぞれの情報を紐付けて管理するため、ユーザーからの要望が集中していて効果が期待できる仮説がどれなのか、検証が足りていない仮説がどれなのか、簡単に把握できます。

新機能のアイデアを検討する際やプロダクトバックログに積み上がった改善アイデアの優先順位を決める際にも、ユーザーの視点を取り入れながら効果が期待できるものを選びやすくなります。

カスタマーインサイトリポジトリを導入・運用するには

Airtableやreframerといったカスタマーインサイトリポジトリ構築にも活用できる無料サービスを使えば、導入のコストは比較的低く済みます。データベースとして完璧な構造をめざす必要はありません。はじめは仮説とリサーチデータの2階層しかない状態でも十分です。

一方で、カスタマーインサイトリポジトリの運用は課題が発生しやすく、形骸化し使われなくなってしまったというケースも散見されます。

形骸化しやすい要因として、カスタマーインサイトリポジトリのフレームから導入することでワークフローと分離してしまうことが挙げられます。カスタマーインサイトリポジトリを運用するためには、日々集まってくる膨大な量の要望を分類し、データとして登録していく作業が必要になります。

こうした作業は、サービス改善の業務の中では緊急度が低いタスクとして認識されてしまいがちです。結果、時間を割けなかったり、担当者が浮いてしまったり運用がうまくいかないという壁に行き当たります。

そうならないために重要なのは、整理する順番です。運用でつまずくパターンの多くが、リサーチデータを先に分類し、そこから仮説を導き出し、仮説のデータ整理を行っています。

リサーチデータではなく、まずは現状のプロダクトがもっている仮説の整理から行いましょう。仮説の整理は「顧客」「課題」「解決策」の3レイヤーに分けて行います。「顧客」仮説に「課題」仮説を対応させ、さらに「解決策」の仮説を紐づけます。どんな新規事業も最初は「顧客」「課題」「解決策」を含んだ1つの仮説からはじまります。rootではその仮説を「事業の芯」と呼びます。事業の芯を丁寧に整理していくと、検証することが明確になります。

仮説が整理できたら、エビデンスとなるユーザーインサイトをリサーチを通じて獲得しに行きます。リサーチ後、得られた情報を仮説に紐づけて分類していきます。

こうすることで、サービスのロードマップや改善施策を考える際に行われる確度の高い仮説を見極めるプロセスに分類の作業を組み込むことができます。施策の意思決定者であるPdMやプロジェクトオーナーが仮説決定時に主体的に分類の作業を行う構造になっていくため、うまくいくケースが多いように感じます。

カスタマーインサイトリポジトリはあくまで手段です。重要なのは、ユーザーが抱える課題起点での改善サイクルがチーム内で回り続けることです。

rootではサービスが抱える課題の解消だけでなく、必要に応じてナレッジの提供やプロセスのインストールといった中長期的かつ本質的な解決の支援も行っています。気になった方はぜひお気軽にご相談ください。