データ基盤を作る際のデータ分析の「目的」をどう設定するのか

「データ分析は目的が大事」より先ってあまり語られないよね

データ基盤を作るときには「目的」が大事とよく聞く。
「データをとりあえず集めてみたので、ここからどう活用するか考えよう」が失敗の典型パターンであるからだ。それはその通りだと思う。
だが、「目的」をきちんと考えられる人がどれぐらいいるかとなると、個人的な経験ではほぼいないと言っていい。「目的」が分からないと自覚できる人はむしろかなり優秀な部類だと思う。
そもそも、データ基盤ができるような新規サービスを前にして「このサービスで何の分析をしたい？」と問われてもかなり難しいだろう。だってサービスほぼ動いてないし。

この分野を経験していて分かってきたことだが、データ基盤の導入前にイメージしがちな「分析」と、データ基盤を導入してデータ分析が組織に根付いてから実際に行われる「分析」にかなり乖離がある。
そもことがデータ基盤の目的の設定を難しくしている。
この記事は、データ基盤導入後に行われる「分析」を整理し、きちんとしたデータ基盤の「目的」を設定する手助けになれば嬉しい。

データ分析は「攻め」と「守り」がある

攻めの分析とは

データ分析には攻めの分析と守りの分析があると思っている。
「攻め」の分析は、よくデータ分析でイメージされるような分析である。つまりこちらが上記で書いた「データ基盤の導入前にイメージしがちな分析」である。
サービスのインサイトを発見し、意思決定に利用されるような分析である。売上のような重要KPIの改善が分析の最終的な成果となり、企業としての価値も分かりやすい。
このイメージの分析を自分は「攻めの分析」と呼んでいる。森岡さんのUSJの本の事例などは典型的な攻めの事例だろう。分析が成功事例として記事にされる場合は攻めが多い。

データ分析は「意思決定に使われなければならない」とよく言われる。意思決定に関わらないやってみただけの分析は意味がないということだ。例えば、アプリに何か施策をやったとしてその施策が効果がなければ前回に戻すだろうか？戻す選択があるのならば意思決定があるが、分析をやってもやらなくても以前に戻ることがない場合には、確かに分析をやる意味はない。

しかし、「意思決定に繋がるような分析」は、かなりサービスを理解した仮説を構築しその検証が必要であったり、問題点を発見するにもとても自摸なく細かい指標を抽出する必要がある。
そんなことをデータ基盤も構築できてないから想定することができるだろうか。
つまり、攻めの分析は最初にデータ基盤を作るための「目的」に設定するには筋が悪い。

守りの分析とは

守りの分析は、攻めのような派手さはない。むしろ、きちんとした企業ならまぁやっているよねと言うような内容なので改めて記事でピックアップされることもない。
しかし、そのきちんとした企業ならやっていることをきちんとやれている企業は実は少ないんじゃないかと思っている。少なくとも自分の場合、データ分析業務はほぼこの「きちんとした企業にすること」にほとんどの力を注いできた。
なので「守りの分析」は「きちんとした企業がやっていること」を具体化する作業になる。
自分は、守りの分析を評価、把握、深堀、監視に分けた。いかにそれぞれを説明する。

評価

評価は効果測定のことである。
例えば、キャンペーンや機能改善の効果測定を行えるようにすることである。LPを作ってアプリの会員登録を促すキャンペーンだったら、インストール数や新規会員登録の数、流入経路の測定をしないといけないと具体化できる。
これをできるようにすることが守りの分析の「評価」である。
自分のサービスが、会員登録があるか、課金があるか、広告を打つかぐらいはサービス開始前でも十分に把握できるだろう。その評価を抽出できる仕組みを作ることは、データ基盤の目的に十分なると思う。
しかし上記で「意思決定をしない分析は無意味である」と矛盾する。ぶっちゃけ、この評価の仕組みを作っても意思決定はしないことは多い。しかし、施策が成功か失敗か評価することはPDCAサイクルが回る、攻めの分析を行う出発点になるために重要である。
あと、経験則的にたぶん分析で一番求められるの最終的には圧倒的にこれだから絶対作っておいた方が良いよ。

