データ分析の民主化を成功させる3つの軸
FiNC Technologies (以下、FiNC) の プロダクト本部 企画グループ グループマネージャーをしている Ryusei (@ryusei_i_1025)です。
エンジニア業務をしながらPO業務に従事しております。
2022年は社内施策として、データ分析の民主化を進めてきたので、その振り返りと成功した点、改善点をご紹介します。
見出しだけでも読んでいってください。
分析の民主化により、社内の分析を増やす
分析を民主化し、PDCAの速度を上げたという事例が増え、「データの民主化」「分析の民主化」という言葉がここ数年で、よく使われるようになりました。
「分析の民主化」について、詳細の説明はここでは省きますが、
を社内では民主化として定義しました。
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. プロダクトマネージャー
得られた成果
難しいと感じられた点
今後の展望
データに対するハードルが減り、分析だけでなく、問題解決にも活用ができるようになったとのことです。
ここで身につけた知識が、分析以外にも役に立ったというのを聞いて、大変嬉しく思います。
一方、SQLの挙動や型の理解が躓きやすいポイントとのことでした。
ケース3. プロダクト運営、プランナー
得られた成果
難しいと感じられた点
今後の展望
やはり、自部署のデータがすぐに見られることのメリットは大きそうです。
データとかSQLだけではなく、分解して考えるといった思考トレーニングとして役立っているとのことで、予期せぬ成果でした。
Tips: 有志より公式にせよ
民主化のための施策ではないですが、FiNCでは公式プロジェクトとして進めることがうまくいった一つの要因だと思います。
社内でも、数年前に有志で行っていたこともありましたが、いまいちアクセルを踏めてなかった状況でした。
実際に私もそうでしたが、「時間がないから、後でやります」が通りやすくなったり、モチベーションの継続が難しかったりなど、やらない理由ができてしまうからです。
過去のこの経験を踏まえて、公式なプロジェクトとして進めました。
CEOやCTO、VPoEなどに相談しながら、経営会議、全社会などでもプロジェクトの共有をしていただきました。
その結果、担当者が所属している上長、チームリーダーなど、周りの人の理解を得られるようにしました。
さらなるレベルアップと学習コストの逓減へ
まだまだ道半ばですが、よりデータを扱える人を増やしていく活動は続けようと思います。
習得した人たちをさらに引き上げる
基本的なスキルを習得していただいた方がもっと、高度なデータ集計ができるように、引き続きサポートをしていきます。
応用的な関数、クエリのレビュー、パフォーマンスや可読性を意識してSQLを書ける人を増やしていくことを目指します。
さらなる学習のナレッジの蓄積
学習の際につまづいたこと、こんなものがあったら良かったなど、学習を通しての反省を残していったり、教え合う機会を設け、社内での学習の効率化をしていきます。
習得してくれた方たちが、また別の方を教育できる状態を目指します。
この記事が気に入ったらサポートをしてみませんか?