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

製品分析機能で得られるデータから、ユーザーがその製品を実際にどのように使用しているのかがわかります。

Sam Tardif Sam Tardif
Browse topics

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

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

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

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

製品分析を導入する

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

製品分析 | アトラシアンアジャイルコーチ
プロからのヒント:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

前述のとおり、十分なデータを得ることは素晴らしいことですが、完全にデータ主導になると、ユーザーのために作ろうとしている全体的なエクスペリエンスをダメにしてしまう場合があります。また、意思決定を行う時なのに必要なデータが揃っていない場合、データのみに頼ると良くない場合があります。

アジャイル製品分析 | アトラシアンアジャイルコーチ

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