プロダクト成長エンジンとしての計測

webアナリスト的な仕事をしていると、たとえばGoogle Analyticsなどの分析ツールが使える、あるいはSQLが書けるなど、手段や方法に寄ったスキルばかりが注目されるような気がする。

しかし、実際に仕事をしていて感じるのは、
そもそもプロダクト成長に向けて、どのようなログをとるべきなのか？
という、事業・サービス視点での見極めや、
そのログを最大限活用するためには、どういう形式でアウトプットすべきか？
という、組織・運用視点が、むしろ大切であるということだ。

プロダクトにおけるあらゆるログを取得したい、という想いもわかるが、実際に活用されなければ、それはまったく意味がない。

なんのための計測なのか？ということを、常に念頭に置く必要がある。

プロダクトとして取るべきログの見極め

すべてのプロダクトには、それによって解決したいユーザーの課題や、実現したい世界がある。

そして、プロダクトを提供することは、すなわちユーザーへの問いかけであり、仮説検証そのものになる。いま自分たちのプロダクトを、ユーザーがどう使っているか、どう評価しているのか、その回答がログに落ちていく。そしてそのログからユーザーの想いを読み取り、そこからさらに改善策を考える。

自分が以前いた職場では、プロダクトのトラッキング実装不備は、サービス障害と同等で扱われることさえあった。ユーザーの反応を見ることができない状態のプロダクトは、それだけ価値を損なう存在であるということなのだ。

つまり、「自分たちのプロダクトを、ユーザーがどう使ってもらえれば成功なのか、ということを念頭に置き、実際にどうだったのかを測り、さらなる改善に向けた意思決定に貢献すること」が、計測設計・レポーティングのキモになる。

そのため、改善指標KPIはもちろん、意味のある分析軸、重要となりそうな変数についても、仮説立てて計測する。

プロダクト成長に向けた分析では、より良い仮説が立てられるか、意味のある分析軸を見つけられるのか、ということが大切だが、それらがそもそも計測されていなければ、見つけることなんてできない。

たとえば、アプリのある機能を改修したところ、インストール初日にその機能を利用する割合が減り、継続率も落ちたとする。

その情報だけ見れば、機能改善は失敗だった、という判断がなされ、次のアクションとしてはきっと、前の状態に戻すか、別の改善策を考えることになる。

しかし、本当にそうなのだろうか？

その機能改善のリリースと同時に、新しい広告メニューでの出稿をしていて、そこから流入したユーザーの属性として、そもそものサービス利用意向の低いユーザーが多く、こういう結果を招いた、ということだってある。
既存の経路からインストールしたユーザーにセグメントを絞ったら、実はその機能の利用率と継続率は上がっているのかもしれない。

得られるデータが制限されれば、判断や意思決定を誤ることもある。
計測内容が、プロダクトの成長に大きく影響してしまう。

計測のアウトプット、最適なレポート形式を考える

ほとんどの場合、計測したデータを見るのは、計測を設計・実装した本人だけではない。つまり、計測のアウトプットは、組織にとって使いやすい状態でなければいけない。

組織の中で、データを見て仮説を出せる、意思決定できるメンバーは、多いほうがいい。むしろ、全員であるべきだ。これは、事業やサービスの成長スピードに大きく関わる。

組織の中では、もちろん数字が大キライなひとたちもいる。

レポートの見せ方は、数値でなくてもいい。赤い下向きの矢印でも、晴れた太陽のマークでも、泣いている表情でもいい。

また、レポートなんて忙しくて見るヒマがない、というひとたちもいる。

重要指標が一目でわかるダッシュボードをつくったり、それを大きなディスプレイに映してフロアに置いたり、先週比で5%以上 下がったときにアラートが飛んだり、そういう仕組みをつくることで、軽減できる部分はあると思う。

"成果が見えること" は、組織全体の改善に繋がる

さらに、自分のした仕事の成果が目に見えることは、モチベーションの向上に繋がる。先月よりも1.5kg痩せた、去年よりもボーナスが増えた、そういう情報はわかったほうがうれしい。

また、自分の業務をタスクの実行ベースで考えるよりも、目的・目標に向けた成果貢献という視点で考えることができるようになると、ムダな仕事は減り、さらなる成果を出すことができる。

たとえば、後輩に仕事を引き継ぐとき、

「あなたの仕事は、週2日きっちりバナーを更新することだ」と伝えた場合、

「あなたの仕事は、週2日のバナー更新の中で、よりクリックされるクリエイティブを見つけることだ」と伝えた場合、

「あなたの仕事は、サービスへの集客を最大化することだ」と伝えた場合、

それぞれで、後輩のモチベーションや数ヵ月後の利益貢献が、大きく変わると思う。

いちばん最初の伝え方をした場合、無駄かもしれないルーチンワークが生まれ、後輩はきっとそこから抜け出せなくなってしまう。

自分だけが計測ログを見て満足するのでなく、組織メンバーにとってわかりやすく見せることで、各々が次のアクションを考え、実行することができる組織にしていく。
そして、その成果も目に見える状態になれば、みんなのモチベーションも底上げできるかもしれない。

そうやって、各自が自走する環境をつくることができれば、組織全体の生産性、つまりはプロダクトの成長スピードを、きっと飛躍的に上げられると思う。