イシュー単位からはじめる、データを用いた意思決定
こんにちは、プロダクトマネージャーのたけまさです。
書籍で指標設計やデータを用いた意思決定の話を読んで、目先業務に応用が難しくて途方にくれる。そんな理想と現実の「間をつなぐもの」をゴールに当記事は作成しました。
プロダクトに関わる人に向けて「エピックやイシューという小さな単位から、データを用いた意思決定をはじめる方法」を紹介します。
データドリブンの段階を定義する
一言で「データを意思決定に使う」とはいっても、粒度の違いで難易度に差があります。はじめにデータドリブンの活用段階を3つ定義して、地図とルートを用意したいと思います。
START：なにも見えない
データがとれない、データ収集に目的がない。
経験的な勘などで意思決定をする状態。なにも見えない。
WEBサービスであればユーザーの行動をデータとして蓄積します。しかし、定量的に現状把握ができていない。「必要かもしれない」考慮の積み重ねや、顧客の声の大きさなどで開発スコープが大きくなる傾向があります。
機能や施策のリリース後の振り返りも困難なため、「見えないものは改善できない」の典型的な状態です。でもスタートはここからです！
STEP 01：単一の事象
エピックやイシューといった小さな単位で、
データを活用した意思決定ができる状態。
前ステップとの差は、これから開発/改善する1つの機能でユーザーの利用状況を把握し、その事実をもとに仕様検討や取捨選択ができることです。
これができると、過剰な要件を開発スコープから外し、小さなリリースができるようになります。当記事の本題です。
STEP 02：複数事象の連動
プロダクト内のユーザーの行動実績をファネルやツリーなどで、
構造と連続性をデータで定量的に理解して意思決定ができる状態。
前ステップとの差は、ユーザー行動を1機能といった局所ではなく、プロダクトの利用開始から目的達成までのプロセスで、CVや離脱状況を定量的に把握していることです。「風が吹けば桶屋が儲かる」の因果や相関の関係をプロダクト内で理解した状態です。
これができると、無数の選択肢の中から投資対効果の高い価値提供や優先度設定ができるようになります。
STEP 03：北極星を目指す
プロダクトの実現したい状態を定義し、North Star MetricやKPIなどの指標設計と予実管理によって目標を達成を目指す状態。
前ステップとの差は、取り扱う時間軸の違いです。これまでは過去の実績をベースにした話でしたが、未来の話が含まれます。「未来に向けて実現したい状態定義と、それを牽引する指標設定」が重要です。
これができると、教科書やベストプラクティスで語られるようなデータドリブンな意思決定ができるのでしょう。
そんな理想を目指して、1ステップづつ前進することを目指しましょう。
イシュー単位のデータを用いた意思決定
「これから着手する1機能のことだけで考えよう」がこのSTEP01のコンセプトです。事例を混ぜつつ解説します。
①データをみる前に仮説をつくること
×：データを見てから、仮説を立てる。
○：仮説を立ててから、データをみる。
データ分析の恐ろしいところは、無限に時間を使えるところです。
仮説
・ASIS：現状はこうである
・ TOBE：あるべき姿はこうである
・ギャップ：課題はこうである
・対策：解決策はこうである
検証
・この仮説の検証に必要なデータだけ集める
・仮説に誤りがあれば、修正して再検証する
仮説を作ることで、自分の正解に対するスタンスを明確にします。間違いを認知できる状態をつくるのが大事です。検証必要なデータだけ見ればよいので、探索範囲を小さくして作業を減らせます。
②データをどんな視点でみるのか？
使いやすい４つの視点を紹介します。基本の基本ですが1つの事象の分析なら、組み合わせでほとんどのケースをカバーできると思います。
A.切り分ける
複数の論点を混ぜて話すと、情報の取り扱いの難易度が上がります。目の前の事象がどんな要素と構造で成り立つか、分析の下準備としてロジックツリーなどを使って分解します。論点を1つ1つ取り扱える状態を作ります。
- カレーの論点を切り分ける
- 食べる相手
- 食事シーン
- 材料
- 調理方法
- 調理道具
B.比較をする
「比べて、違いを見つける」は分析の基本にして奥義ではないでしょうか。
比較軸を揃えて、２つ以上の対象で「同じ」や「違い」を理解します。
・ユーザーの業種別で利用数や利用率を比較する
・LTVの高いユーザーと低いユーザーの違いを比較する
・昨年同月の売上を比較する
C.構成比をみる
１つの要素を構成するの割合（比率）を理解します。
円グラフなどで見える化をします。
・プロダクトの利用ユーザーの従業員規模別の構成比をみる
・総ユーザー数のうちアクティブユーザー数の比率をみる
D.分布をみる
データの散らばり方（分布）を理解します。
度数分布やヒストグラムなどで見える化をします。
・ユーザーの1ヶ月のログイン回数の分布をみる
・ユーザーの一覧ページ内のデータ保持数の分布をみる
E.推移をみる
１つの事象が時系列でどう変化してきたかを理解します。
折れ線グラフや棒グラフなどで見える化をします。
・ある機能の利用率の推移をみる
・注力しているユーザー属性のユーザー数の成長推移をみる
③データをどのように意思決定に使うのか？
集めたデータを使って、どのように意思決定を行うのか。
開発の現場で私がよく使うフレームを紹介します。
メジャー、マイナー、エッジケースを定義する
プロダクトの中でユースケースを幹枝葉で切り分ける。
・メジャーケース（幹）：利用傾向の80%程度を構成するケース。
・マイナーケース（枝）：利用傾向の20%程度を構成するケース。
・エッジケース（葉）：実在はするが極端な外れ値ケース。
ユーザーのファイル一覧ページの利用傾向
・80%のユーザーは、保持するファイル数は20件以下である（メジャー）
・95%のユーザーは、保持するファイル数は50件以下である（マイナー）
・ユーザーが最も保持するファイル数は10,000件である（エッジ）
開発スコープの絞り込み。「必要かもしれない」を排除する。
利用傾向で定量的な裏付けがない議論は、「必要かもしれない」が大量に発生します。ユースケースの幹枝葉を見える化することで、過剰や不足のない開発スコープで、ユーザーに価値を素早く提供できます。
ユーザーのファイル一覧ページのリニューアル案件の開発スコープ
①初期の開発スコープにいれる
・メジャーケースに関連する課題
②初期リリース後に要望の量/質が高まった場合に再検討する
・マイナーケースに関連する課題
③基本的に対応しない。高いリターンが得られる場合に再検討する
・エッジケースに関連する課題
データをみた感想が「ほーん」の時は注意
あるデータを見た時の感想が「ほーん」で終わることがあります。これは自分の判断に必要な示唆が得られていない状態です。あるあるです。
仮説に対してデータをみるべき軸や粒度が合っていない、そもそも自分が仮説を持っていないなどの原因が考えれらます。データを見た時に仮説の正誤の判断ができる、アクションに落とし込むことができることが大事です。
データを使った対話の注意点
ある事象を上手に説明したデータには、反論の余地がない強さがあります。
裏付けのない意見に、自明の事実を持ち出して論破することも容易い。
だからこそ、関係者には背景となぜを丁寧に説明する必要があります。
おわりに。小さくはじめてみること。
完全性や網羅性を志向すると呆然と立ち尽くします。
1つでもデータで取り扱える事象が増えたら前進。
前進の繰り返しで、次の段階に進むタイミングが訪れます。
まずは小さなデータドリブンをはじめていきましょう！
この記事が気に入ったらサポートをしてみませんか？