Pairsの成長を推進させるデータ分析
はじめに
この記事は「Eureka Advent Calendar 2023」22日目の記事です。
こんにちは、BI (Business Intelligence) TeamのBabaです！私は2年半前にEurekaのBI TeamにData Analystとしてjoinし、2023年からBI TeamのManagerをやらせてもらっています。
本記事は、「BI TeamのManager1年目がどのようにPairsの成長を推進させてきたか？」を言語化します。昨年はプロジェクト単位の成果を最大化するための取り組みを書かせて頂きましたが、
Managerになった今年は、Product全体の成果最大化へのデータ分析の取り組みを主眼に書きたいと思います。データ利活用の状況は会社によって千差万別であり、唯一の正解は無いと考えているので、あくまで事例の一つとして読んでもらえると幸いです。
想定読者
・Productに関わるData Analystの働き方に興味がある人
・全社のデータ利活用推進に関心がある人
・Managerになりたての自分
この1年間で取り組んだ課題の概要
ManagerになりPairs全体の成果最大化が関心事となった際に、Pairsのデータ利活用に関する最重要課題を下記であると定義しました
- Pairsの現在地点が分からない
・・売上指標含めて、どの指標・ダッシュボードを見ればよいか定まっていない - Pairsの目指したい到達地点が分からない
・・各プロジェクトの貢献で、Pairs全体が良い方向に進んでいる実感が持てていない
ベクトルの始点・終点も定まっていない中では、「カイゼン」を回しづらい状態です。勿論、今までも各プロジェクト・各社員が賢明に開発に取り組んでいましたが、Pairs全体の成長に繋がっているか疑問の声が出ていました。
それぞれの課題をどのように解決したのかを言語化していきます。
1. 現在地点が分からない → 統一されたダッシュボードの浸透
この課題が一番深刻でした。
まず、売上・MAU・DAU・機能利用率などの基本的な指標ですら、全社で定義が統一されていませんでした。それに加えて、これらの指標を見るためのダッシュボードが整備されておらず、いわゆる野良ダッシュボードの乱立状態でした。具体的には以下のような問題を抱えていました。
- ダッシュボード間に指標の定義差分がある
- 指標間が構造化されていない（KPI Treeになっていない）
- ダッシュボード置き場がバラバラ（スプレッドシート、tableau、tableau内でもフォルダ管理が煩雑）
- メンテナンスされていないダッシュボードが見られていることがある
- 見たい切り口があったら各人が書捨てSQL
︙
この状態では現在地点の解釈・会話が各社員で揃わず、Pairs全体のヘルスチェックができない状態でした。
当然この状態では、
- 間違った数字をもとに意思決定が行われる
- 施策立案・効果検証が困難
- Pairsの体験が改善しているか判断ができない
- 数字ズレの調査コストが発生する（日毎の新規登録者数のようなシンプルな指標も複数のSQLが散逸しており、定義・数値ズレ調査に何度も泣かされました笑）
など様々な課題を産んでいました。
そこで、全社で使われる共通のダッシュボードを企画・実装・浸透させました。ステップはザックリ3つです
- 指標の定義を決め・関係各所と合意した
- メンテコストを下げる実装・利用シーンを意識した可視化をした
- 浸透させた
上記を振り返ってみます。
1.1 指標の定義を決め・合意した
正解の定義が無いが故に、野良定義が乱立し定義ズレが起こっていたので、まずは定義を確定することが何よりも最優先でした。指標は売上指標とUX指標に大別できます。それぞれ下記のように見直しました。
- 売上指標：Finance Teamが見ている指標定義が最も扱いやすかったので、この指標定義を参考に見直しました。
- UX指標：Pairsの目指したい到達地点（詳細は後述します）をPdMと議論しながら、到達地点から逆算して構造化していきました。
重要なポイントは、最上段からトップダウンに整理することです。
- まずは売上の最上段から整理する
- UX指標は大きいファネルから構造化しながら整理する
逆にボトムアップに指標を組み上げると定義の不整合・見落とし漏れが起こりやすい懸念が有ります。また、全社へ与えるインパクトを考えると上から整理する方がコスパが良いです。
指標の定義を決めたら、実装・可視化が待っています。
1.2 メンテコストを下げる実装・利用シーンを意識した可視化をした
1.2.1 メンテコストを下げる実装
ダッシュボードが読み込むtableを実装する際は下記の工夫を念頭においてました。
- SSOT(Single Source of Truth)を意識した構成。中間tableも永続UDFも積極的にdbtで管理
- 表示速度は命。中間テーブルで切り出しは積極的に。セグメントはシンプルに
・・SQL料金を下げるメリットもあります - TableauのcustomSQL含めて全てgitで管理。野良SQL絶対駄目。Pull Requestに検算もセットで載せる
- ビジネスニーズに伴う拡張性を意識
1.2.2 利用シーンを意識した可視化
可視化も超が付くほど大事です。まずは方針を決めました。
数字とデザインに強いPdMと議論しながら(TさんBig感謝です！）、下記のような方針でダッシュボードを実装しました。
人は怠惰であり、
- 難しいものは見たくない
・・大通りはシンプルに、複雑なものは奥に隠す - 知りたいことを一発で分かりたい
・・よく見る切り口は操作レスで考えさずに到達させる - すぐに現在地を忘れる
・・徹底した構造化
また、利用シーンに最適なダッシュボードを用意することは大切です。ダッシュボードが利用されるシーン・利用者の組み合わせはどういったものが挙げられるでしょうか？
大雑把には3つに大別されます。
- 定期的に俯瞰して見たい経営層
- 先週出した施策の効果を確認したい開発メンバー
- 次なる施策立案のために、セグメント毎に分解して使いたいPdM・BI
それら全てのダッシュボードの用途を同時に満たす可視化方法は難しいので、SSOTを意識しながらダッシュボードに役割を持たせました。各ダッシュボードの使い分けを説明した図が下記です。
1.3 ダッシュボードを浸透させた
ダッシュボードを実装したら終わりではありません。社員に見られないと価値がありません。これらのダッシュボードも社員にアクセスされなければ、野良ダッシュボードの一つに成り果てる未来が待っています。
浸透させるために様々な施策を前述のPdMと協力しながら実施しました。
特にインパクトが大きかったのは下記の施策です。
- ダッシュボード一覧をまとめたグラフィカルなポータルを作った
・・各ダッシュボードの意味を表すアイコンを作り、KPI Treeに沿って構造化しながら配置
・・ここに載っているダッシュボードはメンテし、逆に載っていない物は原則メンテしないことを宣言 - 草の根運動をした
・・施策リリースなど何かにつけてSlackで投稿し続ける
・・Slackに投稿するときはダッシュボードのURLを付ける
・・会社で宣伝し続ける（全社共有会などでも告知しました） - ノイズになる野良ダッシュボード群を大量に断舎離した
- 要望を取り入れながら改善し続けた
特にポータルの効果は絶大でした。ポータル内のダッシュボードはメンテされていることを明示することで、各社員が数値の誤りや定義ズレなどを気にすること無くデータを見れるようになりました。各ダッシュボードが構造化されているので、ついでに気になった指標を回遊する効果もありました。
このポータルを各施策リリースや経営層向けの報告でも常に使うことで、数値の共通認識・ダッシュボードの浸透を広げていきました。
- 横のコミュニケーションの統一：プロジェクト間で同じ指標に基づいて、施策立案・効果測定の会話ができる
- 縦のコミュニケーションの統一：マネジメント層と現場間で、Pairsのヘルスチェックを同じフォーマットで議論できる
1.4 ダッシュボードを浸透させて得られたインパクト
これらの取り組みのおかげで、下記のようなインパクトを得ることができました。
- 構造化された同じ指標を見て、各開発メンバーの会話が噛み合うようになった
- 各施策を数値ベースで効果検証・施策立案できるようになった
- 週次経営会議の全数値は単一のダッシュボードポータルで管理できるようになった
- BI Teamのダッシュボードメンテコストを削減できた
- ダッシュボード閲覧回数・人数が大幅増加（具体的数字は掲載できないですが、社内のいたるところで活用されるようになりました）
以上が、全社で活用されるダッシュボードを浸透させるための取り組みです。勿論ここでは書けていない様々な取り組みがあった上で得られた成果でした。例えば、
・大量のダッシュボードの数年間に続く断舎離
・dbt＆Dagsterによるデータ基盤環境のリプレイス
・ダッシュボード統一を目指した数年間のその他取り組み
などの過去の数々の貢献と、数値管理ニーズの急速な高まりに後押しされて得られた成果でした。私は難しいことをしておらず当たり前のことを愚直にやっただけです。同じ課題感を強く持っていたメンバーを巻き込めたのが幸運でした。
特にTさん・Aさんを始めとする、PdM・BI Teamの皆さんに感謝です。
2. 目指したい到達地点が分からない → North Star Metricを中心とするProduct改善サイクルの浸透
ダッシュボード整備により現状把握ができるようになった次に求められるのが、「Pairsはどこの到達地点を目指すべきか？」という課題です。
目指すべき方向が決まらないと、暗闇を進むようなものであり、何のアクションをすれば良いかわからないです。指標の改善に紐づかない施策のリリースが目的になっている節もありました。
そこで、North Star Metricを導入しました。この指標はKPIの一つとも定義できますが、会社全体が同じ方向を向くコアなUX指標という想いを込めて、NSMと定義しました。
North Star Metric(NSM)とは？
North Star（北極星）は人々を迷うことなく同じ方向へと導くための目標。
North Star Metricはプロダクトのコアとなる価値がユーザに届いているかを知るシンプルな定義の指標であり、KPI(収益指標等)の先行指標となる。具体例としてZoomにおける、「Zoomで主催された一週間あたりのミーティングの数」がNSMとして挙げられる。
『プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで』（及川 卓也, 小城 久美子, 曽根原 春樹 ,2021）、「7.4.3 評価指標を立てる 」よりBabaによる意訳
ステップはザックリ2つです
- PdMを中心に開発メンバーと何度も議論をし、NSMの定義を決めた
- NSMを中心とする改善サイクルを回し続けた
上記を振り返ってみます。
2.1 PdMを中心に開発メンバーと何度も議論をし、NSMの定義を決めた
ここが最重要と言っても過言では無いステップです。特にPdM TeamのManagerらを中心に開発メンバーと何度も議論し、NSMの定義を決めました。組織の「腹落ち感」を得ることで、開発メンバーの体重が乗り施策が力強く進みます。
Data Analystである私は特に、「まずシンプルな定義を考え、次にKPIの先行指標であることを示す」に注力していました。シンプルな定義は言わずもがなでしょう。複雑な定義だと組織に浸透せず、プロダクトが目指す北極星にはなりません。
NSMがKPIの先行指標であることを示すのはAnalystの腕の見せ所です。下記の2方向からのアプローチで、NSMがKPIの先行指標になることを示しました。
- マクロな関連性を示す
・・NSMとKPIが時系列で連動しているのか？ - ミクロな実験を複数実施する
・・NSMを伸ばす操作した場合に、実際にKPIが伸びるのか？
マクロの関連性についてはシンプルにグラフを書き、2指標間に強い相関があることを確認しました。
しかし、時系列に指標を並べただけでは擬似相関の可能性があり、NSMを伸ばしたところでKPIが伸びるのか疑問が残ります（勿論、マクロな連動性は視覚的に分かりやすいので、経営陣などへの説明にはマクロなグラフが適しているケースはあります）。そこで、NSMがKPIに一定の因果関係を持つことを示すために、複数のA/B Testを通じて下記の取り組みをしました。
- 因果関係がありそうか？：介入Tによって介入群のNSMを伸ばした場合に、KPIが介入群>対照群となるか？
- 再現性がありそうか？：介入Tを複数種類試した場合にも、NSM・KPI共に介入群>対照群となるか？（一回の実験のみだと、介入Tによってのみ or たまたま成り立っただけの可能性があるため、複数種類試しました）
結果的に、NSMがKPIに一定の因果関係を持ちそうなことが分かったため、腹落ち感・説得力が一気に増しました。まさにA/Bテスト実践ガイドにあるように、最も挑戦的な評価に成功し、開発チームの方向性がアラインされました。
評価方法を確立する上で、最も一般的かつ挑戦的なものの1つは組織のゴールメトリクスとドライバーメトリクスの因果関係の確立である。つまりこのドライバーメトリクスが実際にゴールメトリクスを促進しているかどうかの評価である
『A/Bテスト実践ガイド 真のデータドリブンへ至る信用できる実験とは 』（Ron Kohavi, Diane Tang, Ya Xu , 大杉 直也, 2021) 「第6章 組織を運用するためのメトリクス」より引用
2.2 NSMを中心とする改善サイクルを回し続けた
社内で定義の理解を一定得られましたが、NSMを伸ばす事例を作れなければ結局のところ「絵に描いた餅」です。
大雑把に下記4つのステップを回しました
- NSMを伸ばすための企画→効果検証の流れを確立する
- 素早く施策を試す仕組みを作る
- 施策リリースの知見を会社に貯める仕組みを作る
- 知見から施策を産むサイクルを回す
まずは、最初のステップです。
2.2.1 NSMを伸ばすための企画→効果検証の流れを確立する
NSMを直接伸ばそうとすると施策のイメージが出てきません。そこで、NSMを主要因に分解し課題選定と解決策実行をひたすら回しました。このプロセスは昨年の私の記事が参考になるかも知れません。
重要なポイントは「最もインパクトを出せそうなコスパの良さそうな主要因・施策は何か？」をPdMと徹底的に吟味したことです。コスパが良い施策を打つこと自体がインパクトを出すために単純に重要ですが、そもそもNSMを通じた改善施策でインパクトを早い段階で出せないと、社内でのNSMの存在感が薄れ、やがてはリソースを割けなくなる懸念があります。
2.2.2 素早く施策を試す仕組みを作る
また、施策リリースサイクルを加速させるために、A/B Testの実験成熟度にBI TeamのManagerとして投資を一年間続けました。弊BI TeamのNoakiさんが書いたA/B Testの記事が参考になるかもしれません。
2.2.3 施策リリースの知見を会社に貯める仕組みを作る
ある程度施策を打ったら、施策の知見を貯める仕組み作りも大切です。
このような話は「A/Bテスト実践ガイド」の第8章「インスティチューショナルメモリとメタアナリシス」に詳しいので、参考になるかもしれません。
組織に学びを貯めるために、各A/Bの施策は企画から効果検証まで統一のテンプレートを使って言語化し、誰もが見れるところで一元管理し、次なる成功の種を産める仕組み作りをしていました。
2.2.4 知見から施策を産むサイクルを回す
施策を複数打つサイクルを繰り返した結果、当たらない施策もあれば、当たった施策で大勝するケースもありました。ここで意識していたのは、大勝した時ほど深掘り＆横展開することです。失敗した原因を深ぼることも大事ですが、成功した理由を深掘り再現性をもたせる方がコスパが良いとPdMとよく議論し、結果的に成功体験が成功体験を産むサイクルを作れました。
2.3 NSM改善サイクルを回して得られたインパクト
このようなNSMを中心とした施策改善サイクルを回すことで、下記のようなインパクトを得られました。
- KPIを含む各種指標の成長
- 指標改善を目的とした、施策サイクルを回す仕組みの定着
- 指標と施策への鋭い感覚
- 「腹落ち感」を持って開発できる体験
数えきれない改善施策を打ち続けた非常にタフな一年間でした。
勿論、ここでは書いていない様々なTeam・社員の貢献の上に得られた成果です。特にPdMのWさん、ありがとうございました。
まとめ
BI Team Manager一年目の自分がデータ分析を通じて会社を推進させた事例を書いてみました。他にも書きたいテーマはありますが、長くなるので筆をそろそろ置きたいと思います。年明けに登壇の機会を早速頂いたので、「Data Analystが価値を発揮するための仕組みづくり」を話そうと考えています。
具体的には、弊BI TeamのNoakiさんが執筆したA/B Testの前述の記事のように、Analystが価値を出す機会を増やすためにBI TeamのManagerが何をやったのか？を中心にお話しようと考えています。
最後に、この一年間で私が特に意識していたことを載せたいと思います。社内の日報に自分が垂れ流してたのをまとめてみました。
- 常に構造化：Goal・長期目線から常に逆算
- 理想像に拘れ：理想像で最大値も限られる。理想が決まれば優先度の問題
- 巻き込め：周りを巻き込め。声を出せ
- 全部自責：自分が最後の砦になる。全ての変数を握って、自分が変える
また、BI TeamではData Analystを現在募集中です。まずはカジュアル面談からもお待ちしております！
一個人の例ですが、Productに関わるData Analystの参考に少しでもなれば幸いです。コメントや意見がある方は、@ba_data_ana までお願いします。
