©2023 10X, Inc. データの受託開発からの卒業 2024/08/20 大規模データの負債解消への道のり Lunch LT #data_findy 上野 弘敬 | 株式会社10X

©2023 10X, Inc. ● X,Twitterは @hiro_30_1000 ● 株式会社10X データ基盤チーム DataAnalyst ＆ AnalyticsEngineer ○ データを活用した事業推進に伴奏 ○ データ基盤の構築・運用や全社横断のデータ活用の促進 ● これまでの職歴は ○ ○ ○ ● マラソンが趣味です。毎朝15km走ってます🏃 2016 - 2020：キリン(株), スタートアップ 2021 - 現在：スタートアップ, Retty(株), 現職 2024 - 現在：現職 上野 弘敬 | Hiroyuki Ueno 自己紹介 - 法人営業, BizDev - DataAnalyst - AnalyticsEngineer

©2023 10X, Inc. お客様アプリ ● 数万SKUから商品からスムーズにカゴを作成できるUX ● キーワード・カテゴリ検索・お気に入り・注文変更・ 購入履歴といった基本機能 ● 商品の受け取り方法を選択 ● 注文状況・配達状況の確認や通知 ● Web(オプションにて提供) 数万点のSKUから スムーズにお買い物ができるUXを提供 主な機能 3 提供プロダクト

©2023 10X, Inc. スタッフアプリ ● ピッキングリストを自動生成 ● 移動距離最短化、複数スタッフに並行作業可能 ● バーコード照合でのヒューマンエラー防止をサポート ● 多様な受け取り方法に対応 ミスが少なく効率的な 業務オペレーションシステムを提供 主な機能 4 提供プロダクト

©2023 10X, Inc. 5 アジェンダ こんな方々に役立つ内容を意識しています テーマ 01 02 03 04 05 状況：データ負債がどうやって生まれてきたか 課題：データ負債が生まれた結果、どういう悪影響が出てきたか 解決：既存のデータ負債を、どう解消していったか 工夫：新規にデータ負債を生み出さないように、どういう工夫をしているか 振り返り データの可視化や活用が進んでいる一方で、基盤整備が追いつかず、今後の改善を模索している方 データや指標の管理が一貫しておらず、整合性のある分析環境の構築に悩んでいる方 組織全体にデータ活用の意識を広め、共通の理解を形成したいと考えている方

©2023 10X, Inc. 6 データ負債が どうやって生まれてきたか

©2023 10X, Inc. データ活用範囲 前提 社内(Biz, Marketing, Product) パートナー(小売事業者) ● 利用範囲：社内 ＆ パートナー(=社外) ● 用途：事業分析, 商圏エリア, マーケティング, 売り場, オペレーションなど ● 基盤：BigQuery, dbt, Tableau 社内だけでなくパートナーも利用, 用途が広い

©2023 10X, Inc. データ負債の発生原因 状況 上記の要素が複合的に作用し、短期的なニーズに対応するために、 適切なガバナンスや標準化プロセスを省略した結果として蓄積された課題 ≒ データ負債 が生まれた BizDev,Ops, Marketer パートナー データアナリスト 基盤チーム パートナーによってデータの用途が異なる 未成熟 データ基盤の状況: ● DWHやデータマートの整備が進んでおらず、データ基盤に 関係のないメンバーでもデータソースにアクセスできる状態 ● 事業部や機能ごとに、redashやmetabaseやスプシで自由に カスタムクエリやダッシュボードを作ることを許容していた 短期的 ニーズに 即時対応 組織構造: ● 事業部にアナリストが紐づいていた組織構造上、パートナー や社内のデータ利用者の直接的な要望に迅速に応える形に ● ドメインの認知負荷が高く、事業部ごとにデータを作成し、 締め切り優先で依頼通りに対応せざるをえなかった 当時の組織

©2023 10X, Inc. 負債が生まれるループ 状況 依頼を もらう あるべき姿が ない あるべき姿を 考えられない 標準を定義で きない 一旦なんでも 作る 受託開発ループ 要望の即時対応が目的化していた

©2023 10X, Inc. 10 データ負債が生まれた結果、 どういう悪影響が出てきたか

©2023 10X, Inc. データ負債が生まれた結果、どういう悪影響が出てきたか 課題 データの 不整合 統一された基準の欠如: ● 組織全体で統一された基準が存在しないため、品質にばらつきが生じる 指標の不一致: ● 同じ指標に基づくデータマートとダッシュボード間でのデータ不一致が発生。これにより、データの信頼性が社 内外で低下し、統一されたデータの可視化や分析が困難になり意思決定が進まなくなる 運用の課題 コストの 課題 ● 「即対応」が優先され、メンテナンスすべき優先度が不明確 ● レビュープロセスや提供品質の基準が不明確 ● これら古いモデル, パイプラインを2名体制で管理 ● BigQueryのコストが嵩んでいるが、整理がされてないがゆえにコストも減らせない ● カスタムクエリを読み解くことが難しく、メンテナンスコストが高い

