なめらかなデータ利活用体験へ。UbieがLightdashを導入したわけ
こんにちは。UbieでアナリティクスエンジニアをやってますOKIYUKIです。自己紹介ページはこちらです。
最近UbieではLightdashをBIツールとして導入しました。Lightdashはちょうど最近dbt Sementic Layerとの統合が開始されるなど盛り上がってますね!
つい先日、弊社データエンジニアのYuさんがUbieに導入したLightdashについて紹介してくれましたが、改めて自分のほうでもなぜUbieはLightdashを導入したのか?について詳しく紹介したいと思います。
Ubieのデータ利活用のこれまで
2023年10月時点で社員数が280人となり、さまざまな目的でのデータユーザが増えてきました。 「テクノロジーで人々を適切な医療に案内する」というミッションに向けて、生活者向け事業や医療機関事業などで複数のプロダクトや各種機能が続々とリリースされています。Ubieはヘルスケア領域におけるデータを扱うことから、個人情報を保護し、医療データ特有の法令に遵守した上でのデータ利活用が求められます。守りをしっかり固めないと大きなリスクにつながることから、全社的にデータガバナンス・リスクマネジメントに力を入れています。
データの特徴としては、希少疾患と呼ばれる珍しい病気を扱うことも多いことからNが少ないデータを分析したり、時系列でのユーザージャーニーを追うことが事業のコア価値となります。そのためデータプラットフォーム上でのデータ信頼性を向上する取り組みは全社的に非常に優先度の高いテーマの一つです。データ信頼性を向上する取り組みはデータ基盤管理の考え方〜dbtの極意〜で以前発表しました。
Ubieは2021年ごろからdbtを中心としたデータパイプラインの開発・運用を行い、データ基盤は一定の進化を遂げ、安定したデータをデリバリーする仕組みや運用する体制もできてきました。分析のためのデータマート開発も複数チームで行われ、定量データだけでなく定性データと掛け合わせた分析をすることで、意思決定の質や納得度が向上する事例も複数出てきています。
しかしながら、1,2年後の目標に対してまだまだ進化への途中ではあります。Ubieが目指す利活用のテーマとしては、大きく以下2つのテーマがあります。
- データオーナーシップを各チームが持ち、データ信頼性を最大化することでデータの価値毀損を無くし、安全に管理されたデータをユーザに届け続ける
- セルフサービスによるデータ分析を可能とし、だれでも速度・精度を最大化してデータ利活用できるように
これら2つのテーマを進めるなかで、Lightdashは特にセルフサービスによるデータ分析を加速させるために導入しました。
データ利活用面でのこれまでの課題感
1年前ではデータ利用者に多少不便があっても、一定人手や認知負荷をかけてカバーしていた部分も多くありました。しかし、各事業やプロダクトのドメインがどんどん深くなり、社員数や組織も大きくなり、スケーラビリティを考えるとそのような運用はさすがに厳しくなってきます。「社員数 × データ利活用率 × ドメインの深さによるデータの複雑度」 がそれぞれ大きくなったことで、認知負荷をかけて解決するフェーズは終えました。真っ向から課題と向き合い、速度・精度を最大化したデータ利活用体験を構築していく必要があります。これを"なめらかな"データ利活用体験とUbieではよく表現しています。
データ利活用までの速度毀損
- SQLをクエリ書かないとデータ分析や可視化ができない。SQLはBizメンバーへの敷居があるのはもちろん、SQLを書くのにエンジニアの工数や時間を使ってしまう
- SQLだけだと、様々な軸でドリルダウンに分析するための集計作業が煩雑になりがち。BIツール内になるべくロジックは残したくないトレードオフとの格闘
データ利活用における精度毀損
- 分析・集計結果が人によって揃わないことで、スプレッドシートやLookerStudioのグラフを再現できない。結果、意思決定の判断ミスに繋がってしまう
- DWH側の変更により、ダッシュボードが壊れた場合を検知することができていない。dbt exposuresが登録されていても、ダッシュボードの中での集計が壊れてないかまでは人力で確認することになる
データ利活用のガバナンス管理
- センシティブなデータを扱うUbieにおいて、各種BIツールによってだれがどの権限で閲覧できるか・編集できるか適切に管理し、auditする仕組みが必要不可欠
- これらを人手で管理するとミスが発生する可能性も高くなるので、圧倒的にコードで管理したい...!
Lightdash導入
上記課題解決に向けて、UbieではいくつかのBIツールの導入・検証を行い、Lightdashを選定することにしました。検証項目としては上記プラットフォームとしての要件に加えて、アナリティクスエンジニアがLightdash上で様々な分析・ダッシュボード開発して、データユーザに提供するまでの一連のデータ利活用プロセスを評価しました。
- データを探索できるInterative UIを搭載しており、GUI上の操作で集計・可視化が可能
- dbt上でのMetric定義により、人によって集計結果が揃うように制御できる
- Lightdashが様々なAPIを提供してくれているため、それをもとにコードで管理しやすい
- Lightdash上では、データとダッシュボードが接続されているので、データの変更により壊れたダッシュボードを自動的に検知できる
Lightdashが可能とする各種機能やイメージについての詳細は、Yuさんの記事で紹介されていますのでぜひ読んでみてください。
課題の解決はもちろんのこと将来に向けたいくつかの拡張も視野にいれた選定です。Lightdashが様々なAPIを提供していること、OSSやクラウド版があること、LLM等のAIとの親和性も今後期待できるBIツールとして、データ利活用体験のさらなる発展・拡張していくことを考えています。
Lightdashは現在Seed roundで活発に開発してる最中なので、すべての機能が満足にある状態ではないですが、Ubieではクリティカルなものはないと判断しました。仮にこの記事を読んだ方がLightdash導入を検討する際は、要求事項を事前にクリアにした上で判断するとよさそうです。
カスタムクエリの保存について
redashのときはSQLでカスタムクエリを書いて保存して、アドホックにダッシュボードを構築するといったユースケースがありましたが、Lightdashでは現時点でカスタムクエリの保存はサポートされていません。ただし、開発は進行中なので将来的にはできる可能性あります。
アラート機能
Scheduled deliveriiesの機能で、定期的なDashboardの配信などは可能ですが、redashのようになんらかの閾値をトリガーにアラート通知上げる機能は現時点ではありません。
ただし、Ubieではdbt testsやdbt-elementaryを活用しているのでそれらで代替できる予定です。
より細かな権限管理
Project Rolesより細かい粒度での権限付与が現状はできないです。Lightdash Project自体を分割するなどの基盤の設計で考慮する必要があります。
ARRAYやSTRUCTの扱い
カラムとしてARRAYやSTRUCTのあるカラムをLightdashで一部利用できないケースがあります。この辺の細かいところの使い勝手は今後さらに改善されることを期待しています。
導入した所感
検証を終え、データマートを用いた可視化やダッシュボード化の実践投入しています。まさにこれから各組織への浸透を進めていくためのガイド含めた準備中です。実践に向けた運用上の工夫点はいろいろありますが、個人的にはいい感じのMetrics on Metricsが定義できると最高に気持ちがよいですね!この辺はまた別の機会で紹介したいと思います。
一緒に進めてくれるエンジニアを募集しています
Ubieではデータオーナーシップの導入・データ信頼性の最大化・セルフサービス分析を可能とするデータプラットフォームづくりなど、これらを進めるアナリティクスエンジニアやデータエンジニアの採用をOpenしています。また、その他エンジニア系職種も広く募集しているので、少しでも興味を持ちましたら直接応募していただいてもかまいませんし、一度カジュアルにお話したい方は私までX(Twitter) DMお待ちしております!
Discussion