10倍スケールを見越したデータモデリングのリアーキテクチャ

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

3 © 2025 Leverages Co., Ltd. 森下研人レバレジーズ株式会社テクノロジー戦略室データエンジニアリンググループ MGR ● 日系SIerでDBエンジニアを経験後、 2019年11月にレバレジーズへジョイン ● データエンジニア6年目 ● データ基盤構築 / データマネジメント / データガバナンス / チーム作り / 採用などなど幅広くやってます ● 3歳で5kgの猫と同居してます自己紹介 3 機密情報・転載禁止 © 2023 Leverages Co., Ltd.

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

6 機密情報・転載禁止 © 2025 Leverages Co., Ltd. 会社概要検討中オフィス⽴地や社員数等最低限の情報（最新の数値に更新する）デザイン調整する社名従業員数代表者資本⾦所在地‧拠点グループ会社レバレジーズ株式会社 Leverages Co.,Ltd. 2,838名（2024年4⽉現在）岩槻知秀 5,000万円本社：東京都渋⾕区渋⾕2丁⽬24番12号渋⾕スクランブルスクエア24F‧25F 国内拠点：27拠点海外拠点：3拠点レバテック株式会社レバレジーズM&Aアドバイザリー株式会社 ATLIKE株式会社レバレジーズメディカルケア株式会社レバレジーズオフィスサポート株式会社レバレジーズプランニングサポート株式会社レバレジーズスタッフィング株式会社員点動⼒（上海）⼈⼒資源有限公司 Leverages Career Mexico S.A. de C.V. Leverages Career Vietnam Co., Ltd. Leverages U.S.Inc. 会社について

Slide 7

Slide 7 text

7 機密情報・転載禁止 © 2025 Leverages Co., Ltd. 10年後に⼀兆円規模を⽬指す企業の安定性と成⻑性を担保する独⾃の経営戦略のもと、創業以来、黒字経営を継続し、 2023年度は1,149億円を達成しました。企業理念として「顧客の創造を通じて、関係者全員の幸福を追求し、各個⼈の成⻑を促す」を掲げ、⼈の感情と向き合いながら次の時代を創るグローバル企業を⽬指しています。ベンチャーを牽引する成⻑で、次代を創る企業へ売上推移会社について

Slide 8

Slide 8 text

8 機密情報・転載禁止 © 2025 Leverages Co., Ltd. ポートフォリオ経営とは、業界やビジネスモデルなどにこだわらず、分散投資をしていく経営形態のこと。この経営形態のメリットは、予測困難な外部変化に会社全体で衝撃を吸収しやすい点にあります。例えば、コロナ禍では海外事業などは打撃を受けた⼀⽅で、IT事業や医療‧ヘルスケア事業は追い⾵を受け、過去最⾼の売上を更新、黒字経営を継続しました。経営のリスク分散を⾏うことで、未曾有の状況でも安定した成⻑を実現しています。ポートフォリオ経営による安定した収益基盤で創業以来、黒字経営を継続経営体制について会社について

Slide 9

Slide 9 text

9 機密情報・転載禁止 © 2025 Leverages Co., Ltd. 「⻑期的に市場の成⻑性が⾒込まれること」「社会や⼈の負を解決すること」を市場参⼊軸とし、現在は、IT、医療‧介護‧ヘルスケア、 M&A、SaaS、海外、若年層などの領域で、約50の事業を展開中。今後、より収益が安定し、⼤規模な投資が可能になれば、エネルギーや⾷料、宇宙産業など、世界の課題を解決するための事業を展開していきます。世界を視野に、国や業界にとらわれない事業展開事業数の推移事業展開事業について

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

12 © 2025 Leverages Co., Ltd. ● ELT：Fivetran ● DWH：BigQuery ● Transform：Dataform ● BI：Tableau, Looker Studio ● Metadata：Dataplex ● Quality Check：Dataplex ● Reverse ETL：trocco ● Orchestration：Airﬂow データ活用基盤 - 全体概要アーキテクチャ

Slide 13

Slide 13 text

13 © 2025 Leverages Co., Ltd. データ活用基盤 - 個別アーキテクチャ ● 全社で40近くのサービスを展開していることもありブランド単位でまとめつつデータ活用基盤を分割 ● データ活用基盤の数は10ほど ● BigQueryを中心としつつ、事業売上や関係者数、実装時期によって少しずつアーキテクチャが異なる ● 異なるビジネスモデルや売上規模でも設計が変わらないよう共通利用できる技術を選定

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

18 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - DWHの発展史 ● データ活用が進むにつれ、データソースが増えていった ● ひとまずDWHに繋ぐという実装が進んで行った ● データ活用を浸透させ、事業貢献するために、テーブルがもりもり増えて（増やして）いった SFA データソースデータレイクデータウェアハウスデータマートビジュアライズ広告データアクセスログ

