はじめに
こんにちは、プラットフォーム事業本部の石垣雅人(@i35_267)です。 DMM.comのサービスで利用されるプラットフォーム基盤においてProduct Owner(以下、PO)を務めております。
今回は、2019年02月15日に開催された『Developers Summit 2019』で登壇してきた内容を補足説明しながらご紹介したいと思います。
登壇内容
セッションは、以下のタイトルで登壇してきました。
当日は、ユーザーレビュー基盤のプロダクトを例に『データ駆動戦略』を実現するために必要なことを『三種の神器』と定義して、主に以下の4点を主にお話しました。
- プロダクトがGrowthする流れ
- データ駆動戦略についての『Why / What / How to』
- ユーザーレビュー基盤について
- データ駆動戦略を実現する『三種の神器』
- データ分析基盤の重要性
- 優れた指標でないと『駆動』しない
- 高速にデータ駆動で計測→学習するための開発プロセス
ひとつずつ述べていきます。
プロダクトがGrowthする流れ
まずは、登壇資料の題名にもあるプロダクトをGrowthさせるためにデータ駆動の必要性をSequoia Capitalが提唱している成長モデルをもとに述べていきます。
以下の図をご覧ください。
プロダクトの成長段階としては、左図のような『S字カーブ』描きながら上昇して行くことが理想とされています。
はじめにEarly Phaseで緩やかに上昇(10％)して、そのあとGrowth Phase、Hyper Growth Phaseで急上昇(40％ + 40％)します。
そして、理想のプロダクトとしては右図のように『S字カーブ』が連続して続いている状態が良いとされています。
では、こういった理想のプロダクト成長曲線を描くためにはどうすればよいでしょうか？
１つの解としては、下の左図にあるように過去の機能からの学習です。 いかに今までの機能を分析して学習し、次の機能へと活かすことができるかが重要となってきます。
そして、どのように学習するかは右図にあり、『データ・ドリブン』という考え方です。
データを見ながら、戦略を立てさらなるプロダクトの拡大へと導いていきます。
セッションでは、データ・ドリブンを『データ駆動』と日本語に言い換えています。
詳しい内容は後述しますが、データが『駆動』することで、次のアクションへとつながる意味を分かりやすく表現しています。
データ駆動戦略についての『Why / What / How to』
次に『データ駆動戦略』について述べていきます。
そもそもデータ駆動戦略とは何でしょうか。以下の図で定義しています。
つまり、データ・ドリブン = データを軸としてプロダクト戦略を立てていくことで、プロダクトや組織における不確実性を極力まで下げることです。
では、なぜデータ駆動戦略が必要なのでしょうか？ Whyの部分を述べていきます。
以下の図は、データ駆動ではない開発プロセスの一例です。
クラムで行っていることを例にすると以下が簡単な流れになります。
- プロダクトバックログを作るにあたってPOが仮説を立ててストーリーベースでプロダクトバックログを作成していきます。
- それをスプリントバックログへ落とし込み開発チームが開発→リリースします。
- リリースしたものがインクリメント(=成果物)となり市場へ投入されます。
データ駆動ではない開発プロセスの中で一番問題になるのは以下です。
要約するとデータがないので、仮説立案が『直感』に頼ることになります。 直感に頼る仮説は、アイデアマンであれば量産されて、それがプロダクトバックログとして落とし込まれ、そのままリリースしなければいけない機能となります。
そうすると開発チームが開発しなければいけないものが増えていき圧迫していきます。この状況は避けなければいけません。
また、もう１つの問題点としては、データ駆動でないとリリース後にどうしてリリースした機能がヒットしなかったのか、分からなくなります。
つまり、上で述べた『S字カーブの連続』が起こりにくい状態になります。
以上がデータ駆動な戦略を立てなければいけない『Why』です。
次にデータ駆動戦略で何ができるのかの『What』の部分を見ていきます。以下の図にある5点です。
特に良い点は、3,4の部分です。
データ駆動は、仮説の妥当性が担保できます。
例えば、1つの機能を仮説としての妥当性を持たせる場合、パワーポイントなどに『どうしてこの機能が必要なのか』の資料を作成して上司やチームに見せる必要があったりするケースが出てきます。しかし、データ駆動の場合、事実としてそこにあるデータを提示すれば良くなります。
つまり、意思決定までのリードタイムを短くできます。
そして、それを開発するチームに対しても納得感を得ながら開発を進めることができます。
これが、データ駆動戦略を行うと実現できる『What』です。
では、この章の最後にどうやってデータ駆動戦略を実現するかの『How to』を説明していきます。以下の3つです。
- データ分析基盤 = まずはデータが集約していないと始まりません。
- 優れた指標 = データが集約した後にその中からビジネス価値があるデータをどうやって見つけるかを指標として定義していきます。
- 開発プロセス = 計測→学習までを高速化したプロセスを整備することでより効率的にプロダクトのGrowthを目指します。
次の章以降で、詳しく説明していきます。
データ駆動戦略についてのまとめ
- Why = 直感に頼る仮説は量産されやすく開発者を圧迫する。そしてリリース後学習ができずにプロダクトがGrowthしにくい。
- What = データを定量的に提示することで意思決定が高速化する。
- How to = データ分析基盤 → 優れた指標 → 開発プロセス
ユーザーレビュー基盤について
今回、実際にデータ駆動戦略を利用しているプロダクト例として『ユーザーレビュー基盤』を紹介します。
そして、DMMではユーザーレビューが導入されているサービスの仕組みを１つのプロダクトチームが専門で開発運用しています。
そうすることで、データを一元管理でき分析から効果的な施策を打つことができます。
一例ではありますが、データ駆動として以下をトラッキングしています。
JSのライブラリを埋め込むことで、どこまでスクロールしたかなど詳細なユーザー行動を取得できます。
データ駆動戦略を実現する『三種の神器』
では、本題であるデータ駆動戦略を実現する『三種の神器』を1つずつ説明していきます。
データ分析基盤
まずは、上で述べたようなトラッキングしたデータなどが蓄積されているデータ分析基盤についてです。
はじめに、なぜデータ分析基盤がデータ駆動戦略をする上で必要なのかを述べていきます。
つまり、データ駆動戦略は組織として遂行しなければ効果が生まれない。そして、そのためには優れたデータ分析基盤を使って効果を定量的に提示しなければならないといった形です。
DMMでは、こういったデータ分析基盤があり規模感としては以下です。
現在までに数千億レコードが蓄積されています。
こちら、どういった仕組みで構築されているかなどは以下に記事がありますのでご覧ください。
DMM.comのビッグデータ基盤を支える技術 - Speaker Deck
また、DMMではBIツールとしてはRe:dashを採用しており、権限を付与された人なら自由にSQLを叩いてほしい情報を取得できます。
最近では、非エンジニアである営業や運営の方などが、データ分析基盤からデータを取得するケースもあります。
今までは、営業や運営の方がエンジニアに対して必要なデータの収集を依頼していたが解消されます。
お互いのリードタイムが削減され、組織としてのケイパビリティ向上となります。
優れた指標
さて、データ分析基盤の重要性を説いてきましたが、この中からビジネス価値が高い指標(=データ)を取得して、KPIなどに落とし込まないと意味がありません。
社内にビックデータ基盤は、あるがあまり有効活用できないといった組織が多いのではないでしょうか。
データ駆動戦略では、『優れた指標でないとデータが『駆動』しない』と定義づけています。
データが駆動するとは、以下の図のような状態です。
何かの施策などを行う(1.Action)をすることで、データ分析基盤にデータが溜まり、結果(2.Result)を返してくれます。
その結果を見て、次のアクション(3.Next Action)が決まります。こうしたデータを見ることで次のアクションが決まることをデータが『駆動』すると言います。
今回、優れた指標として『3つの土台』と『4つの指標』をベースに述べていきます。
基本的には、土台を基本として4つの指標をもとにKPIなどのプロダクトの状態を可視化する指標を作成していきます。
この優れた指標のベースについては、過去に以下の記事でユーザーレビューのプロダクトを例に述べておりますので興味がある方はご覧ください。
本記事では、各4つの指標の要約と上記の記事では述べていない『相関指標と因果指標』について、ユーザーレビューのプロダクトに落とし込んだ時にどういったデータを取得すれば良いかについて言及していきます。
まずは、ユーザーレビューのプロダクトのデータ取得イメージとしてユーザー行動を可視化します。
大きく分けて2つあります。
- 『書く』という行為の要素
- レビューを書く人 + レビューを書く(投稿)
- 『見る』という行為の要素
- レビューを見る人 + レビューを見て購入
この行動をそれぞれの指標で見ていきます。
定量的指標 vs 定性的指標
ユーザーレビューのプロダクトとしての定量的指標としては、以下があります。
それぞれ、『書く』『見る』という行為別に考えていくのがポイントです。
また、定性的な部分で言えば、現在はユーザークレームを毎月可視化してインプットとしています。
虚栄の指標 vs 本物指標
虚栄の指標とは、次の行動につながらない指標のことです。逆に本物の指標は、次の行動につながる指標です。
例えば、会員登録数という指標は虚栄の指標です。
もちろん、追うべき数値ではありますが、時間とともに増加するものなのでモニタリングしてもデータが駆動しておらず次の行動につながりません。
本物の指標では、会員登録数の他に以下の指標と見ていく必要があります。
- 離脱率
- アクティブユーザー数
ユーザーレビューのプロダクトとしての虚栄の指標と本物の指標としては、以下があります。
新規レビュアー率は、その月に会員登録したユーザーを母数にどのくらいレビュアーになっているかをコホート分析*1で見ていきます。
先行指標 vs 遅行指標
3つ目の指標として、先行指標と遅行指標です。
ポイントとしては、データ駆動でデータを追うことで未来をある程度予測できます。
例えば ユーザーレビューを増やしたい場合、季節ごとにレビュー投稿数の多い・少ないといったボリュームにある程度偏りがあることがデータから読み取れます。そちらを踏まえた上で「どのくらいユーザーレビューが増えたか」といったキャンペーン評価を行うための効果測定が大切です。
相関指標 vs 因果指標
この指標が一番大事だと感じています。 そもそも、相関指標と因果指標に関しては以下の図にあるとおりですが、一番大事なのは因果指標を見つけることです。
そのためには、相関指標がありそうな指標をひたすらに日々モニタリングして分析していく必要があります。
例えば、レビュー増加率をあげる因果指標が知りたいときは、月ごとのバラツキがあるかアクティブユーザー数との関係などコホート分析などを利用しながら可視化していきます。
高速にデータ駆動で計測→学習するための開発プロセス
三種の神器の最後に開発プロセスの話をします。
記事の冒頭で『直感に頼る仮説は量産されやすい』という問題提起をしましたが、データ駆動戦略を実現する開発プロセスの流れは以下になります。
ポイントとしては、有名なリーンスタートアップのBMLループ*2というサイクルを使いながら以下を担保していきます。
- A/Bテストやユーザーストーリーマッピングなどで仮説の妥当性を担保する。
- リリース後にデータを計測→学習することで次の仮説に活かす。
特にLearn→Ideaの部分で仮説の妥当性を担保すると、今まで直感ベースの仮説が10機能あったとしても、3機能などに減り、さらに機能の優先順位もデータをもとに策定できます。
まとめ
いかがだったでしょうか。今回は、『データ駆動戦略』をキーワードに実現する方法をユーザーレビューのプロダクトを例に交えながら説明させていただきました。
特に下図の三種の神器を覚えていただければ、データ駆動戦略のスタートはできるかと思います。 ぜひ、データ駆動戦略に取り組んでみてください。
最後に
最後に採用情報をお伝えさせてください。 私がPOを務めるプラットフォーム事業本部 Customer Decision Support Teamでは、一緒に働いてくれる仲間を探しています。 2018年7月に立ち上げたばかりでまだまだポテンシャルを秘めたチームです。 少しでもご興味のある方はぜひご応募ください！
また、プラットフォーム事業本部には、各プロダクトチームと連携してDMM.comの多様なビックデータからデータ分析してくれるアナリストチームやビックデータ基盤を作っているエンジニアが存在します。今回のユーザーレビュー基盤のデータもアナリストチームやビックデータ基盤のエンジニアと協力しており、日々データ戦略を立てています。そちらも採用募集しておりますので、ぜひご応募ください。
*1:類似したユーザーをセグメンテーションして、時間の経過とともに比較していく手法
*2:IdeaからスタートしてプロダクトをBuild→Productをしてリリースします。そしてデータを計測して学習するといった流れです
