tokyo_dbt_meetup_#14_意志ある羅針盤たれ＜データサイド＞

GA technologies では、「不動産による資産形成を、あたりまえにする」というブランドミッションのもとで、AI不動産投資「RENOSY」というサービスを提供しています。不動産ドメインというレガシーな産業のデータをどのように取得し、基盤構築を行い、最終的に事業に資するように利活用するのかについてお話しいたします。オンライン上にデータがリッチに残りにくい不動産業において、取得・基盤構築・利活用、すべてのポイントにおいて多くの失敗を繰り返しつつ、弊社が導出した解決策についてお伝えできればと思います。

Transcript

1. 意志ある羅針盤たれ＜データサイド＞ 
 SSoTの実現で、組織のベクトルを揃え、 
 事業の前進を加速させる 
 
 @Tokyo dbt Meetup #14
 
 GA technologies Data本部 Data Analysis部 
 山口貴矢 Data Analyst
 2025/06/17

3. 会社紹介 / GA technologiesの概要 
 ※コーポレートストーリー 2025年3月より（証券コード：3491） 

5. 　 登壇者紹介：山口 貴矢
 職歴：2019年 GA technologies 新卒入社（2017年からインターン）
 　　　財務経理 → 経営戦略（IR）→ 営業企画 → 事業戦略 → データ
 （ 事業側：5年、データ側：1.25年 ）
 所属：データ本部 データアナリシス部 データアナリスト
 趣味：炭火（庭, キャンプ）、お風呂でのジャーナリング、俳句 
 GA technologiesでの取り組み：主要事業における、データの取得 / モデリング / 利活用
 • 取得　　　　：非構造化データの構造化など 
 • モデリング　：事業ファネルに応じたファネルテーブル （One Big Table）の作成
 • 利活用　　　：構造化されたデータから、 Asset Planner のキーアクションの発見を推進 
 ※1 ※1 ファネルテーブル：社内用語で、一般的な One Big Tableを意味する。詳細は本日の夜に開催予定の、 dbt tokyo meetup #14「意思ある羅針盤たれ＜データサイド＞」にて発表予定 ※2 弊社では、一般的な営業職のことを「アセットプランナー（ Asset Planner）」と呼称している。営業という言葉がもつ「販売することが何よりも重要であり、販売したらそこまで」という印象から脱却し、一人一人 の顧客が所有しているアセット（資産）を継続的に最適なものとなるようサポートし続けるというニュアンスをこめている。 ※2 事業
 データ

6. 1. GA technologies の SSoT への道のり
 2. SSoT 構築における RENOSY 事業での課題
 3. どのように SSoT を実現したか
 4. 今後の課題
 アジェンダ

7. 1. GA technologies の SSoT への道のり

8. GA technologies の SSoT への道のり
 SSoT を実現する 技術 SSoT を組織に定着させる 技術 各KPIを表現するにあたり 
 唯一の情報源から利活用可能な状態 
 
 裏を返せば、ある KPIを
 二つ以上の方法で表現しない状態 
 データチームが提供する 
 データを活用している状態 
 
 裏を返せば、各事業部で 
 野良のダッシュボードがない状態 
 ※ ※ 「SSoTを組織に定着させる技術」に関しては、本日昼に開催された、 TECHPLAY データマネジメントの勘所「意思ある羅針盤たれ＜事業サイド＞」にて発表
9. 既存データの中身を確認 （RAW層の内容を把握） FY24 下期 FY25 上期 データモデリングを行い SSoTな環境を整備 FY25 下期 SSoTなデータを利用し 事業の成長に貢献する 社内システムのデータを紐解き、 dbt × Snowflakeで達成
 OBT （One Big Table）の概念を採用し、技術的 SSoTを局所的に達成したが、まだ道半ばな状態 
 GA technologies の SSoT への道のり（実現する技術）
 ※ ※ OBT（One Big Table）：一つのテーブルの中に必要な情報や指標を非正規化してまとめて持たせる構成（例：顧客情報の OBTでは、顧客IDに対して多種多様な情報を付与させる）
10. 2. SSoT 構築における RENOSY 事業での課題

11. SSoT でない状態が引き起こすこと
 意思決定の質が低下する 意思決定が遅くなる 正しいか不明瞭なデータを使用するため 
 誤った意思決定となるリスクが高まる 
 
 データの取得条件や集計ロジックが 
 複数あることがよくある原因である 
 SSoTとは、Single Source of Truthの略称。組織内でデータの唯一の正しい情報源を定め、すべての関係者 が同じデータを基に意思決定できるようにする考え方のことを指す。 
 
 同じ指標を表す指標が複数あると 
 どれを参照すべきか確認が必要になる 
 
 この遅延が、事業の機会損失や 
 競争力の低下につながる可能性がある 