Slide 19

Slide 19 text

19 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - DWHの発展史 ● 社内のデータ活用が拡大していくなかで、DWHやDMがどんどん作られていった ● 早く実装して早く事業貢献するために、各人の裁量に任せて実装が進んで行った ● テーブル間の依存関係が複雑化し、テーブル重複などが度々発生するようになった SFA データソースデータレイクデータウェアハウスデータマートビジュアライズ広告データ登録システムアクセスログ

Slide 20

Slide 20 text

20 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - DWHの発展史 ● Dataformのリネージ機能を使っても巨大すぎて全体像の表示で落ちるようになった ● テーブル数が多すぎて認知負荷の限界を超えた ● システムリプレイス時の影響調査が大変すぎた SFA データソースデータレイクデータウェアハウスデータマートビジュアライズ旧登録システム広告データ新登録システムアクセスログ

Slide 21

Slide 21 text

Slide 22

Slide 22 text

22 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - 蓄積されたつらみ ● DWHのつらみ ○ 当初の設計思想を超えてデータ基盤が肥大化した結果、チームメンバーの認知の限界を超えた ○ SFAのみを使用する想定が、10以上のデータソースを接続することになった ○ 明確な実装方針やルールがないまま、データ活用を浸透させるためにスピード重視で実装していった ○ 結果として似たようなテーブルが乱立し、Dataform管理のテーブルが400を超えた ○ テーブルも多く依存関係が複雑すぎるため、Dataformのテーブルリネージで全体像を描画できなかった ○ ドキュメントも不十分で、データ定義の意図や背景が読み取れなかった ○ データの除外タイミングが統一されておらず、似て非なるテーブルが大量にあった ● ビジュアライズ層のつらみ ○ 実装の明文化されたルールがなかったため、ダッシュボードごとに実装が異なっていた ■ BigQueryで計算させてから送る vs BIツールでデータ結合やデータ型変換を行う ■ DWHでリネームする vs BIツールでリネームする ○ 機能制限もなかったため、一定以上のスキルがないと保守運用できないダッシュボードが大量にあった ○ ダッシュボード改修の際、BIツールだけで完結するのかテーブル改修が必要か毎回調査が必要だった

Slide 23

Slide 23 text

Slide 24

Slide 24 text

24 © 2025 Leverages Co., Ltd. テーブル結合データの型変換フラグ付与複雑なデータ指標定義ビジュアライズ割合の計算カラムのリネーム ● 技術要素の確定 ○ 変えることも考えたが、リアーキテクチャとは別軸で考えることにし、既存を踏襲 ■ DWH：BigQuery ■ Transform：Dataform ■ BIツール：Tableau Cloud ● DWHとBIの責務を分離 ○ BIツールでは何を行うか？何を行わないか？をディスカッションして決定 ○ BIツールの入れ替えを容易にするため、できるだけBIツール側の責務を減らす方向でルールを決定 ■ Github管理を推進するため、Tableauの計算フィールドを極力減らしたい ■ BIツールに送るデータ量を削減し、画面描画の速くする ○ あくまでも配信用ダッシュボードのルールとして策定し、探索用には幅広く使える形にするデータモデリングのリアーキテクチャ - 最初に確定させたこと BIツールで行うこと BIツールで行わないこと

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

27 © 2025 Leverages Co., Ltd. ● ワイドテーブルにする！ ○ 新規事業も多く事業成長も速いため、ディメンション・ファクトの切り分け難易度が高い ○ 少人数で保守運用していくため、認知負荷の低い設計が必要 ○ データ利用時の誤ったキー結合を防ぎ、誤ったデータ抽出を事前に防ぐ ○ データ利用者にテーブル結合の手間を取らせない、問い合わせの工数を削減させる ■ テーブル名やカラム名の命名は徹底的にこだわり、誰でも理解できる名前にする ● ビジネスモデルに依存した設計は回避する！ ● BIツールでしかできないことにBIツールは集中する！ ● 利用人数やデータ量が10倍になっても耐えられる形にする！データモデリングのリアーキテクチャ - 考慮事項の大方針の決定

Slide 28

Slide 28 text

28 © 2025 Leverages Co., Ltd. ● ワイドテーブルにする！ ● ビジネスモデルに依存した設計は回避する！ ○ 技術要素とアーキテクチャを共通化させて柔軟な人的リソース配置を可能にする ○ どの事業でデータ活用基盤が必要になっても同じ設計で実装できるようにする ○ 事業ごとの属人化を可能な限り排除する ● BIツールでしかできないことにBIツールは集中する！ ● 利用人数やデータ量が10倍になっても耐えられる形にする！データモデリングのリアーキテクチャ - 考慮事項の大方針の決定

Slide 29

Slide 29 text

