データ基盤の現在地 - L0 カリキュラム

ストーリー

田

田中VPoE

今月のテーマは「データウェアハウス全体を設計しよう」だ。組織のデータは複数のシステムに散在し、「同じ指標なのに数字が違う」問題が頻発している。この状況をどう思う？

あなた

実際にうちのチームでも、売上の数字がマーケティング部門と経理部門で異なっていて、会議のたびに「どの数字が正しいのか」議論になっています

あ

田

田中VPoE

その問題の根本原因は、データの「信頼できる唯一の情報源（Single Source of Truth）」が存在しないことだ。各部門がそれぞれのスプレッドシートやデータベースから独自に集計するため、定義の違い、集計タイミングの違い、フィルタ条件の違いで数字がずれる

あなた

なるほど。データウェアハウスを設計すれば、全社で統一された指標を提供できるようになるんですね

あ

田

田中VPoE

そうだ。ただし、データウェアハウスは単なる「大きなデータベース」ではない。データ戦略、アーキテクチャ設計、データ品質管理、ガバナンスを含む包括的なデータ基盤だ。今月はその全体像を設計してもらう

「同じ指標なのに数字が違う」問題

よくある原因

原因	例	影響
定義の不一致	「アクティブユーザー」の定義がチームごとに異なる	DAUが部門ごとに違う数字になる
集計タイミングの違い	リアルタイム集計 vs 日次バッチ集計	同じ日の売上が一致しない
フィルタ条件の違い	テストアカウントの除外基準が統一されていない	ユーザー数が合わない
データソースの違い	アプリDB vs ログ分析 vs 外部ツール	同じイベントの件数が異なる
通貨・タイムゾーン	JSTとUTCが混在	日付境界でデータがずれる

ビジネスへの影響

データの不整合が引き起こす問題:

1. 意思決定の遅延
   ├── 会議のたびに「どの数字が正しいか」議論
   ├── データの検証に時間がかかる
   └── 最終的に「感覚」で判断される

2. 信頼性の低下
   ├── データチームへの不信感
   ├── 各部門が独自のデータパイプラインを構築（シャドーIT）
   └── データ民主化の阻害

3. コストの増大
   ├── 重複するデータパイプラインの運用コスト
   ├── 手動データ突合の人件費
   └── 誤った意思決定による機会損失

「データの問題は技術の問題ではなく、組織の問題だ。技術で解決するには、まず組織がデータをどう扱うべきかの戦略が必要になる」 — 田中VPoE

データ基盤の進化

世代別の変遷

世代	時代	アーキテクチャ	特徴
第1世代	1990年代	データウェアハウス（DWH）	ETL、スタースキーマ、OLAP
第2世代	2010年代前半	データレイク	Hadoop、スキーマオンリード、非構造化データ
第3世代	2010年代後半	クラウドDWH	BigQuery、Snowflake、Redshift
第4世代	2020年代	レイクハウス / Data Mesh	Delta Lake、Iceberg、分散型所有権

モダンデータスタックの全体像

モダンデータスタック:

データソース                    取り込み            変換              配信
┌──────────────┐        ┌──────────┐      ┌──────────┐     ┌──────────────┐
│ SaaS (CRM等)  │──┐     │ Fivetran │      │ dbt      │     │ BIツール      │
│ アプリDB       │──┼────→│ Airbyte  │─────→│ Spark    │────→│ ダッシュボード  │
│ ログ/イベント   │──┤     │ CDC      │      │ SQL      │     │ MLパイプライン  │
│ 外部API        │──┘     └──────────┘      └──────────┘     │ リバースETL    │
                                  │                           └──────────────┘
                         ┌────────┴────────┐
                         │  データレイク /    │
                         │  ウェアハウス      │
                         │  (S3, BigQuery,   │
                         │   Snowflake)      │
                         └─────────────────┘
                                  │
                    ┌─────────────┼──────────────┐
                    │             │              │
              ┌──────────┐ ┌──────────┐  ┌──────────────┐
              │ データ品質  │ │ カタログ  │  │ リネージ      │
              │ Great     │ │ DataHub  │  │ OpenLineage  │
              │ Expectations│ │         │  │              │
              └──────────┘ └──────────┘  └──────────────┘

データの信頼性を測る5つの柱

柱	説明	メトリクス例
鮮度（Freshness）	データが最新であるか	最終更新からの経過時間
正確性（Accuracy）	データが正しいか	異常値の割合、整合性チェック通過率
完全性（Completeness）	欠損がないか	NULL率、レコード数の期待値との乖離
一貫性（Consistency）	複数ソース間で整合しているか	クロスチェック一致率
一意性（Uniqueness）	重複がないか	重複レコード数

Month 7のロードマップ

Step	テーマ	得られる成果
1	データ戦略とアーキテクチャを理解しよう	データ戦略、アーキテクチャパターン、Data Mesh、Medallion
2	データレイクとウェアハウスを設計しよう	レイク/DWH/レイクハウス設計、ディメンショナルモデリング
3	ストリーム処理とリアルタイム分析を設計しよう	ストリーム処理、CDC、リアルタイム分析基盤
4	データ品質とガバナンスを確立しよう	品質フレームワーク、リネージ、カタログ、オブザーバビリティ
5	MLOpsとフィーチャーストアを設計しよう	MLOpsパイプライン、フィーチャーストア
6	データウェアハウスを完成させよう	全社データ基盤設計書

「データは21世紀の石油と言われるが、精製されていない石油は使えない。データウェアハウスは、生データを経営判断に使える情報に精製する工場だ」 — 田中VPoE

まとめ

ポイント	内容
データの課題	「同じ指標なのに数字が違う」問題は、Single Source of Truthの欠如が原因
データ基盤の進化	DWH → データレイク → クラウドDWH → レイクハウス/Data Mesh
データの信頼性	鮮度・正確性・完全性・一貫性・一意性の5つの柱で計測する
Month 7の目標	全社で活用できるデータ基盤を設計し、データの信頼性を確保する

チェックリスト

「同じ指標なのに数字が違う」問題の根本原因を説明できる
データ基盤の世代別の進化を理解した
モダンデータスタックの全体像を把握した
Month 7のロードマップを理解した

次のステップへ

次は「データ戦略の策定」を学びます。組織のビジネス目標に紐づいたデータ戦略をどう策定するか、そのフレームワークを身につけましょう。

推定読了時間: 15分