12. 弊社事例）SSoT でないデータが事業に与える影響
 意思決定の質が低下する 意思決定が遅くなる 事例 顧客からの問い合わせ数という KPIが 部署ごとで把握している数字が異なると 経営会議で明らかになる 影響 経営の重要論点を議論すべき時間が、 数字ずれの原因追求の場となってしまい 意思決定のスピードが遅くなる KGIとして見ている数字が正しくなく、 経営資源の投資領域を見誤る データに対する信頼性が損なわれ、 意思決定を合意する難易度が高まってしまい 質の低下が事業成長の足かせとなってしまう
13. 事例）SSoT でない状態になぜなってしまったか
 従来のデータ組織の構造は事業部に対して担当者が配置されている分権型の状態だった 
 現在は、機能組織として事業部に横断的に関与するハイブリッド型の状態である 
 従来：分権型 現在：ハイブリッド型 事業部 データ 事業部 データ 事業部 データ 　事業部 　事業部 　事業部 　データ部 横 断 的 に 関 与 事業部内に各担当者を配置 
 事業部横断でデータ活用 

14. 余談）部分的に進んでいたデータモデリングの負債
 SSoTな状態を目指そうというプロジェクトが始動する前から自然と発生していた共通部分の集約化は、 
 一時的には成功したものの、運用保守がされずに徐々に負債化してしまった 
 共通部分を集約してモデリング 運用保守を仕組み化できず負債に データマート 共通部分 共通部分 共通部分 データマート データマート 共 通 部 分 ・モデリングした共通部分を横断利用
 データマート 共通？部分 共通？部分 新規作成 データマート データマート 共 通 部 分 新 規 ・共通部分の変更が更新されない
 ・本来共通のものが新規に作成される
 共通部分を集約化する活動は、一時的な実現ではなく、運用保守までを仕組み作りが重要
15. 3. どのように SSoT を実現したか（半年強のプロジェクト）

16. GA technologies でのデータモデリングとDWH構築
 フェーズ アクション 所要期間（ 1ヶ月単位） 1 重要指標のデータマッピング 2 RAW層データリネージ整理 3 既存Data Warehouse構成の見直し 4 データレイヤー設計 5 Semantic LayerとMetrics導入の試行と現実 6 OBT（One Big Table）設計とSSoTの現実解 7 テーブル設計方針と実装アプローチ 8 導入効果の測定
17. GA technologies でのデータモデリングとDWH構築①
 フェーズ 1 重要指標のデータマッピング 〜1ヶ月目 既存ユースケース一覧 各テーブルのカラムの重要度判定 まず行ったことは事業として必要な指標を明確化することと、データカラムのマッピングです。
 既存のユースケースを洗い出し、事業運営に必要な指標を特定することで、手戻りの最小化を目指しました。

18. GA technologies でのデータモデリングとDWH構築②
 フェーズ 2 RAW層データリネージ整理 〜1ヶ月目 RAWテーブル リネージ図 エンジニア組織の文書文化が成熟する前に作成されたテーブルが多く、GitHubのDiscussionで直接エンジニアと
 コミュニケーションをしながら、テーブルリネージを作成していきました。時間はかかったが、価値は大きい。
 各種RAWテーブル 重要度整理
19. GA technologies でのデータモデリングとDWH構築③
 フェーズ 3 既存Data Warehouse構成の見直し 〜1ヶ月目 次に着手したのは、既存Data Warehouseの棚卸しです。当初は利用できる部分の再利用も検討しましたが、
 ロジックが複雑性の高いものだったため作り直すことに。事業サイドからの理解が得られる関係が功を奏した。
 既存DWHの棚卸し & 利用検討の痕跡 旧集計ロジックから新集計ロジックへの変更で KPI数値が変動 旧集計ロジック 新集計ロジック 事業サイドに、日々モニタリングしている数値のロジック変化を 許容してもらえなければ、ロジック変更は難しい...