29 © 2025 Leverages Co., Ltd. ● ワイドテーブルにする！ ● ビジネスモデルに依存した設計は回避する！ ● BIツールでしかできないことにBIツールは集中する！ ○ 保守運用をしやすくする ○ BigQueryの計算リソースを最大限利用する ○ BIツールの入れ替えを見越してBIツールの責務を薄くする ○ ダッシュボード実装方法を統一して、ダッシュボードの品質を保つ ● 利用人数やデータ量が10倍になっても耐えられる形にする！データモデリングのリアーキテクチャ - 考慮事項の大方針の決定

Slide 30

Slide 30 text

30 © 2025 Leverages Co., Ltd. ● ワイドテーブルにする！ ● ビジネスモデルに依存した設計は回避する！ ● BIツールでしかできないことにBIツールは集中する！ ● 利用人数やデータ量が10倍になっても耐えられる形にする！ ○ 人数とデータ量が3年で2倍にスケールする環境に合わせる ○ データ職種の採用難易度が高いため、少人数で回せる設計にするデータモデリングのリアーキテクチャ - 考慮事項の大方針の決定

Slide 31

Slide 31 text

Slide 32

Slide 32 text

32 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - 具体的なアーキテクチャ ● ビジュアライズ層含めて4層から8層に分解 ● 各層の役割、責任範囲、対応しないこと、してはいけないこと、保守運用担当を明文化 ● データセットの命名規則を整理して決定 ○ 『データマネジメントが30分でわかる本』を参考に決定 ● テーブルリネージをシンプルにするため、手前の層のテーブルしか使用しないルールを策定

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

36 © 2025 Leverages Co., Ltd. 具体的なアーキテクチャ - シングルシステムデータウェアハウス層 ● 目的 ○ テーブル同士を結合し、データ活用の最大公約数となるテーブルを作成する ● やること ○ 同一システム内でのテーブル結合、ビジネスロジックの挿入、カラム名の統一（~~日 → xx_date など） ○ ワイドテーブルで実装 ● やらないこと ○ 他システムデータのテーブル結合を行うこと

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

41 © 2025 Leverages Co., Ltd. 具体的なアーキテクチャ - セマンティックレイヤーを2層にした理由 ● データ定義処理の共通化を目的として、セマンティックレイヤーを2層に分割 ○ ファクトは同じでディメンションだけ違う場合、似たような計算処理がダッシュボード毎に発生する ● 1層目で全ディメンションに対してファクトを集計、縦持ちで持たせることにした ● 2層目はダッシュボードに必要なデータだけをselectし、送り込むデータ量を最小限にする ● 全ディメンションの組み合わせが数億あったが、ファクト集計処理が5分以内に完了したので採用

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

44 © 2025 Leverages Co., Ltd. リアーキテクチャの効果 ● 事業のスケールに耐えられる自信がついた ● データ定義の問い合わせ数が減った ● ワイドテーブルを採用したため、テーブル数が減った ○ データマートで言うと、40から10に減った ○ （カラムはすっごく増えた） ● 責務の分割をきっちり行ったため、新規開発も既存の改修も工数が激減した ○ 影響範囲の調査が容易 ○ 設計時の考慮事項が少ない ○ システムリプレイス時の影響範囲が狭い ● 設計に関する全てをドキュメントに起こし、必要な議論を行ったため、関係者の認識が揃った ● DWH→データマート→DWH、といった負債依存関係がなくなった

Slide 45

Slide 45 text

Slide 46

Slide 46 text

46 © 2025 Leverages Co., Ltd. 今後の展望 ● 他事業部への展開 ○ 2025年1月時点では、リアーキテクチャの適用は1事業しか完了してません ○ 少なくとも残り10事業への展開が必要 ● データウェアハウスやデータマートの現場浸透 ○ レバレジーズは現場でSQLを書ける人材が数百人おり、データレイクのデータを結合してデータ活用しているケースが非常に多い ○ データ組織とデータ利用者の責務を分割するため、データ利用はデータウェアハウス以降に限定したい ● BIツールの再検討 ○ BIツールの責務を少なくした結果、レバレジーズに必要な機能しか残らない ○ 全社的に最適なツールを検討する ● データ品質チェックエラーから対応までのフロー構築 ○ システムエラーにならない不具合も事前に検知して対応する

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

49 機密情報・転載禁止 © 2025 Leverages Co., Ltd. ビジネスグロース DX 営業企画 SFA 開発 CRM/MA CJM スコアリング CS システム構築プロモーションプロダクト UI/UX SEO プロトタイプ Web 広告クリエイティブ TV CM 電⾞広告仮説設定レバレジーズはマーケティングやセールスといった全ての組織がインハウスで機能しており、データ戦略が事業運営上重要なハブとなる構造になっています。データ戦略の役割データ戦略 

Slide 50

Slide 50 text

Slide 51

Slide 51 text