【テンプレあり】英語データメッシュ設計書の書き方｜ITプロジェクトで使える日英フォーマット付き

データ基盤を一元管理するアーキテクチャの限界に気づいているが、英語でデータメッシュをどう設計書に書けばいいかわからない。ドメイン分散型のデータ管理をグローバルチームに説明しようとすると、用語や概念が伝わらず議論が止まる。そんな経験を持つエンジニアは多い。

データメッシュ（Data Mesh）は、データを中央集権型の基盤ではなく、ビジネスドメインごとに分散管理するアーキテクチャパターンだ。英語で設計書を書くことで、組織横断のデータプロダクトオーナーやアーキテクトと設計方針を共有しやすくなる。

この記事では、英語データメッシュ設計書を4つのセクションで構成する方法を解説する。日英テンプレートをそのまま流用できる。

英語で設計書を作成することで、データエンジニアリング・プラットフォームエンジニアリング・ビジネスドメインのステークホルダー全員が同じ設計方針を理解できるようになる。

データメッシュ設計書を英語で書く理由
Section 1：Domain Ownership & Scope（ドメイン所有権とスコープ）
1. ドメイン定義の書き方
2. 役割定義
Section 2：Data Product Design（データプロダクト設計）
1. データプロダクトの定義
Section 3：Self-Serve Data Infrastructure（セルフサービスデータインフラ）
1. セルフサービスプラットフォームの構成要素
Section 4：Federated Governance（連邦ガバナンス）
1. ガバナンス組織の書き方
テンプレートをダウンロード（Word）
日本語版テンプレート（コピペOK）
英語版テンプレート（コピペOK）
まとめ：英語データメッシュ設計書は4つのセクションで完成する

データメッシュ設計書を英語で書く理由

データメッシュ設計書を英語で作成する目的は、分散データ基盤の設計方針をドメインをまたいで統一することだ。

日本語のみの設計書では、海外拠点のデータエンジニアや外部パートナーがデータプロダクトの仕様・所有者・品質基準を把握できない。結果として、同じデータを複数のチームが独自に作成し、一貫性が失われる。

英語で書く主なメリットは3つある。

ドメイン間の設計整合：各ドメインのデータプロダクトの仕様が統一されたフォーマットで共有される
データプロダクトの発見性向上：英語のカタログを通じて、全社のデータ資産を検索・利用できる
ガバナンスの標準化：品質基準・SLA・セキュリティポリシーがグローバルに統一される

データメッシュ設計書は4つのセクションで構成する。次のセクションから順に解説する。

Section 1：Domain Ownership & Scope（ドメイン所有権とスコープ）

最初のセクションでは、データメッシュのドメイン分割方針と各ドメインの責任範囲を定義する。

ドメインの境界が不明確だと、データの所有権を巡る議論が頻発する。ドメイン定義を明文化することで、誰がどのデータプロダクトに責任を持つかが明確になる。

ドメイン定義の書き方

データメッシュのドメインは、ビジネス領域に対応させて分割する。

ドメイン	英語表現	所有チーム	主なデータ資産
顧客ドメイン	Customer Domain	CRMチーム	顧客プロファイル・行動履歴
商品ドメイン	Product Domain	カタログチーム	商品情報・在庫・価格
注文ドメイン	Order Domain	ECチーム	注文・決済・配送
マーケティングドメイン	Marketing Domain	マーケチーム	キャンペーン・広告・コンバージョン
分析ドメイン	Analytics Domain	データチーム	横断分析・レポート

英語テンプレート：

## Domain Ownership

### Domain Definition

| Domain | Owner Team | Key Data Assets | Consumers |
|--------|-----------|----------------|-----------|
| Customer | CRM Team | Customer profiles, behavioral history | Marketing, Analytics |
| Product | Catalog Team | Product info, inventory, pricing | Order, Analytics |
| Order | E-Commerce Team | Orders, payments, shipping | Finance, Analytics |
| Marketing | Marketing Team | Campaigns, ads, conversions | Analytics, Product |
| Analytics | Data Team | Cross-domain analytics, dashboards | All domains |

