ディメンショナルモデリングを採用してない組織がモデリング本を通じて得られたこと

by Tech Leverages

Slide 1

Slide 1 text

ディメンショナルモデリングを   採用してない組織が   モデリング本を通じて得られたこと   レバレジーズ株式会社   于　原駿 

Slide 2

Slide 2 text

自己紹介 

Slide 3

Slide 3 text

自己紹介 

Slide 4

Slide 4 text

datatech-jpというコミュニティで #みん強イベントの企画運営とMCしてます  自己紹介  ⬇先月末SnowVillageと  コラボイベント開催！ 

Slide 5

Slide 5 text

会社紹介 

Slide 6

Slide 6 text

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

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. ● データサイエンティスト：2名 ● データアナリスト：4名 ● データアーキテクト：6名 ● AIコンサルタント：3名 ● データエンジニア：5名 ● AI/MLエンジニア：4名 ● 先端技術研究員：2名 ● (マネージャー：2名) レバレジーズのデータ関連職種データ職種の正社員は28名が在籍 (2025年8月時点) 9 © 2025 Leverages Co., Ltd.

Slide 10

Slide 10 text

データ活用基盤の紹介  

Slide 11

Slide 11 text

11 © 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 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

詳しくはこちらのspeakerdeckにて！

Slide 15

Slide 15 text

今回伝えたいことの前提  

Slide 16

Slide 16 text

自分の職務環境の変化について   ● 前職  ○ 1つのSaaS事業のプロダクトや社内向けのデータ分析基盤  ○ ディメンショナルモデリング採用、ゴリゴリにモデリング  ○ 技術スタックはBigQuery、dbt、Looker  ● 現職（レバレジーズ）  ○ 多種多様な事業がいろいろある  ○ dwh,martなど多層であるが基本ワイドテーブルで実装  ○ 技術スタックはBigQuery、Dataform、Tableau 

Slide 17

Slide 17 text

レバレジーズのデータ系職種の職務領域について   ● データエンジニア  ○ システム本部所属のエンジニア職で構成されている  ○ 各事業のデータを、CloudComposerやFiveranを使ってBigQueryに集約する  ○ 一部の事業については、Dataformの開発を行っている  ● データアーキテクト  ○ マーケティング部の非エンジニア職で構成されている  ○ 各事業ごとのモニタリング指標をDataformで開発  ○ 各々が事業部に入り込み、課題を見つけてはデータで解決 

Slide 18

Slide 18 text

話すこと/話さないこと   ● 話すこと  ○ ワイドテーブルを採用している組織が、アジャイルデータモデリングの輪読会をどのように行ったか  ○ 非エンジニアメンバーとの間でディメンションやファクトをどにょうに共通言語にしたか  ○ 得られた学びや、実際にディメンショナルモデリングを採用できるか否か  ● 話さないこと  ○ レバレジーズにおける、具体的なモデリング話  ○ ディメンショナルモデリングを取り入れてみた話 

Slide 19

Slide 19 text

輪読会で取り組んだこと  

Slide 20

Slide 20 text

輪読会で取り組んだこと   ● 対象書籍  ○ アジャイルデータモデリング  ● 参加者  ○ データエンジニア、データアーキテクト、合わせて8~10人前後  ● 期間  ○ 週1に1時間、8ヶ月ぐらい  ● 形式  ○ 6ヶ月間の輪読会と、最後の2ヶ月はワークショップを実施 

Slide 21

Slide 21 text

輪読会で取り組んだこと   ● 輪読パート  ○ 前半30分で書籍を読み、後半30分で議論する形式  ○ 学び、疑問、気になったことなどを話してもらう  ○ 特にマーケティング部のアーキテクトの皆さんが、各事業のデータマートやダッシュボードの構築をしているので、各事業ごとの事例を話してもらうことが多かった 

Slide 22

Slide 22 text

輪読会で取り組んだこと   ● 実践パート  ○ 特定の事業に関するデータマートテーブルを、ディメンションとファクトテーブルから作り直す、というお題を自分が用意  ○ 1チーム約3人の合計10人、なるべくデータエンジニアとデータアーキテクトが混ざるようにチーム分ける  ○ 各チームごとにブランチを切って、ディメンションとファクトのテーブルを Dataformで実装してもらい、モデリング内容や設計意図を共有・議論した 

Slide 23

Slide 23 text

輪読会で取り組んだこと   ● 実践パート  ○ 各事業のイベントマトリクス、ビジネスプロセスを言語化  ○ 書籍に従って、アジャイルデータプロファイリングもしてみた 

Slide 24

Slide 24 text

輪読会の工夫ポイント  

Slide 25

Slide 25 text

輪読会の工夫ポイント   ● 非エンジニアも多く、ディメンショナルモデリングを知らない人が大半だった前提で設計  ● 事前準備をせず、継続してい全員が最後まで参加できること  ● 各メンバーがたくさん発話できるよう各事業に紐づけた議論をすること 