把握

把握は、事業の全体像の把握である。会員数やLTV、数字がどれぐらいになっているのかの把握することである。把握に必要なデータは、KPIツリーや事業計画書を指標化するなどして、定点観測したい指標をまとめることで明確化する。
こちらもやはり「データで意思決定をする」と相性が悪い。事業の全体像を把握して意思決定することは多々あるだろうが、事前にどんな意思決定するかを決めることは難しい。
むしろ全体族は、意思決定の前提になっていることが多い。
「KPIツリーの上位を適切なタイミングで把握するため」は十分データ基盤を作る目的になる。
ただ、大事なのはKPIをしっかり作ることである。KPIツリー、カスタマージャーニーなどを用いてただただ思いついた重要な数字でなく、整合性のあるロジックを作った方が失敗は少ない。
そもそも、それができていなければデータ分析基盤云々言う前にそこをきちんとやれって話になるし、そこをきちんとやっていれば必然的にデータ分析基盤が必要だよねって話になるはずである。

深堀

深堀は、把握をさらに細かく分析することである。把握で全体像を見たときに、「どこの店舗で売り上げが落ち込んでいるんだろう？」「何歳ぐらいのユーザーがこの動きをしているんだろう？」など、いつも切り口のパターンが決まっていることがある。
このような原因分析のいつもの型のことを自分は「深堀」と呼んでいる。
おそらく、データ基盤の最初のころはなくてもすぐに出てきてtableauのフィルターに現れてくる。

監視

監視は把握と似ているが、こちらは目的が明確である。監視は、「ここが急激に変動したらヤバい数字を定常的に監視すること」が目的である。つまり、指標に対するアラートの設定である。
課金率、会員登録数などは典型的に落ちたらヤバい指標であろう。
しかし、そういったKPIツリーの上位だけでなく、KPIツリーの下の方になるといつの間にか下がっていた数字を発見することがたまにある。
他にも、事前に「この数字がここまで変化すればこんなアクションを行う」と決まっていればリスクを最小限に抑えることができる。
例えば、「お菓子の売り上げがx円以下になれば原因調査を行う」である。アラートがなってパートさんに聞いてみたら、実は近くにお菓子のまちおかが近くにできていたと簡単に分かる可能性もあるが、トリガーがなかったらずっと把握できず、気まぐれで見たときにようやく発覚することになる。

まとめ

データ基盤を作るときは、この４つの守りの分析を目的に設定すればいいと思う。と言うか、KPIツリー作って最低限それを取得できる状態を目指せば、最低限の状態はできると思う（KPIツリー作るのも結構難しいけど）。

ただ、個人的な経験から言わせてもらえば「データ分析基盤は目的を設定しないと失敗する」は半分嘘だと思っている。事業が走り出したらすぐに「目的」は発生するし、とにかく走り出したプロジェクトも後付けの目的でも、「なんとかなれ～！」でなんとかなった。めっちゃ頑張ったけど。

ただ、最初からうまくいくには絶対にあった方が良い。それと、指標の定義をとにかく明確にすることだ。まず一番荒れるのは「新規」の定義だ。例えば、インストールした人なのか会員登録した人なのか。インストールした人を「新規」とした場合、端末を変えて再インストールしてログインした場合も「新規」とカウントしてしまう。
マーケチームとサービスチームで定義が異なるなんかもよくある。

むしろ、最初から満点のデータ基盤を作るなんて無理だ。一番必要なことは、目的を作り、データ基盤を作り、実態を把握して目的を修正しデータ基盤を修正する覚悟かもしれない。
データ基盤は、導入することに優秀な人材と評価をしがちである企業もあるだろう。だが、運用のフェーズでただ維持するのではなく、改善できる人材をあてるのが成功のコツだと思う。

自分の経験則をまとめた話だが、誰かの参考になれば嬉しい。