こんにちは、delyでデータエンジニアをしているharry(@gappy50)です。
現在、弊社ではLightdashを全社BIツールとして標準化しながら、データエンジニアやアナリティクスエンジニアではなく、データから意思決定をするメンバーにdbtのデータモデルの開発およびデータ管理を含めたオーナーシップをもってもらうためのDataOpsを実践し始めています。
一方で、弊社でもボトムアップ/トップダウン問わずAI-Firstの大号令のもと、AI利活用のための制度設計やエンジニアリング業務でのAI活用事例が増えてきています。
その中で、データ利活用に関してどのようにAI活用をしていくかについて、先程のDataOpsの活動とあわせて解像度が高くなってきました。
具体的には、データモデルに対してTierを設定してデータの品質・メタデータをどのように組織として整備していくか、継続的に管理してAIに対してどのようにコンテキストを与え続けていくかのオーナーシップや役割を明確にしていくことが重要だと考えています。
先日、Ubieさんの BI生成AIラジオ のPodcastに出演させていただいた際にも、こちらの取り組みをご紹介させていただいたので、ぜひそちらもご視聴ください！
今回は、そのTieringについて社内でどのようにルールを設定しているかという事例をご紹介します。
Tierによるデータの格付け
まず、我々が設定しているTierの全体像をお見せします。
| Tier | Verified | 用途 | Ownership | Metadata | dbt test | TTL | AI利用 |
|---|---|---|---|---|---|---|---|
| Tier 1 | ✅ | 監査・外部公表（MAU/DAU等） | Data Owner & Data Engineer | All | unit test, generic test | - | Yes |
| Tier 2 | ✅ | 経営KPI・意思決定 | Data Owner | All | unit test, generic test | - | Yes |
| Tier 3 | ❌ | 部門意思決定・レポート | Data Owner | All | generic test | - | Yes |
| Tier 4 | ❌ | アドホック可視化 | Data Owner | - | - | 90日 | No |
| Tier 5 | ❌ | 個人検証・試行 | - | - | - | 30日 | No |
現在、すべてのデータモデルに対してTierを設定しています。
Lightdashで直接SQLを書いて作るチャートはTier5として扱います。
そこから、dbtでモデル管理しセマンティックを定義した状態がTier4、
最低限のテストとビジネスメタデータをすべて埋めたものがTier3と、
データモデルとメタデータの品質が高くなるにつれてTierが上がっていきます。
それらの品質がTier3まで上がってきたタイミングでAIエージェントを利用した分析を可能にすることを現時点では想定しています。
また、Tier4以下のデータモデルについては一定期間で自動削除をする実装もしており、アジリティを確保する一方で、定常的に見る必要があるデータは品質を高めることで、より高い品質と利便性を実現できることを目指しています。
このTier表で実現したいことは、AI活用のインセンティブをもたせつつ、アジリティと品質のトレードオフを解消するデータガバナンスの段階的なアプローチです。すべてのデータを同じレベルで管理するのではなく、用途と重要度に応じて必要十分な管理レベルを適用する。これが弊社の企業文化に根ざした、持続可能なデータマネジメントの実践の鍵になると考えています。
なぜTierが必要なのか
これまで、アジリティを重視することは我々の競争力の原動力でした。Redashで前日リリースした機能の速報値をクイックに数値を確認することでプロダクトの開発速度を支える。これは今でも変わらず重要です。
しかし、
- 0→1の繰り返しでデータが資産として蓄積されない
- そのため同じような指標を計算するRedashのクエリが量産される
- 0->1は早いが常に0->1のコストを払わなければプロダクトの開発速度に追いつかない
- 品質の悪い数値から間違った意思決定をしてしまう可能性・リスクが高すぎる
- Redashでのデータマネジメントを実施するコストが高すぎる
- 自由度が高い分、DataOpsを実装しても品質を高める活動にクエリを書く人が向き合うことが難しい
- 少ないデータエンジニアの数では注力すべき重要な数値の品質管理やモデル開発が最重要となる
- こちらもまた0→1の繰り返し
- すべてのデータ利活用の再現性を作るためのDataOpsに向き合うコストを捻出することが困難
- データエンジニアが意思決定のための解像度を理解するまでのコストと、そこから品質を高める活動までのサイクルが開発サイクルと全く一致しない
といった課題に直面していました。
これらの課題を解決するために、私たちはデータライフサイクルを意識したDataOpsの実装と、組織全体でそれを実践するためのデータ利活用プロセスの再定義に取り組みました。
単にツールを導入するのではなく、データの生成から削除までのライフサイクル全体を設計し、誰がどの段階で何に責任を持つのかを明確にする。そして、そのサイクルをどれだけ早く回すことができるのかを組織のカルチャーやメンバー育成、ツールによる支援とあわせて実践していくことを目標としてデータ基盤の再整備などを行っていました。
このプロセス再定義の中核となったのが、意思決定者自身がデータオーナーになるという責任分界の明確化でした。
Data Ownerという考え方
Data Ownerとは？
データオーナーとは、チームのデータに基づく意思決定に責任を持つ人という定義をしています。多くの場合はPdM（プロダクトマネージャー）がその役割を担いますが、場合によってはPdMから委任された人が担当することもあります。
Data Ownerは以下の責任を持ちます。
- 意思決定に用いるデータの管理
- データの目的と利用文脈の説明
- データ品質の維持と向上
- ビジネスメタデータの整備
なぜData Ownerでないといけないのか
先ほども書きましたが、データエンジニアが意思決定にオーナーシップを持つことは以下の観点で難しいと考えています。
- そもそもデータエンジニアが意思決定を行うわけではないため、ビジネスの解像度が意思決定者ほど高くない
- 様々なチームの依頼を労働集約的にこなしていくのでは意思決定のスピードはスケールアウトしない
- 品質ありきでデータモデルを作成する場合のリードタイムが開発速度と一致しない
一方、意思決定者がData Ownerになることで、
- 最も高い解像度でデータを定義できる
- ビジネス文脈を正確に理解している
- アジリティが格段に向上する
- 依頼・待機のサイクルがなくなる
- 責任と権限が一致する
- 使う人が作り、管理する
弊社はRedashでSQLを書き続ける0->1の文化やスキルがある分、その方々が最終的なデータに対してのオーナーシップをもつことが自然であり、それらの方々にデータオーナーの役割を担ってもらう、もらいやすいようにすることが重要と考えています。
Data OwnerとData Engineerの新しい関係性
Data Owner制度の導入により、データチームとビジネスチームの関係性が根本的に変わりました。
データエンジニアの新しい役割
- データ基盤とツールの整備・改善
- Tier2以上の品質ゲートキーパー
- ベストプラクティスの共有と教育
- 複雑なデータモデリングの支援
Data Ownerが得た権限と責任
- dbtモデルの作成・更新権限
- Lightdashでのメトリクス定義
- ビジネスメタデータの管理
- チーム内でのデータ活用推進
この新しい関係性により、データエンジニアは「依頼を受ける人」から「品質を守り、育成する人」へ。Data Ownerは「依頼する人」から「自ら作り、責任を持つ人」へと進化しました。結果として、データライフサイクル全体が高速化し、組織全体のデータ活用が加速しています。
Lightdash導入による成功体験の積み重ね
Lightdashの導入により、まずはTier 4レベルでも目に見える成功体験が生まれ始めました。
Single Source of Truth（SSOT）の実現
これまでBizチームと開発チームが別々のRedashクエリで数値を確認していた状態から、Lightdashの同じダッシュボードを見るように変化しました。
「昨日の継続率、Bizでは85%って言ってるけど、開発では83%になってる」みたいな会話がなくなりました。同じdbtモデルから生成された同じ数値を、全員が参照するようになったからです。
SQLを書けない人の解放
これまでSQLを書けないメンバーは、データエンジニアやアナリストに依頼して待つしかありませんでした。
Lightdashなら、すでに定義されたテーブルやメトリクスをポチポチするだけ。商談中に「先月の地域別の売上は？」と聞かれても、その場でドリルダウンして答えられるようになりました。リアルタイムでインサイトを得られる、この体験は革命的でした。
新たな課題：増える責任領域
ただし、これで万事解決とはいきませんでした。
車輪の再発明がなくなり工数削減にはなったものの、Data Ownerが管理すべき領域が急激に増えました。dbtモデルの管理、メタデータの整備、テストの実装、ドキュメントの更新...。「便利になったけど、やること増えるのはつらい」という状態になるのは当たり前の話でもあると思います。
Tierを上げるためのインセンティブ設計
そこで考えたのが、品質向上に対する明確なインセンティブです。
AIエージェントを使うために必要な活動=Tierを上げるための活動
ここからは現在対応中ではあるのですが、Tier 3以上のデータにはAIエージェントが使えるようにすることを計画中です。
「先月と比べて売上が落ちた要因を分析して」のような自然言語だけでデータ分析が可能になることこそが、AI-Readyなデータ利活用で必要なものだとするのであれば、我々はデータライフサイクルを正しく回していくことで「あれ？いつの間にかAI-Readyなデータ活用ができている」という状況になっている、それこそが今後のAI活用とデータの活用の文脈で継続的に活用ができる組織になるためにとても重要と考えています。
つまり、品質を上げれば上げるほど、分析が楽になるという仕組みです。Data Ownerの負担を増やすのではなく、品質向上が自分たちの業務を楽にする。このインセンティブ設計が、Tier運用を機能させる鍵となりました。
データライフサイクルを高速で回すためのAI活用
それ以外にもDevinを使ったデータパイプライン実装の自動化やClaude Codeを利用したAIコーディングなど、Tierを上げていく以外にもデータライフサイクルを高速で回すための取り組みをAIを使って加速できないかトライしています。
Claude Codeについての事例はまた別でご紹介できればと思っています。
まとめ：AI-Readyなデータ活用への道筋
ここまで、delyのTier運用とData Owner制度について紹介してきました。
データの生成から削除までのライフサイクル全体を設計し、Data Ownerという形で責任の所在を明確化することでDataOpsによる組織全体のデータ活用をよりよくできる状態になってきています。
そして、データライフサイクルを意識したデータ基盤の再構築を実施し、dbtとLightdashのデータモデル作成を全員で実施することで成功体験を積み重ね、現在はTTLによる自然淘汰とAIインセンティブで、アジリティと品質を両立させるための挑戦をしています。
0→1のアジリティを保ちながら、1→10、10→100へと成長させる。AIがコーディングを支援し、人間が意思決定と品質に集中する。この分業により、「いつの間にかAI-Readyなデータ活用ができている」という状態を実現できます。
重要なのは、完璧を目指すのではなく、データも育てていくという考え方。Tier運用は、その成長を支える仕組みです。
最後に
データの民主化と品質担保の両立。この永遠の課題に対して、私たちは
- データライフサイクルを高速に回すためのDataOps
- データマネジメントにボトムアップで向き合うためのデータ基盤の再構築およびツール選定
- データモデルの管理のためのTiering
という組み合わせで挑戦しています。
まだまだ改善の余地はありますが、少人数でも持続可能なデータマネジメントは実現できる。そう確信していますし、AI活用における適応課題の解法としてもこれらを実践し続けていければと考えています。
みなさんの組織でも、似たような課題があれば、ぜひこのアプローチを参考にしてみてください。そして、より良い方法があれば、ぜひ教えてください！
データの未来を、一緒に作っていきましょう。
パワー！！💪
Discussion