製品分析について
すべてのプロダクトマネージャーが
知っておくべきこと

The data we glean from product analytics tells us how users actually use the product.

Sam Tardif Sam Tardif

As product managers, we take every opportunity we get to learn more about our customers because understanding their needs is critical to building useful products. This means conducting customer interviews, running surveys, and examining in-product analytics. The data we glean from product analytics tells us how users actually use the product – not what they want to do, how they think they're using them, or even how we think they are using them.

Where software development differs, and home building could definitely benefit, is the use of agile methodology. Agile allows multiple teams to respond to changes, quickly. So how can agile, a method based on frequent, continuous delivery exist with long-term, big-picture planning? Is it possible to create a realistic forecast over a long period of time, knowing that the one constant is change?

プロダクトマネージャーとして「ユーザーは毎日この製品にどのくらいの時間を費やしていますか?」「彼らが最も多く取るアクションは何ですか?」「最も使用頻度が少ないフィーチャーはどれですか?」といった質問をすることは、ユーザーの理解に非常に役立ち、彼らの体験をさらに良くする方法のヒントを与えてくれます。 この記事では、製品分析とは何か、およびあなたが製品分析を行うべき理由、ユーザーを本当に理解して「共感的負債」を打ち消す方法を説明します。また、新しいフィーチャー開発のガイドとなるように分析を用いる方法について説明します。

それでは、始めましょう!

製品分析を導入する

ユーザーがあなたの製品をどう使っているかを定量的に把握するために、最初のステップとして分析を実施します。それは、どれくらいのユーザーがフィーチャーを使用しているか、またはその頻度についての集約的視点を得ることができるよう、ユーザーが製品に対して実施可能なすべてのアクションに対し、イベントをトリガするということです。例えば、ユーザーが特定のボタンをクリックした回数を追跡したい場合、「big-red-button.click」というイベントをトリガすることがあります。そこから、対応が必要なフィーチャー、最も重要なものがわかり、その情報を使用して、変更に優先順位を付けることができます。 

Product analytics | Atlassian agile coach
ProTip:

There are a ton of solutions out there that give you a framework for adding analytics events and tracking them. Check out Google Analytics or KISSmetrics as a starting point.

アトラシアンでは、誰もができるだけ簡単に分析データを取得でき、独自のクエリやレポートを実行できるよう取り組んできました。当社では通常、社内で開発したいくつかのツールを使用してこれらのサービスを提供していますが、Google Analytics から始めることもできるでしょう。これにより、開発者からプロダクトマネージャー、デザイナーに至るまで全員が、使用状況に関して質問し、自分たちがビルドしたものの影響を理解しようと努めるようになりました。

「共感的負債」: 新しい種類の負債

この新しい用語である、「共感的負債」について考えてみましょう。

コンセプト テストや顧客インタビューなどの活動を通じて収集された質的フィードバック、製品分析や NPS 調査などを使用して製品内で収集された量的データの 2 つの方法で共感的負債を返済することができます。

例えば Confluence はこれまで非常に長い期間にわたり使用されてきていますが、ほとんど分析がないフィーチャーが多数あります。そのうちの一つがダッシュボードです。ダッシュボードはほとんどのユーザーが Confluence の最初に使用する機能です。実際に私たちは現在、この機能を再検討している最中です。顧客インタビューによってダッシュボードに関するフィードバックをいくつか得ることが出来ました。しかし、使用状況を本当に把握するために必要な、定量的観点からの製品分析は実施できていません。次のように、未回答の質問が多数あります。

  • ダッシュボードの使用率はどのくらいか?ユーザーは一般的な Confluence セッションで、ダッシュボードを何回訪問するか?
  • ユーザーは実際にダッシュボードを何の目的で使用しているか?「すべての更新」フィードを見るため?「人気」フィードを見るため?目的のスペースへ移動するため?
  • ユーザーはダッシュボードに何を求めているのか?ダッシュボードを訪問後のユーザーの行動に基づいて、私たちは今後注力すべき点を決められるか?

