はじめに
データ解析本部のn_maoです。
前回は高速集計ツールmコマンドのご紹介をしました。
今回は趣向を変えて、社内に分析部隊をゼロから作り、データドリブンなサービス改善を実現するためにまず行うべきこと、意識することをまとめてみました。
これは実際にゼロから初めた私の経験に基づくものです。
１つのケーススタディとして読んでいただければと思います。
主張を大まかな流れに分類すると、
1. 分析環境を整える
2. 社員のデータに対する意識を高める
3. データ分析とサービス開発を結ぶ仕組みを作る
4. 小さな効果を体感してもらう
5. 現状を把握し、指標を作る
という感じです。
以下で各トピックの詳細について触れていきます。
1. 分析環境を整える
分析のためのサーバーを用意する
当然のことですが、念のため。
データ分析や集計を行っていると、どうしてもメモリやCPUに高負荷のかかる処理が発生します。
ここはケチらずに、分析を行うためだけに存在するサーバーを用意しましょう。
分析用のデータベースを作る
そして、分析や集計業務を行いやすいように、分析用のデータベースを作りましょう。
サービスを行ううえで適したデータ構造と、分析を行ううえで適したデータ構造は異なります。
コツは、同じキーのデータセットはなるべくまとめることです。
ただし、毎回分割して処理をかけるようなことがあれば、同じキーでもあえて分割させて保存しておきましょう。
この辺は好みや実際に運用してみて、柔軟に変更してみてください。
図に表すとこんな感じです。適当ですみません。
2. 社員のデータに対する意識を高める
最終的には、皆が自分で分析できるようになることが理想ですが、そうは言っても最初は何をすれば良いか分からないと思います。
まずは、日々のユーザーの動きであったり、売上げなどの成果がどのようになっているのかになるべく興味を持ってもらうところから始めましょう。
そのために、皆がデータを気軽に確認できる場所を作りましょう。
いわゆるダッシュボードというやつです。
最近よく開発されているBIツールを導入しても良いし、自社で１から作っても良いです。
個人的には、ダッシュボードとしては予測モデルや多変量解析などの機能が充実している高価なBIツールは必要ないと思っています。
3. データ分析とサービス開発を結ぶ仕組みを作る
さて、分析環境が整い、ダッシュボードも出来上がったら、そこからが分析者の本領発揮です！
分析者はここぞとばかりに良い分析をしようと張り切ります。
実際に客観的事実に基づいた有意義な分析結果が出て、それを現場に持って行ったとします。
分析者「こんな面白い結果が出たんですよ！」
「ここ、改善しましょう！」
現場 「なるほどねぇ」
「うん、そうだよね。ありがとう」
・・・・・・終わり！？
結局いつ改善されるんだ？？
これ、意味あったのか？？
このようなケースに陥ったことのある組織は多いのではないでしょうか。
以下ではそうならないように「意識すること」と「データドリブンな仕組み作り」について議論します。
意識すること
まずは一個人としての信頼を得ることです。これも当然ですが一応。
データ分析者は、実際に分析を行って、
「このサイトのここが良いんです！」
というだけでは意味がなくて（勿論それも重要ですが）、
「ここが問題だから、こんな改善をしてみてはいかがでしょうか」
と提案しなければなりません。
そして、その提案が通って初めて分析に意味ができます。
しかし、データ分析者というのは微妙な立ち位置です。
実際にサービスを作るエンジニアでもなければ、ディレクションもしていない。
営業もしていないし、ましてや社長でもありません。
そんな分析者の言うことに耳を傾けてもらうためには、
確かな分析スキルに加え、サービスのことを
どれだけ愛しているか
どれだけ考えているか
を日々伝えることが意外と重要になってきます。
そのためには、開発現場や営業の人と日々コミュニケーションをとることを心がけ、日々競合のチェックをすることを心がけましょう。
もちろん、ちゃんとサービスを愛し、日々思いを巡らせましょう。
仕組みについて
分析結果を開発に組み込み、高速なPDCAスパイラルを回すためには、ちゃんとした仕組みが必要です。
データドリブンにおいて重要なことは、データ至上主義に陥るのではなく、経験やセンス、勘も大事にしていくことです。
図で表すとこんな感じ。
さらに、分析者が１人で企画まで考えるのではなく、皆で議論し解決策にたどり着くことも重要です。
以下の図は弊社で実践しようとしているPDCAサイクルの基本例です。
もちろん目的はサービスが改善されることで、この流れを遵守することではないため、柔軟に調整していきます。
以下、各MTGの概要です。
①問題提起MTG
- 目的：現状のサイトの問題点を議論、取り組む分析テーマを決める
- 主催者：基本的にデータ分析者
- 出席者：各部署から必須で１名の参加と、分析結果に興味のあるチームメンバー
- 必要なもの：客観的事実に基づく問題や仮説が提起された資料
- 補足
- 時間を決めてメリハリをつける
- 現状の共有だけでも定期的に開催する
②アイデア創出MTG
- 目的：分析結果をもとに、どんな解決策があるかを議論する
- 主催者：データ分析者
- 出席者：各部署から必須で１名の参加と、分析結果に興味のあるチームメンバー
- 必要なもの：
- テーマに沿った正確な分析結果
- サービスをより良いものにしたいというアツい想い
- 補足
- アイデアは思いつきレベルで構わない
- 議論はなるべく発散させる
- アイデアを発言する場であり、否定する場ではない
- 時間を決めてメリハリをつける
③アイデア選別MTG
- 目的：技術コストやインパクトの観点からアイデアを絞る
- 主催者：データ分析者
- 出席者：メインディレクター、メインエンジニア、メインデータ分析者
- 必要なもの：アイデアリスト
- 補足：
- 選別するものがなければ開催しない
- 多くても３つか４つに絞る
- 選別基準は明文化する
④アイデア決定MTG
- 目的：最高意思決定者により、アイデアを決定する
- 出席者：意思決定者（PO）、メインディレクター、メインエンジニア、メインデータ分析者
- 必要なもの：アイデアリスト
4. 小さな効果を体感してもらう
仕組みができたら今度こそようやく分析開始です！
しかしここでも１つ注意点があります。
いきなりホームランは狙わないでください。
分析環境がある程度整ったとはいえ、あなたの手元にあるのはまだ作り込みの甘いデータです。
データの性質もよくわかっていません。
そんななかで壮大な分析を行おうとすると、着地までにとても時間がかかることは目に見えています。
そもそも着地できるかどうか。
最初は手堅く小さな効果を出し、データ分析の効果を実感してもらいましょう。
5. 現状を把握し、指標を作る
どんな分析をするにしても、目的が決まっていないと着地できません。
目的とは例えば、
- 「当サイトにとって良いユーザーとは誰か」
- 「当サイトの健康的な状態はどのような状態か」
などです。
これらを定量的に説明できなければ、分析は困難なものになります。
分析を本格的に開始する前に、ますは現状を調査し、指標を作りましょう。
さいごに
今回は分析の文化がない組織にデータドリブンなサービス開発を導入する際に注意したことを書きました。
サクッと書くつもりが、かなり長文になってしまいました。笑
これでようやく分析が開始できますね！
再度言いますが、これは小規模の会社の１ケースにすぎませんので、完全にこの形にあてはめようとせず、各組織で良いやり方を考えてみてください。
この投稿がきっかけとなって、データ分析者が実力を発揮できる組織が増えていってほしいなと願っています。
こんなことも気をつけたほうがいいとか、ご指摘あればコメントにてお願いします。