20. GA technologies でのデータモデリングとDWH構築④-1
 フェーズ 4 データレイヤー設計 1〜2ヶ月目 dbtのベストプラクティス（※1）とKimball's Dimensional Modeling（※2）の考え方を参考にしています。
 データの整流化とモデリングを両立する構成を意識し、Fuunel / Aggregation / Exposure はオリジナル構成。
 ※1: dbt best practice guide ( https://docs.getdbt.com/best-practices) ※2: Building a Kimball dimensional model with dbt (https://docs.getdbt.com/blog/kimball-dimensional-model)
21. GA technologies でのデータモデリングとDWH構築④-2
 フェーズ 4 データレイヤー設計 1〜2ヶ月目 レイヤー名 目的 特徴 Raw データの信頼性とトレーサビリティを確保すること データソースから取得した生データをそのまま格納し、加工を一切行わず最も 粒度の細かい状態で保持している。 Staging：STG 分析に使いやすい形式にデータを整えること RAWのデータに対して、命名や型の統一、不要なカラムの除外などの軽微な 整形・正規化を行っている。 Intermediate：INT 共通処理の集約と Transform層の簡素化を図ること 複数のStagingテーブルを結合・加工して、前処理された中間成果物を生成し ていり。 Transform：DIM / FCT ビジネスロジックに基づいた指標定義と、 fact/dim構造の確立によるデータの統一を実現すること Kimballのモデリング手法に基づき、事業指標の集計やディメンションの分離、 退化ディメンジョンの取り扱いを行っている。 Semantic 指標定義の一元管理と高い SSOT性の実現 Transformで定義された指標を、 dbt Metricsを用いて中央集約的に管理する 設計にしている。 ただ、Tableauとの接続性の課題により、本番運用は見送られている。 Funnel（独自）： FNL 非データユーザーでも簡単に利用できる形で、 主要メトリクスを提供すること OBT（One Big Table）形式で、集計単位ごとに非正規化されたテーブルを格納 しており、select文だけで利用可能な構成にしている。 Fixed Aggregation（独自）： AGG 特殊な集計処理の精度と整合性を保つこと 複数のキーの組み合わせ（例：日時 ×媒体別）をサロゲートキーで PK化し、一 時的に保持している。 Exposure Layer（独自）： EXP 外部ツールへのデータ出力を安定的かつ管理しやすくすること SpreadsheetやMAツールへのリスト出力を行うための Reverse ETL用テーブ ルを格納し、クエリは dbt内で一元管理している。
22. GA technologies でのデータモデリングとDWH構成⑤
 フェーズ 5 Semantic LayerとMetrics導入の試行と現実 2〜3ヶ月目 SSoT実現のために、dbt Semantic Layer（dbt SL）の活用は非常に理想的なものでした。順調にdbt SLでの実装を
 進めtableauもversionを上げて導入を試みたものの、コネクタがβ版で安定性に欠け、下記トラブルが生じました。
 トライ：dbt Semantic Layer × Tableau 生じたトラブル データ読み込みに 膨大な時間がかかり、 実用に耐えない ratioやderived metricsなど 一部指標がTableauで表示 されず、実用に耐えない
23. GA technologies でのデータモデリングとDWH構成⑥
 フェーズ 6 OBT（One Big Table）設計とSSoTの現実解 3〜4ヶ月目 Semantic Layerによる理想的なSSoTを一旦見送り、現実的なSSoT構成としてOne Big Tableを採用した。
 Transform（dim/fact）層で定義を集約し、OBT（funnel）層をSSoTの表現として活用し、下記メリットを享受。
 OBTによるSQLの簡易化 現場ニーズへの解答力 & 速さ OBT間のリネージの明確化 SSoTを維持可能な運用 OBTには名称通り 分析単位ごとの主要な情報が 全て含まれているため SQLがシンプルに記述可能に OBT作成にあたり各カラムの 定義も整理され直したため 現場が必要な情報を用意する コストが低下し納品速度向上 上流のOBTを下流で再利用 可能なビジネス構造のため 効率的、かつ、明確に OBT間のリネージが記述可能 ユースケースに応じて新規に 必要になったカラム情報を データマートで作成せずに OBT内に用意して利用する
24. GA technologies でのデータモデリングとDWH構成⑦
 フェーズ 7 テーブル設計方針と実装アプローチ 4ヶ月目以降 テーブル設計と実装の整合性を高めるため、 dbtプロジェクトのディレクトリ構成にルールを設けました（例 : models/funnel … FNL層）
 テーブル命名にも各層の情報を付与することで、コードベースでも構造が自然と可視化されました（例： fnl_xxx … FNL層のテーブル）
 テーブルの全量管理と実装進捗管理シート 各テーブルの詳細設計シート
25. GA technologies でのデータモデリングとDWH構成⑧
 フェーズ 8 導入効果の測定 7ヶ月目〜 運用を開始したのが2025年3-4月頃だが、そこから数ヶ月だけでも「使いやすく・信頼できるDWH」の効果を実感
 アドホック分析の効率化、メンテナンス性の向上が実現し、意思決定の質やスピードの向上が設計通り実現された
 OBTによるSQLの簡易化 現場ニーズへの解答力の高さ OBT間のリネージの明確化 SSoTを維持可能な運用 OBTには名称通り 分析単位ごとの主要な情報が 全て含まれているため SQLがシンプルに記述可能に OBT作成にあたり各カラムの 定義も整理され直したため 現場が必要な情報を用意する コストが低下し納品速度向上 上流のOBTを下流で再利用 可能なビジネス構造のため 効率的、かつ、明確に OBT間のリネージが記述可能 ユースケースに応じて新規に 必要になったカラム情報を データマートで作成せずに OBT内に用意して利用する 🎉 実現された 🎉
26. 4. 今後の課題

27. 1. データの統一とガバナンスの強化（データ本部の横断機能の強化）
 2. 適切な運用と保守の継続と改善
 3. メタデータ管理の徹底とデータ品質の向上
 4. Semantic Layer の導入
 a. Tableau Next（Tableau Semantic Layer）
 b. Snowflake semantic view @ Snowflake Summit
 5. 他事業部への展開
 今後の課題

28. ご清聴ありがとうございました！ 

29. 採用強化中です！ 
 一緒に働きませんか？ 
 HERP データ関連職種求人一覧
30. RENOSY トップページ RENOSYのオーナー様 になりませんか？