yigarashiのブログ

学んだことや考えていることを書きます

『DMM.comを支えるデータ駆動戦略』を読んだ

最近はエンジニアとして事業への貢献度を高めたくなっていて、同僚が本書をオススメしていたので読んでみました。チームや社内でデータ駆動の意思決定がどんどん盛り上がっていたこともあり、データを軸にしたアジャイル開発について、一度まとまった知見を得たいと思っていたのでした。実際に読んでみた感想としては、データ駆動アジャイル開発の大枠を掴むことができ、かつ実際の事業に基づいて各所がしっかり肉付けされているので、具体的なアクションとして実行しやすい知見も多くあり、とても良い本だったと思います。

ざっくり要約

本書の議論は、事業がブラックボックスであるために成長させる方法が分からないという課題から始まります。これまでは、多くの人が手探りでやっていくなかで、ごく稀に全てを見通すスーパースターが現れて事業を成長させていました。しかし、それだけでは目の前の事業が沈没してしまうので、どうにか凡人でも事業を伸ばせる再現性のある手法が必要になります。それこそが本書の言うデータ駆動戦略です。事業をKPIツリーによって表現し、KPIに対する仮説立案とその検証を繰り返すことで、ブラックボックス化された事業を徐々に予測可能なものにし、事業改善の精度を高めていきます。データ駆動戦略を進める上では、より高速に仮説検証のイテレーションすことが大事です。早く知見が増えれば、より早く施策を軌道修正することができます。そのために、A/Bテストによって失敗をコントロールする、アジャイルに進める、バリューストリームマッピングをはじめとしたツールでプロセスを検証・改善する、といったプラクティスが紹介されています。

さらに、仮説検証の結果による状況の変化や市場の変化に素早く適応したり、自発的にプロセスを改善していくためには、学習する組織ないし自己組織化された組織が重要であると述べられており、そうした組織を作るための方針として「戦略的Unlearn」が紹介されています。Unlearnとは、既存のやり方やメンタルモデルにゆらぎを加えて崩し、もう一度積み直すことで体系化するプロセスのことで、それを戦略的に起こすことで自己組織化を進めようというのです。世間で流行っている手法や隣のチームでうまく行っているプラクティスを取り入れることで、既存の手法を相対化したり、新しい手法をチームに合わせて改善して、より成長していくことができます。しかし、単に戦略的Unlearnといっても難しいので、戦略的Unlearnを進めやすい枠組みにまで議論は及び、その文脈でXPとスクラムが厚く解説されています。XPはある種のプラクティス集であるからゆらぎを生み出すのが容易であるとか、スクラムは自分たちのプロセスをふりかえるセレモニーがふんだんに用意されているので戦略的Unlearnしやすい、といったことが述べられています。

特に気付きのあった点

まず本書を読んで強く感じたのが、「本気で」データ駆動してるなということです。事業改善やプロジェクトを始めるなら、まずはKPIツリーを作るところから始める。KPIツリーに必要なデータはとにかく全部取る。データの重要な因果関係についてはA/Bテストで検証するといった具合です。そのなかでも特に、今ある機能を消すだけのA/Bテストをして、改善しようとしている機能が本当にコンバージョンと因果関係があるのか確かめるという事例に衝撃を受けました。A/Bテストといえば新機能の効果を検証するイメージが強かったのですが、確かにそこに限る必要は全くないです。企画を科学的なプロセスと捉えて、リスクの高い不確実性をデータによって淡々と排除しており、一歩先のパラダイムにいるなと感じました。

また、スクラムを運営しているエンジニアとして、データ駆動戦略とスクラムシナジーについて様々な側面から論じられている点も面白かったです。仮説検証を素早く進めるという観点では、職能横断なスクラムチームはリードタイム削減に有利な上に、スプリントごとにリリース可能なインクリメントを作成することを基本とするので、検証、つまりユーザーに触ってもらってデータを集めるまでにかかる時間を短縮できます。スプリントのたびに再計画が可能なので、仮説検証の結果を開発に反映するチャンスもすぐにやってきます。データ駆動もスクラムも不確実性に対処するための枠組みなので、そのあたりが本質的に相性が良いのかもしれません。

最後に、自分が関わるプロダクトでデータ駆動を進めるにはどうしたら良いかを考えてみると、本書ではデータ駆動を土台として議論を展開していますが、実際にはそれ以前にサービスのミッションやコアバリューが定まっていることが重要だと感じます。単に収益モデルをKPIツリーにして、収益が上がるなら何をしてもよいわけではないはずなんですよね。一時的に末端の数字は上がるが、実はユーザーの価値を損ねる施策というのはいくらでも考えられると思います。KPIツリーに収益とユーザー価値の両方が現れて、それが交わる様子が自然に表現されているのが理想だと思います。そして、サービス的にまずい施策を打つと、相関指標としてユーザー価値がちゃんと落ちると嬉しい。そうした「良い」KPIツリーを作るためには、言語化されたサービスの価値が大事だと思います。

とはいえ突然すべてが完璧になることはないので、まずは小さなところから、データ駆動の文化を作っていくぞという気持ちです。