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

1. 1 © 2025 Leverages Co., Ltd. 10倍スケールを見越した データモデリングの リアーキテクチャ 2025/01/30 みんなの考えた最強のデータアーキテクチャ 　〜2025もやってきましょうSP！
2. 2 © 2025 Leverages Co., Ltd. 自己紹介
3. 3 © 2025 Leverages Co., Ltd. 森下 研人 レバレジーズ株式会社 テクノロジー戦略室 データエンジニアリンググループ MGR • 日系SIerでDBエンジニアを経験後、 2019年11月にレバレジーズへジョイン • データエンジニア6年目 • データ基盤構築 / データマネジメント / データガバナンス / チーム作り / 採用 などなど幅広くやってます • 3歳で5kgの猫と同居してます 自己紹介 3 機密情報・転載禁止 © 2023 Leverages Co., Ltd.
4. 4 © 2025 Leverages Co., Ltd. Contents 自己紹介
 会社紹介
 データ活用基盤
 データモデリングのリアーキテクチャ
 リアーキテクチャの効果
 今後の展望
 さいごに
 01. 02. 03. 04. 05. 06. 07.
5. 5 © 2025 Leverages Co., Ltd. 会社紹介
6. 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. 会社について
7. 7 機密情報・転載禁止 © 2025 Leverages Co., Ltd. 10年後に ⼀兆円規模を ⽬指す 企業の安定性と成⻑性を担保する独⾃の経営戦略のもと、 創業以来、黒字経営を継続し、 2023年度は1,149億円を達成しました。 企業理念として「顧客の創造を通じて、関係者全員の幸福を追求し、 各個⼈の成⻑を促す」を掲げ、⼈の感情と向き合いながら 次の時代を創るグローバル企業を⽬指しています。 ベンチャーを牽引する成⻑で、 次代を創る企業へ 売上推移 会社について
8. 8 機密情報・転載禁止 © 2025 Leverages Co., Ltd. ポートフォリオ経営とは、業界やビジネスモデルなどにこだわらず、 分散投資をしていく経営形態のこと。 この経営形態のメリットは、予測困難な外部変化に会社全体で衝撃を 吸収しやすい点にあります。例えば、コロナ禍では海外事業などは打 撃を受けた⼀⽅で、IT事業や医療‧ヘルスケア事業は追い⾵を受け、 過去最⾼の売上を更新、黒字経営を継続しました。 経営のリスク分散を⾏うことで、未曾有の状況でも安定した成⻑を実 現しています。 ポートフォリオ経営による安定した 収益基盤で創業以来、黒字経営を継続 経営体制について 会社について
9. 9 機密情報・転載禁止 © 2025 Leverages Co., Ltd. 「⻑期的に市場の成⻑性が⾒込まれること」「社会や⼈の負を解決す ること」を市場参⼊軸とし、現在は、IT、医療‧介護‧ヘルスケア、 M&A、SaaS、海外、若年層などの領域で、約50の事業を展開中。 今後、より収益が安定し、⼤規模な投資が可能になれば、エネルギー や⾷料、宇宙産業など、世界の課題を解決するための事業を展開して いきます。 世界を視野に、 国や業界にとらわれない事業展開 事業数の推移 事業展開 事業について
10. 10 © 2025 Leverages Co., Ltd. • データサイエンティスト：2名 • データアナリスト：4名 • データアーキテクト：8名 • データエンジニア：3名 • 機械学習エンジニア：3名 • 機械学習研究：1名 レバレジーズのデータ関連職種 社員数2,800人に対して、データ職種は 2025年1月時点で業務委託含め21名 10 © 2025 Leverages Co., Ltd.
11. 11 © 2025 Leverages Co., Ltd. データ活用基盤
12. 12 © 2025 Leverages Co., Ltd. • ELT：Fivetran • DWH：BigQuery • Transform：Dataform • BI：Tableau, Looker Studio • Metadata：Dataplex • Quality Check：Dataplex • Reverse ETL：trocco • Orchestration：Airflow データ活用基盤 - 全体概要アーキテクチャ
13. 13 © 2025 Leverages Co., Ltd. データ活用基盤 - 個別アーキテクチャ • 全社で40近くのサービスを展開していることもあり ブランド単位でまとめつつデータ活用基盤を分割 • データ活用基盤の数は10ほど • BigQueryを中心としつつ、事業売上や関係者数、 実装時期によって少しずつアーキテクチャが異なる • 異なるビジネスモデルや売上規模でも 設計が変わらないよう共通利用できる技術を選定
14. 14 © 2025 Leverages Co., Ltd. データモデリングの リアーキテクチャ
15. 15 © 2025 Leverages Co., Ltd. データモデリングの リアーキテクチャ • DWHの発展史 • 蓄積されたつらみ • 最初に確定させたこと • 全体共通方針の策定 • 具体的なアーキテクチャ • やってみて実際どうだったか？ 15 © 2025 Leverages Co., Ltd.
16. 16 © 2025 Leverages Co., Ltd. データモデリングの リアーキテクチャ - 発展史
17. 17 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - DWHの発展史 • もともとはSFAのデータのみを使用してDWH〜DM〜BIまで繋いでいた SFA データソース データレイク データウェアハウス データマート ビジュアライズ
18. 18 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - DWHの発展史 • データ活用が進むにつれ、データソースが増えていった • ひとまずDWHに繋ぐという実装が進んで行った • データ活用を浸透させ、事業貢献するために、テーブルがもりもり増えて（増やして）いった SFA データソース データレイク データウェアハウス データマート ビジュアライズ 広告データ アクセスロ グ
19. 19 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - DWHの発展史 • 社内のデータ活用が拡大していくなかで、DWHやDMがどんどん作られていった • 早く実装して早く事業貢献するために、各人の裁量に任せて実装が進んで行った • テーブル間の依存関係が複雑化し、テーブル重複などが度々発生するようになった SFA データソース データレイク データウェアハウス データマート ビジュアライズ 広告データ 登録 システム アクセスロ グ
20. 20 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - DWHの発展史 • Dataformのリネージ機能を使っても巨大すぎて全体像の表示で落ちるようになった • テーブル数が多すぎて認知負荷の限界を超えた • システムリプレイス時の影響調査が大変すぎた SFA データソース データレイク データウェアハウス データマート ビジュアライズ 旧登録 システム 広告データ 新登録 システム アクセスロ グ
21. 21 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - DWHの発展史 • このままだとDWHが事業成長の足枷になることは明らかだった SFA データソース データレイク データウェアハウス データマート ビジュアライズ 旧登録 システム 広告データ 新登録 システム アクセスロ グ
22. 22 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - 蓄積されたつらみ • DWHのつらみ ◦ 当初の設計思想を超えてデータ基盤が肥大化した結果、チームメンバーの認知の限界を超えた ◦ SFAのみを使用する想定が、10以上のデータソースを接続することになった ◦ 明確な実装方針やルールがないまま、データ活用を浸透させるためにスピード重視で実装していった ◦ 結果として似たようなテーブルが乱立し、Dataform管理のテーブルが400を超えた ◦ テーブルも多く依存関係が複雑すぎるため、Dataformのテーブルリネージで全体像を描画できなかった ◦ ドキュメントも不十分で、データ定義の意図や背景が読み取れなかった ◦ データの除外タイミングが統一されておらず、似て非なるテーブルが大量にあった • ビジュアライズ層のつらみ ◦ 実装の明文化されたルールがなかったため、ダッシュボードごとに実装が異なっていた ▪ BigQueryで計算させてから送る vs BIツールでデータ結合やデータ型変換を行う ▪ DWHでリネームする vs BIツールでリネームする ◦ 機能制限もなかったため、一定以上のスキルがないと保守運用できないダッシュボードが大量にあった ◦ ダッシュボード改修の際、BIツールだけで完結するのかテーブル改修が必要か毎回調査が必要だった
23. 23 © 2025 Leverages Co., Ltd. データモデリングの リアーキテクチャ - 最初に確定させたこと
24. 24 © 2025 Leverages Co., Ltd. テーブル結合 データの型変換 フラグ付与 複雑なデータ指標定義 ビジュアライズ 割合の計算 カラムのリネーム • 技術要素の確定 ◦ 変えることも考えたが、リアーキテクチャとは別軸で考えることにし、既存を踏襲 ▪ DWH：BigQuery ▪ Transform：Dataform ▪ BIツール：Tableau Cloud • DWHとBIの責務を分離 ◦ BIツールでは何を行うか？何を行わないか？をディスカッションして決定 ◦ BIツールの入れ替えを容易にするため、できるだけBIツール側の責務を減らす方向でルールを決定 ▪ Github管理を推進するため、Tableauの計算フィールドを極力減らしたい ▪ BIツールに送るデータ量を削減し、画面描画の速くする ◦ あくまでも配信用ダッシュボードのルールとして策定し、探索用には幅広く使える形にする データモデリングのリアーキテクチャ - 最初に確定させたこと BIツールで行うこと BIツールで行わないこと
25. 25 © 2025 Leverages Co., Ltd. データモデリングの リアーキテクチャ - 全体共通方針の策定
26. 26 © 2025 Leverages Co., Ltd. • ワイドテーブルにする！ • ビジネスモデルに依存した設計は回避する！ • BIツールでしかできないことにBIツールは集中する！ • 利用人数やデータ量が10倍になっても耐えられる形にする！ データモデリングのリアーキテクチャ - 全体共通方針の策定
27. 27 © 2025 Leverages Co., Ltd. • ワイドテーブルにする！ ◦ 新規事業も多く事業成長も速いため、 ディメンション・ファクトの切り分け難易度が高い ◦ 少人数で保守運用していくため、認知負荷の低い設計が必要 ◦ データ利用時の誤ったキー結合を防ぎ、誤ったデータ抽出を事前に防ぐ ◦ データ利用者にテーブル結合の手間を取らせない、問い合わせの工数を削減させる ▪ テーブル名やカラム名の命名は徹底的にこだわり、誰でも理解できる名前にする • ビジネスモデルに依存した設計は回避する！ • BIツールでしかできないことにBIツールは集中する！ • 利用人数やデータ量が10倍になっても耐えられる形にする！ データモデリングのリアーキテクチャ - 考慮事項の大方針の決定
28. 28 © 2025 Leverages Co., Ltd. • ワイドテーブルにする！ • ビジネスモデルに依存した設計は回避する！ ◦ 技術要素とアーキテクチャを共通化させて柔軟な人的リソース配置を可能にする ◦ どの事業でデータ活用基盤が必要になっても同じ設計で実装できるようにする ◦ 事業ごとの属人化を可能な限り排除する • BIツールでしかできないことにBIツールは集中する！ • 利用人数やデータ量が10倍になっても耐えられる形にする！ データモデリングのリアーキテクチャ - 考慮事項の大方針の決定
29. 29 © 2025 Leverages Co., Ltd. • ワイドテーブルにする！ • ビジネスモデルに依存した設計は回避する！ • BIツールでしかできないことにBIツールは集中する！ ◦ 保守運用をしやすくする ◦ BigQueryの計算リソースを最大限利用する ◦ BIツールの入れ替えを見越してBIツールの責務を薄くする ◦ ダッシュボード実装方法を統一して、ダッシュボードの品質を保つ • 利用人数やデータ量が10倍になっても耐えられる形にする！ データモデリングのリアーキテクチャ - 考慮事項の大方針の決定
30. 30 © 2025 Leverages Co., Ltd. • ワイドテーブルにする！ • ビジネスモデルに依存した設計は回避する！ • BIツールでしかできないことにBIツールは集中する！ • 利用人数やデータ量が10倍になっても耐えられる形にする！ ◦ 人数とデータ量が3年で2倍にスケールする環境に合わせる ◦ データ職種の採用難易度が高いため、少人数で回せる設計にする データモデリングのリアーキテクチャ - 考慮事項の大方針の決定
31. 31 © 2025 Leverages Co., Ltd. データモデリングの リアーキテクチャ - 具体的なアーキテクチャ
32. 32 © 2025 Leverages Co., Ltd. データモデリングのリアーキテクチャ - 具体的なアーキテクチャ • ビジュアライズ層含めて4層から8層に分解 • 各層の役割、責任範囲、対応しないこと、してはいけないこと、保守運用担当を明文化 • データセットの命名規則を整理して決定 ◦ 『データマネジメントが30分でわかる本』を参考に決定 • テーブルリネージをシンプルにするため、手前の層のテーブルしか使用しないルールを策定
33. 33 © 2025 Leverages Co., Ltd. 具体的なアーキテクチャ - データレイク層 • 目的 ◦ データソースから無加工でBigQueryへ連携する • やること ◦ FivetranやCloudComposerを利用してローデータを取得しBigQueryを更新する • やらないこと ◦ データに対して何らかの加工を行うこと
34. 34 © 2025 Leverages Co., Ltd. 具体的なアーキテクチャ - ステージング層 • 目的 ◦ ローデータを利用しやすい形へ最低限の加工を行う • やること ◦ 不要なカラムの削除、データ型変換、物理削除されたレコードの除外 • やらないこと ◦ テーブルの結合
35. 35 © 2025 Leverages Co., Ltd. 具体的なアーキテクチャ - データレイクと層ステージング層の関係 • Fivetranが付与するメタデータの削除、Timestamp型からDatetime型への変更を行う • 参照データセットを変えずにデータソースの更新方法を変えるため、Viewテーブルを採用
36. 36 © 2025 Leverages Co., Ltd. 具体的なアーキテクチャ - シングルシステムデータウェアハウス層 • 目的 ◦ テーブル同士を結合し、データ活用の最大公約数となるテーブルを作成する • やること ◦ 同一システム内でのテーブル結合、ビジネスロジックの挿入、カラム名の統一（~~日 → xx_date など） ◦ ワイドテーブルで実装 • やらないこと ◦ 他システムデータのテーブル結合を行うこと
37. 37 © 2025 Leverages Co., Ltd. 具体的なアーキテクチャ - データウェアハウス層 • 目的 ◦ 複数システム間のデータを多様な用途に耐えられる形にする • やること ◦ 複数システム間のテーブル結合、ビジネスロジックの挿入 ◦ ワイドテーブルで実装 • やらないこと ◦ 単一システムデータ内のテーブル結合を行うこと
38. 38 © 2025 Leverages Co., Ltd. 具体的なアーキテクチャ - データマート層 • 目的 ◦ 特定の目的に合わせたデータのみを保持する • やること ◦ 特定のKPIや施策に必要なデータに絞り込む ◦ 事業で使用する用語を正確に表現するため、カラム名を日本語へ変更 • やらないこと ◦ 複数の目的に合致したテーブルを作成する
39. 39 © 2025 Leverages Co., Ltd. • 目的 ◦ 指標定義を履歴管理しGithubで管理する ◦ 集計処理を共通化させ、データ定義を縦持ちで1箇所に集約する • やること ◦ 指標定義をSQLで表現し、Github管理する • やらないこと ◦ データマートもしくはBIツールでKPIの管理を行うこと 具体的なアーキテクチャ - セマンティックレイヤー
40. 40 © 2025 Leverages Co., Ltd. • 目的 ◦ BIツールへ転送するためのデータを抽出する • やること ◦ BIツールで必要なデータに絞り込みを行う • やらないこと ◦ セマンティックレイヤー以外のデータを接続すること 具体的なアーキテクチャ - セマンティックレイヤーtoBI
41. 41 © 2025 Leverages Co., Ltd. 具体的なアーキテクチャ - セマンティックレイヤーを2層にした理由 • データ定義処理の共通化を目的として、セマンティックレイヤーを2層に分割 ◦ ファクトは同じでディメンションだけ違う場合、似たような計算処理がダッシュボード毎に発生する • 1層目で全ディメンションに対してファクトを集計、縦持ちで持たせることにした • 2層目はダッシュボードに必要なデータだけをselectし、送り込むデータ量を最小限にする • 全ディメンションの組み合わせが数億あったが、ファクト集計処理が5分以内に完了したので採用
42. 42 © 2025 Leverages Co., Ltd. • 目的 ◦ 関係者全員が同じ指標を見て意思決定を行う • やること ◦ 意思決定に必要なデータの可視化を行う • やらないこと ◦ セマンティックレイヤー以外からデータを繋ぐこと ◦ BIツール側で複雑な計算を行うこと 具体的なアーキテクチャ - ビジュアライズ層
43. 43 © 2025 Leverages Co., Ltd. リアーキテクチャの効果
44. 44 © 2025 Leverages Co., Ltd. リアーキテクチャの効果 • 事業のスケールに耐えられる自信がついた • データ定義の問い合わせ数が減った • ワイドテーブルを採用したため、テーブル数が減った ◦ データマートで言うと、40から10に減った ◦ （カラムはすっごく増えた） • 責務の分割をきっちり行ったため、新規開発も既存の改修も工数が激減した ◦ 影響範囲の調査が容易 ◦ 設計時の考慮事項が少ない ◦ システムリプレイス時の影響範囲が狭い • 設計に関する全てをドキュメントに起こし、必要な議論を行ったため、関係者の認識が揃った • DWH→データマート→DWH、といった負債依存関係がなくなった
45. 45 © 2025 Leverages Co., Ltd. 今後の展望
46. 46 © 2025 Leverages Co., Ltd. 今後の展望 • 他事業部への展開 ◦ 2025年1月時点では、リアーキテクチャの適用は1事業しか完了してません ◦ 少なくとも残り10事業への展開が必要 • データウェアハウスやデータマートの現場浸透 ◦ レバレジーズは現場でSQLを書ける人材が数百人おり、 データレイクのデータを結合してデータ活用しているケースが非常に多い ◦ データ組織とデータ利用者の責務を分割するため、 データ利用はデータウェアハウス以降に限定したい • BIツールの再検討 ◦ BIツールの責務を少なくした結果、レバレジーズに必要な機能しか残らない ◦ 全社的に最適なツールを検討する • データ品質チェックエラーから対応までのフロー構築 ◦ システムエラーにならない不具合も事前に検知して対応する
47. 47 © 2025 Leverages Co., Ltd. さいごに
48. 48 © 2025 Leverages Co., Ltd. We Are Hiring! • まずはカジュアル面談からどうぞ！ • 3年で2倍にスケールする環境で、データを使った変革を起こしましょう！ • 募集職種 ◦ データサイエンティスト ◦ データアナリスト ◦ データアーキテクト ◦ データエンジニア ◦ 機械学習エンジニア ◦ 機械学習研究員
49. 49 機密情報・転載禁止 © 2025 Leverages Co., Ltd. ビジネス グロース DX 営業 企画 SFA 開発 CRM/MA CJM スコア リング CS システム 構築 プロ モーション プロダクト UI/UX SEO プロト タイプ Web 広告 クリエイ ティブ TV CM 電⾞ 広告 仮説 設定 レバレジーズはマーケティングやセールスといった全ての組織がインハウスで機能しており、 データ戦略が事業運営上重要なハブとなる構造になっています。 データ戦略の役割 データ戦略

50. 50 © 2025 Leverages Co., Ltd. レバレジーズ テックブログ https://tech.leverages.jp/ データ戦略ブログ（週1更新） https://analytics.leverages.jp/ 全社の情報発信媒体(melev) https://melev.leverages.jp/ 情報発信しています！
51. 51 © 2025 Leverages Co., Ltd. ご清聴ありがとう ございました！！