### Domain Principles
1. Domain teams own their data end-to-end — from ingestion to serving.
2. No cross-domain direct database access; use published Data Products only.
3. Each domain is responsible for the quality and availability of its data.
4. Data Products must meet the federated governance standards.

日本語テンプレート：

## ドメイン所有権

### ドメイン定義

ドメイン | 所有チーム | 主なデータ資産 | 利用ドメイン
--------|-----------|-------------|------------
顧客 | CRMチーム | 顧客プロファイル・行動履歴 | マーケティング・分析
商品 | カタログチーム | 商品情報・在庫・価格 | 注文・分析
注文 | ECチーム | 注文・決済・配送 | 財務・分析
マーケティング | マーケチーム | キャンペーン・広告・コンバージョン | 分析・商品
分析 | データチーム | 横断分析・ダッシュボード | 全ドメイン

### ドメイン原則
1. ドメインチームはデータを取り込みから提供までエンドツーエンドで所有する。
2. ドメイン間の直接DBアクセスは禁止。公開されたデータプロダクトのみを使用する。
3. 各ドメインは自分のデータの品質と可用性に責任を持つ。
4. データプロダクトは連邦ガバナンス標準を満たす必要がある。

役割定義

役割	英語表現	責任
データプロダクトオーナー	Data Product Owner	データプロダクトのビジョン・優先度・品質最終責任
データエンジニア	Data Engineer	パイプライン設計・実装・保守
ドメインアーキテクト	Domain Architect	ドメイン内のデータアーキテクチャ設計
プラットフォームエンジニア	Platform Engineer	セルフサービスインフラの構築・維持
データスチュワード	Data Steward	データ品質・メタデータ・分類管理

Section 2：Data Product Design（データプロダクト設計）

2つ目のセクションでは、各ドメインが公開するデータプロダクトの仕様を定義する。

データメッシュの中核はデータプロダクトだ。単なるデータセットではなく、利用者がそのまま使えるプロダクトとして設計することで、データの再利用性と品質が向上する。

データプロダクトの定義

優れたデータプロダクトは5つの特性（DIMAP）を持つ。

特性	英語表現	意味
発見可能	Discoverable	データカタログで検索・発見できる
アドレス可能	Addressable	一意なURIでアクセスできる
自己記述的	Self-describing	スキーマ・SLA・オーナーが明記されている
相互運用可能	Interoperable	標準フォーマット（Parquet・JSON・Avro）に準拠している
信頼できる	Trustworthy	SLAと品質基準を継続的に満たしている

英語テンプレート：

## Data Product Specification

### Data Product: Customer 360 Profile

| Attribute | Value |
|-----------|-------|
| Product Name | Customer 360 Profile |
| Domain | Customer |
| Owner | CRM Team (Data Product Owner: [Name]) |
| URI | dp://customer/customer-360-profile/v1 |
| Output Port | BigQuery: `project.customer.customer_360_profile` |
| Update Frequency | Daily (06:00 UTC) |
| SLA (Freshness) | Data available by 07:00 UTC |
| SLA (Availability) | 99.5% |
| SLA (Accuracy) | < 0.1% null rate on key fields |

### Schema

| Column | Type | Description | PII |
|--------|------|-------------|-----|
| customer_id | STRING | Unique customer identifier | No |
| email_hash | STRING | SHA-256 hashed email | Yes (hashed) |
| country_code | STRING | ISO 3166-1 alpha-2 country code | No |
| segment | STRING | Customer segment (Premium/Standard/Trial) | No |
| last_purchase_date | DATE | Most recent purchase date | No |
| lifetime_value_usd | FLOAT | Estimated LTV in USD | No |

### Input Sources
- CRM system (Salesforce) — via CDC
- Order service — via event stream (Kafka)
- Marketing platform — via daily batch

### Consumers
- Marketing Domain (campaign targeting)
- Analytics Domain (customer reporting)
- Product Domain (personalization)

日本語テンプレート：

## データプロダクト仕様書

### データプロダクト名：顧客360プロファイル

