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

要約: 製品分析は、ユーザーが製品またはサービスにどのようにかかわっているかを分析するプロセスです。これによって、製品チームはユーザー エンゲージメントや行動データを追跡、視覚化し、分析することができます。各チームはこのデータを使用して、製品またはサービスを改善し、最適化しています。

プロダクト マネージャーとして、私たちはお客様についての情報を得られるあらゆる機会を逃しません。なぜなら、役に立つ製品を開発するためにお客様のニーズを知ることは不可欠だからです。そのために、顧客インタビューや調査、製品内分析を実施します。製品分析から得られるデータによって、ユーザーがどのように製品を使用したいかではなく、実際に製品をどのように使用しているかがわかります。ユーザーの製品使用方法を、私たちがどう思っているか、でもありません。

ソフトウェア開発が住宅建設と違うところといえば、アジャイル手法の使用です (住宅建設に活用しても大いにメリットが見込めると思われます)。アジャイルを使用すれば、複数のチームが変更にすばやく対応できます。それでは、アジャイル、つまり頻繁な継続的デリバリーに基づいた手法を、どのようにすれば全体を見据えた長期的な計画に活用できるのでしょうか? 計画は常に変化し続けると知りながら、長期間にわたる現実的な予測を作成することは可能でしょうか?

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

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

製品分析は、ユーザーが製品またはサービスにどのようにかかわっているかを分析するプロセスです。これによって、製品チームはユーザー エンゲージメントや行動データを追跡、視覚化し、分析することができます。各チームはこのデータを使用して、製品またはサービスを改善し、最適化しています。

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

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

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

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

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

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

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

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

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

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

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

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

前述のとおり、十分なデータを得ることは素晴らしいことですが、完全にデータ主導になると、ユーザーのために作っている全体的な体験が見えなくなってしまう場合があります。また、データのみに頼っていると、意思決定を行う時なのに必要なデータが揃っていない場合、困った状況になる可能性もあります。

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