こんにちは。Ubie Discoveryのおきゆきです。アナリティクスエンジニア/データアナリストとして働いています。自己紹介ページはこちらです。
Ubieでは、各チームが適切にデータを利活用できるようにするためのBI民主化活動を行っています。この記事では、昨年行ったBI民主化の取り組みの一部を紹介します。
BI民主化が必要なわけ
データチームが依頼の窓口となり、各チームの依頼に対応するというやり方は、ナレッジが独人化しがちで、チケット管理などの運用コストが増し、中長期的にみてもデータチームの生産性が低下しがちです。結果、本質的なデータ基盤改善や攻めの分析活動が後手になりやすいです。また、ドメインに詳しい依頼元が分析実施できたほうが良い示唆を得られることが多々あります。
一方、データチームを介さずに各チームで分析の実施までできている以下のケースではどうでしょうか。
「あるデータが欲しいプロダクトオーナーAが、チーム内のエンジニアBにメンションし、そこからそのデータに詳しい隣のグループGにダッシュボードがないか確認のためメンションし、ダッシュボードが見つからず、エンジニアBがローデータからSQLクエリを書いて、プロダクトオーナーAに伝達する」
このケースの改善点は、
- （slack等に常時返せる状態であれば）このやりとりに数十分程度はかかる = 時間がかかる
- 複数のメンバーとやりとりをしている = 生産性低下
- 慣れないローデータからSQLクエリを書くことで、誤った集計や他の指標と整合性が揃わない可能性がある = 精度低下
このように、各チームでの生産性および精度面での課題が大きくなります。そこで、Ubieでは、各チームが得たいデータを得るまでの速さと精度が高い状態を維持して、データ利活用できるようにするためのBI民主化活動 を行っています。
各チームへのヒアリングを通じて課題の把握
まず各チームが感じるデータ利活用の課題感を確認するためにヒアリングを行いました。職種やデータの利活用状況をみながら、複数のチームを対象に合計4回ほど分けて行いました。
各チームはそれぞれ扱うプロダクト（toB向けユビーAI問診 / toC向けユビー）やチームが目的とする活動やフェイズ（0→1 /10→100）も異なります。
ヒアリングする際に意識したことは、 「必要なデータの確認 → 実際のSQLを書く → 可視化する → ダッシュボード化する → 結論を得る → ナレッジを貯める」と言ったデータ利活用時のプロセス に沿って聞いていき、ボトルネックになってる箇所を発見することを意識しました。
もう少し具体的にいうと、
- 現在のBI業務(クエリ/ダッシュボード作成 & モニタリング & 分析 etc.)の1週間の割合
- あるデータを分析に使いたいとなったときどうしてる？
- クエリを書くとき、困ることはないか？
- 可視化/集計結果の信頼性や解釈に困ったことある？
- レビューとかどうしてる？
- ダッシュボードのメンテナンス（継続利用していく上での）に困りごとはないか？
- dbtは使ってる？ちゃんとデータマート作ったほうがよさそうなところとかある？
- ナレッジをどこかにまとめてる？
のような項目です。
できていることの整理
ダッシュボードの構築と定期的なデータのモニタリング
Ubieの多くのエンジニアは、自らSQLを書いて、チームの目的に沿った追うべき数値を可視化し、ダッシュボード化しています。また、多くのチームで、日次・週次のMTGでダッシュボードを確認するのがミーティングフローに組み込まれています。Ubie Discoveryは組織形態としてホラクラシーを導入しているので、ミーティングプロセスの中でメトリクスレビューが最初からセットされるため、チームが追う定量指標はなにか？を意識することが習慣付けられています。
そのタイミングで、「数値おかしくない？」「ダッシュボードなんか壊れてない？」 などの、数値の検知が一定できており、データを見る文化はすでに定着されています。
開発して終わりではなく、数値を見る文化
各チームである開発を行った後、作って終わりではなく、その結果数値がどう変化したか？数値が正しく取れているか？を明確にチケットの完了条件としていたり、子タスクとして明確に分けているチームが多いです。
その結果、なんとなく開発を終えて、完了したということはなく、数値で確認し、どれくらいインパクトがありそうか？、今後もっとそこを伸ばしたほうがいいか？などの意思決定にチーム内で自主的にデータが活用されています。
課題感の整理
逆にできていない箇所はどのあたりかをマインドマップツールを利用して整理します。ここでのポイントは、ヒアリングを通じて得た課題をそのまま羅列して表面的な理解をするのではなく、エピソードをベースに会社全体のレバレッジが効きそうな課題を見つけることです。
例えば、「ある集計クエリが間違っていたことにより、◯◯が起こってしまった」 「普段よく使うデータやクエリを、◯◯のようにして保管しているが、見つからないことも多々ある」「◯◯をしているが、データ集計した結果の解釈に自信がないまま利用している」のようなエピソードを複数集め、その原因がなぜ起こっているかを深掘って整理していきました。
新たに始めたこと
月1度のBIオンボーディング
課題感の整理から、浮かびあがった課題として「各種ナレッジの認知・How理解の不足」「データチームからの利用推進」というのがありました。
各種チーム内でデータの利活用は進んでいる一方、「意外とこの便利マートの存在が知られてなかった」「このSlackチャネル知らなかった」「Ubieのデータパイプラインの命名規則やルールが伝わってなく、不必要な処理をしている」「SQLの書き方に自信がなく、数値がおかしいときのSQLデバッグなどで書くのに時間がかかってる」など複数見つかりました。明確にこれらを知る機会が設けられてなかったことや、データチームからも利用推進できていなかった気づきがありました。
そこで、ドキュメントとしてまとめたのちに、社員向けにBIオンボーディングを月一度定期開催する場を改めて作りました。こういうドキュメントは一度作って終わりになりがちですが、新入社員が毎月入社されることもあり、ドキュメントをアップデートする機会が強制的に発生するので、鮮度の維持ができていると感じています。
また、既存メンバにもエンジニアの全体定例MTGで話し、改めて全体でBI業務の基礎的な理解を進めました。
とくに好評だったのが、Ubie流のSQLの書き方講座で、基本的にはdbtLabsが公開している Refactoring legacy SQL to dbtをベースに、「CTEに分割せよ。なぜなら◯◯だから」「最初は、import_xxxで始めよ。なぜなら◯◯だから」「コメントにはWhyを書くべき。なぜなら◯◯だから」といった例をベースに説明しました。個人的にも、複数のチームのSQLレビューを行うことが多いので、それ以降SQLの記法揺れが抑えられて認知負荷が下がり、生産性が上がったと感じます。
データチームによる定期的なクエリモニタリング
課題感の整理から、浮かびあがった課題として「データチーム内での不適切な利用の検知」というのがありました。
Ubieではエンジニアだけでなく、BizDev含めて多くのメンバーがBigQueryで分析をしており、Ubie Discovery社員の半数以上でSQLクエリが発行されています。とても良いことなのですが、その中には改善できそうなクエリもいくつかあります。例えば、「コストがかかっているクエリ」「処理時間がかかっているクエリ」「古いマートや信頼性が低いログを使用したクエリ」などです。これらは、BI民主化が進むと一定の頻度で今後も発生するので、データチームのほうでに定期的なクエリモニタリングを行い、改善対象を検知する取り組みをしました。具体的には、下記を参考にBigQueryのINFORMATION_SCHEMAを利用した利活用ダッシュボードを整備しました。
結果、コストがかかっているクエリの廃止だけでなく、このテーブルAとBを同時によく使ってるユーザが多いので、クエリをマート化したら、便利そうなど、クエリを精査することで、全体の品質や生産性を上げるための改善を拾えるようになりました。
それ以降進めてること
対象チームを広げ、データマネジメント成熟度アセスメントの項目も使いながら、定期的にヒアリングをする場をセットしています。とくに、普段はデータを使う立場ではないけど、Data Segregationやセキュリティを定義し、守る立場のチームや、データを使いたいと思ってるけど使えてないチームのヒアリングが行えていないので、新たな課題感を拾っていきたいと思います。また、下記の記事を参考にヒアリングの型も定めていきたいと思います。
各チームで施策に対する検証を定量的に測れていますが、施策や開発によってそのチームの目的外のメトリクスへの思わぬ数値影響があったりします。会社や事業として重要なメトリクスは一定中央集権的に管理・モニタリングすることをやっていきたいと思っています。かといって運用コストは上げたくないので、Data Observabilityツールの導入による、データ品質やメトリクスの異常検知を効率よく行えるように検証中です。
浮かびあがった課題の1つに「知識のアセット化と共通化」というのがあり、そのHowの1つとしてエンジニアが積極的にデータマートを構築していく取り組みも行ってます。なかなか本業の開発がある中で、データマート化まではリソースが足りないので、定期的なクエリモニタリングで検知した1名1名と手厚くペアプロ的にdbtのmodel化を行っています。Ubieのエンジニアは興味の幅が広く、BI領域に興味のあるエンジニアも多いので、あとはやっていくだけです。
ぜひ一緒にやりましょう
上記のようなBI民主化の推進、事業に直結するデータプロダクトを継続的に改善する取り組み、これらを実行するためのデータプラットフォームづくりを進めるアナリティクスエンジニアやデータエンジニアを募集しています。
興味のある方は下記JDから直接応募していただいてもかまいませんし、一度カジュアルにお話したい方はそれぞれのメンバーと話せるカジュアル面談ページがあるのでぜひお気軽にご連絡ください。
Discussion