データプロダクトの設計と構築

データプロダクトのアーキテクチャ

データプロダクトの構成要素

[データプロダクト]
├── インプットポート
│   └── ソースデータの取り込み
├── 変換ロジック
│   └── ビジネスロジックの適用
├── アウトプットポート
│   ├── テーブル/ビュー（SQL分析用）
│   ├── API（アプリケーション用）
│   └── イベントストリーム（リアルタイム用）
├── メタデータ
│   ├── スキーマ定義
│   ├── ビジネス説明
│   └── SLA
├── 品質管理
│   ├── データテスト
│   ├── モニタリング
│   └── アラート
└── ディスカバリ
    └── カタログ登録情報

データプロダクトの例：顧客セグメント

name: customer_segments
domain: marketing
version: "1.2.0"
description: |
  顧客を購買行動に基づいて5つのセグメントに分類したデータプロダクト。
  RFM分析（Recency, Frequency, Monetary）をベースにしている。

input:
  - source: orders-domain/daily_orders
  - source: customer-domain/customer_profiles

output:
  tables:
    - name: customer_segment_current
      description: "最新の顧客セグメント"
      update_frequency: "daily"
    - name: customer_segment_history
      description: "セグメント変遷の履歴"
      update_frequency: "daily"
  api:
    - endpoint: /api/v1/customer-segments/{customer_id}
      description: "特定顧客のセグメント取得"

schema:
  customer_segment_current:
    - customer_id: STRING (PK)
    - segment: ENUM(VIP, LOYAL, REGULAR, AT_RISK, DORMANT)
    - rfm_score: INTEGER
    - last_purchase_date: DATE
    - total_purchases: INTEGER
    - total_amount: DECIMAL
    - updated_at: TIMESTAMP

quality:
  tests:
    - "customer_id is unique"
    - "segment is not null"
    - "rfm_score between 1 and 125"
  sla:
    freshness: "毎日AM8:00までに更新"
    completeness: ">= 99.5%"

データプロダクトの設計原則

1. 消費者ファースト

データプロダクトは消費者のユースケースを起点に設計します。

悪い例：「注文テーブルをそのまま公開する」
良い例：「マーケティングが顧客セグメント分析に使いやすい形に加工して提供する」

消費者のニーズを理解するために：

• データ消費者へのインタビュー
• 現在の分析依頼の傾向分析
• ペインポイントの特定

2. 不変性とバージョニング

データプロダクトのスキーマは後方互換性を保ちます。

バージョニングルール：

v1.0.0 → v1.0.1：バグ修正（パッチ）
v1.0.0 → v1.1.0：カラム追加（マイナー、後方互換）
v1.0.0 → v2.0.0：破壊的変更（メジャー、移行期間を設ける）

破壊的変更が必要な場合：

1. 新バージョンを並行して公開
2. 消費者に移行期間を通知（最低30日）
3. 全消費者が移行完了後に旧バージョンを廃止

3. 自己記述性

データプロダクトは自分自身を説明できる必要があります。

• スキーマの全カラムに説明が付与されている
• ビジネス用語との紐付けが明確
• データの生成ロジックがドキュメント化されている
• 利用例とクエリサンプルが提供されている

4. 品質の組み込み

品質管理はデータプロダクトの一部として組み込みます。

品質チェックの自動化例：

[データ取り込み]
    ↓
[スキーマバリデーション] → 失敗時アラート
    ↓
[データ品質テスト]
  ├── NULL率チェック
  ├── ユニーク性チェック
  ├── 値域チェック
  └── レコード数の異常検知 → 失敗時アラート
    ↓
[品質スコアの算出・記録]
    ↓
[公開]

データプロダクトの開発フロー

1. ディスカバリ（発見）

• 消費者のニーズをヒアリング
• 既存データの棚卸し
• データプロダクトの候補を特定

2. 設計

• スキーマの設計
• SLAの定義
• インターフェース契約の策定
• 消費者とのレビュー

3. 構築

• データパイプラインの実装
• データテストの実装
• モニタリングの設定
• カタログへの登録

4. 運用

• 品質の継続的な監視
• 消費者からのフィードバック収集
• スキーマの進化管理
• パフォーマンスの最適化

データプロダクトのテンプレート

プラットフォームチームが提供する標準テンプレート：

data-product-template/
├── dbt/
│   ├── models/
│   │   ├── staging/          # ソースデータの取り込み
│   │   ├── intermediate/     # 中間処理
│   │   └── marts/            # 公開データ
│   ├── tests/                # データテスト
│   └── schema.yml            # スキーマ定義
├── monitoring/
│   ├── alerts.yml            # アラート設定
│   └── dashboards/           # 運用ダッシュボード
├── docs/
│   ├── README.md             # データプロダクトの説明
│   ├── sla.md                # SLA定義
│   └── examples/             # 利用例
├── catalog/
│   └── metadata.yml          # カタログ登録情報
└── ci/
    └── pipeline.yml          # CI/CDパイプライン

まとめ

チェックリスト

• データプロダクトの構成要素を説明できる
• 4つの設計原則を理解している
• バージョニングルールを説明できる
• データプロダクトの開発フローを理解している

次のステップへ

データプロダクトの設計と構築を学びました。次は、フェデレーテッドガバナンスの設計方法を学びましょう。

推定読了時間：30分