こんにちは、おきゆきです。Ubieでデータ周り全般をやっています。自己紹介ページはこちらです。
この1年でUbieではBIツールとしてLightdashを導入しました。導入背景や選定理由などを以前いくつかの記事で紹介させてもらいました。
この記事ではLightdash導入によるUbieで起こった効果について改めて紹介したいと思います。導入を決めたときには、少なくとも私自身が想像できてなかった想定以上のポジティブな効果が多かったと感じています。それらについて詳しく話したいと思います。
Lightdashでの利用に適したデータマート設計に変更し、開発と運用コストが減少した
Ubieでは以前から4層レイヤーによるデータパイプラインを開発しています (参考: Ubie Tech Talk で、「2021/12/14 dbt 運用の7つの疑問と対策」という発表をしました)
- if層 (interface層) : 異常データ・開発者データなどを除いたクリーンなソースデータ
- dc層 (data component層): 再利用可能な意味のあるデータがまとまった使いやすいデータ
- dwh層 (data warehouse層): 上流の複数データを結合済みにした大福帳テーブル（One Big Table）
- dm層 (data mart層): 個別のユースケースに特化した分析・レポーティングのためのデータ
Lightdash導入前は、BigQueryコンソールでSQLを書いたり、別のBIツールでカスタムクエリを書いて可視化するといった分析が多く、SQLを書くのをいかに効率化できるかという点でdwh層の大福帳テーブルを構築していました。データアナリストのような特にデータを詳細に分析するメンバーにとっては有用なのですが、コードが膨れ上がることでdwh層にロジックを追加できるメンバーは限定的になったり、開発工数が増加することが起こっていました。また、dwh層が便利になることで特定の分析用途でしか使わないようなカラムも運用上追加する必要になり、それに関心のないメンバーにとっては混乱を招いたり、時間が経つとメンテナビリティが下がることがわかってきました。
Lightdashには以下のような機能が備わっているため、上記のようなdwh層/dm層を整備する頻度が減り、dc層のコンポーネント開発の関心度をあげることができます。結果、各チームのエンジニアが便利なdc層のコンポーネントを開発運用していくデータオーナーシップ醸成も進めやすくなりました。
-
タイムスタンプのカラムは様々な粒度の時間・日付に変更できるので事前にテーブル上でカラム定義しておく必要がなくなります(Time-intervals)
-
特定の分析用途で必要なカラムをLightdash用に追加定義できます(Additional Dimensions)。これは、テーブル上では運用上文字列型になってしまっているものをLightdash上では日付型にしておく、また逆にも変更できます。また元のカラムは利用者には匿名性の観点で閲覧不可にしたいが便宜上変換したものを追加するといったことも可能とします。
-
Lightdash上のJOINができることで、必要以上にdwh層でJOINしておく必要がなくなります(Joins reference)
- 特に粒度の異なるデータを ARRAY<STRUCT> 構造でJOINすることが有用な場面も多いですが、上記に書いたとおりコードが膨れ上がる原因になったり、同じようなカラムがコードベース上複数存在することでノイズになることも多いです。
-
集計をコードで定義できるため、dm層のデータを必要以上に作る必要がなくなります(Metrics)
事例としては、あるチームで週に複数回ABテストをするようなケースがあり、エンジニアがABテストの変更に合わせてdc層やdwh層に追加改修する必要があるといった作業が発生していました。
これを改善するために、ABテスト用の汎用dc層コンポーネントを作り、Lightdash joinsを使って粒度の異なるdwh層データで分析できるように設計を変更しました。エンジニアにとっては見慣れたABテスト用のdc層コンポーネントの開発を意識しておくだけで、ABテストで共通的なメトリクスを閲覧できる状態を実現できました。
Lightdashに適したABテストのテーブルができ、今後の検証時の開発・分析効率があがった
データ分析が活発になり、施策がヒットする確率が上がった
Lightdashで分析できる分析軸やメトリクスが充実したことで、Lightdashにいけば得たいものが得られる・個々のメンバーが気になった軸での分析もGUI上でポチポチやれば得られるといったことが浸透してきました。最初はアナリティクスエンジニアからのオンボーディングで始めて、日々の業務で触っていくうちに徐々に覚えていくといったプロセスです。
Ubieでは同じ週に複数の施策をリリースし、その検証効果を確認するといったことが盛んに行われています。そのため、アナリティクスエンジニアがすべてを分析していてはスケールしません。また次の施策を考えるにあたってチーム全員で施策がどうだったか・こんな軸で切ってみたらどうかといった議論をしてMTGの最中に確認できるスピード感がとても大事です。議論を限られた時間内に濃密に行うことができ、チームでの分析回数（打数）が増えることで、インサイトが見つかり次の施策もポジティブな結果になる確率（打率）もあがったと体感しています。今ではLightdashを中心としたデータ利活用体験の構築を期初に重点的に行っています。
Lightdashがチームの全員に浸透し、全員が分析できるようになった
ロジックがdbtに残るようになり、チーム外メンバーのデータ分析の生産性が上がった
Lightdash以外のBIツールを使っていたときはBIツール上の最終ロジック（カスタムクエリやBIツール仕様のロジック）を読み解く必要がありました。これは開発したメンバーなら把握できると思いますが、隣のチームなどの普段その結果を見慣れないメンバーにとっては難しく、分析に再利用するのが困難でした。
一方、Lightdash化を進めたことで、ロジックがdbtのSQL上だったり、dimensions定義を記述するschemaのYAMLファイル上にコードベースで残ることで検索しやすく、比較的容易にロジックをトレースすることができるようになりました。これは特にプロダクト横断的な分析をしたいメンバーにとって、データを効率よく探せるようになりました。
Lightdash浸透により、データドメインに詳しくないメンバーが容易にコードベース上で定義を把握できている
ダッシュボードやチャートが壊れたものが早急に検知され、予想外や突発的な対応が減少した
Ubieではdeployしたdbt modelについてCI/CDでLightdash validateを行い、Failしたときのエラー内容を開発者に通知する仕組みを運用しています。これにより安全に古くなったカラムやメトリクスの撤退を行うことができます。もちろん想定以上に利用されていた場合には切り戻すなどの対応判断にも利用しています。
Slackチャネルに通知される内容
特定のチャートで使われていたカラムが無くなり、該当チャートでエラーが出ていることを漏れなく通知
壊れたチャートがある場合、それを正しく修正したり、利用していない場合は削除することで、漏れなく誤ったデータを廃止することができます。この機能がないときは間違ったグラフが残ったり、想定外の社内ユーザが利用していて、後から問い合わせを受けることがありましたが、このような突発的な対応を減らせることができたと感じています。
データアナリスト・データサイエンティストを募集しています
Lightdashを導入したことにより期待以上の効果が各所で出て、データ分析が活発に行われるようになりました。今ではdbtとLightdashを中心としたデータ利活用体験の進化をさらに進めています。このようにデータ分析が社内で活発に行われている中で、Ubieではよりヘルスケアドメインの深いデータ分析やプロダクト横断的な視点でデータ分析を一緒に進めてくれる方を絶賛募集中です。少しでも興味を持ちましたら直接応募していただいてもかまいませんし、一度カジュアルに話を聞いてみたい方は私までXのDMお待ちしております！
Discussion