会社にデータエンジニアがいることでできるようになること

https://monotaro.connpass.com/event/360460/ での発表内容です

Transcript

1. 10X, Inc. ALL RIGHTS RESERVED 会社にデータエンジニアがいること でできるようになること 関西データエンジニア/アナリティクスエンジニアMeetup〜モノタロウ、10X、タイミー、ダイハツ〜 株式会社10X Yasuhisa Yoshida
2. 10X, Inc. ALL RIGHTS RESERVED 自己紹介 • 吉田 康久 ◦ Xやはてなidは@syou6162 / id:syou6162 • 株式会社10Xでデータエンジニア ◦ 2022/09に入社 ◦ エンジニアリング本部 データサイエンス&エンジニアリング部に所属 ◦ データマネジメント / データガバナンスの仕事をしてます • 京都から働いてます ◦ 新卒からずっと関西 ◦ 東京の満員電車が無理です... • これまでの職歴としては研究者(NLP & ML) => Webアプリケーションエンジニア, MLエンジニア => データエンジニ ア, Analytics Engineer • dbt Community spotlight & Google Developer Expert(旧Google Cloud Champion Innovator)に選出されました • Data Engineering Studyのアドバイザに就任しました • 最近の趣味 ◦ 卓球観戦:WTT横浜を四泊五日で応援してきた ◦ Claude Codeで自分用のツールを書かせること(CLIのRSSリーダー / Podcast支援作成ツール / cchook) 2
3. 10X, Inc. ALL RIGHTS RESERVED データエンジニア / アナリティクスエンジニアの仲間を増やしたい! • datatech-jpというコミュニティの運営をやってます ◦ Slackを中心に活動、1831人の参加者がいます • 色んな会をやってます! ◦ Casual Talks(データに関係するあらゆるテーマをカジュアルにわいわいする会) ◦ データ関連のOSSのニッチな会 ▪ 全日本dbt-osmosisを愛でる会 ▪ 全日本datacontract-cliを使い倒す会 ▪ コントリビューターでもあります ◦ Data Contract事例共有会 ◦ アジャイルデータモデリングの輪読会(6月末にスタートしたばかりです!) 3
4. 10X, Inc. ALL RIGHTS RESERVED 夏から秋にかけて他にも色々話すので、是非来てください! • Tokyo dbt Meetup#16: dbt開発 with Claude Codeのためのガードレール設計 • Data Engineering Study #31: データエンジニアがこの先生きのこるには...? • アーキテクチャConference2025: 現場課題から考えるセマンティックレイヤーとデータモデリング 4
5. 10X, Inc. ALL RIGHTS RESERVED アジェンダ • 背景: 10XとStailerについて • データエンジニア今昔 • 今なお存在するデータの困った課題 • 会社にデータエンジニアがいることでできるようになること ◦ 個別課題の撃破...ではなく全体を見通す: データマネジメントのアセスメントの実施 ◦ データ品質の可視化、そこからのデータ基盤運用改善 ◦ 入口のデータ品質の担保: Data Contract ◦ 出口の期待値調整: Data Reliability Levelの設定 • まとめ 5
6. 10X, Inc. ALL RIGHTS RESERVED アジェンダ • 背景: 10XとStailerについて • データエンジニア今昔 • 今なお存在するデータの困った課題 • 会社にデータエンジニアがいることでできるようになること ◦ 個別課題の撃破...ではなく全体を見通す: データマネジメントのアセスメントの実施 ◦ データ品質の可視化、そこからのデータ基盤運用改善 ◦ 入口のデータ品質の担保: Data Contract ◦ 出口の期待値調整: Data Reliability Levelの設定 • まとめ 6
7. 10X, Inc. ALL RIGHTS RESERVED ネットスーパー運営に必要な全ての要素を提供しています 7 Stailer ネットスーパー事業 - 提供プロダクト 小売事業者向けアプリ ミスが少なく効率的な 業務オペレーションを実現 配達スタッフ向けアプリ スタッフ用アプリと完全連動し、 効率的なルーティングを実施 ネットスーパーアプリ 数万点のSKUからスムーズに お買い物ができる
8. 10X, Inc. ALL RIGHTS RESERVED Stailerは小売のドメインデータを統合し、経営課題を解消するために複数 のプロダクトをスムーズに提供します Stailer マルチプロダクト戦略 8
9. 10X, Inc. ALL RIGHTS RESERVED アジェンダ • 背景: 10XとStailerについて • データエンジニア今昔 • 今なお存在するデータの困った課題 • 会社にデータエンジニアがいることでできるようになること ◦ 個別課題の撃破...ではなく全体を見通す: データマネジメントのアセスメントの実施 ◦ データ品質の可視化、そこからのデータ基盤運用改善 ◦ 入口のデータ品質の担保: Data Contract ◦ 出口の期待値調整: Data Reliability Levelの設定 • まとめ 9
10. 10X, Inc. ALL RIGHTS RESERVED データエンジニアの仕事は何かしらの形で置き換えられてきている • Hadoop / HDFS => BigQuery / Snowflake / Databricks / S3 / GCS / … / etc ◦ 大規模データに関わる開発 / 運用が圧倒的に簡単になってきた • Embulk / Digdag => Fivetran / TROCCO / dbt / Dataform ◦ データの取り込みや加工がSaaSやSQLだけで簡単に行なえるようになってきた • Looker Studio / TableauなどのBIツールにより、データ分析や可視化も簡単に行なえるようになってきた ◦ Semantic LayerやConversational Analyticsで一貫した分析が画面操作や自然言語でも簡単に • データカタログ / メタデータ管理 ◦ Dataplex Universal Catalogのようなマネージドサービスも当たり前になり、LLMもメタデータを記入できる • 細かなデータに関するスクリプトの作成はLLM Agentが数分でやってくれるようになってきた • 少しずつ確実にデータエンジニアの仕事は置き換わってきている • 注意: これらのプラットフォームを作ること自体ももちろんデータエンジニアリングですが、今回は事業会社でデー タ活用を推し進めるデータエンジニアリングに焦点を当てます 10
11. 10X, Inc. ALL RIGHTS RESERVED 11 データエンジニア、要らんのでは...🤔?
12. 10X, Inc. ALL RIGHTS RESERVED 12 ある意味そうなってきている...!
13. 10X, Inc. ALL RIGHTS RESERVED 13 でも、データエンジニアがいるからこそ 出せる価値がまだまだある(はず)
14. 10X, Inc. ALL RIGHTS RESERVED アジェンダ • 背景: 10XとStailerについて • データエンジニア今昔 • 今なお存在するデータの困った課題 • 会社にデータエンジニアがいることでできるようになること ◦ 個別課題の撃破...ではなく全体を見通す: データマネジメントのアセスメントの実施 ◦ データ品質の可視化、そこからのデータ基盤運用改善 ◦ 入口のデータ品質の担保: Data Contract ◦ 出口の期待値調整: Data Reliability Levelの設定 • まとめ 14
15. 10X, Inc. ALL RIGHTS RESERVED データにまつわる課題例: 必要なデータはどれ?!問題 15 分析には正しいデータを使うことが必須...だけど現実は厳しい BigQueryにはOrderって名前のテーブ ルがたくさんあるけど、自分の用途に 合っているのはどのテーブル ...? このテーブルな気がするけど、カラム AとカラムBの違いが分からな い...微妙に数字が違うけど、どっちを使えばいいの ... そもそもこのテーブルを管理しているの は誰なの... よく分からないけど、今回はこのテーブ ルで分析してみるか (案の定用途に 合ってないテーブルで手戻り発生 ) BizDevやアナリスト
16. 10X, Inc. ALL RIGHTS RESERVED データにまつわる課題例: データ品質が低い 16 聞いてるだけで胃が痛い... やっとのことでそれっぽいテーブル が見つかったぞ... 分析に使いたいカラム、 20%くらい 欠損してるけど、なんで ... どうも去年の10月分までのデータ しか入ってないんだが ... えっ、そもそもデータ更新のバッチ が先月から止まってるの ?! こんな品質のデータではパート ナーの信用は勝ち取れないよ ... BizDevやアナリスト
17. 10X, Inc. ALL RIGHTS RESERVED データにまつわる課題例: このデータどうやって作られてるの問題 17 エンジニアの悩み...データがどうやって作られているかの謎を解き明かすために我々はアマゾンの奥地に FireStore GCS BigQuery(ローデータ) BigQuery上で 様々な加工... スプレッドシート上で 様々な加工... BI上で 様々な加工... 品質に問題があるって言われたか ら、このデータどうやって作られて るか見てみるか... 構成図もないから、 コードを読み解くしか ない。このテーブルを 作っているのはどこ だ... いくつもの層で加工されていて頭 が混乱してきた... この作り(アーキテク チャ)で求められてる 品質を満たすの無 理じゃないか... 元データもそういう 用途で使われること を想定していなかっ たらしい エンジニアやアナリスト
18. 10X, Inc. ALL RIGHTS RESERVED データにまつわる課題例: 全体をいい感じに回さないといけない問題 18 各所からくる要望が溢れていて、困り果てる担当者 メタデータが整備されない と、分析するまで大変です ! データ品質が高くないと業務 に支障が出ます! データアーキテクチャちゃん としないと要求に答えられな いです! データセキュリティ、ちゃんと してください! とにかく色んな要望があること だけは分かる。それ以外は何 も分からない... どれが本当に重要度が高く て、どういう順番でアプローチ すればいいんだ...
19. 10X, Inc. ALL RIGHTS RESERVED アジェンダ • 背景: 10XとStailerについて • データエンジニア今昔 • 今なお存在するデータの困った課題 • 会社にデータエンジニアがいることでできるようになること ◦ 個別課題の撃破...ではなく全体を見通す: データマネジメントのアセスメントの実施 ◦ データ品質の可視化、そこからのデータ基盤運用改善 ◦ 入口のデータ品質の担保: Data Contract ◦ 出口の期待値調整: Data Reliability Levelの設定 • まとめ 19
20. 10X, Inc. ALL RIGHTS RESERVED 全体を見通す: データマネジメントのアセスメントの実施 20 取り組む順番を依存関係のDAGとして定義 特に優先して進めたい項目 ! 時系列で毎年の推移が追えます(一昨年 / 去年 / 今年) 何をどういう順序で解くとデータガバナン スとしてよさそうか、依存関係を決めるこ とができた
21. 10X, Inc. ALL RIGHTS RESERVED 参考: 過去3年間のアセスメントの結果 21 データ基盤チームの成熟や事業の状況によりレベル感や優先度も変化する データセキュリティは初手で着手し、優先度は落ち着いてきた LLM Agentの登場によりドキュメント管理の優 先度がかなり上がってきた データ品質のレベル感は高くなってきたが 求められるものも高いため優先度はほぼ変わらず
22. 10X, Inc. ALL RIGHTS RESERVED データエンジニアがいると...! 22 個別の課題をやみくもに力技で撃破 するのではなく、全体を見通した上でデー タの課題に取り組むことができる !
23. 10X, Inc. ALL RIGHTS RESERVED アジェンダ • 背景: 10XとStailerについて • データエンジニア今昔 • 今なお存在するデータの困った課題 • 会社にデータエンジニアがいることでできるようになること ◦ 個別課題の撃破...ではなく全体を見通す: データマネジメントのアセスメントの実施 ◦ データ品質の可視化、そこからのデータ基盤運用改善 ◦ 入口のデータ品質の担保: Data Contract ◦ 出口の期待値調整: Data Reliability Levelの設定 • まとめ 23
24. 10X, Inc. ALL RIGHTS RESERVED 参考: データ品質 24 項目名 具体例 可用性 注文の分析をしたいと思い、いつも通り利用している注文テーブルを確認しようとしたらテーブルが存在していなかった 一意性 あるユーザーIDに対して二つのレコードが存在しており、ユーザーが登録した日時が正確に判断できない 一貫性 商圏を確認するために注文情報にある住所データを利用していたが、同じ地域なのに別の表記がされていて分析するときに名寄 せが必要になってしまう 妥当性 購入率などの確率を表す指標が 100%を超えてしまう 追跡可能性 スプレッドシート経由でデータを提供しようとしたが、他のシートの参照やコピーを複数利用していたので実際にどのデータから作 成されたシートなのかが判断できない 明瞭性 商品の分析をしようと BigQueryにアクセスしてデータを探していたが、目的のデータがどこにあるのかわからない
25. 10X, Inc. ALL RIGHTS RESERVED データ品質やその管理のあるべき状態を定義する 25 項目 As-is To-be データの目的の明 確化 データの目的が不明瞭なものがある - あるデータの目的が見たいときにいつでも見れる状態になっている - データの目的に関する項目は一定のフォーマットに従って統一的に定義さ れている データ品質指標の 定義 全社共通の指標の定義がない 全社共通でデータ品質を計ることができる指標が明確に定義されている。開 発者の間で指標の共通認識がある 指標の測定方法 の確立 指標の測定方法がない 指標を定量的に測定するメトリクスが定義されている 指標の可視化・監 視 指標が可視化されておらず、指標に変化があっても検知できない - 指標を常に可視化し、データ利用者がデータの品質を認識できる - 指標のマクロな変化を監視し、データ開発者がデータ品質が維持できてい るかを確認できる 指標を維持、改善 する開発ライフサ イクル 一部にアーキテクチャは存在するが、個人の設計や実装能力に依 存している部分が大きい - 個人に依存しない開発ライフサイクルやパッケージを開発し、指標に対応し た実装方法やテストが明確になっている - 各開発チームの中で開発ライフサイクルに関する To-beが定められており、 それらに向かった活動が行われている (Enabling) 利用者の品質の 認知 - データ利用者によってデータ品質の理解度に差がある - 共通の理解が取れているのかは定かではない データ利用者が品質に対する高い理解を等しく持てている状態を作る (デー タアンバサダー施策など ) いきなりテストの追加や指標の 可視化を行なわない!
26. 10X, Inc. ALL RIGHTS RESERVED データ品質指標の定義 • DAMAやデータ品質管理ガイドブックなどデータ品質の定義はよく知られたものがある ◦ しかし、指標の定義が10以上あり、スタートアップがデータ品質に取り組むにはちょっと重い... • チーム内の認知負荷を上げないためにも、大雑把に4つに分類 ◦ Data Quality Score: The next chapter of data quality at Airbnbを参考にさせてもらった 26 利用性については dbt-osmosisを使ったメタ データ管理で大部分でき ていた dbtを使っていれば自然 とリネージが可視化でき るため、大部分できてい た
27. 10X, Inc. ALL RIGHTS RESERVED 正確性の可視化の例 27 コード含めた詳細はこちらを 参照してください 「データセットA / B / Cは特にテストが 多いが、データセットCはvalidity(妥当 性)に関するテストが圧倒的に少ない」
28. 10X, Inc. ALL RIGHTS RESERVED 正確性の可視化を通じた各レイヤが担うべきテストの見直し 28 データレイク Staging Raw Vault Business Vault Data Mart Fact / Dim 正確性の観点でもデータユーザーから の問い合わせが一番多いのはData Mart。 とにかくData Martのテストを増やして 正確性を担保すればいい...? ビジネスロジックはBusiness Vaultに寄せていく。ロジックが絡む妥当性 (Validity)に関するテストもBusiness Vaultで行なおう。 一方で、Data MartはJOINに関するミスが起きやすいから、一意性 (Uniqueness)や完全性(Completeness)のテストを厚めにしよう! レイヤ毎に正確性の可視化を行なった結果、どのレイヤで何を担保す るためのテストを行なうべきか見直したりToBeの設定ができるように なった。可視化しているので、ギャップも分かる! Data Mart内にビジネスロジックが書か れているのがよくない! ビジネスロジックやそれに関するテスト も似たようなものが多数できてしまって SSoTにできてない...
29. 10X, Inc. ALL RIGHTS RESERVED データエンジニアがいると...! 29 • モグラ叩きのように「データ利用者から重複し た集計を指摘された。 dbtのuniqueテストを書 かなきゃ...」ではなく • 現状がどうなっているかを可視化した上で、レ イヤ毎の責務を明確にしどこに何のテストを書 くべきかのToBeを見通した上でデータ品質の 課題に取り組めるようになる !
30. 10X, Inc. ALL RIGHTS RESERVED アジェンダ • 背景: 10XとStailerについて • データエンジニア今昔 • 今なお存在するデータの困った課題 • 会社にデータエンジニアがいることでできるようになること ◦ 個別課題の撃破...ではなく全体を見通す: データマネジメントのアセスメントの実施 ◦ データ品質の可視化、そこからのデータ基盤運用改善 ◦ 入口のデータ品質の担保: Data Contract ◦ 出口の期待値調整: Data Reliability Levelの設定 • まとめ 30
31. 10X, Inc. ALL RIGHTS RESERVED 最近: データソース側の課題が目立つようになってきた 31 データパイプライン ダッシュボード / 各分析のユースケース データソース データ品質の改善が進んできた データパイプラインが改善された結果、データソー ス側に課題を感じることが増えてきた
32. 10X, Inc. ALL RIGHTS RESERVED 課題感: データソースのProducerとConsumerの仕様のやり取り 32 毎回違う人にデータの仕様聞か れて、開発がなかなか進められな い... このイベント、Google Analyticsに 先週から流れてこなくなってるよ?! プロダクトやサービスの運用もあ るし、考えるべきことは分析のこと だけじゃないよ... このカラム、INTだったのが STRINGに変わってバッチが落ち たよ! このカラム、どういうときにNULL が入ってくるか全然分からない。。 オペレーションの調査用に作った テーブル、いつの間にか分析に使 われてる... えっ、このカラム0の場合あるの?! データソースの 生成者側(Producer) データソースの 消費者側(Consumer)
33. 10X, Inc. ALL RIGHTS RESERVED Data Contractをインターフェイスにしたコミュニケーション • Slackでやり取りするのはお互いしんどい • 仕様についてのコミュニケーションを疎にしたい ◦ Producer: ▪ 生成するデータの仕様を書く ▪ 仕様に沿ったデータソースの生成に責任を持つ ◦ Consumer: ▪ まず仕様書を確認する ▪ 仕様を信じた上で、DWHやデータマートを作る ◦ ProducerとConsumerでコミュニケーションが発生するのは「仕様が明確でない」あるいは「データが仕様に 沿っていない」ときのみ ▪ マイクロサービスを運用しているチーム間がスキーマをベースに会話するのと同じ • ここでいう仕様のことを「Data Contract」と呼ぶ ◦ 欧州の決済系サービスGoCardlessのエンジニアのAndrew Jonesが提唱した概念 ◦ より詳細はDriving Data Quality with Data Contractsにまとまってます ◦ datatech-jpで読書会を行ないました 33
34. 10X, Inc. ALL RIGHTS RESERVED Data Contractの例: テーブル単位 • テーブルのdescription ◦ イベントデータなどであればイベントの生成ポイントがいつか、なども • 可用性 ◦ XX時までに前日分のデータがBigQueryに同期される • どのチームがオーナーか ◦ 開発チームはドメインチームで分割されているため • 主キーはどれか • テーブルがdeprecatedかどうか ◦ 削除や更新の停止がいきなり起きないで欲しい 34
35. 10X, Inc. ALL RIGHTS RESERVED Data Contractの例: カラム単位 • カラムのdescription • Nullableか ◦ NULLが入る場合も、「いつ以降はNULLが入らないように設計している」や「NULLが入り得るのはこういう ケース」という情報も欲しい。リバースエンジニアリングで条件を同定するのは大変だし、担保できない • 重複がないか • Enumの場合、どういう値を取り得るのか。また、それぞれに対応する番号のdescription ◦ 例: dbtのaccepted_valuesテストの生成に使える ◦ 例: payment_type = 1 => クレジットカードによる決済 • 外部キーの場合、参照先のテーブルのカラム名 ◦ 例: ER図の自動生成に使える ◦ 例: dbtのrelationshipsテストの生成に使える • 値の範囲の制約 ◦ 例: 価格の値で0を含むのか、含む場合はどういうケースか • PIIな情報を含むかどうか ◦ データ基盤に取り込まなくする、あるいは列レベルセキュリティで守るなどの検討基準として欲しい ◦ 開発側とデータ基盤側のセキュリティの基準を揃える意味でも有用 • Deprecatedなカラムかどうか 35
36. 10X, Inc. ALL RIGHTS RESERVED 導入時の考慮ポイント: いきなり全部やらない • 先ほど説明したData Contractの内容はかなり盛りだくさんになっている ◦ 全部の内容を記載する場合、Consumer側には理想的ではあるが、Producer側には高負担 • 導入時は重要かつ負担が少ない箇所から始める ◦ 10Xの場合、型 / description / Nullableかどうか、からスタート ◦ (拡張性は持たせておく) • なぜData Contractを導入したいか、Producer側である開発チームに協力を求める ◦ どういった課題がデータ活用の現場で起きているのか、どういう世界を目指したいのか、どういう始め方をし たいのか、機を見て何度も丁寧にコミュニケーション ◦ (後述する)Data Reliability Levelも同時期に進めているので、「Trusted」で使われているデータソースから優 先的にやりたい、など濃淡を付ける 36 結果的に、一部分でPoC的に スタートすることができた...!
37. 10X, Inc. ALL RIGHTS RESERVED 運用時の考慮ポイント: 自動化 • Contractをコードとは別にドキュメンテーションすると、スプレッドシートと同様に古びてしまう... • データを生成するコードにData Contractに関する情報を埋め込み、Data Contractの仕様書をCIで自動生成するのが オススメ ◦ 仕様書を成果物としてcommitに含めるでもよいし、スキーマレジストリに登録するなどでもよい ◦ 10Xの場合、GitHub Actionsで自動化して、Data Contractがyamlとして成果物に含まれる形 ◦ 仕様の変更があった場合、どのcommitから変わったのかも追従しやすい! • 現在はData Contract Specificationに沿った運用をしています ◦ 実際の運用の乗せられるようにdatacontract-cliへのコントリビューションもしています 37
38. 10X, Inc. ALL RIGHTS RESERVED Data Contractの進展(その1) 38 データパイプライン データソース 集計結果などをデータソースへ書き戻す(Data activation / Reverse ETL) 箇所でもData Contractを使ってDartのコード生成。データ基盤がProducer側になることもある! 今までは「データソース」から「データパイプライン」への Data Contractの話のみをしていた
39. 10X, Inc. ALL RIGHTS RESERVED Data Contractの進展(その2) 39 データパイプライン データパイプライン データパイプライン データパイプライン データプロダクト同士のやり取りのインターフェイスとして Data Contractが導入されてきている!
40. 10X, Inc. ALL RIGHTS RESERVED データエンジニアがいると...! 40 • 人間同士がSlackやスプレッドシートで仕 様をやり取りするのではなく Data Contractをインターフェイスにやり取りで きる! • Data Contractを前提にデータ基盤や データプロダクトを固くスムーズに構築で きる!
41. 10X, Inc. ALL RIGHTS RESERVED アジェンダ • 背景: 10XとStailerについて • データエンジニア今昔 • 今なお存在するデータの困った課題 • 会社にデータエンジニアがいることでできるようになること ◦ 個別課題の撃破...ではなく全体を見通す: データマネジメントのアセスメントの実施 ◦ データ品質の可視化、そこからのデータ基盤運用改善 ◦ 入口のデータ品質の担保: Data Contract ◦ 出口の期待値調整: Data Reliability Levelの設定 • まとめ 41
42. 10X, Inc. ALL RIGHTS RESERVED 最近: 活用側との期待値のギャップが目立つようになってきた 42 データパイプライン ダッシュボード / 各分析のユースケース データソース これまでに改善が進んできた 活用側との期待値のギャップが出てきた!
43. 10X, Inc. ALL RIGHTS RESERVED 課題感: 開発者と活用側の間の期待値のギャップ 43 大まかな傾向が分かればいいと 聞いていたのに、なんでそんなク リティカルなオペレーション用途で 使われているの...? バッチ落ちたら土日でも対応してく れますよね 色々要望あったから頑張ってメン テナンスしてたけど、全然使われ てないじゃん... なんでこのカラムにNULLが入る の? ちゃんと品質担保してよ こういう仕様で要望してたのに、い つの間にか仕様満たせてないじゃ ん! PoCで欲しいって言われたテーブ ル、いつまでメンテナンスし続けな いといけないの? 欲しいテーブルが全然見つけられ ない。重要なテーブルはちゃんと 見つけられるようにして! 開発者 活用側
44. 10X, Inc. ALL RIGHTS RESERVED Data Contractよりもう少し人間 / 分析に向いた枠組みが欲しい • Data Contractは割とかっちりとした枠組み。対システムを意識している ◦ 例: Data ContractからProtocol BuffersやdbtのsourceのYAMLファイル / テストを自動生成 ◦ 例: カラムにPIIのラベルが付与されていたら、カラムレベルセキュリティで自動的に権限を絞る • 分析向けでは、もう少し柔らかい枠組みが欲しいことが多い ◦ 例: 正確さは多少犠牲にして、スピード重視で分析がしたい ◦ 例: 不確実性が大きいため、半年後も運用し続ける必要があるか分からない ◦ 例: あまり精査されていないが、深掘り分析のためにスプレッドシートとJOINがしたい ◦ 例: 一週間くらいバッチがこけても実は何とかなる利用用途 • Data Contractの思想は反映しつつ、対人間の分析向けの枠組みが欲しい ◦ 「Data Reliability Level」として、自社独自に定義 44
45. 10X, Inc. ALL RIGHTS RESERVED Data Reliability Level: 分析向けのデータに対する期待値を定義する • 元々はGitLabのData Developmentを参考にしており、10Xに合った形で定義しなおした • Trusted / Business Insight / Adhocの3つのレベルを定義 ◦ それぞれのレベルに応じて、どういった観点や開発プロセスを満たしている必要があるかを明示する • Trusted: ◦ ビジネスの重要な意思決定に使われるデータ ◦ 代表例: 経営向けのダッシュボード、CRMなどで使われるテーブル • Business Insight: ◦ 定常的な観測用のダッシュボードなどに使われるデータ ◦ 代表例: ファネル分析のダッシュボード、ディメンショナルモデリングを提供しているテーブル • Adhoc: ◦ アドホックやPoCで利用するデータ ◦ 代表例: 特定店舗用の未精査の指標が使われている分析 45
46. 10X, Inc. ALL RIGHTS RESERVED Data Reliability Levelの代表的な観点 • Speficication ◦ ビジネスオーナーが記載されているか ◦ (adhocであれば)削除期限が記載されているか • Data Catalog ◦ テーブルやカラムのdescriptionは記載されているか • Test Development ◦ テストのカバレッジは十分か、項目毎に必須のテストが通っているか • SLO ◦ どの程度の可用性が要求されているか • Information Mart ◦ 適切なモデリングを経て、テーブルが生成されているか • Manual Data Usage(手動で作成されたデータが使われていないか) ◦ 精査されていないスプレッドシートなどを参照していると品質が担保できない • Direct Source Usage(データソースを直接参照していないか) ◦ 適切にモデリングされ、テストされたコンポーネントを参照しないと品質が担保できない 46
47. 10X, Inc. ALL RIGHTS RESERVED Data Reliability Levelの現在地 47 Data Reliability Levelに関連する各項目をAsIsをdbt のyamlファイルに記載。 dbtの成果物(manifest.json)を利用しスクリプトで記 入したり、気合で全ファイル記入。 必要な項目を人間がチェックするのは大変なので、CI 上でJSON Schemaを回して治安を守る。 記入したAsIsと実際のToBeにどれくらい距離があるかLooker Studioで可視化(elementaryを利用)。 重点的に強化したほうがいい項目を洗い出したり、レベルを下げ れるテーブルがないか、などを検討しやすくなった。
48. 10X, Inc. ALL RIGHTS RESERVED Data Reliability Levelの進め方 • 特にTrustedと定義したデータについて、満たすべき品質まで高める ◦ 逆に言うと、Data Reliability Levelを定めることで、基準が低くてよいものは頑張り過ぎる必要がない、という ことを定義できているとも言える ◦ 手間をかけるところに濃淡を付ける • 「何でもかんでも品質を高める」ではなく、品質をコントロール配下に置き、制御できるようにすることが重要 ◦ SREのSLOと思想は同じ ◦ 制御できるように、チーム内で以下のような動きを取った ▪ 当初、Business Insightに該当するテーブルが148個(多い...!)あった ▪ 「今のチーム状況で、これだけのBusiness Insightレベルのテーブルを運用できますか?」を自問自答 ▪ 約半数をadhocに運用レベルを落とす、あるいは捨てるという動きを取れた • 新規にテーブルやダッシュボードを作る際は、活用側とData Reliability Levelを定めた上でデータの提供する • すでに提供しているテーブルやダッシュボードについては、活用側とData Reliability Level認識を合わせた上でデータ を提供する形に持っていく 48
49. 10X, Inc. ALL RIGHTS RESERVED データエンジニアがいると...! 49 • データ活用者との期待値のギャップを最 小限にしながら開発 / 運用できる! • 本来時間をかけるべき価値を出す / 出し ている成果物に時間を投下できる !
50. 10X, Inc. ALL RIGHTS RESERVED まとめ • チーム内 / 局所的 / 小さいタスクはSasS / マネージドサービス / LLM Agentでできるようになってきた ◦ 実装や運用の効率化のために使い倒せばよい ◦ データエンジニア以外でもやりやすくなってきているし、できるようにケイパビリティを高めていくのもデー タエンジニアの仕事 • 俯瞰した視点で何をやるべきか / チーム間でのデータに関するコミュニケーションやプロトコルの設計はデータエン ジニアが今後も責任を担っていく仕事の一つ ◦ コミュニケーション: with 人間 / プログラム / LLM Agentなどなど ◦ プロトコル: Data Contract / データユーザーとのインターフェイスになるSemantic Layerやディメンショナル モデリング • 価値を出せるようにより本質的なことをやれる時期になってきた、とも言える...! 50
51. 10X, Inc. ALL RIGHTS RESERVED 最後に • データエンジニア / アナリティクスエンジニアの仲間を増やしたい! • コミュニティ: datatech-jpに来てね! ◦ アジャイルデータモデリングの輪読会やってます! • イエント: 夏から秋に色々あるので来てね! ◦ Tokyo dbt Meetup#16: dbt開発 with Claude Codeのためのガードレール設計 ◦ Data Engineering Study #31: データエンジニアがこの先生きのこるには...? ◦ アーキテクチャConference2025: 現場課題から考えるセマンティックレイヤーとデータモデリング • 10Xでもデータエンジニアを募集してます! ◦ カジュアル面談からお待ちしてます 51