項目 | 内容
----|----
プロダクト名 | 顧客360プロファイル
ドメイン | 顧客
オーナー | CRMチーム（データプロダクトオーナー：[氏名]）
URI | dp://customer/customer-360-profile/v1
出力ポート | BigQuery: project.customer.customer_360_profile
更新頻度 | 毎日（06:00 UTC）
SLA（鮮度） | 07:00 UTCまでにデータを利用可能にする
SLA（可用性） | 99.5%
SLA（精度） | 主要フィールドのnull率 0.1%未満

### スキーマ

カラム | 型 | 説明 | PII
------|----|----|----
customer_id | STRING | 顧客の一意識別子 | なし
email_hash | STRING | SHA-256ハッシュ化メール | あり（ハッシュ化済み）
country_code | STRING | ISO 3166-1 alpha-2国コード | なし
segment | STRING | 顧客セグメント（Premium/Standard/Trial） | なし
last_purchase_date | DATE | 最終購入日 | なし
lifetime_value_usd | FLOAT | 推定LTV（USD） | なし

### 入力ソース
- CRMシステム（Salesforce）— CDC経由
- 注文サービス — イベントストリーム（Kafka）経由
- マーケティングプラットフォーム — 日次バッチ経由

クラウドセキュリティとデータメッシュを組み合わせる場合、データプロダクトへのアクセス制御はIAM設計と連動させる必要がある。英語クラウドセキュリティ設計書の書き方も合わせて参照してほしい。

Section 3：Self-Serve Data Infrastructure（セルフサービスデータインフラ）

3つ目のセクションでは、ドメインチームが自律的にデータプロダクトを構築・運用できるプラットフォームの設計を定義する。

中央集権型の基盤では、プラットフォームチームがボトルネックになりやすい。セルフサービスインフラを整備することで、ドメインチームがプラットフォームチームを介さずにデータプロダクトをデプロイ・管理できる状態を作る。

セルフサービスプラットフォームの構成要素

コンポーネント	英語表現	目的	ツール例
データカタログ	Data Catalog	データプロダクトの発見・検索	Dataplex・DataHub・Alation
パイプラインテンプレート	Pipeline Templates	標準パイプラインの迅速な構築	dbt・Apache Beam・Dataflow
データ品質フレームワーク	Data Quality Framework	品質チェックの自動化	Great Expectations・dbt tests
監視・アラート	Monitoring & Alerting	SLA違反の早期検知	Looker・Grafana・PagerDuty
アクセス管理	Access Management	列・行レベルのアクセス制御	BigQuery IAM・Apache Ranger
メタデータ管理	Metadata Management	スキーマ・系譜・オーナー情報の管理	OpenLineage・Amundsen

英語テンプレート：

## Self-Serve Data Infrastructure

### Platform Capabilities

| Capability | Tool | Responsibility |
|-----------|------|---------------|
| Data Catalog | Google Dataplex | Platform Team |
| Pipeline Templates | dbt Cloud | Platform Team (templates), Domain Team (implementation) |
| Data Quality | Great Expectations | Domain Team (rules), Platform Team (runtime) |
| Monitoring | Grafana + PagerDuty | Platform Team |
| Access Control | BigQuery IAM + Column-level security | Platform Team (policy), Domain Team (request) |
| Lineage Tracking | OpenLineage | Platform Team |

### Data Product Deployment Process
1. Domain team picks a pipeline template from the internal catalog.
2. Team configures source, transformations, and output port.
3. Automated quality checks run in CI/CD pipeline.
4. Data Product is registered in the Data Catalog automatically.
5. Consumers discover and subscribe via the catalog.

### Service Level for Platform Team

| Service | SLA |
|---------|-----|
| Data Catalog availability | 99.9% |
| Pipeline template provisioning | < 1 business day |
| Access request fulfillment | < 4 hours |
| Incident response (P1) | < 30 min |

日本語テンプレート：

## セルフサービスデータインフラ

### プラットフォーム機能

機能 | ツール | 責任者
----|--------|------
データカタログ | Google Dataplex | プラットフォームチーム
パイプラインテンプレート | dbt Cloud | プラットフォームチーム（テンプレート）・ドメインチーム（実装）
データ品質 | Great Expectations | ドメインチーム（ルール）・プラットフォームチーム（実行環境）
監視 | Grafana + PagerDuty | プラットフォームチーム
アクセス制御 | BigQuery IAM + 列レベルセキュリティ | プラットフォームチーム（ポリシー）・ドメインチーム（申請）
系譜追跡 | OpenLineage | プラットフォームチーム

