ケーススタディ：データアーキテクチャ

実務シナリオ + アーキテクチャ設計 — Specialist試験対策

Case 1: データプラットフォームのアーキテクチャ選択

背景

急成長するフィンテック企業（DAU: 300万人）。初期はRDB（MySQL）とBIツール（Tableau）の組み合わせで運用していたが、以下の問題が発生：

日次のデータ集計で本番DBに負荷がかかり、サービス品質が劣化
ユーザー行動ログが1日2TBで増加中。RDBでは保管コストが急増
リアルタイムの不正検知要件が新たに追加
データサイエンスチームがMLモデルのトレーニング用にデータへのアクセスを要求

アーキテクチャ進化の検討

Option 1: Data Warehouse（従来型）

ソース → ETL → DWH（Snowflake/BigQuery）→ BI

メリット: 構造化データの分析に最適、SQL利用者が多い組織に馴染むデメリット: 非構造化データ（ログ、画像）の扱いが困難。ML用途に不向き

Option 2: Data Lake

ソース → [Data Lake（S3/GCS）] → Spark → ML / Adhoc分析
                                 ↓
                             BI（クエリが遅い）

Schema-on-Read：データを書き込む時にスキーマを定義せず、読む時に決めるメリット: あらゆる形式のデータを低コストで保管。MLに最適デメリット: 品質管理が困難（「データスワンプ」化しやすい）。BI用途に遅い

Option 3: Data Lakehouse（採用）

ソース → [Data Lake（S3）]
              ↓ Delta Lake / Iceberg でトランザクション保証
         [Lakehouse Layer]
              ├── [BI Layer]（Databricks SQL / Redshift Spectrum）
              ├── [ML Layer]（Spark / MLflow）
              └── [Streaming Layer]（Kafka + Spark Streaming）

採用理由:

非構造化データ（ログ）と構造化データを統一基盤で管理
リアルタイム不正検知はStreaming Layerで対応
MLトレーニングはLake側のデータに直接アクセス
BIはLakehouse Layer（DWH的な機能）から高速クエリ

Case 2: Data Mesh への移行

背景

大手メディア企業（事業部門数：12部門、データエンジニア：4名）。中央集権型データチームがボトルネック：

データリクエストのバックログが常時80件以上
ビジネス部門がデータを使うまでに平均6週間待ち
中央チームがすべてのドメインを理解できない

Data Mesh の4原則（Specialist試験で出題）

原則1: Domain Ownership（ドメインオーナーシップ）

データは生成したドメインチームが所有・管理
例: ECチームはEC関連データを、広告チームは広告データを管理

原則2: Data as a Product（データをプロダクトとして扱う）

従来: データはETLの副産物
Mesh: データはプロダクト（消費者のためのUI/APIを持つ）

Data Product の特性（DAMA補足）:
  □ Discoverable（発見可能）← データカタログで検索可能
  □ Addressable（参照可能）← 一意のURIを持つ
  □ Trustworthy（信頼可能）← SLAとDQ保証
  □ Self-describing（自己記述）← メタデータと文書化
  □ Interoperable（相互運用可能）← 標準フォーマット
  □ Secure（セキュア）← アクセス制御

原則3: Self-serve Data Platform（セルフサービスプラットフォーム）

各ドメインが独立してデータプロダクトを構築・運用できる基盤
インフラ・デプロイ・監視・カタログ登録を自動化

原則4: Federated Computational Governance（連邦型計算ガバナンス）

各ドメインが自律的だが、グローバル標準は守る
例: データフォーマット標準、セキュリティポリシー、インターオペラビリティ仕様

Data Mesh vs 従来型 DWH の選択基準

状況	推奨
小〜中規模、ドメインが少ない	従来型DWH
データドメインが多く、各ドメインに開発力がある	Data Mesh
中央チームがボトルネックになっている	Data Mesh を検討
データの整合性・一貫性が最重要	従来型DWH（Data MeshはFederated故に難しい）

Case 3: エンタープライズデータモデル（EDM）の設計

EDMとは何か

定義: 組織全体の概念・論理データモデル。すべてのデータ資産の「地図」。

EDM の構造:

Enterprise Data Model
  │
  ├── Subject Area 1: Customer Management
  │     ├── Customer (Entity)
  │     ├── Address (Entity)  
  │     └── Contact (Entity)
  │
  ├── Subject Area 2: Product Management
  │     ├── Product (Entity)
  │     ├── ProductCategory (Entity)
  │     └── Pricing (Entity)
  │
  └── Subject Area 3: Financial
        ├── Account (Entity)
        ├── Transaction (Entity)
        └── Invoice (Entity)

EDMがないとどうなるか（実務の失敗例）

問題1: 「顧客」の定義が部門ごとに異なる

営業部門: 「見込み客も顧客」
請求部門: 「支払い実績のある法人のみ顧客」
マーケ部門: 「メールを受信している全員が顧客」

→ 同じ「顧客数」レポートで数字が3倍異なる

問題2: システム間のデータ連携に毎回一から設計

A-Bシステム連携、A-Cシステム連携…とN×(N-1)/2 個の変換ロジック
EDMがあれば、各システムがEDMに準拠するだけで連携が簡単に

EDMの段階的構築

Phase 1: 主要エンティティの特定（概念レベル）
  → 部門横断ワークショップで「会社の主要なモノ」を特定
  → 成果物: Entity-Relationship図（20〜50エンティティ）

Phase 2: 定義の合意
  → Business Glossaryへの登録（Business Stewardが担当）
  → 各エンティティのオーナー（Data Steward）の任命

Phase 3: 論理モデルへの展開
  → 属性・データ型・制約の定義
  → ビジネスルールの明示

Phase 4: 物理実装への参照
  → 各システム開発がEDMを参照してDB設計
  → EDMとの乖離をガバナンスプロセスで管理

Case 4: TOGAF × DAMA の組み合わせ

TOGAFの4ドメインとデータアーキテクチャの位置付け

ドメイン	内容	DAMAとの関係
Business Architecture	ビジネスプロセス・組織	Business Glossary / Data Governance
Data Architecture	データエンティティ・フロー	EDM / Data Lineage（DAMA主管）
Application Architecture	アプリケーション・連携	Data Integration Architecture
Technology Architecture	インフラ・プラットフォーム	Data Storage / Database選定

実務での使い方

TOGAFは「アーキテクチャフレームワーク」、DAMAは「データ管理知識体系」。実務では両方を使い、TOGAFのADM（Architecture Development Method）の中でDAMAのプラクティスを適用する。

ADM フェーズ × データ管理:

Phase A: Architecture Vision（全体ビジョン）
  → データ戦略の方向性

Phase B: Business Architecture
  → ビジネスプロセスとデータの関係

Phase C: Information Systems Architecture
  Data Architecture部分:
    → EDMの構築
    → データリネージの定義
    → セキュリティ要件

Phase D: Technology Architecture
  → DWHプラットフォーム選定
  → データベース技術の選定

アーキテクチャ判断の頻出シナリオ

シナリオ1: Lambda Architecture vs Kappa Architecture

Lambda（バッチ + ストリーム）:

ソース
  ├──→ [Batch Layer]（正確・遅い）→ [Serving Layer]
  └──→ [Speed Layer]（近似・速い）→ ↗

問題: 2つのレイヤーで同じロジックを実装（メンテナンス負荷）

Kappa（ストリームのみ）:

ソース → [Stream Processing（Kafka + Flink）] → [Serving Layer]

利点: 単一のコードベース。ストリームでバッチも処理可能（再生機能）問題: ストリーム処理の複雑なビジネスロジックが難しい

選択基準:

「過去データの再処理が頻繁」→ Kappa（ストリームの再生）
「バッチ処理の正確性が最重要」→ Lambda
「運用シンプルさ優先」→ Kappa

シナリオ2: Hub-and-Spoke vs Point-to-Point

接続数の計算（試験で出る）:

N個のシステムを接続する場合
Point-to-Point: N×(N-1)/2 個の接続
Hub-and-Spoke（ESB/APIゲートウェイ経由）: N個の接続

例：10システムの場合

P2P: 45接続（管理不能）
Hub: 10接続

→ システム数が4以上ならHub-and-Spokeが有利（試験頻出の判断基準）