Slide 26

Slide 26 text

輪読会の工夫ポイント   ● 事業や業務フローについて、全員が解像度高いわけじゃない  ○ 業務理解やシステム仕様のキャッチアップで時間を費やしてしまうのをケアしたい  ○ システム都合で複雑な前処理が必要なものは、事前に処理済み簡易データソースを用意した  ○ ワイドテーブル特有のカラム数が膨大なのは、ディメンションやファクトも一部のみに指定してお題を選定  ○ 幸い（？）にも一部データが分析に向いていない楮になっているので、ディメンションやファクトの作り方が複数パターンありえるものを選んだ 

Slide 27

Slide 27 text

輪読会の工夫ポイント   ● テーブル定義書を見るのが辛い問題を解消したい  ○ 結局色んなスプシを参照しまくって見続ける羽目になった  ○ 2つ目のお題以降は、自分がサクッと用意できるという理由でdbt docsで準備し、リネージ周りを全部集約した 

Slide 28

Slide 28 text

輪読会の学び  

Slide 29

Slide 29 text

輪読会の学び   ● イベントマトリクスを作るという過程を通して、業務を全部可視化するのが大事そう  ○ 一方、この表が活躍するタイミングがわかりづらい。初期はスピード重視で実装し、実装を通じて事業解像度が上がっていくので、どのタイミングで作るんだろうか？  ● どんなビジネスプロセスを追いたいのか？システムのデータがどう表現されているのか？この反復横跳びが求められる  ○ 詳しい人を捕まえて、たくさんお話をしないといけなさそう  ● ディメンションやファクトという言葉が、データモデリングを行うメンバー間の共通言語になった 

Slide 30

Slide 30 text

輪読会の学び   ● 同じロジックを複数のmartに書いている現状が、ディメンションに切り出せると実装の重複が避けられるのは良さそう  ● 各ディメンションやファクトテーブルが増えていくと、どのテーブルをどうjoinするべきかがわからなくなりそう  ● ワイドテーブルのせいかSQLの行数が凄まじいので、最終的なmartテーブルはシンプルになりそう 

Slide 31

Slide 31 text

輪読会の学び   ● 既存のモデリングと、ディメンショナルモデリング導入後のモデリングの差分をこんな感じで解説   

Slide 32

Slide 32 text

輪読会の学び   ● 過去自分が登壇したディメンショナルモデリングを軽く紹介する資料もあるので、これもよかったら！   

Slide 33

Slide 33 text

じゃ、dimensional modeling採用できそう？  

Slide 34

Slide 34 text

無理　笑 

Slide 35

Slide 35 text

正確には、まだ、無理  

Slide 36

Slide 36 text

採用が難しいポイント  

Slide 37

Slide 37 text

採用が難しいポイント   ● 今の課題ってモデリング手法にあるんだっけ？  ○ コンソール上でのDataformの開発が開発効率が悪く、Copilot Agentなどの恩恵を受けづらい  ○ 開発体験を改善することを優先したい  ● ディメンショナルモデリングで課題が解消できるか今は怪しい  ○ 多分、なんちゃってモデリングを導入してしまうと、結果的にテーブルjoin の難易度が高くなり、参照祭りになりそう 

Slide 38

Slide 38 text

採用が難しいポイント   ● 影響範囲のデカさ  ○ レバレジーズではデータ民主化がかなり進んでおり、現場の営業の方が自分たちでSQLを書いてスプレッドシートに連携し、BIツールに提供しているダッシュボード以外でも各自モニタリングしている  ○ モデリングし直すことにより現場メンバーへのSQL書き換え祭りが多発する  ● 事業が多すぎる  ○ 多くの事業を少ないデータ系職種が対応している。ディメンションやファクト、適切なモデリングをレビューできる体制が出来ない   ○ とテーブル乱立状態になり、ワイドテーブルよりも辛い状況が生まれる 

Slide 39

Slide 39 text

まとめ 

Slide 40

Slide 40 text

まとめ  ● ディメンショナルモデリングのベースの考えは伝わった  ● 今の設計思想で少しずつ浸透させるようにしたい  ○ 例えばサブクエリをdim/factごとに作ってみると、ワイドテーブルの実装であってもレビューや保守運用しやすくなる  ○ みたいものをそのままSQL書くのではなく、何を計測し、どのような切り口で分析したいのか？という意識をもたせる  ● データ系職種の事業ドメインの解像度が上がり、モデリングのレビューが出来る状態が生まれれば、datamart → dim/factへの切り出しはAIの力を借りながら実現は可能  ● ちょっとずつディメンショナルモデリングreadyな組織を目指していく 

Slide 41

Slide 41 text

さいごに 

Slide 42

Slide 42 text

Slide 43

Slide 43 text

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