Confluence で最も頻繁に訪問されるページの 1 つであるダッシュボードに変更を加える前に、回答するべき非常に基本的な質問があります。また、あなたの製品に分析を行っていない場合、または変更したい特定のフィーチャーすらない場合も上記と同じケースで、非常に慎重に決断する必要があります。今こそ共感的負債を返済する時です!

ダッシュボードをテストするうちに、ダッシュボードにおいてもっともよくあるアクションの一つは「お気に入りページ」を見ることだと分かりました。これはとても重要な発見です。最初の仮説において気づいている必要はありません。ここでの主な学習は次のとおりです:共感的負債はできるだけ早く返済しましょう。製品の分析を行っていない場合は出来るだけ早く実施し、製品の意思決定に役立つデータを集め始めてください。そうでない場合は、暗闇で重要な決断を下すようなものです。分析は嘘をつきません!分析はユーザーが製品をどのように使用しているかを正確に示しますが、もう少し深く掘り下げ、分析結果を使用して、ユーザーが本当に望んでいるものを理解してください。

まだ見ぬ未来をテストする

ユーザーが既存のフィーチャーをどのように使用しているかを理解するために製品分析を行うことは非常に価値があります。また、追加を検討している新しいフィーチャーや新しい体験をテストするためにも製品分析は非常に価値があります。フィーチャーの使用頻度に対する明確な目標がある場合、製品分析を行うことで、「早く失敗し、成功するまで繰り返す」という昔からあるアジャイルの信念にしたがって取り組めるでしょう。

一般的に使用するプロセスは次のようになります:

  • 製品の変化に対する明確な仮説を定義する。例:「コメントボックスのサイズを大きくすることで、コメントが 5% 増加すると予測する」
  • この変化を最も安く実現できる実装をビルドし、必要な分析イベントを組み込むことで、仮説をテストできる。
  • A/B テストとして、ある顧客グループにこの変更をデプロイする。
  • 結果を待つ。
  • 複雑な変更の場合は、分析担当者の助けを借りて結果の内訳を作成し、変更が成功したかどうかを判断する。

ダッシュボードを変更するため、私たちは最終的に 3 つの非常に「特徴的な」ダッシュボードをデザインしました。それぞれが異なる使用事例と行動セットを想定しています。次にこのプロセスを実行し (当社の仮説はもっと複雑なものではありましたが)、本当にうまくいきました。ただし、新しいフィーチャーをこの方法でテストする前に考えておくべき共通点がいくつかあることも分かりました。中には困難なこともあります。

注意すべきアンチパターンは以下のとおりです:
  • 実験の最後に到達したのに、必要なイベントが不足していることに気付くのは最悪です。 収集できる情報が思い通りのものであるかを確認するため、実験を行う前に、いくつかのダミーデータを使用して分析を試行してください。
  • 仮説を考えるのは時間がかかるかもしれませんが、事前に用意しましょう。実施する前にその製品分析で仮説を証明、または反証できる見通しが必要です。実施前にダミーデータを使用して分析を行うと、このテストにも役立ちます。
  • 十分なユーザー数、十分な期間をもってテストを行うようにしてください。結果が統計的に十分なものであると保証する必要があります。
  • 悪いアイデアは捨てる覚悟をもちましょう!前述の通り、フィーチャーのテストはできるだけ安価に行い、これらのテストを出来るだけ早く実行する必要があります。すばやく失敗するのは良いことです。 

ユーザーの意見にも耳を傾ける

As I mentioned above, it’s great to be data-informed, but being entirely data-driven can sometimes leave you blind to the overall experience that you’re creating for users. Being dependent entirely on data can also be a bit crippling when it comes time to make a decision and you don’t have all the data you need.

Agile product analytics | Atlassian agile coach

製品分析は、ユーザーが製品や特定のフィーチャーをどのように使用しているかについての生の現実が明るみになりますが、非常に一次元的なものになる場合もあります。製品分析データから分かると思われることと、顧客インタビュー、コンセプト テスト ワークショップ、会話などから得られる質的フィードバックを組み合わせることで、実際に何が起きているかの全体像が分かり、考えられる最高の製品を開発することができます。

次の記事
チーム