©2023 10X, Inc. 12 既存のデータ負債を どう解消していったか

©2023 10X, Inc. 同じ指標間で数字が合わない / 統一された可視化や分析が困難 / 開発優先度が不明確 上記をアナリスト,基盤チームを中心に 中央集権的 に取り組んでいく体制に変更 既存のデータ負債をどう解消していったか 解決 イシュー データの標準化 01 要望や依頼があれば個別で即対応 / 古いモデル, パイプラインを 2名体制で管理 / コスト高(BigQueryコスト) 認知負荷の軽減 02 コスト高(メンテナンスコスト) 運用効率の向上 03 解決の取り組み ・標準の規定 ・仕様書の導入 01 ・ライフサイクルの徹底 ・ロードマップ作成と合意形成 ・リネージのToBeを規定 02 03

©2023 10X, Inc. 体制の構築 解決 全パートナー標準のデータマート, BIツールの設計・開発, 活用の推進する機構を構築 BizDev,Ops, Marketer パートナー データアナリスト 基盤チーム

©2023 10X, Inc. ● 定義した優先度, メトリクスをもとに、全社統一の横断的な 標準データマート, ダッシュボードを設計, 展開 ● BIロードマップとして公開することで、事業部のコミュニケー ションを促進し、各ステークホルダー間でデータのデリバリー スピードやスケジュールの期待値を合わせる武器とする ● ヒアリングしつつ、定義を統一化することで小売事業者間の 要件, 仕様差異が原因で個別化しない ● 機能の峻別と方向性の明示: ○ 事業成長に伴走していると、イシューは山ほど出てく る。事業を飛躍的に成長させるためには、最も重要な 課題解決に伴うデータ,インサイト提供に集中させる ことが不可欠。一方、事業成長への関与が薄いもので あっても、小売事業者にとってはクリティカルな イシューはある。この部分は各事業部でガバナンスが 効いた基盤による個別対応・ 依頼ベースで対応し、 線引きを容易にする 標準を規定する 解決 プラットフォームとして提供する標準を定める BIロードマップ 標準的なマートとダッシュボードを規定 Point

©2023 10X, Inc. ● 依頼者との期待値調整: 完成前の段階で依頼者との期待値を 調整し、仕様書をベースに機能適合性を確保 ● 仕様書のレビュー徹底: 仕様の見落としや意図のズレを、 アナリストとアナリティクスエンジニア間のレビューで確認 し、機能適合性と共通理解を事前に確保 ● 目的と構造の明確化: マートの目的や構造、各カラムの定義 と型を明文化し、作成者と利用者間での共通理解を促進 ● 品質と標準の強化: カラムごとに期待品質基準を設ける マートの仕様書を書く 解決 データ整合性の確保 効率的な運用とコスト管理 機能適合性の整合 ● 設計者と実装者の橋渡し: マートの設計から実装、メンテナ ンスに至るまでのガイドとして機能し、一貫性を保たせる ● 追跡の容易化: マートの変更履歴を仕様書に記録する 仕様書

©2023 10X, Inc. ● dbtのモデルとTableau、Connected Sheetsの依存関係をdbt exposureで表現、どのモデルが実際に使用されているかを把握 対象を減らす 解決 結果、BigQueryのコストを10%削減 ● モデルやデータパイプラインの数が多いと、リファクタリング が困難、まずは利用されていないモデルを減らす 利用されていないモデルを減らす dbt exposureの活用 BigQueryのスロット量のモニタリング

©2023 10X, Inc. ● 作るより捨てる方が、緊急性がない故に組織から目が向けられ なく、カロリーが必要。「使わないものは定期的に廃棄する」 をチームの習慣に ● パートナーや事業部と連携し、モデル削除の合意形成ととも に、新しいマートやダッシュボードを提供 対象を減らすポイント 解決 ● 古いデータパイプラインを撤退, 新しいモデルでも一定期間 使われていなければ削除 ● 撤退基準を言語化し、schemaに記述 ライフサイクル管理の徹底 事業部を巻き込む 何かを作るより、捨てる方が尊い 重要なモデルに運用を割くことが結果、全体の品質を上げる 使われていないモデル, ダッシュボードの削除を事業部に確認

