【データ分析の民主化】データドリブンな組織になるには何をしたらいいのか考えてみた
こんにちは。
今日は、データドリブンな組織になるために、何をしたらいいかを考えてみたので、それについて書きます。
データドリブンな組織の必要性
先日、以下の記事で「データドリブンな組織ってなんで必要なのか」と言う観点で記事を書きました。
上の記事を要約すると、以下のようになります。
- 意思決定を「早く・確実に・納得感を持って」するために、データ分析をする(アナリスト視点)
- データを活用して新機能の開発やコスト削減を行う(MLエンジニア視点)
- データ分析をベースにした組織、つまりデータドリブンな組織になるためには「データ分析の民主化」が必要(組織全体の視点)
データドリブンな組織になるためには、「データ分析の民主化」って言う最近のホットワード(?)なのか知りませんが、そう言うのが必要です。
ぼんやりした言葉なので、具体的に何をすればいいのかと言うのを、この記事では考えてまとめてみます。
また、様々な企業様の事例を元に書いている部分がありますが、いつもリスペクトしかなく、大変勉強させていただいております。ここからは私の考えという名の妄想も入りますが、様々な点で参考にさせていただきました。
会社では、一部実践していることもありますが、まだできていないことが多く、こうしたほうがいいんだろうなぁみたいなところも含めて、全部書いてみたいと思います。
データ分析の民主化ができている状態とは
データ分析の民主化ができている状態を考えてみます。字が汚いのとかは一旦置いておいて、イメージとしてはこんな感じです*1。
上の図の要素を洗い出すと、以下のようになります。
- 適切なデータ取得
- 分析できる形にデータが整形されていること
- データへのアクセス方法が複数種類用意されている
- データ分析に関する情報にアクセスできる環境がある
- データ分析をする人が多い
上から順番にやればなんか良さそうな感じがしますが、順番にやっていった先に「そもそも文化が作れなかった」とかになると泣きたくなると思うのと、なんだかんだ一番「人」の部分が時間がかかると思うので、「全部並行して初めは小さく進めていきつつ、場面によって注力ポイントを変えていく」というのが良いと思います。
以下では、それぞれの項目についてみていきます。
適切なデータ取得
インフラやアプリケーション、GoogleAnalyticsなどのサービスなどから適切なデータを取得します。
ここでは、「基本的に取得したほうがいいよね」というデータとか「この活用方法やデータ分析を見据えて取得する」データなどが思いますが、その意味で「適切なデータ」という表現をしています。
ここがないと全部が破綻しますし、サービス開発初期からこういうのを意識してやっているかどうかとかでもだいぶ変わります*2。
また、「適切なデータ」というのは、ポジティブな表現ですが、データ分析の民主化を強く推進するのであれば、別で管理されているデータを能動的にDBにぶち込むとかはやるべきかなと思います。全部をDBに突っ込んでおけば、みんなやるようになると思うので、「環境」からある種の縛りを作るのはありかもしれません。
分析できる形にデータが整形されていること
システム的には十分なデータ、例えば正規化がしっかりとされていたり、とりあえずデータ分析に必要だから貯めているけどいざクエリ叩くとデカ過ぎて処理に時間がかかるなどのデータだったりを、「良い感じで分析できるような形に整形された状態」であることが必要です。
良い感じというのは、
- テーブルを必要以上にJOINしなくても良く
- 必要な粒度で集計処理がされた中間テーブルであり、
- データの一次クレンジングがされている
ようなデータです。
こちらの「データドリブンな組織を作るときにまず行うこと 〜我が社よデータ分析色に染まれ〜 - ハウテレビジョン開発者ブログ」という記事で紹介されている以下の図がありますが、
この図のように分析のために必要なデータは別途集計され、まとめられている必要があります。
でないと、様々な人が高度で難解なSQLクエリをぶっ叩いたり、簡単なことでも無駄に高い技術レベルを身につけたりなどの必要が出てきて、そもそもデータにアクセスするハードルが高くなります。これでは、誰もアクセスしません。
これを防ぐために、「分析しやすいデータにして保持しておく」というのはクソ重要ですし、これをやってくれるデータエンジニアの存在は貴重ですし、感謝の気持ちを持たなければなりません。
データへのアクセス方法が複数種類用意されている
データへのアクセス方法として、使うユーザーに合わせて様々なアクセス方法が用意されているのが好ましいです。どこまでやるかは会社によって違うかなと思いますが、主には以下の方法があるかなと思います。
- Dashboard:BIツールなどを使って作ったDashboardからアクセス
- BI / SQL queryBIツールからクエリを叩いてアクセス
- ChatTool:Slackなどで定期的にbotやグラフのURLとしてデータを発信
- Cloud:AWS/GCPなどのサービスからアクセス
- Database:DBに直接アクセス
- API:API経由でアクセス
手段を用意すればするほど、コストもかかりますが、コストに見合うものがあればやるべきかなと思います。手段が多いほど、データ分析のレベルが高い人も低い人もみんな使うことができるようになるので、攻めてレベルを3段階くらい分けたとして、3つくらいのアクセス方法は用意しておきたいです。
データ分析に関する情報にアクセスできる環境がある
後で紹介する「データ分析をする人が多い」状態にするためにも、勉強会などでデータ分析の全体的なナレッジを底上げしたり、Wikiなどを使ってデータ分析に関する知識を広げたりすることができる必要があります。
また、データ分析のレベルも人によって様々なので、たくさんのナレッジにアクセスできるようにしておくことは重要です。例えば、以下のようなものが挙げられます。
- Wikiなどでのドキュメント
- Slack botなどでの情報の取得
- GithubなどでのQuery Snippets
- 全体への社内勉強会や個別指導会
- Slackなどでのデータ分析に関する記事の共有
このように、Wikiなどに書いておくことによって、データ分析に強い人たちへの質問なども減り、個々人が自走できるようになるので、ナレッジをしっかりと蓄積し、伝搬できる状態にするのは重要です。
データ分析をする人が多い
データ分析をある程度のレベル感の人であればできるようになったら、できる人を増やす布教活動を行い、できるメンバーを増やします。
データ分析ができるメンバーが増えれば増えるほど、意思決定の「早さ・確度・納得感」などがどんどん増していくはずなので、これを元にビジネスを加速させていく感じで行ければ良いのかなと思います。
-
-
-
-
-
-
- -
-
-
-
-
-
データ分析の民主化は、基本的にこれを達成するために地道にアクションを取っていくことが重要なのかなと思っています。以下では、アクションについて触れる前に、データ分析を行うにあたってのレベル感についても再考してみたいと思います。
データ分析のレベル
どのような観点で考えるか
前提として、
- データアナリストとして、SQLをいじって分析ができるのが本業で、Pythonでコードも書けてモデルもいじれる人
- MLエンジニアとして、Pythonとかインフラまでできてサービスインできるのが本業で、SQLとかで分析もできる人
といった二つの役割は別々だと思っているという前提はあると思いますが*3、ここではあまり意識せずに書いてみたいと思います。
その上で、ここでは個人と組織の2軸で考えてみたいと思います。
個人からみたデータ分析のレベル
これに関しては、以下の記事にもあるような感じなのかなと。
また、これは一般化することは非常に難しいと思うのですが、無理やりやるとだいたい以下のようになるのかなと思います。
- Lv1 : 用意されたデータを日常的に見て、理解できる
- Lv2 : エクセルやSQLを使ってデータを可視化して、仮説検証などの分析ができる
- Lv3 : 統計的な手法や機械学習のモデルを使って分析・自動化ができる
とはいっても、Lv3まで必要がなかったり、そもそもタスク依存であったりします。なので、ここではあまり触れませんが、Lv2の感覚でデータ分析できる人を増やす方が、ビジネス的には全体的にインパクトがあると感じています。
組織からみたデータ分析のレベル
組織からみたデータ分析のレベルについては、以下の記事に書かれていて、
前に死ぬほど頷いた記憶があるので、ここで引用いたします。
データサイエンティストは組織におけるデータ活用状況について、レベル分けして考えます。
(中略)
Lv0:
データ収集、ログ設計
Lv1:
システムから切り離された環境でのデータ蓄積=データの民主化
SQL等による基礎統計
統計等からインサイトを得られる状況
Lv2:
基礎統計の充実、BIツールによるダッシュボード化
ピボットテーブル等による探索的な手動データマイニング
手動データマイニングから施策を立案できる、手動で実行できる
Lv3:
機械学習アルゴリズムを利用した探索的データマイニング
ABテスト等を利用した、データに基づく意思決定
ちくわ大明神
Lv4:
機械学習等を利用して、自動的に施策実行される環境を構築する
機械学習により安定的に稼ぐ仕組みを作る
Lv5:
Lv4で作ったシステムで使われている機械学習アルゴリズムをより高度なモノ(例えばディープラーニングとか)に置き換えていき、収益性を改善する
まずは、手元からスモールにでもどんどんデータ分析をガンガンやれるようにしていき、最終的にはアナリストとしてもMLエンジニアとしてもしっかりと事業に貢献できるような組織になっていくのかなと思っています*4。
こちらの「貴社の「データドリブン成熟度」は5レベルのどれぐらい? | データドリブン・マーケティング&ADフォーラム レポート | Web担当者Forum」記事にある、以下の図でまとめられている「データドリブン成熟度」の5段階のレベルも面白いです。
この各レベルの割り振りに対して、記事中では、「それぞれのレベルにおける課題と解決アプローチ」も書かれています。
これらは、組織全体におけるデータ分析やデータ基盤の技術レベルよりもどちらかというと、意識や活用度に寄せて議論されていて面白いですね。
また、これらには人数規模の話は出てきていませんが、段階としては、以下のようになると思います。
- Lv1 : データ分析の専門職の人たちだけができる
- Lv2 : データ分析の専門職と一部のデータ分析よりの人たちや仲間内だけができる(数人レベル)
- Lv3 : データ分析の専門職の人じゃない人たちがデータ分析を他の人にも広め、人数が増える(数十人〜数百人レベル)
- Lv4 : 全員ができるようになる
データ分析の専門職の人たちができるのは当然として、それ以外の人たちも徐々に広めていって、最終的には全員が何かしらの形でデータ分析やそれを行なって得た結果に関わって、意思決定なりをしている状態が理想となります*5。
アクションに向けてのまとめ
個人・組織・組織規模のレベルをそれぞれあげていくために、アクションをやっていく必要があります。
どれにも共通しているのが、「最初は小さく初めて、それぞれのステップで効果を出していきながら大きくする」というのなのかなと思っています。
次項からは、「データ分析の民主化」を実現するための状態を中心に、ぞれぞれどうアプローチすればいいか、タスクリストも含めて整理してみようと思います*6。
とはいっても、状態のところで結構書いたので、参考になりそうな資料とアクションリストを中心にまとめます。
データ分析の民主化実現に向けてのアクション
前提となる組織の意識
前提として、組織をデータドリブンをしようとした時に、
- 組織全体がデータドリブンに意思決定をしようと思っている
- 組織全体では思っていないが、必要だと思うので、小規模に進めたい
というのでは、だいぶ違うと思います。
大抵のシチュエーションでは、組織全体ではまだ浸透していないので、小規模に進めていくというケースがほとんどだと思います。
なので、今回はそのケースを元に考えていきますが、「データドリブンな組織を作ることでメリットが得られそうかどうか」というのに、ぼんやりでもイメージがないと、スモールにでも始める意味はありません。
スモールに初めていって、結果として意味があんまりなかったってなるのは良いことかなと思いますが、そもそも意味があるかはちょっと考えてみる必要はあると思います。
意味があるという前提で、各状態になるプロセスを考えていきます。
適切なデータ取得
まず適切なデータを取得するフェーズにおいては、以下のようなアクションが必要だと思います。
- 目的に対して必要なデータの整理
- そのデータの取得
それぞれ見ていきます。
目的に対して必要なデータの整理
これをやるために、以下の項目が必要かなと思います。
- KGI・KPIや分析したい項目の整理
- 現在取得・存在しているデータの整理(データ保存先、テーブル定義書の作成など)
- 顕在化しているやりたいことに必要なデータの整理
参考記事は以下の通りです。
組織によっては、Githubなどの利用状況などを可視化して開発状況を把握したり、
Slackのメッセージを可視化したり*7、
など、「解決したい課題」や「設定している目標」によって、必要なデータは様々考えられます。
まとめると、「目的に合わせて必要なデータのリストを作成し、現在取得できているデータとそうじゃないデータをそれぞれ整理する」というのが一番最初にやることかなと思います。
そのデータの取得
データの取得については、
- 取得したいデータに対して、現状のシステムからのログ取得をどうするか
- 使っているサービスからAPIなどで取得する
などがあげられると思います。
以下は参考記事です。この辺りは開発しているサービスや目的などに依存するので、適切な手段を選ぶのが良いのかなと思いますので、ここでは深く入り込みません。
分析できる形にデータが整形されていること
以下の記事にあるように、しっかりとデータが利用者や目的にそって整理されている必要があります。
データ基盤の三種類にあるような区分で、データが整備されているとかなり幸せになります。
利用者によってやりたいこと・できることも変わりますし、みたいデータの粒度も変わってきます。なので、しっかりとこんな感じで整理されている方が、みんなハッピーになります。
なので、どのような技術要素を使うかも含めて、データ基盤をしっかりと作ることがここでのステップになると思います。また、作るときも、がっつり一気に作るのではなく、
1. 利用のユースケースの整理する
2. 小さくまずは使ってもらう
3. 運用が回ってきたらシステムに反映する
といったようにステップを細かく踏むことで余計な時間がかからずに済みます。
データへのアクセス方法が複数種類用意されている
データへのアクセス方法が複数用意されている状態を作ります。例えば、以下のような記事が参考になります。
- メルカリのデータサイエンスチームと分析エコシステムのはなし - Mercari Engineering Blog
- プロダクトの変更ログを記録することと、Slack+Zapier+Google Calendarを利用した記録の自動化について - Gunosyデータ分析ブログ
- Gunosyを支えるKPI管理 - Gunosyデータ分析ブログ
具体的にあげてみると、以下のような方法で様々な人が自由にアクセスできるような環境を作ってあげるのが良いのかなと思っています。
- Jupyter Notebook:PythonやRなどを使ってのアドホック分析
- BIツール:Redash、Tableau、Lookerなどを使ってのデータの抽出・可視化・Dashboard作成
- ChatTool:Slackなどと連携して、受動的または他者へのデータ共有を受けれるようにする
- CSV:Spreadsheetやエクセルなどを使って分析できるように、CSVとしてデータがダウンロードできる
- Database:ターミナルからでも、ORmapperからでもなんでも良いが、とにかく直で触って分析できる
- Cloud:AWS/GCP上もしくはそこからデータを引っ張って分析できるようにする
少なくとも上の環境はサクッと作れるようにしたいですね。ただ、正直技術的にも工数的にも大したことなくても、
- Githubをビジネスメンバーにも付与するための努力
- AWSとかのアカウント発行
みたいな、「なんかうん」みたいな作業の方が大変だったりします。
が、そういうのを乗り越えれば、GithubでSQLのクエリを共有できたり、AWS上でこねこねできたりします。
最近では、クラウドのサービス上でJupyter Notebookで分析するのがやりやすく、Amazon SageMakerなどを使って機械学習のモデル開発などを行なっている事例もいくつか出ています。
- プロダクション環境ですぐに活かせそうなAWS re:Invent 2018のSageMakerアップデート5選 - コネヒト開発者ブログ
- AWS Dev Day Tokyo 2018 で Wantedly の機械学習基盤と Amazon SageMaker の活用について話しました! | Wantedly Engineer Blog
個人的にも、リクルートさんのこちらの記事「Wantedly の機械学習プロダクト開発を支える機械学習基盤 / #rejectcon2018 - Speaker Deck」のようにやりたいと思いつつ、このためにインフラを作るのはなぁって思っていたので、SageMakerは最初の一歩として選択肢になりそうだなと思って会社でトライアル的に使ってみています。
データ分析に関する情報にアクセスできる環境がある
上でほどんど書いちゃいましたが、以下のようにとにかく情報にアクセスできる環境があるようにするのは大事だと思います。
- Wikiなどでのドキュメント
- Slack botなどで、可視化されたデータ分析結果の情報の取得
- GithubなどでのQuery Snippets
- 全体への社内勉強会や個別指導会
- Slackなどでのデータ分析に関する記事の共有
加えて、分析を普段の業務に少しずつ取り入れて、ミーティング中であったり、実際の業務であったりで徐々に「こんな風にやっています」とか「こんな風にやったらうまくいきました」とかを共有するのも大事だと思っています。
こんな感じで、日常的にデータにアクセスする機会や方法を掴んでいくことが大事だと思うので、1日に1回以上は全員が触れるくらいのレベルでやるべきだと思います。
データ分析をする人が多い
データ分析をするメンバーを増やすことも同時に大事です。上でやっていることをいろんな関係者を含めてやれるようにすれば、自ずと分析をする人が多くなるのかなと思いますが、
- 使っているツールなどをできる限り多くの人にオープンにしてアカウントを発行する
- 使い方を伝える勉強会を開催する
など、使うパイを多くするような施策も大事だと思っています。
まとめ
DataOpsという考え方
以下のスライドは、少し前に読んだのですが、本当に凄まじいなと思いました。
このレベルでDataOpsがしっかりとしていて、しかもこれほどまでに事例を紹介しているものをまだ私は見ていません*8。
今回書いた記事は、データ分析の民主化という話だったのですが、これを実現するためのDataOpsをしっかりやっていくということに尽きるなぁと、改めてスライドを見ながら思いました。
地道に一歩ずつ
なんかこうやってみてみると、一個一個はかなり地味というか、地道に頑張っていくみたいな感じなんだなぁと改めて思いました笑。前のスライドにあった以下のスライドをみて、これに比べたら頑張れるなぁと思いました笑。
以下の記事とかにある、「データ基盤は使われてこそ意味がある」とかも身にしみます。
また、こういうのって張り切ってやっちゃいますが、しっかりと業務に着目して、小さく小さくアウトプットしながら進めていきたいなと思いました。
来年から頑張ってこの辺りをやれそうなチャンスがあるので(やるから思考整理もかねて書いているというのもある)、一通りやってみての振り返り記事とか書ければと思っています。
それでは。