Projectを推進させるデータ分析
はじめに
この記事は「Eureka Advent Calendar 2022」23日目の記事です。
こんにちは、BI TeamのBaba(Seigo Baba)です。私は新卒でモバイルゲーム会社に入社しData Analystを5年ほど経験した後、1年半前にEurekaのBI Teamにjoinしました。EurekaのData Analystが関わる領域は様々ありますが、私はProductに関わるのがメインとなっています。
本記事は、Product Data Analyst(Product分析を主な生業とするData Analyst)として自分がデータ分析をする上で心がけていることを言語化します。Data Analystの働き方の一つの例をお見せできればと思い筆を取りました。Data AnalystのRoleに唯一の正解は無いと考えているので、あくまで事例の一つとして読んでもらえると幸いです。
想定読者
- Productに関わるData Analystの働き方に興味がある人
- Data Analystなりたての人
- Data Analyst 1年目の自分
EurekaでのProduct Data AnalystのRole
EurekaのProduct Data Analystの主なRoleは、Productに関する各種Projectに所属しデータを武器にProject推進をすることです。勿論、所属Project外のデータ分析やBI Teamのスループット向上(例：Data基盤整備)に取り組むこともあります。時期にもよりますが割合は8:2 ~ 6:4くらいです。
Product Data Analystは基本的には1つのProjectに専任で関わりますが、複数のProjectに関わることも少なくないです。各ProjectにはDaily/Weekly単位で関わり、同じ数字目標（売上・エンゲージメント指標 など）を背負っています。まさに、同じ釜の飯を食う関係性となってます。数字目標をどうやって達成するかをプロジェクトチームと日々考えています。
本記事では、各Projectを推進するために私がどのようなデータ分析をしているのか？を話していきます。
Projectへの私の心構え
私の心構えは一言でいうと、「ProjectのROIの最大化を目指す」です。そのための手段として、”主に”データを使って、価値ある意思決定を推進することを目指しています。
ここでのROIは下記を指しています。
- ProjectのReturnを上げる( 売上、エンゲージメント指標など)
- ProjectのInvestmentを下げる(実装工数、関心コストなど)
数値目標が売上のProjectを例に平たく言うと、売上最大化を目指してますってことです。
Data Analystになりたての自分は「アクションに繋がるデータ分析をしよう」を意識していました。しかし、アクションだけだとどのデータ分析を優先的にしたら良いか分からなく行き詰まったことがありました。その先にあるReturnやInvestmentも考慮すると優先順位を決めやすいことに気づいて、自然と仕事がしやすくなりました。そのため、現在はROIの最大化を意識しています。
Projectの施策サイクルは大まかに、課題を見つけ、解決策を実行するサイクルを繰り返すことで回っています。課題選定、解決策実行の各ステップを回す上で、自分というリソースの使い方は勿論、プロジェクトチームの皆さんのROIを最大限高めるためにどうしたら良いか？を日々考え続けています。その中で最も大事だと考えているのは、各ステップで「今関心を持つべき話は何か？」を自ら生みだすことです。
前提として、関心を持つべき話の答えは誰にも分からないと思ってます。その中で、この話を今すべきではないか？の自らの考えをProjectにブツけています。勿論ズレていることもありますが、論点を疑う役割を他人任せにせずに、何が今/未来に求められるか？を自分なりに考えています。
「”主に”データを使って」という表現は、データ以外の領域の知識/スキル（例：Product Management領域）もProject推進で必要だと常々感じているため書きました。勿論、データ分析を軽んじる気持ちは無いですし、分析スキルの専門性を磨くために勉強を日々続けています。
長々と書きましたが要は、限られた日々の時間をプロジェクトチームが有効に使うためにはどうしたら良いか？をBabaは考えていますって話です。（仲の良いPdMに、「Babaの口癖は、それをやる意味あるんですか？だよね」と言われたこともあります）
次節からは、課題選定から解決策実行のステップを推進するために、Babaが実際にどのようなデータ分析をしているのか？を紹介していきます。
1. 課題選定。何に注力するか？
超が付くほど重要なテーマです。注力する課題次第でReturnの最大値は決まります。最近発売された『解像度を上げる』でも同様の記述があります。
解決策が課題を完璧以上に解決していたとしても、課題の大きさ以上の価値は生まれないのです 。『解像度を上げる』より
課題発掘は主に下記を手がかりにやってます。
- KPIツリー
- ファネル分析
- 定性調査/自分＆プロジェクトメンバー＆PdMのユーザ感覚
- シナリオプランニング
- 事業戦略の未来から逆算
1.1 課題の発掘方法
KPIツリー
こちらは最も馴染み深いテーマでは無いでしょうか。例えば、「ラーメン屋の売上=顧客単価*顧客数」に分解でき、顧客単価が今1000円だとしたら、売上を伸ばしたいなら顧客数増加が課題では？という話です。勿論、顧客単価も1000円よりも伸ばせる可能性はありますが、ラーメンが土俵だと難易度が高いと私は感じています。
私が意識していることは、KPIツリーで見落とした指標が無いか？と幅広い視野で見ることです。先程のラーメン屋の例では、（お気づきだと思いますが）売上のみを見ているせいで、粗利・営業利益・原価・販管費の概念が欠落しています。なので、営業利益を見るようにすると、材料調達ラインを見直して原価を下げる、などの課題・アクションが一気に産まれます。これは単純な例ですが、サービス開発の現場でも意外と変数を見落としているケースは見られます。
今のKPIツリーで良いのか？、意識外に課題は無いか？、動かせないと思いこんでいる固定値は無いか？と定期的に広い視野で見渡すように自分は心がけています。
もしKPIツリーで迷うことがあれば下記が助けになるかもしれません
ファネル分析
個人的には思い入れ深いテーマです。私が困ったら初手で使うことが多い武器です。ファネル分析については、MercariさんのAnalytics Blogに詳しいです。
私がファネル分析で大事にしている観点は下記です。
- 前提で見落としている致命的条件は無いか？
- ファネル遷移率でなく、流入に課題は無いか？
前提で見落としている致命的条件は無いか？
自分が何度も踏んだことがある例です。例えば、ECサイトの購入フローをファネル分析で最適化する事例を考えてみましょう。ファネル改善を通じても遷移率がなかなか上がらず見直したら、クレジットカードを登録していない人の導線への流入が多かった事実が分かり、ファネルとは直接関係ないカード登録フローを改善したら購入ファネルも改善したケースです。
これは分かりやすい例ですが、なにか致命的条件を見落としてないか？を常に疑うのを心がけています。
ファネル遷移率でなく、流入に課題は無いか？
これも何度も踏んだことがある例です。前提として、ファネル分析は楽しいです。皆で緻密に離脱原因を考えたり、A/B Testを実施したり、PDCAが回しやすく成果も出るためついつい深みに入りがちです。
しかし、本当の課題はファネルへの流入にあるケースがあります。ファネル遷移率向上にそれ以上労力を使う意味があるのか？と問いを立てることを私は意識しています。
例えば、導線から購入完了まで6ステップあるケースを考えてみましょう。導線〜購入完了の遷移率が6%だとします。これだけ見るとまだまだ伸びしろがあるように見えますが、各ファネルを見ると最初の5ステップは90%で遷移、最後の購入ページが10%だと分かりました。
(0.9)⁵ * 0.1=0.059=5.9% というオチです。
これは私の肌感覚ですが、各遷移率の90%をそれ以上伸ばすのは難しいと思います。また購入ページの10%を伸ばすのも至難の業です。
このように事実上の上限を迎える例は稀ですが、ファネル分析にとらわれずファネル以前の流入を増やす努力ができないか？（例：導線の訴求を見直さないか？）など視点を変え、Projectの関心事を移す必要があるか検討することを私は意識しています。
定性調査/自分＆プロジェクトメンバー＆PdMのユーザ感覚
こちらも言わずもがななテーマでしょう。Product内の定量データで行動の結果は分かっても、理由や利用シーンが分からない問題に直面したことがあるData Analystは多いと思います。弊社には素晴らしいConsumer Insights teamがあるので、よくお世話になっています。定性調査の結果を定量データと組み合わせて、課題の大きさを見積もる手法は私もよく選択します。弊社Okumura(Jun Ernesto Okumura) が前職で発表した課題優先度がまさにその事例です。
各メンバーやPdMのユーザ感覚を頼ることも多々あります。to Cサービスですので、自分で使ってみたユーザ感覚は意外と当たるものです。言語化・ユーザ視点に長けているPdMと議論して生まれた課題・アクションが刺さった経験は何度もあります。
PdMとの議論の土俵に立つためにお世話になっているのが下記の書籍です。
シナリオプランニング
個人的に直近テーマになることが多かったのが、シナリオプランニングです。日々の課題に向き合っているだけでもProjectは前に進みますが、未来を想定した先回りの課題発掘も時には必要だと感じています。シナリオプランニングは『NOKIA復活の軌跡』に詳しいです。
一番分かりやすいのが、新機能リリース後の動きを事前に整理することでしょうか。例えば、自分は下記を整理することを意識しています
- 最重要指標が何であり、目標未達の場合に取れる動きは何か？
- 想定外の副作用が発生しないか？起こった場合にRollBackはするか？その基準は？
- (A/B Testは特に) 全展開基準・撤退基準はどうするか？
これらの動きを事前に整理する理由は、リソースや対策方針を事前にPdM or しかるべき人と合意してないと、適切に動けない可能性があるからです。特に新機能リリース直後は忙しい可能性が高いため、時間がある内に検討をある程度済ませておきたいです。Product全体で勝負の時期と重なっていると尚更です（例：年末年始、GWなど）。そのような時期だと、対応が遅れると事業全体の損失が大きいので、シナリオプランニングで少しでも損失確率を下げて、ROI向上を目指しています。
シナリオプランニングの副次的な効果として、事象の解像度が上がることが挙げられます。例えば、新機能リリースで起こりうる副作用を洗い出すことで副作用を回避できる実装ができないか？などです。
日々シナリオプランニングすることは労力が掛かるので、大きなイベントタイミング（大型機能リリース日や年末年始など)の数週間前には自分は意識的にシナリオ・潜在的課題を考えるようにしています。あらゆるシナリオを想定するのは無理ですが（例：数年後に感染症流行で生活スタイルが一新される）、蓋然性が高いシナリオへの対策はある程度用意したいと考えています。
事業戦略の未来から逆算
前述までの課題発掘方法は近未来の視点で生まれる課題がメインとなります。しかし、それだけではProject・事業に非連続的な成長をもたらすのは難しいと考えています。そこで、時には長期目線で課題を発掘する必要があります。
1年後・5年後に事業・会社はどうなってありたいのか？をPdM・CxOらの考えを聞いたり、書籍の考えを参考にしたりし、そこからProjectに求められる動きを逆算することも時には必要です。自分は下記書籍を参考にしています。
常日頃から考えるのは難しいですが、Q単位の節目で考えることを自分は心がけています。
1.2 課題Sizing
前節までで課題の発掘方法を紹介しました。これらを駆使して課題は山程出てきます。しかし、本当にやるべき課題を絞る必要があります。
そこで重要となるのが課題Sizingです。この課題を仮に解決した時にProjectにどの程度Returnをもたらすかをザックリ試算して優先順位をつけることは、ROI向上に不可欠のステップです。
具体的には、KPIツリー・ファネル分析・定性/定量調査を駆使して試算します。一番イメージしやすいのがKPIツリーでしょうか。先程のラーメン屋の例で考えてみます。
例えば顧客単価が1000円であり、日毎に100人来店する架空の店舗で売上を上げる方法を考えてみます（粗利・利益率はこの例では無視）。先程も説明したとおりラーメン屋で顧客単価を1000円よりも上げることは難しいでしょう（1000円を疑うのは時には大事ですが、今回は疑わないことにします）。そこで顧客数を更に伸ばすことを課題に置きます。変数を絞る行為はProjectのROIを高めるためには重要で、自分やプロジェクトチームの思考リソースをフォーカスすることができます。
さて、顧客数はどこまで伸ばせるでしょうか？ このお店がチェーン店であり店舗データが豊富にあるなら、駅からの距離・駅の利用人数・飲食店の数などに注目して回帰分析なりで需要予測をし、この課題の売上インパクトを見込むことができるでしょう。チェーン店で無くデータが豊富で無ければ、フェルミ推定などで商圏の人口 、商圏の客層などに注目してオーダーレベルの概算値をSizingできるでしょう。
勿論、この課題Sizingで良いのか不安はあります。しかし、そもそも完璧な課題Sizingは不可能だと考えています。また、事業の将来を見据えると、今はReturnが見込めなくても取り組まざるを得ない課題も時にはあります。関係各所と議論を重ねて、納得のいくロジックを構築し、ファクトを集めて各課題をSizingして取り組むべき課題を我々は決めています。
そろそろ課題選定の話は終わりにしたいと思います。
長々と書きましたが要は、視野を広く持ってどこに課題が有るか網羅的＆深く考え、Sizingを通じて最も筋が良さそうな課題に取り組むようにしています。
課題選定は幅優先探索>深さ優先探索の感覚を持つようにしています。何の課題に注目するかは自由です。
さて、次は2.解決策実行の話です。
2. 解決策実行
2.1 解決策の発掘
自分が最も意識しているのは、解決策の発掘はプロジェクトチーム全員の知恵を借りることです。
下記の『一兆ドルコーチ』でも
背景情報をメンバーに伝え問題解決の知恵を借りると、想像を超えるソリューションを生み出してくれる。『一兆ドルコーチ』より、Babaによる意訳
と記述があります。
課題と事実をプロジェクトチームに正確に伝え、アイデアを引き出すことを私は意識しています。ダッシュボードを整備することは勿論、日々の朝会やリリースの節々でプロジェクトチームに状況を伝えることを続けています。そうすると、様々なProfessional(Client/Backend Engineer、PdM、Designer、 Marketer など) がそれぞれの視点・専門性をフルに活かして、様々な解決策を発案する場面に何度も遭遇しました。
詳細は話せないですが、執筆時点の本日もとあるProjectで企画会議してたら素敵なアイデアが沢山生まれて、その中のいくつかがReturn見込めそうで筋が良さそうだったから早速開発しリリースしました。翌日にはProjectの最重要指標が想定通り伸びてガッツポーズしました。
2.2 解決策の仕様決定
解決策を発掘できた上で、解決策を実行に移すためには決めないといけない項目が沢山あります。例えば、特定機能の特定セグメント（例：機能未利用だが商品購入経験があるユーザ）の利用UUを増やすために割引CPのプッシュ通知を打つ解決案が出たとしましょう。そうすると、下記を決める必要があります
- どの時間帯に打つ？
- 訴求文言は？
- etc…
その中で、「データ分析に基づいて仕様を決めたらReturnを高く見込めるか？」を私は意識しています。逆に言うと、分析しすぎないことです。
例えば、時間帯は分かりやすい例です。プッシュ通知開封回数の真の最大化を目指すならば、今回のターゲットとなるセグメントが過去のプッシュ通知に反応した回数を調べて、開封回数が多かった時間帯を分析する案はあるでしょう。
しかし、そこまで最適解に拘る必要はあるでしょうか？これは私の考えですが、おそらくユーザセグメントによってプッシュ通知を開封する時間は大きくは変わらないと思います。更に、分析しなくとも、プッシュ通知の開封回数が最大を取る時間帯は、ユーザ全体のログインUUが最も多い時間帯に概ね近いと推定されます。
よって、プッシュ通知を打つ時間帯の仕様は、ユーザ全体のログインUUが最も多い時間帯に決めるで十分だと思います。（勿論、あえてログインUUが少ない時間帯に打つ戦略もあると思いますが、ここでは考慮から外します）
一方で、訴求文言はどうでしょうか？これは私の経験ですが、文言次第で開封率は1.0~2.0倍程度まで伸びる印象です。なので、これらの過去事例を分析（例：購入経験があるユーザの開封率が高かった文言を調べる）するのはReturnが高い分析と考えています。また、文言のA/B Testができる準備を進めてもいいかもしれません。A/B機構ができると様々な文言を試せPDCAを回しやすく、長期的なナレッジも溜まっていきます。短期目線でも長期目線でもReturnが高いデータ分析と言えるでしょう。
2.3 解決策のSizing
このステップも欠かせないです。課題発掘→課題Sizing→課題選定と同じステップを、解決策にも踏むことで、よりROIが高い解決策を選択することができます。Sizing方法は解決策次第なのでケースバイケースですが、最も分かりやすい例は需要予測でしょうか。
例えば、先程のラーメン屋の例で考えます。隣駅に新たに出店する解決策をとって顧客数増加・売上増加を狙うとします（販管費などは無視）。この解決策のSizingも課題Sizingと同様に、需要予測の回帰分析やフェルミ推定などで概算値をSizingできるでしょう。
課題Sizingと同様に解決策Sizingも完璧な予測は不可能なものであると割り切るのも大事にしています。結局のところ、解決策をリリースするまでは答えは分かりません。なので、この解決策を信じて良いか？をPdM・Financeと議論を重ねることが重要だと考えています。
2.4 解決策の効果検証方法を決定
Data Analystが最も効果を発揮するステップです。皆さんご存じだと思いますが、解決策を実施前に効果検証の仕様を決めることは重要です。このステップを飛ばすと、解決策リリース後に結果が良かったのか悪かったのか全くわからない可能性があります。
Product分析をしていると様々な効果検証をしたいケースに遭遇します。例えば、A/B Testをどのように実施したら良いか？関心のある指標が複数あり多重比較をする場合はどうしたらよいか？ そもそもA/B Testができない場合はどうしたら良いか？
実務をこなすと上記のような様々な問いが何度も産まれてきます。それらを打ち返せるように常に知識・スキルを吸収することを私は心がけています。参考程度に私が参照することが多い書籍を列挙しておきます。
このようなステップを踏んで、我々は解決策実行を進めています。一方で、明らかに筋が良さそうなアイデアであれば早く試せる方法がないか模索して議論するのも大事と考えています。丁寧にステップを踏むことに固執すると、リリースまでに時間がかかります。その期間分だけ売上などのReturnを失うのも勿論、リリースによる我々の学びの機会も失われます。勿論、思いついた解決策を全て試す工数はありません。そこのバランス感覚を磨くことも意識しています。
最後に
過去の自分を振り返りながら、自分がどのようなことを意識しながらデータ分析を通じてProject推進を進めているかを言語化してみました。データ分析は完璧な正解をもたらすものでは無く、今より不確実性をちょっと下げてくれるものだと自分は捉えています。そのデータ分析を通じて、自分が関わっているProjectのROIを少しでも高められればと思い日々を過ごしています。
一個人の例ですが、Productに関わるData Analystの参考に少しでもなれば幸いです。コメントや意見がある方は、@ba_data_ana までお願いします。
