■ 1. イベント概要
- データエンジニアリングスタディ#36
- テーマ: 良いデータモデルはどこから生まれるのか
- SQL・DBTによる実装自動化が進む現在、データエンジニアの価値は「何をどうモデリングするか」という上流の設計思想にシフトしている
- 3つの角度から掘り下げた:
- ドメイン駆動設計（DDD）の視点（増田）
- ビジネスプロセスからの捉え方（寺島）
- 20年以上の現場実践（松井）
■ 2. セッション1: ビジネスプロセスから始めるデータモデリング（寺島、株式会社10X）
- AI時代のデータモデリングにおける変化:
- 変わらないこと: ガーベジイン・ガーベジアウトは引き続き有効であり、人間が読んで難しいクエリはAIが読んでも難しく再現性が低い
- 変わること: 汎用的な「大福帳」テーブルの相対的価値が低下し、ルールに従って積み上げられたディメンショナルモデルをAIが扱えるようになっている
- SQLを書くハードルがAIにより劇的に下がった結果、ディメンショナルモデリングされたデータをデータユーザーが扱える「モデリングチャンスの時代」が到来した
- 言葉の定義:
- ビジネスプロセス: 業務の集まり（例: ネットスーパーの「注文する」「梱包する」「配達する」）
- ビジネスイベント: それ以上分割できない業務の最小単位の出来事（例: 「注文が完了する」「注文変更する」「注文が確定される」）
- モデリングチャンス1「秘伝のWHEREが必要なファクト」:
fact_ordersに毎回「秘伝のWHERE」が必要になっていた原因は、テーブルが何のビジネスイベントを表しているかが不透明だったため（プロダクト側のDB設計をほぼそのまま移植した結果）- リファクタリングで「配達完了を表すイベント」として
fact_orders_deliveredを定義し直した- 選択の根拠:
- 注文変更が締め時間まで可能なため、元の
fact_ordersの金額は「事実」と言い切れない- 社内の重要KPIが配達完了注文の金額から計算されていると判明した
- 結果: 秘伝のWHEREなしに安全なクエリが可能になり、1〜2年後も情報欠落の問題は発生しなかった
- このリファクタリングはキンボール（Kimball）の4ステップ・ディメンショナルデザインプロセスに対応している:
- Select the Business Process（配達完了を選択）
- Declare the Grain（注文単位）
- Identify the Dimensions（誰が・どこでのディメンショナルキーを用意）
- Identify the Facts（ファクトに持たせる数値を決定）
- 社内KPIが何のビジネスプロセスから集計されたかを明らかにする作業は現在でも人間に残されており、ヒントは社内ダッシュボードや秘伝スプレッドシートにある
- モデリングチャンス2「無理やりなJOIN」:
on_coupon_idをアンダースコアでスプリットしてクーポンコードと紐付けるという脆弱な処理が発生していた- 原因: プロダクト側DB設計に引っ張られすぎ、クーポンごとの文脈で集計できない構造になっていた
- リファクタリングでクーポン周りのビジネスイベントを「取得する」と「使用する」に分けて再定義した結果、複雑なロジックが不要になった
- 合わせてクーポンコードにスペースが入り得る脆弱性も発見し同時に改善できた
- ファクトとディメンションの境界線:
- ドメインによって異なる（例: 住所変更はECサービスではディメンション、引っ越し業者ではファクトになり得る）
- ソースが状態しか持っていない場合はアプリケーションエンジニアにイベントとして残してもらうよう依頼することが重要
- まとめ「モデリングチャンスのサイン」:
- 秘伝のWHEREを毎回書いている
- 無理やりなJOINでコンテキストをやりくりしている
- AIに暗黙知をプロンプトで毎回渡している
- ルールが闇鍋のように詰まっている
- Q&Aでの補足:
- DIM＝ビジネスオブジェクト、ファクト＝ビジネスイベントは概ね妥当な捉え方であり、5Wに当てはまるものがディメンションになる（吉田）
- データモデリングのROI証明は困難であり、セキュリティ観点や大福帳のメンテナンスコスト増大を論拠にする方が戦いやすい（寺島）
- JOINが多くても機械的なパターンに従えるならAIが担える。書く大変さをAIが吸収しつつ、読む時の理解しやすさは高まるという観点がある（寺島）
- 「何をモデリングしないべきか」については、使われなければ消しやすくする仕組みを作ることも重要（寺島）
- バス行列（縦にイベント、横にディメンション）を作り複数ファクトで共有されるディメンションを整理することで優先度の高いディメンションを判断しやすくなる（吉田）
■ 3. セッション2: データエンジニアリングとドメイン駆動設計（増田徹、有限会社システム設計）
- データメッシュの概要:
- DDDの影響を受けて生まれた非集中型データアーキテクチャ
- 各業務のアプリケーション開発チームがデータ生成・提供・分析データの利用を自チームに閉じて担当する
- 他チームのデータを利用する場合は提供側が品質を保証した「データプロダクト」として提供する
- 各チームがプロダクトを提供し合うことでメッシュ（網目）構造のネットワーク構造になる
- データのライフサイクル（3段階）:
- データ生成: 業務プロセス実行系アプリケーションのDBに記録
- データ提供: データを収集・変換して利用者に提供
- データ利用: 意思決定支援、機械学習、業務プロセスへのフィードバック
- データプロダクトの特徴:
- 特定の課題を解決するための製品であり、汎用的なデータパッケージではない
- 内容説明・取り扱い方法・品質保障・アフターサービスまで含めて提供される
- データソースのアプリケーション開発チームが所有するデータを利用者のニーズに合わせて提供する
- 非集中型を採用する3つの理由:
- 目的適合性の向上: データソースの業務活動に精通したチームが正しい意味を熟知しており、専門性を持ったチーム同士が意図を伝達し合うことで高度なデータ活用が実現できる
- 発展性の向上: データソースのモデルと提供パッケージが独立して進化可能であり、活用方法を発展させやすい
- 安全性の向上: データ管理の境界がアプリケーション開発単位で明確に定義され、出てはいけないデータを管理できる
- 非集中型における全体最適化のアプローチ（2つの側面）:
- 目指す方向の一致と設計判断の一貫性:
- 「中核の業務領域」（競争優位を生む）と「一般の業務領域」（他者と同じでよい）を区別する
- 業務ロジックの複雑さと競合他者との差別化の影響度の4象限で整理する
- 中核は自社独自で徹底的に取り組み、一般は模倣・購入・省略・AIの一般論活用も選択肢
- 効率化・無理・無駄・ムラの検知と除去:
- 事業目的適合性を優先して評価・優先付けする
- データエンジニアの実践コミュニティを立ち上げ、現場の課題や失敗談を話し合える場を定期的に持つ
- 「お客さんが自社を選ぶ理由」を全社的に問い続け、多様な視点で方向性を洗練させる
- 専門部署による中央集権的なルール管理より、この方が的確で効果的
- Q&Aでの補足:
- N対Nの複雑性は事業目的適合性による優先順位付けで対処する。中核は優先的に提供し、一般は単純なモデリングでサッと提供、優先度が低ければ作らない（増田）
- 品質の認識差は最初から綺麗な合意は取れないため、できるだけ早期に出して使ってもらい継続的な話し合いで解決する（増田）
- 複数ドメインから参照される「顧客」エンティティ問題は「そこにコストをかける価値があるか」という議論が起点であり、合わせられないなら「実は中核の業務かもしれない」という議論になる（増田）
- データエンジニアはディメンショナルモデルだけでなくリレーショナルモデルも学び、視点を増やして繋がりを考えることが重要（増田）
- リレーショナルの正規化を突き詰めた第6正規形はほとんどデータボルトと同じ構造になり、各アプローチが行き来できるようになる（増田）
- 「継続することが唯一の戦略実行の条件」であり、断続的になっても続けることだけが戦略を実行できる理由（増田）
■ 4. LT: プライムナンバーからのご案内（高畑、プライムナンバー）
- 良いデータモデリングを実行する際の3つの難所:
- 対話の促進: DDDは対話のための設計技法であり、対話を促進するためのやり方とその時間・労力の問題がある
- イベントの整理: 現実世界で起こっていることをまとめるために多くの関係者との対話が必要
- 設計への落とし込み: データボルトなど様々な概念の中でどう設計に落とすかの問題がある
- プライムナンバーではデータ基盤構築支援を提供しており、DDDや各種設計技法を踏まえた土台作りや既存データ基盤の改修も対象
- 8月25日に「PUGfest」を開催（AI活用を中心とした豪華登壇者・交流企画あり）
■ 5. セッション3: 分析基盤におけるデータモデリング20年史（松井太郎、Vポイントマーケティング株式会社）
- 登壇者の立場:
- Vポイント（年間利用者1億3000万人）のテクノロジー戦略本部長
- 2011年頃からTポイント・Vポイントの分析基盤に携わっている
- 「良いデータモデルはどこから生まれるか」への答えは「何を解くかの見極めから生まれる」
- 2003年〜 Tポイント誕生と初期基盤:
- 国内初の共通ポイントサービスとしてTポイントが誕生し、1業種1社の原則で急ピッチで拡大
- 急速な事業拡大によりインフラ・アプリ・データモデル全体の再構築が必要になった
- 2008〜2010年 基盤刷新:
- 数万QPS対応のための処理性能向上
- トランザクション処理方式の根本的な見直し
- 企業・業態・店舗などの階層データをポイントデータとして持てるよう整理
- 2011年〜 加盟先データの標準化（現代で言う「データコントラクト」）:
- 加盟先ごとのカスタマイズをやめ、分析に必要な項目を明文化して加盟先に弊社仕様でデータを送ってもらうよう契約時に合意形成した
- 標準化の具体的内容:
- ジャンルコード・商品コードの正規化
- 税抜き統一（消費税率変化による売上誤解を避ける）
- 値引き仕様の統一
- テーブルごとの必須・オプション項目の区別
- セールスエンジニア的な役割が重要であり、結果として年間数十社加盟してもスケールするようになった
- 2013年〜 商用分析サービスの構築と履歴管理（現代で言う「SCD Type 2」）:
- 外部向け商用分析サービスの構築により特定時点でのマスタとの整合性が必要になった
- データの履歴管理と特定時点でのマート化を実装した
- 分析サービス拡大でアクセスが10倍以上になりExaDataがパンク、2015年にVerticaへリプレースして処理性能を数十倍向上
- 2016年〜 クラウドへの移行とアナリストとの役割分担（現代で言う「メダリオンアーキテクチャ」）:
- OracleからAzure Synapseへ移行し、データマートを自由に作れるようになった
- 役割分担を確立:
- エンジニア（5名）: 外部データを正規化するまで
- データアナリスト（当時40名→現在70名）: BIへの連携・レポート作成
- アナリストのスキルのばらつきに対してガードレールや実装ガイドラインを継続的に見直している
- 2017年〜 販売管理システムの再構築（DOAアプローチ）:
- 会員基盤6〜7000万人に伴いサブシステムが乱立したため、全社的に業務フロー・機能・帳票を可視化・ドキュメント化
- 媒体が今後も増えることを前提に汎用的に運用できるデータモデルを設計し、DOA（データ中心アプローチ）でデータモデルを中心に業務設計した
- 2021年〜 Snowflakeへの統合:
- Vertica・Azure Synapse・Oracle ExadataをSnowflakeに統合（ハードウェア保守期限やライセンス契約タイミングを考慮しながら5年かけて段階的に移行）
- 成果:
- SSOT（Single Source of Truth）の実現
- コスト・性能担保の容易化
- エンジニアが3つのDBを覚える必要がなくなり、内製化が進んだ
- テーブル数は1万超（ワークテーブル含めると2万近く）であり、用途別のDB・スキーマへ再配置し重複・不要テーブルの整理を業務・アナリスト・運用チームで協力して実施
- まとめ「歴史から得られた知見」:
- 良いデータモデルは「作った瞬間がいい」のではなく、「維持されているからいい」
- 「どこでモデリングするかを選び続けた」ことが最大の価値であり、上流の機幹システム・プロダクトへの直接投資にこだわってきた
- 基本的にディメンショナルモデル＋スタースキーマ構成で格納し、アナリストがSQLでJOINしながらレポートする構成
- 今後は「どこで生むか」に加えて「いつ見直すべきか」が重要な課題になる
- 式年遷宮的アプローチ:
- 「式年遷宮」（数年に1回業務のずれを溜め込んで一気に直す）とアジャイル型の継続的改善を補完的に組み合わせる
- 式年遷宮の際に業務の可視化・言語化・暗黙知の形式化とアーキテクチャの改善も合わせて行う
- モデル更新が必要なサイン:
- 入力情報の定義変化・意味の変化
- 入力エラーの増加
- 特定の機幹システムから毎日全量ダウンロードしているなど（システム外に新しい業務が生まれているサイン）
- AIエージェントを動かす上でも業務や機幹システムが最新化されていないとエージェントはずれた動きをするため、業務変化やずれの意味を判断できる人材育成が必要
- Q&Aでの補足:
- 「相手の目線でなく相手のことを考えながら、あるべきは何かから入る」ことを重視している（松井）
- データモデル入れ替えでの過去データとの整合性は極力移行し、無理な場合はレガシーテーブルとして残すなど落としどころを決めて割り切る（松井）
- 自社の媒体の特殊性がSaaSに合わなかったため自社開発・DOAアプローチを選択した（松井）
- 「美しい世界を作りたい」という動機で取り組み、2〜3年後に自分が作ったシステムを壊して作り直すこともある（松井）
- コミュニティ活動は外の物差しを知るという意味で価値がある（松井）