### データプロダクトのデプロイフロー
1. ドメインチームが内部カタログからパイプラインテンプレートを選択する。
2. ソース・変換ロジック・出力ポートを設定する。
3. CI/CDパイプラインで自動品質チェックが実行される。
4. データプロダクトがデータカタログに自動登録される。
5. 利用者がカタログ経由でデータプロダクトを発見・利用する。

Section 4：Federated Governance（連邦ガバナンス）

4つ目のセクションでは、分散したドメインを横断する統一的なガバナンス方針を定義する。

データメッシュの分散性を維持しながら、データ品質・セキュリティ・コンプライアンスを組織全体で統一するために、連邦ガバナンスが必要だ。中央集権型ではなく「標準を決める組織」として機能する。

ガバナンス組織の書き方

組織	英語表現	構成	責任
データメッシュ推進委員会	Data Mesh Council	各ドメインのデータプロダクトオーナー	標準策定・ポリシー決定
データアーキテクトグループ	Data Architect Guild	各ドメインのアーキテクト	技術標準の設計・レビュー
セキュリティワーキンググループ	Security Working Group	セキュリティ・コンプライアンス担当	アクセス制御・規制対応

英語テンプレート：

## Federated Governance

### Governance Model
Data Mesh uses a federated governance model:
- Standards are set centrally by the Data Mesh Council.
- Implementation is the responsibility of each domain team.
- Compliance is enforced automatically via platform guardrails.

### Global Data Standards

| Standard | Requirement | Enforcement |
|---------|------------|-------------|
| Data format | Parquet (batch), Avro (streaming) | CI/CD validation |
| Schema versioning | Semantic versioning (v1, v2...) | Catalog registry |
| PII classification | Tag all PII columns in schema | Automated scanner |
| Encryption at rest | AES-256 via CMEK | Platform default |
| Retention policy | Defined per data classification | Automated lifecycle |
| SLA definition | Freshness + Availability + Accuracy | Published in catalog |

### Data Quality Standards

| Dimension | Minimum Threshold | Measurement |
|-----------|------------------|-------------|
| Completeness | > 99% non-null on key fields | Great Expectations |
| Accuracy | < 0.1% anomaly rate | Statistical sampling |
| Freshness | Within SLA window | Catalog metadata |
| Uniqueness | 0 duplicate primary keys | dbt tests |

### Compliance & Privacy

| Regulation | Requirement | Domain Responsibility |
|-----------|------------|----------------------|
| GDPR | Right to erasure for EU PII | Customer Domain |
| CCPA | Opt-out for CA residents | Customer Domain |
| PCI DSS | Card data must not be stored unencrypted | Order Domain |
| Internal policy | All PII must be hashed or tokenized in non-prod | All Domains |

日本語テンプレート：

## 連邦ガバナンス

### ガバナンスモデル
データメッシュは連邦ガバナンスモデルを採用する。
- 標準はデータメッシュ推進委員会が中央で策定する。
- 実装は各ドメインチームが責任を持つ。
- コンプライアンスはプラットフォームのガードレールで自動強制される。

### グローバルデータ標準

標準 | 要件 | 強制方法
----|------|--------
データフォーマット | Parquet（バッチ）・Avro（ストリーミング） | CI/CDバリデーション
スキーマバージョン管理 | セマンティックバージョニング（v1・v2...） | カタログレジストリ
PII分類 | スキーマ内のPIIカラムにタグ付け必須 | 自動スキャナー
保存時の暗号化 | CMEKによるAES-256 | プラットフォームデフォルト
保持ポリシー | データ分類ごとに定義 | 自動ライフサイクル管理
SLA定義 | 鮮度・可用性・精度 | カタログに公開

### データ品質基準

