レガシー化したデータパイプラインの撤退

2025/04/16 | datatech-jp Casual Talks #7 | #datatech-jp

Transcript

1. ©2023 10X, Inc. レガシー化したデータパイプラインの撤退 2025/04/16 datatech-jp Casual Talks #7 #datatech-jp 上野 弘敬 | 株式会社10X
2. ©2023 10X, Inc. • X,Twitterは @hiro_30_1000 • 株式会社10X データ基盤チーム DataAnalyst ＆ AnalyticsEngineer ◦ データを活用した事業推進に伴奏 ◦ データ基盤の構築・運用や全社横断のデータ活用の促進 • これまでの職歴は ◦ 2016 - 2020：キリン(株), スタートアップ - 法人営業, BizDev ◦ 2021 - 現在：Retty(株), 現職 - DataAnalyst ◦ 2024 - 現在：現職 - AnalyticsEngineer • マラソンが趣味です。毎朝15km走ってます🏃 上野 弘敬 | Hiroyuki Ueno　　 自己紹介
3. ©2023 10X, Inc. 提供プロダクト お客様アプリ • 数万SKUから商品からスムーズにカゴを作成できるUX • キーワード・カテゴリ検索・お気に入り・注文変更・ 購入履歴といった基本機能 • 商品の受け取り方法を選択 • 注文状況・配達状況の確認や通知 • Web(オプションにて提供) 数万点のSKUから スムーズにお買い物ができるUXを提供 主な機能 3
4. ©2023 10X, Inc. 提供プロダクト スタッフアプリ • ピッキングリストを自動生成 • 移動距離最短化、複数スタッフに並行作業可能 • バーコード照合でのヒューマンエラー防止をサポート • 多様な受け取り方法に対応 ミスが少なく効率的な 業務オペレーションシステムを提供 主な機能 4
5. ©2023 10X, Inc. 5 アジェンダ Goals • レガシーパイプラインをどうやって撤退・合意形成したか • ステークホルダーとの対話の進め方 No Goals • モデリングや構成の詳細 (気になる方はチームメンバーの発表で) ◦ #データ品質を守り続けるための データ基盤の考え方 ◦ #10Xでのデータ基盤の変遷とこれから Agenda 1. データパイプラインの変遷 2. レガシーパイプライン撤退と新パイプラインへの移行 3. 直面した課題と対応策 4. 振り返り 5. Key Sentence
6. ©2023 10X, Inc. 6 データパイプラインの変遷
7. ©2023 10X, Inc. データパイプラインの年表 データパイプラインの変遷 Period One Word Key Words Tools StakeHolder / Team 〜2022/3 Digdag時代 ・DWH初期構築（非dbt） Digdag, BigQuery 少人数 （構築担当のみ） 2022/4〜 2022/9 v0.1 立ち上げ・ dbt 開発着手・活用拡大 ・DataMartの展開が進むが、属人化 ・ブラックボックス化 dbt(v0.1), BigQuery アナリスト含め活発に開 発 2022/10〜 2023/6 v0.2の着手 ・v0.1の限界からv0.2のモデリングに 着手 dbt(v0.2), BigQuery モデリング・再設計 2023/7〜 2023/12 v0.1の撤退 ・使用頻度・構造をもとに順次撤退 ・Data Reliability Level 運用開始 dbt(v0.2) データ基盤チーム主導 2024/1〜 v0.1/adhocの整理と 価値提供拡大 ・使われていないモデルの撤退 ・再利用設計強化 dbt(v0.2), dbt(adhoc一部 整理) 全社横断で活用・ メンバー増加
8. ©2023 10X, Inc. データパイプラインの年表 データパイプラインの変遷 本スライド・の中心 *このスライドでは、「v0.1 = レガシーパイプライン」と位置づけています Period One Word Key Words Tools StakeHolder / Team 〜2022/3 Digdag時代 ・DWH初期構築（非dbt） Digdag, BigQuery 少人数 （構築担当のみ） 2022/4〜 2022/9 v0.1 立ち上げ・ dbt 開発着手・活用拡大 ・DataMartの展開が進むが、属人化 ・ブラックボックス化 dbt(v0.1), BigQuery アナリスト含め活発に開 発 2022/10〜 2023/6 v0.2の着手 ・v0.1の限界からv0.2のモデリングに 着手 dbt(v0.2), BigQuery モデリング・再設計 2023/7〜 2023/12 v0.1の撤退 ・使用頻度・構造をもとに順次撤退 ・Data Reliability Level 運用開始 dbt(v0.2) データ基盤チーム主導 2024/1〜 v0.1/adhocの整理と 価値提供拡大 ・使われていないモデルの撤退 ・再利用設計強化 dbt(v0.2), dbt(adhoc一部 整理) 全社横断で活用・ メンバー増加
9. ©2023 10X, Inc. v0.1の位置づけ データパイプラインの変遷 項目 データパイプライン（v0.1） データパイプライン（v0.2） 目的・思想 探索的な分析やスピード重視で 柔軟 モデリング思想に基づいた設計 運用体制 分析者自身がモデル作成・運用 データ基盤チームが設計・運用を主導 実装ニーズ・手段 スプレッドシートやBIツールの カスタムクエリが主なニーズ dbtベースで統一的に管理、品質向上 モデリング 個別最適・属人的構造 DataVault / Dimensional Modeling 指標の扱い モデルごとに定義がバラバラ 用途ごとのDatamartで再定義・整理 データの整合性 SSoTの概念なし SSoT導入により、整合性と信頼性を担保 データ提供のスコープ 主に社内利用を想定 外部提供(小売事業者)も考慮 v0.1は、分析ニーズの立ち上がりを柔軟に支え、 探索とスピード重視を推進した初期基盤として機能
10. ©2023 10X, Inc. 探索的データ分析ニーズの高まり PdM・BizDev・アナリストがそれぞれにSQLを書き、スピード優先の柔軟な対応が求められた。 ビジネスの急速な成長に伴い、データ分析の需要が急増 現場駆動の実装進行 SQLに長けたメンバーが多く、ビジネスプロセスをモデリングする前に、 とりあえず必要な指標をスプレッドシートから移植する形で、dbt上に多数のモデルが作成されていた。 v0.1がどうやって生まれたか データパイプラインの変遷
11. • dbtにモデルがあるが、設計が 一貫しておらず、横展開が難しい • クエリが放置され、定義や目的、 ライフサイクルが不明な状態に 保守性の欠如 • カスタムクエリが複雑化し、 構造把握が困難に • 誰がどの定義を使っているか分 かりづらく、影響範囲の 特定にコストがかかる 再利用性・展開性の欠如 コスト削減の困難さ • 同様のクエリや中間モデルが乱立し、 BigQueryのコストが嵩みやすい • モデルの整理・統合が進んでいない ため、無駄なスロット・重複の温床に SSoTの不在 • 各mart・各ダッシュボードごとにロジックがバラバラ • 「どれが正なのか」都度説明・検証が必要 設計思想の欠如による波及 • fact_orders や dim_users のような命名ながら、 ディメンショナルモデリングの思想を踏襲していない 実質大福帳なテーブルが多数誕生 • そのまま社外提供martやBIツールにも参照された結果、 データの整合性リスクに継続的に悩まされた v0.1に内在していた構造的課題 データパイプラインの変遷
12. v0.2の完成度 SSoTの明確化、ロジックの統一、再利用性の確保 v0.1の継続利用リスク 技術的負債として固定化される恐れ ビジネスプロセスの理解と再定義 アナリスト・BizDevからのヒアリングを通じて、分析観点で混乱の多かった領域（例：売上定義・注文処理など） も明確化 Why now: なぜv0.1の撲滅に踏み切ったか データパイプラインの変遷 v0.2が業務をカバーできる状態となり、ヒアリングを通じ、 ビジネスプロセス視点でも筋の通った構造化が進んだことが、移行判断の後押しとなった
13. ©2023 10X, Inc. 13 レガシーパイプライン撤退と 新パイプラインへの移行
14. 移行するための軸 • 参照有無, 回数 • スロット数 • v0.2のパーツ有無 • 個別性(ex. 小売事業者に提供している) 軸 Step 1. モデルの利用状況を可視化 2. モデルのレベル分け 3. 削除・移行のためのヒアリング・提案 レガシーパイプライン撤退と新パイプライン移行
15. Step1：モデルの利用状況を可視化 利用状況の可視化 exposureを活用した可視化 利用者の特定 誰が・何回・いつ参照したか 優先順位付け 利用頻度に基づく分類 一歩目として、exposureを活用してv0.1モデルがデータマート・BIツール （ex.Tableauやスプレッドシート）から誰に・何回・いつ参照されたかを把握 参照なし、または頻度が少ないものは、削除対象へ レガシーパイプライン撤退と新パイプライン移行
16. 60 削除対象 • 実際には参照されておらず、 古いダッシュボードとの接続だ けが残っているモデル • ステークホルダーに事前説明を 行った上で削除を実施 30 v0.2移行対象 • v0.2の構成要素が揃っており、 業務委託の方を中心に移行 移行できる状態のモデル 10 v0.2移行待ち • v0.2側での構成要素が未整備な モデルで、即時移行が難しいもの 削除対象が全体の6割を占め、移行が技術的に難しいケースは一部のみ 残りのモデルに注力し、後述の合意形成に向けた対話へ Step2：モデルのレベル分け レガシーパイプライン撤退と新パイプライン移行 % % %
17. Step3：削除・移行のためのヒアリング・提案 ヒアリングの実施 ステークホルダーや社外の小売事業者と直接ヒアリングを実施し、利用の有無・具体的な用途を確認 代替案・再定義の提示 v0.2をベースとした代替案や再定義を提示し、合意のうえで削除または移行を進行 インセンティブの説明 v0.2に移行することのメリットやインセンティブも丁寧に説明 「移行強制」ではなく「納得のある移行」を実現 v0.2への移行メリットとして「メンテナンス性の高さ」、 「Data Reliability Levelの運用」、「ビジネス状況の変化への柔軟な対応」などを説明 レガシーパイプライン撤退と新パイプライン移行
18. ©2023 10X, Inc. 18 そんな簡単にはいかない
19. ©2023 10X, Inc. 19 直面した課題と対応策
20. 実際の声： • “KPIダッシュボードの取引高に「キャンセル分・配送料・クーポン手数料」が含まれておらず困った“ • “消費税が含まれてるか不明で困った“ • “「定義が変わると小売事業者にレポーティングしづらく、過去と比較できない」“ 課題： • v0.1からv0.2へのパイプライン移行により、過去の数値と一致しないケースが発生。 • 定義の違いの不信や混乱の原因となっていた。 直面した2つの課題と対応策 数値のズレに対するビジネス本部側の不安 直面した課題と対応策
21. 直面した2つの課題と対応策 数値のズレに対するビジネス本部側の不安 直面した課題と対応策 解決方針 • 「正確な再現」よりも 「現在の目的に合ったあるべき定義」 が重要であることを、丁寧に説明 • “商品がユーザーに届いた注文のみ”を「注文完了」 と再定義し、取引高を集計 • 全社共通のダッシュボードではこの定義で統一 • 小売事業者ごとの要件は、ディメンショナルモデリングで個別に切り出し対応できるようにした
22. 直面した2つの課題と対応策 直面した課題と対応策 社外ステークホルダーとの調整負荷 課題： • 社外の小売事業者のに対して、定義の変更・削除・置き換えに関する説明や合意形成が必要 • 一方的に古いものを「完全に消す」方針では、現場・パートナーとの摩擦が大きくなる 実際の声： • “小売事業者Aの幹部(1人だけ)が見ているので、ダッシュボードを削除してほしくない ◦ 前提; このダッシュボードはv0.1で作られており、カスタマイズゴリゴリで撤退したいもので あった
23. 直面した2つの課題と対応策 直面した課題と対応策 社外ステークホルダーとの調整負荷 解決方針： • ビジネス本部と連携し、段階的な合意形成プロセスを設計 ◦ 「撲滅」ありきではなく、納得感のある移行を最優先に。 • Step1. 移行先の提示： ◦ v0.2で整備された横断ダッシュボード（小売事業者共通）を、新たな参照先として提案 ◦ 多くの旧ダッシュボードを包含しており、大半の業務要件をカバー可能。 • Step2. 代替共有を許容： ◦ 一部未対応の指標については、スプレッドシートでの一時的な代替共有を許容。 ◦ この際に共有のライフサイクル期限を明示（ex.：指標追加時点＋n週間） • Step3. 撤退： ◦ 期限到達後にスプレッドシートを廃止。
24. ©2023 10X, Inc. 24 振り返り
25. 振り返り：成果 • 動かないコードを放置せず、原則に従って整理を行ったことで 「動かないけど残っているコード」が発生しにくい環境に • アジリティを確保し、ビジネス要件への素早い対応が以前より可 能となった 不要なコードの排除による健全な開発環境の維持 認知負荷の軽減とオンボーディングの効率化 • テーブルや処理の構造が整理され、新しいメンバーがチームに 入った際に把握すべき範囲が明確になった • 属人的な理解に依存せずにチームが回る設計となり、 v0.2環境下では不要な負担なく立ち上がれるようになった メンテナンス・運用コストの削減 • 処理の軽量化やジョブ実行時間の短縮により、 障害調査スコープの限定やCI環境の負荷軽減に寄与 • 必要な情報・定義にアクセスしやすい設計へと整理された ことで、保守運用のボトルネックが減少 Google Cloudコストの最適化 • Google Cloudのコストを約15%削減 • 不要なストレージやSlotを削減し、運用・コスト効率の両面を改善 • 中身が異なる同名・類似名テーブルの撤退により、データの 信頼性・コードの可読性も向上できた 振り返り
26. ©2023 10X, Inc. 26 Key Sentence
27. • ロジック変更によって数値や定義にズレは起こるもの。 • 大事なのは、説明を放棄しないこと。 • 元々の定義が必ずしも正しいとは限らず、現状の指標に 引っ張られるのではなく、必要があれば “今見るべき定義” を再定義・提示することがビジネス的にも価値を持つ • そのうえで、妥当性の高い定義を提示しながら、メンテナン ス性の低いものは削除していくスタンスが重要 説明を放棄しない 迷ったら削除 > 代替 • 必要になったらすぐに作り直せるモデリングを保つ ことが重要 • 「残しておくことで守ったつもりになる」よりも、 「削除して必要ならすぐ作る」設計のほうが、持続 可能で柔軟性の高い状態を保てる Key Setentence Key Setentence