©2023 10X, Inc. リネージのToBeを規定 解決 ● martからmartをつくらない ● martはdim/factからつくらない ○ dim/factでmartを作るのは一般的だが、同一レイヤー 参照はリネージを複雑にする。アドホック分析要望に 応えたいが、martへ予期せぬ影響を与えてしまうため ToBe例 ● dim/factをmartから引き剥がし 規定に反しているモデルをリファクタリング

©2023 10X, Inc. 20 新規にデータ負債を生み出さない ために、どう工夫をしているか

©2023 10X, Inc. 工夫 information mart mart dim/fact adhoc分析 BIで利用 reporting layer mart layer 生データを使わず分析可能に データ活用者が生データを直接参照せず分析できるようにする ● fact/dimはデータユーザーのための「アドホックな分析をする ための基本的なパーツを提供する場所」として提供 dim/fact層の構築 Point ● 作る・周知だけでは使われない、根気強い布教がセット: 利用者は慣れた環境を手放さない。目的、メリット、代表的な クエリ例等を用いた勉強会等を通して促進、FB得ることをを最 初のゴールとして、UXを洗練させる

©2023 10X, Inc. ● リファクタリングしやすい基盤 ≒ 最強: 過去の設計に リスペクトを持ちながら、未来のチームがリファクタリングを しやすい基盤を作ることが重要。未来のための投資と考える と、将来の負債を最小化する意識が大切 ● 手動ではなく自動: チーム開発では、人手による確認が限界 を迎える。手動レビューを減らし、CI等自動に寄せていくこと が継続的な改善に保守・運用につながる ● データマート等を作成していると「intermidiate層が intermidiate層を参照する」といった複雑なリネージが発生 ● リファクタリングが難しく、レビューでの都度指摘が負担 ● dbt-project-evaluatorで依存関係をチェック ○ 同一レイヤーでの参照が深すぎる場合(ex. 5回以上)、CI で落ちる仕組みを導入 工夫 レイヤードアーキテクチャ CIによる制約管理 同一レイヤーの参照回数に制約を設ける dbt-project-evaluatorの活用 Point https://www.yasuhisay.info/entry/2024/07/03/102056

©2023 10X, Inc. 23 振り返りと学び

©2023 10X, Inc. アナリストだけ、アナリティクスエンジニアだけの仕事はない アナリストとして、当時なぜこの課題に向き合ったのか 振り返り なぜ向き合った？ 組織構造の隙間: 前職の経験から、データ活用が組織にもたらす良い影響を理解 していた データ活用の効果 なぜ向き合った？ データ負債を認識しつつも、アナリストへの期待は担当小売事業 者の(短期的な)事業インパクトの創出 >> 長い目でのデータマネ ジメント(ex. 設計, 保守, 運用, ガバナンス)が大きかった 短期 vs. 長期の優先度 立場によって思考やスキルが異なるため、分析者視点で負債に 向き合い、メンタルモデルを変えるのは難しかった 思考の切り替え とはいえ困った アナリストができる最初のアプローチ ドメイン知識の活用: アナリストだからこそ、必要なデータと不要なデータを見極めがしやすい。まずはドメイン知識を活かし、 プラットフォームとして必要, 不要なデータを提案、 設計できると貢献しやすい 01 02 03 最終的に、データ基盤チームに異動し、アナリティクスエンジニアの業務を兼任するようになった

©2023 10X, Inc. プラットフォーム目線だけだと、現場にズレた実装をしがち。自分が一番のユーザーになり、両者の視点を 行き来しながら、データ基盤の整備と現場のニーズに対応することで、組織全体のデータ活用を進めやすい 課題に向き合い、両視点を経験して学んだこと 振り返り プラットフォームと現場・ドメインの行き来が不可欠 自分が「やるべき = 課題」と思ったことは、職種問わず他のメンバーも課題と感じていることが多い。 最初は少なくても周りを巻き込み、組織のイシューとして確立することで持続的に改善に取り組める なぜ向き合った？ 役割の確立とアラインメント アナリスト, アナリティクスエンジニアを経験して学んだこと

©2023 10X, Inc. 期待値を合わせる武器だけでなく、 機能の峻別と方向性の明示ができる まとめ 振り返り 標準の規定: 何かを作るより 捨てる方が尊い: 仕様書の効用: 新しい環境は作る・周知だけでは使われない、 根気強い布教にこそパワーを使う 今の設計は負債化することを前提に、未来のチームがリファクタリングしやすい基盤を作る データユーザーと機能適合性と 共通理解を事前に確保しやすくなる 「使わないものは定期的に廃棄する」を チームの習慣にする 05 04 03 01 02 大事だった5つのポイント

©2023 10X, Inc. 27 ご清聴ありがとうございました