次元 | 最低閾値 | 測定方法
----|---------|--------
完全性 | 主要フィールドのnon-null率 > 99% | Great Expectations
精度 | 異常率 0.1%未満 | 統計サンプリング
鮮度 | SLAウィンドウ内 | カタログメタデータ
一意性 | 主キーの重複 0件 | dbtテスト

プロダクトエンジニアリングの観点からデータプロダクトのロードマップを設計する場合は、英語プロダクトエンジニアリング計画書の書き方と組み合わせることで、データ開発の優先度をビジネス目標と整合させられる。

テンプレートをダウンロード（Word）

以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。

📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)

日本語版テンプレート（コピペOK）

【英語データメッシュ設計書】

組織名：
作成日：
作成者：
アーキテクチャパターン：データメッシュ（ドメイン分散型）

■ 1. ドメイン所有権とスコープ
ドメイン | 所有チーム | 主なデータ資産 | 利用ドメイン
--------|-----------|-------------|------------
顧客 |  |  |
商品 |  |  |
注文 |  |  |
マーケティング |  |  |
分析 |  |  |

役割 | 担当者 | 責任
----|--------|----
データプロダクトオーナー |  | ビジョン・優先度・品質責任
データエンジニア |  | パイプライン設計・実装
ドメインアーキテクト |  | データアーキテクチャ設計
プラットフォームエンジニア |  | セルフサービスインフラ構築

■ 2. データプロダクト仕様
プロダクト名：
ドメイン：
URI：
出力ポート：
更新頻度：
SLA（鮮度）：
SLA（可用性）：

スキーマ
カラム | 型 | 説明 | PII
------|----|----|----

入力ソース：
利用ドメイン：

■ 3. セルフサービスインフラ
機能 | ツール | 責任者
----|--------|------
データカタログ |  |
パイプラインテンプレート |  |
データ品質 |  |
監視 |  |
アクセス制御 |  |

■ 4. 連邦ガバナンス
グローバルデータ標準
標準 | 要件 | 強制方法
----|------|--------
データフォーマット | Parquet / Avro |
PII分類 | タグ付け必須 |
保存時の暗号化 | AES-256 |
SLA定義 | 鮮度・可用性・精度 |

データ品質基準
次元 | 閾値 | 測定方法
----|------|--------
完全性 | > 99% |
精度 | < 0.1%異常率 |
鮮度 | SLA内 |
一意性 | 重複0件 |

英語版テンプレート（コピペOK）

[Data Mesh Design Document]

Organization:
Date:
Author:
Architecture Pattern: Data Mesh (Domain-Oriented, Distributed)

■ 1. Domain Ownership & Scope
Domain | Owner Team | Key Data Assets | Consumers
-------|-----------|----------------|----------
Customer |  |  |
Product |  |  |
Order |  |  |
Marketing |  |  |
Analytics |  |  |

Role | Assignee | Responsibility
-----|----------|---------------
Data Product Owner |  | Vision, priority, quality accountability
Data Engineer |  | Pipeline design and implementation
Domain Architect |  | Data architecture within domain
Platform Engineer |  | Self-serve infrastructure

■ 2. Data Product Specification
Product Name:
Domain:
URI:
Output Port:
Update Frequency:
SLA (Freshness):
SLA (Availability):

Schema
Column | Type | Description | PII
-------|------|-------------|----

Input Sources:
Consumers:

■ 3. Self-Serve Infrastructure
Capability | Tool | Owner
----------|------|------
Data Catalog |  |
Pipeline Templates |  |
Data Quality |  |
Monitoring |  |
Access Control |  |

■ 4. Federated Governance
Global Data Standards
Standard | Requirement | Enforcement
---------|------------|------------
Data format | Parquet / Avro |
PII classification | Tag required |
Encryption at rest | AES-256 |
SLA definition | Freshness + Availability + Accuracy |

Data Quality Standards
Dimension | Threshold | Measurement
---------|-----------|------------
Completeness | > 99% |
Accuracy | < 0.1% anomaly |
Freshness | Within SLA |
Uniqueness | 0 duplicates |

データメッシュの設計方針を定めた後は、英語データパイプライン運用術を参照することで、ドメインをまたいだパイプライン障害やスキーマ変更を英語で適切に伝えられる。