製品分析をして「empathy debt」を返済する

製品分析とは、ユーザーがどのように製品を使っているかデータを取り、分析する手法です。

そもそも、なぜ製品分析をしなければならないのでしょうか。その理由はシンプルで、ユーザーが求めている機能を作るためです。

顧客インタビューなどによる「定性的フィードバック」と製品分析による「定量的フィードバック」を得ないまま「思い込み」で開発を進めると、ユーザーが求めていない機能（負債）を作ってしまい、後々に改修が必要になります。

Atlassianではこれを「empathy debt」と呼んでいます。つまり、思い込みにより発生する負債です。プロダクトマネージャーは顧客インタビューや製品分析をして「empathy debt」（思い込みにより発生する負債）をすぐに返済する必要があります。

それではAtlassianで過去にあった「empathy debt」の例を見ていきましょう。

Atlassianの製品の1つであるConfluenceはこれまで非常に長い期間にわたり使用されてきていますが、定量的な製品分析がなされていない機能が多数ありました。そのうちの一つがダッシュボードです。

ダッシュボードはほとんどのユーザーが最初に使用する機能で、顧客インタビューによって定性的なフィードバックを得ることができたので、機能の再検討をはじめました。

しかし、その時点では定量的観点からの製品分析は実施できていなかったため、本当の使用状況は理解できておらず、下記の質問の答えはわかっておりませんでした。

ダッシュボードの使用率

• ダッシュボードの使用率はどのくらいか？
• ユーザーは一般的な Confluence セッションで、ダッシュボードを何回訪問するか？

ダッシュボードの使用目的

• ユーザーは実際にダッシュボードを何の目的で使用しているか？
• 「すべての更新」フィードを見るため？「人気」フィードを見るため？
• 目的のスペースへ移動するため？

ダッシュボードに求めるもの

• ユーザーはダッシュボードに何を求めているのか？
• ダッシュボードを訪問後のユーザーの行動に基づいて、私たちは今後注力すべき点を決められるか？

これらの質問への答えを製品分析で明らかにしなければ、思い込みでユーザーが求めない機能を作ることになり「empathy debt」の返済を迫られることになります。

そこで、ダッシュボードに関する製品分析を繰り返したところ、ダッシュボードにおいてもっともよくあるアクションの一つは「お気に入りページ」を見ることだと分かりました。これはとても重要な発見です。

出来るだけ早く製品分析を実施し、製品の意思決定に役立つデータを集め始めて、「empathy debt」をできるだけ早く返済しましょう。

そうでない場合は、暗闇で重要な決断を下すようなものです。分析は嘘をつきません。

分析はユーザーが製品をどのように使用しているかを正確に示しますが、もう少し深く掘り下げ、分析結果を使用して、ユーザーが本当に望んでいるものを理解してください。

ユーザーのすべてのアクションにイベントを設定する

「ユーザーがあなたの製品をどう使っているか」を定量的に把握する製品分析の最初のステップはイベントの設定です。

どれくらいのユーザーがどのくらいの頻度で機能を使用しているかを把握するために、ユーザーが製品に対して実施可能なすべてのアクションに対し、イベントを設定します。

例えば、ユーザーが特定のボタンをクリックした回数を追跡したい場合「big-red-button.click」というイベントを設定します。

このように実施可能なすべてのアクションに対しイベントを設定し、ユーザーのアクションを把握できれば、対応が必要な機能と、その中でも最も重要なものがわかるので、開発の優先順位を付けることができます。

※分析イベントの追加や追跡を行うフレームワークを得るためのソリューションは山のようにあります。出発点として Google Analytics や KISSmetrics などをおすすめします。

Atlassianでは、誰もができるだけ簡単に分析データを取得でき、独自のクエリやレポートを実行できるよう取り組んできました。当社では通常、社内で開発したいくつかのツールを使用して分析を行ってきましたが、Google Analytics から始めることもできるでしょう。

これにより、開発者からプロダクトマネージャー、デザイナーに至るまで全員が、使用状況に関して質問し、自分たちがビルドしたものの影響を理解しようと努めるようになりました。

製品分析によって新しい機能や体験のテストをする

製品分析を行うことで、追加を検討している新しい機能や新しい体験をテストすることもできます。

機能の使用頻度に対して明確な目標がある場合、製品分析を行うことで「早く失敗し、成功するまで繰り返す」というアジャイルの信念にしたがって製品開発ができます。

製品分析を行いながら新しい機能を開発するプロセスは下記のようになります。

1.製品の変化に対する明確な仮説を定義する

例:「コメントボックスのサイズを大きくすることで、コメントが5%増加すると予測する」

2.この変化を最も安く実現できる実装をビルドし、必要な分析イベントを組み込むことで、仮説をテストする

3.A/Bテストとして、あるユーザーグループにこの変更を反映した製品を使ってもらう

4.結果を待つ

5.分析をし、変更が成功したかどうかを判断する

先ほど例に挙げたConfluenceのダッシュボードを変更するため、私たちは最終的に3つの非常に「特徴的な」ダッシュボードをデザインしました。

それぞれが異なる使用事例と行動セットを想定しています。そして上記のプロセスを実施したところダッシュボードの改善をすることができました。

それと同時に、製品分析を新しい機能の開発に応用する上で注意すべきことがいくつかあることも分かりました。

注意すべき点は以下のとおりです：

1.イベントが十分に用意されているか

ユーザーグループに製品を使ってもらった時に、分析に必要なイベントの不足に気付くのは最悪です。収集できる情報が思い通りのものであるかを確認するため、実験を行う前に、いくつかのダミーデータを使用して分析を試行してください。

2.仮説を用意しているか

仮説を考えるのは時間がかかるかもしれませんが、事前に用意しましょう。製品分析を実施する前に、その製品分析で仮説を証明、または反証できる見通しが必要です。実施前にダミーデータを使用して分析を行うと、このテストにも役立ちます。

3.テストは統計的に意味があるか

十分なユーザー数、十分な期間をもってテストを行うようにしてください。結果が統計的に十分なものであると保証する必要があります。

4.悪いアイデアを捨てる準備があるか

悪いアイデアは捨てる覚悟をもちましょう！前述の通り、機能のテストはできるだけ安価に行い、これらのテストを出来るだけ早く実行する必要があります。すばやく失敗するのは良いことです。

製品分析だけでなく、ユーザーの意見にも耳を傾ける

これまで見てきた通り、製品分析によって取得できるデータから「ユーザーがどのように製品を使っているか」は明らかになります。ただし、データを見ても、ユーザーがなぜその行動をするのか、またユーザーのゴールは何か、について理解することは難しいです。

例えば、ダッシュボードの利用率が20%だったとしても、「なぜ20%なのか。そして80%のユーザーはなぜダッシュボードを利用しないのか。」ということはわかりません。

そのため、製品分析に顧客インタビュー、コンセプトテスト ワークショップ、を組み合わせ、ユーザーとの会話から得られる質的フィードバックを組み合わせることで、実際に何が起きているかの全体像が分かり、考えられる最高の製品を開発することができます。

顧客インタビューについては、この連載の第4回に配信させて頂くので、楽しみにして下さい。

まとめ

1. 「empathy debt」を少しでも早く返済するためにすぐに製品分析をしましょう。
2. 製品分析をもとに新規の機能開発を行いましょう。
3. 製品分析による定量的なフィードバックだけではなく、顧客インタビューなどの定性的なフィードバックを得ることを製品開発のプロセスに組み込みましょう。