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

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 開発着手・活用拡大 ・データマートの展開が進むが、属人化 ・ブラックボックス化 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. データパイプラインの年表 データパイプラインの変遷 Period One Word Key Words Tools StakeHolder / Team ~2022/3 Digdag時代 ・DWH初期構築（非dbt） Digdag, BigQuery 少人数（構築担当のみ） 2022/4~2022/9 v0.1 立ち上げ・ dbt 開発着手・活用拡大 ・データマートの展開が進むが、属人化 ・ブラックボックス化 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一部整理) 全社横断で活用・ メンバー増加 本スライド・の中心 *このスライドでは、「v0.1 = レガシーパイプライン」と位置づけています
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