開発チームで回すプロダクト数値改善の走り始め方

初めましてshotaです。ここ数年、複数のプロダクトで数値改善を行う自律的な開発チームを立ち上げてきました。最近「開発組織の中で数値改善をはじめたいけど、何から始めればいいかわからない」的な質問をよく受けるようになって記事を書いてみました。本記事は数値分析の切り口や目的についての記事になっています。

先ず数値改善というと色々な解釈ができてしまうので、プロダクトゴールを元に既存のユーザー向けにプロダクトを最適化していく、くらいを目的に意識しつつどんな目的・切り口で数値分析しているかを書いてます。

前提条件としてのプロダクトログ収集

ログが取れていないと分析ができません。また過去に遡ることもできないのでなるべく早い段階で準備すると良いです。最低限以下のログが取れてbigqueryなどのDWHにいれておけば、SQLを使って大体のモニタリングができると思います。

・ページビューのログ
・ アクションログ
・アプリケーションで使ってるDBの内容のコピー

ページビューのログとはユーザーがどの画面を表示したかを表すログ、アクションログはユーザーがどのボタンをクリックしたかフォームサブミットしたかなどのログをさしています。DBのコピーはそのままの意味です。

ログは自前で仕込むと大変なのでkeen.ioなどを使ったりすると楽です。あとはログを取るときはユーザー情報など載せられる情報ななるべく載せとくと分析の際にJOINとかする必要がなくて楽です。これ以上のテクニック的なここでは割愛します。流入などのマーケ的な話しも割愛しています。

あとは後述の分析で利用するのでGoogleAnalyticsなどのアクセス解析ツールも導入しておくと便利です。(お高いですがPremium版ならそのままログ収集も出来ます。)

示唆を出すための二つの分析方法

次はどんな切り口でプロダクトの数値を分析しているか説明します。
プロダクトの数値分析を行う際、ざっくり分けて二つの方法で数値をみてます。

・アドホック分析
・定常モニタリング

アドホック分析

こちらは仮説検証で情報を深追いしたい時に行う分析のことをさして話しています。グロースハックの初期段階でユーザーがどんな使い方しているのかわからない、サービスのボトルネックがわからないみたいなタイミングでの情報集めに利用します。
全体的な年齢・性別・使っている時間帯・デバイス・ユーザーごとの行動ログを読んでみたりなどなど、目的に応じてデータの見方は無限のパターンがあります。

また一回レポートを出してしまえば集計ロジックとかは一度きりで使い捨てしています。思いついたときになるべく手っ取り早く分析したいので、GoogleAnalyticsなどの分析結果で示唆を出せるなら精緻な情報は求めずそこで分析を済ませたりします。それで無理な場合はSQLを書いて分析しています。

余談ですが、自分は最初SQLを書くのがどうしても嫌いで、pythonを使って分析していました。フレームワーク的なものを作ってなるべく楽でリッチに分析しようと工夫しましたが、汎用的に作って出来上がったものが結局SQLに近いものでした。結局SQLが実行速度も早く環境も必要なくシンプルに分析出来るので、同じ道を歩もうとしている方がいれば参考にしてください。

なお、このアドホック分析、立ち上げの段階などではよく行いますが、大体プロダクトのインサイトが固まればあまり見なくなります。改めて時間をかけて仮説検証したいようなケースが少なくなるからです。なのでがっつり自前で環境を作り込んでいくよりは、SQLとSaaSを上手く使いながら楽をするといいのかなーと思います。

定常モニタリング

こちらはプロダクトのいわば健康診断表のようなもので、永続的に行う数値モニタリングのことです。アドホック分析などを行ってある程度プロダクトの示唆が固まった後に立ち上げます。

このモニタリングシートを見れば、プロダクト改善によるユーザーの行動変化が何らかの数値として追えて、新しくSQLを書くなど分析レポートの作成に時間をかけずともプロダクト改善効果がわかる状態を目指します。

参考までに↓みたいなイメージで、デイリーのユーザーの動きを取れるだけ取ったり(数値などはサンプルです)。内容はサービスごとモニタリングするべき情報が違うので一概言えませんが、目的に応じて複数の角度からレポートを作成しておきます。

このような健康診断表を作る理由はいくつかあります。有力なのは二つで、常に同じ数値を見ることで見方に慣れたり数値を覚えられて変化に気付きやすかったりすぐレポーティングできるようになります。もう一つは、新たに数値を拾いにいく必要がなくなるので分析にかかる時間を節約することができます。

モニタリングの目的はもともとプロダクト改善で、このプロダクト改善はなるべく高速に確度の高い施策を回していくのが良いです。グロースハックチームの立ち上げ時によくあったのは、PDCAの工程でチェックに必要以上に時間をかけてしまうことです。

どこまで数値を見れば良いかわからない問題が原因で定常モニタリングの概念がないときよくに発生していました。
機能改善をリリースするたびに毎回新たにSQLを書いて前後の差異から仮説を立ててみたいな工程を踏みます。毎回どの数値を見れば良いか考えて、算出数値があっているかの検証して、有意差がなければ恣意的に何とか変化を探したり。時間がかかる上そこまで示唆が出ないのでこういった作業はモチベーションが下り次の手が遅くなってしまいます。

基本的に効果測定は、定常モニタリングの範囲で効果があったかなかったのかを判断すると良かったです。そこで出せるだけの示唆を判断して、次の施策に移る。今までこの運用が、有意義な示唆を取りこぼさず分析に時間をかけないトレードオフの良い塩梅でした。

新機能開発の場合や、想定不足で必要な数値が足りない場合、定常モニタリングをアップデートしましょう。こういった運用を繰り返していくと、分析資産を増やしながら進めていくことができます。

実際の立ち上げ方

先ずはもし取れてなかったら最低限ログを収集します。
分析基盤が整えば、まずはじめはアドホック分析でユーザー像やプロダクトの状態を把握します。プロダクトのユーザー体験フローにしたがって体験ごとの通過率をみて離脱ポイントを見つけたり、プロダクトのKPIツリーの数値を出したりなどの仮説検証を通してキードライバーを見つけ出します。

そうすると活動方針が見えたタイミングで定常モニタリングを構築します。運用の中でアップデートしつつも、基本はその数値の中で分析を行いながらなるべく高速にプロダクト改善のPDCAを回して行きます。示唆を出して改善する運用に慣れていくとそれがどんどん高速・高精度になり自己組織化された開発チームに成長していくと思います。

最後に

読んでいただきありがとうございました。会社で数値改善を行う開発チームを作りたいが何から手をつければ良いかわからない、という方への少しでもの支えになれば幸いです。

この記事ではわからない部分や相談ごとなどがあればお気軽に連絡お願いします。

Twitter: @shota_kohara