データ分析の民主化を成功させる3つの軸
FiNC Technologies (以下、FiNC) の プロダクト本部 企画グループ グループマネージャーをしている Ryusei （@ryusei_i_1025）です。
エンジニア業務をしながらPO業務に従事しております。
2022年は社内施策として、データ分析の民主化を進めてきたので、その振り返りと成功した点、改善点をご紹介します。
見出しだけでも読んでいってください。
分析の民主化により、社内の分析を増やす
分析を民主化し、PDCAの速度を上げたという事例が増え、「データの民主化」「分析の民主化」という言葉がここ数年で、よく使われるようになりました。
「分析の民主化」について、詳細の説明はここでは省きますが、
「分析チームだけでなく、セールス、マーケッターなどビジネスサイドや、PO・PdMが自らデータを可視化し、分析をして仮説の検証や課題の特定を行なえる状態」
を社内では民主化として定義しました。
FiNCでも民主化が必要になり、プロジェクトが始まりました。
まずは必要になった経緯から説明させてください。
民主化をしないと属人化とスピードの低下を招く
2022年からデータの担当は私1人になりました。
とはいっても、私はエンジニアリングがメインなので、兼務になります。
兼務しているので、以下の3つの問題が起きます。
・自分のリソースの取り合いによるコスト
・知識とスキルの属人化
・自分がスピードのボトルネックになる
① 自分のリソースの取り合いによるコスト
兼務している状況では、エンジニアリング業務とデータ業務の優先度を天秤にかけます。
エンジニアリングとデータ業務では、管理部署も別で、優先度が比較しづらくなります。
そういった状況でリソースを取り合うので、優先度調整やコミュニケーションのコストが増えます。
② 知識とスキルの属人化
また1人で担当しているので、データに関する社内の知識を私だけが習得していきます。
タスクも1人で行うので、スキルも属人化します。
知識とスキルの属人化は、業務のブラックボックス化を招いたり、もし私が抜けた場合に、スピードが落ちてしまう危険があります。
③ 自分がスピードのボトルネックになる
属人化とリソース調整の結果、私がスピードのボトルネックとなります。
データの依頼が来てから、アウトプットのすり合わせなどのコミュニケーションから始まり、フローの中では、私のリソースがスピードのボトルネックとなります。
顧客企業からデータを求められるセールスの方や、施策の振り返りを行いたいPdMやプランナーの意思決定を遅くしてしまいます。
このような問題から、社内での民主化施策を進めていくことにしました。
民主化施策の3つの軸
民主化には3つの軸を意識して進めていきました。以下、3軸を説明したいと思います。
民主化の軸1: スキル獲得
民主化にはまずデータを扱うために、ある程度専門的なスキルの習得が必要です。
FiNCではRe:dashをBIツールとして使用しているため、SQLの習得がメインとなります。
データ分析のためにスキルの獲得は以下を行いました。
・データ取得に必要なSQLの習得、データベースの考え方を学んでもらう
・ハンズオンを行ったり、実案件を通して学ぶ
・スキルレベルやレベルに合ったスキル定義を作り、学習イメージを作ってもらう
1–1 データ取得に必要なSQLの習得、データベースの考え方を学んでもらう
社内の資料を使って、テーブル、レコード、カラムといったデータベースの基本的な知識や、簡単なSQL操作の書き方を学んでもらいました。
アクティブユーザーや食事記録データといった社内でよく扱うデータを使って、小さく始めて、まずはSQLや構造化データのイメージを掴んでもらうのが目的です。
SQL ZOOやProgateなどSQLを学べるサービスもスキルの獲得に有効ではありますが、社内のデータとBIツールに慣れるためにも、実際のデータを使って学ぶのが良かったかなと思います。
1–2 ハンズオンを行ったり、実案件を通して学ぶ
ある程度、基本的な知識が身についたら、実際の簡単な案件でSQLを書いてもらいました。
例えば、
・普段使っているクエリの条件の追加・変更
・すでにあるクエリAとクエリBを組み合わせて、新規クエリを作成
・サブクエリが2,3個で収まるような新規クエリ
といった少し簡単な案件で、実践してもらいました。
クエリを書き始める前に、どうすれば最終的なアウトプットが完成するか、どのテーブルを使って、どの条件で、どのカラムを使用するかなどを細かく言語化してもらうことが重要です。
プロセスをできるだけ自身で考えてほしかったので、私はレビューやクエリのヒントやアプローチの方法だけをお伝えするのみでした。
1–3 スキル定義やスキルレベルを作り、学習イメージを作ってもらう
数ヶ月学習していくにあたり、学習の継続や挫折をしないように学習のロードマップをデザインしていくことが重要だと思います。
弊社では、スキルのレベルとその定義を作成し、ステップバイステップで習得していくイメージを持ってもらうことにしました。
レベル分けすることで、自分の現在地や中間ゴールを認識してもらい、学習の計画を立ててもらうことが目的です。
「〇〇さんは今このレベルくらいなので、このクォーターではこのレベルまでいってみましょう」という会話ができると、目安がない状態で習得を目指すよりも、具体的なイメージがしやすいと思います。
民主化の軸2: ナレッジ拡散とアクセシビリティ
スキルがあっても、社内固有のデータの知識、どのデータがどこにあるかを把握していないとスムーズな業務遂行ができません。
なので、ナレッジ拡散とアクセシビリティという軸で以下を行いました。
2–1 データに関する知識、データの居場所などがアクセスできる状態を整備と周知
まずは暗黙知を形式知に変えるため、データの出し方、テーブル定義などのドキュメントを作成、更新をしていきました。
よく使用されるデータを中心にドキュメントを作っていきました。
ドキュメント作っても、それが周知されない限り活用されないので、先人たちが作ってくれていたポータルページを更新しました。
ドキュメントにしておくことで、私の説明の負担も減り、データ分析者が1人で解決できる状態が増えました。
ただし、ドキュメントは作るだけではなく、根気強く周知していくことが重要です。
SlackでURLをお渡しするのと同時に、「ここを見たら解決するよ」と声をかけ、ポータルページの存在を伝えていくことにしました。
民主化の軸3: データ抽出の環境整備
データを扱う際に、データ基盤が不安定だったり、データが探しづらい状態だと、クエリ作成の難易度が高くなります。
FiNCもそういった状況だったので、少しずつ以下の改善を行っています
・安定したデータ基盤・インフラを整える
・いらないものは捨てる
3–1 安定したデータ基盤・インフラを整える
FiNCでは、データの更新を自動化させるため、Re:dashで自動更新の機能を使用しています。
定刻になると、Re:dashのスケジューラがクエリを自動で実行し、最新の状態にアップデートします。
その時間帯で度々、キューが積まれすぎて、分析者がクエリを実行できないという状況が置きました。
また、負荷の高いクエリが連発されると Re:dashサーバーがダウンすることもありました。
なので、Redash内で使用するRDSのスペックを最適化したり、キューが積まれすぎたときに、クエリを停止させるスクリプトを作成し、誰でも復旧ができる状態にしました。まだまだ安定しているとは言えないですが、少しずつ改善を続けています。
3–2 いらないものは捨てる
FiNCでのデータ基盤では、以前は使用していたが、現在使用していないクエリやテーブルが多く存在していました。
似たテーブル、似たクエリがたくさんある状態だと、データを扱う人たちが、使用したいテーブルが探しづらいという課題があったので、定期的に使用していないテーブルの削除を行いました。
結果として、テーブルの調査のしやすさは多少は改善されました。
結果、事業部ごとに1人以上は書けるようになり依頼が減った
始めてから1年弱経ち、結果として事業部ごとに1人以上はSQLを書けたり、ダッシュボードを作成できるようになり、私の負担はかなり減りました。
今はクエリのレビューやデータの調査、たまに依頼を受けるくらいにはなりました。
時間を作って、チャレンジしてくれた方に本当に感謝しています。
実際に、チャレンジしてもらった3名の方に感想をいただいています。
ケース1. プロジェクトマネージャー
得られた成果
「仕様検討や集客分析において、より深く検討でき、なんとなくでの検討はなくなった。」
「社外への説明時に説得力が増し、信頼にもつながっていると思う。」
難しいと感じられた点
「トライアンドエラーで何度もやっても、エラーが出続ける。」
「よく使うテーブル（アクティブ情報や記録データ）などは良いが、あまり出さないデータは、どのテーブルを参照すれば良いかわからず、戸惑った。そういった場面ではデータ出すのが手間に感じてしまう。」
今後の展望
「よりスピーディーに、よりいろんなデータを出せるようになっていきたい」
「同じ職種のメンバーにもどんどん広まっていってほしい。そのために自分も教えられるだけの理解を深めていきたい。」
意思決定の判断材料として、データを扱えるようになり、説得力が増したとのことでした。
構文や書き方が誤っていて、エラーが出続けること初学者にとってはたしかにストレスです。
このエラーが出たらこう解決するというFAQページがあってもいいなと思います。
ケース2. プロダクトマネージャー
得られた成果
「データ分析依頼の連絡や待ち時間の手間が省け、その分、自分で書く時間は増えましたが、総工数は、依頼してた時とさほど変わらない程度になったと思います。」
「初動調査が手軽に行えるようになりました。小さな調査でも依頼をしないといけないので、やや尻込みしがちになる時もありましたが、分析に積極的になり、よりデータを活用する機会が増えたことが良かったと思っています。」
「インシデントやお問い合わせ対応等の初期調査についても自分で行えるようになったので、原因の切り分け等にも役立っています。」
難しいと感じられた点
「データソースのテーブル毎の特性の理解（マイクロサービスによってタイムゾーンが違う等）」
「JOINの種類の理解（ドキュメントを見ても、直感的に理解できず苦労した。実際に結果を見て『なるほど、こう指定したらこうなるんだ』を繰り返し、試して理解した。）」
「『型』の理解。whereで期間を絞る時などに、date型に変換する必要があるかどうか。これも既存クエリを参考に実践しながら理解した。」
今後の展望
「効率的な書き方ができるようになっていきたい。今はまだ抽出手順をそのまま順に書いているだけなので、より効率的な書き方や負荷に優しい書き方などができるようになっていきたいです。」
データに対するハードルが減り、分析だけでなく、問題解決にも活用ができるようになったとのことです。
ここで身につけた知識が、分析以外にも役に立ったというのを聞いて、大変嬉しく思います。
一方、SQLの挙動や型の理解が躓きやすいポイントとのことでした。
ケース3. プロダクト運営、プランナー
得られた成果
「部署で見たい数値やインシデントの影響範囲を短時間で参照できるようになった。エンジニア頼りの体制からの脱却に役立っているはず。」
「 思わぬ副産物としては構造化の練習にもなった。クエリを書く際には最終的に得たい結果を因数分解していくが、どこの数値がどう結果に繋がるかを整理することにもなり、KPIの試算や施策の設計などの場面でも役立っている。」
難しいと感じられた点
「自分の日常業務に頻繁に登場しない関数（LEAD関数などのウィンドウ関数]）の使い方」
「どこまでやって、どこで躓いているのかを明確にした上で、さっさと有識者に聞いてしまうのが自分なりのコツ」
「自分の日常業務で使用するクエリは共通点が多く、既存のクエリがいい教材になった」
「最初は部分を書き換えることから始めると思うので、自分も流用しやすいようクエリにコメントを残すようにしている」
今後の展望
「使いまわせる便利なクエリを残す」
「練習で量産された類似/不要クエリや古いテーブルを参照しているクエリを整理したい」
「人のクエリのレビューができるようになる」
やはり、自部署のデータがすぐに見られることのメリットは大きそうです。
データとかSQLだけではなく、分解して考えるといった思考トレーニングとして役立っているとのことで、予期せぬ成果でした。
Tips: 有志より公式にせよ
民主化のための施策ではないですが、FiNCでは公式プロジェクトとして進めることがうまくいった一つの要因だと思います。
社内でも、数年前に有志で行っていたこともありましたが、いまいちアクセルを踏めてなかった状況でした。
実際に私もそうでしたが、「時間がないから、後でやります」が通りやすくなったり、モチベーションの継続が難しかったりなど、やらない理由ができてしまうからです。
過去のこの経験を踏まえて、公式なプロジェクトとして進めました。
CEOやCTO、VPoEなどに相談しながら、経営会議、全社会などでもプロジェクトの共有をしていただきました。
その結果、担当者が所属している上長、チームリーダーなど、周りの人の理解を得られるようにしました。
さらなるレベルアップと学習コストの逓減へ
まだまだ道半ばですが、よりデータを扱える人を増やしていく活動は続けようと思います。
習得した人たちをさらに引き上げる
基本的なスキルを習得していただいた方がもっと、高度なデータ集計ができるように、引き続きサポートをしていきます。
応用的な関数、クエリのレビュー、パフォーマンスや可読性を意識してSQLを書ける人を増やしていくことを目指します。
さらなる学習のナレッジの蓄積
学習の際につまづいたこと、こんなものがあったら良かったなど、学習を通しての反省を残していったり、教え合う機会を設け、社内での学習の効率化をしていきます。
習得してくれた方たちが、また別の方を教育できる状態を目指します。