はじめに
『Data Management at Scale, 2nd Edition』（邦題『大規模データ管理 第2版 ―データ管理と活用のためのモダンなデータアーキテクチャパターン』）を読みました。
著者の Piethein Strengholt 氏は、ABN AMRO 社でチーフデータアーキテクトを務めた後、Microsoft Netherlands 社で最高データ責任者（CDO）として、50 社を超える大企業のデータ変革に関わってきた人物です。本書はその現場経験をベースに、「大規模組織においてデータをどう管理し、どう価値に変えるか」を 12 章かけて体系立てて語った一冊です。
一言でいうと、データメッシュに対する「実務家からの批判的な再構成」 です。データメッシュの思想を否定はしませんが、「大企業でそのまま適用すると壊れる」という立場から、より現実的な設計指針を提示しています。
設計・アーキテクチャに関心のあるエンジニアにとっては、ドメイン駆動設計（DDD）、CQRS、API 設計、イベント駆動アーキテクチャ（EDA）といった馴染みのある道具立てが、エンタープライズ規模のデータランドスケープにどうスケールするかという観点で再解釈されていく点が面白いところです。
書誌情報
| 項目 | 内容 |
|---|---|
| 原題 | Data Management at Scale, 2nd Edition |
| 邦題 | 大規模データ管理 第2版 ―データ管理と活用のためのモダンなデータアーキテクチャパターン |
| 著者 | Piethein Strengholt |
| 出版社 | オライリー |
| 構成 | 全 12 章 |
| 想定読者 | CDO / CTO / チーフアーキテクト、データエンジニア、データサイエンティスト、ガバナンス・セキュリティ担当者 |
本書の全体構造
著者は本書の読み方を「ヘリコプターでの飛行」に例えています。
- まず高度を上げ、データ管理・データ戦略・データアーキテクチャを俯瞰する（1〜3 章）
- 高度を下げ、データを提供する側（ソースシステム側）に降りていく（4〜7 章）
- 再び上昇し、ガバナンス・メタデータ・マスターデータという横断領域を巡る（8〜10 章）
- データを消費する側へ飛び、価値化の方法を見る（11 章）
- 最後に、理論を実践に落とし込む（12 章）
この「提供側」と「消費側」を明確に分けて論じる構成が、本書の主張の骨格になっています。
第1部：なぜ今、大規模データ管理なのか（1〜3章）
1章：データ駆動型への旅
1 章は、現状分析と戦略策定にあてられています。
著者は、データランドスケープが断片化していく要因として、クラウド化、SaaS、マイクロサービス、API エコシステム、そしてプライバシー・セキュリティ要求の高まりを挙げます。その結果としてポイントツーポイント連携が増殖し、データ品質とオーナーシップの議論が延々と続く、という現場感のある指摘が続きます。
そのうえで、従来型アーキテクチャの限界が語られます。
- エンタープライズデータウェアハウス（EDW）：唯一の信頼できる情報源を目指したが、中央集権のボトルネックになった
- データレイク：構造化・非構造化データの中央リポジトリを目指したが、同じ問題を抱えた
著者の診断は、技術の限界ではなく 「背後にある中央集権的な考え方」 そのものが問題だ、というものです。中央集権的な管理、オーナーシップ、データモデルによって、データの専門家がビジネスドメインから切り離され、中央チームがすべてのリクエストを捌ききれずボトルネック化する。だからこそ、ドメインチームによる連合型モデルが強力だ、と論を進めます。
ただし本書はここで単純な非中央集権礼賛には向かいません。
連合型の責任分担を実現するなら、まず中央から始める必要がある。
企業レベルで標準を定義し、境界を設定し、専門知識を提供する中央の権威がなければ、権限委譲は混乱を招くだけだ、と釘を刺します。実際に著者は、チームが独自の相互運用性標準やデータモデリング標準を作り始めた結果、ドメイン間でデータを結合できなくなった事例を挙げています。
だから必要なのは データ戦略 である、というのが 1 章の結論です。データ戦略の策定にあたっては、技術トレンドに振り回されず、まずビジネス目標から始めること、「守り」と「攻め」のバランスを決めること、測定可能な KPI とマイルストーンを置くこと、といった具体的なチェックポイントが列挙されています。
1 章で繰り返し出てくるのが「中央集権と非中央集権のバランス」というテーマです。本書全体を貫く問題意識なので、ここは丁寧に読む価値があります。
2章：データドメインを利用したデータの整理
2 章は、DDD とビジネスアーキテクチャの話です。
出発点として、著者は身も蓋もない事実を確認します。アプリケーションはそれぞれ固有のコンテキストを持つため、あるアプリから別のアプリへデータを移すときには必ず変換が要る。ETL だろうと ELT だろうと、仮想だろうと物理だろうと、バッチだろうとリアルタイムだろうと、この「データ統合のジレンマ」からは逃れられない、と。
そのうえで、複雑さを分割する道具として DDD のコンテキスト境界とユビキタス言語を導入し、さらに ビジネスケイパビリティ（企業が何を「できる」か）をドメイン分割の基準に据えます。ここが本書のオリジナリティのひとつで、DDD を「アプリケーション設計の技法」から「エンタープライズの構造化技法」へ引き上げています。
示されるデータドメインの設計原則は、たとえば次のようなものです。
- データは各ドメインで管理・配信される。データ品質もパイプラインもドメインの関心事
- コンテキスト境界は、インスタンス化されたビジネスケイパビリティに対応する
- 1 つのコンテキスト境界は 1 つのチームに属する
- 境界内は密結合でよい。ただし境界を越えるときはインタフェースで分離する
- ドメインデータは、中間システムや仮想化レイヤーを介して配信すべきではない（出所が不明瞭になるため）
- 汎用データサービスにドメインロジックを置かない
Android / モバイル開発でレイヤ分割やモジュール分割をやっている感覚がそのまま通用する原則が多く、設計をやっているエンジニアなら腹落ちしやすい章だと思います。
なお著者は、データメッシュが主張する「単一のデータモデルは存在しない」という立場に明確に反論しています。データを正しくモデル化するには、ビジネス全体で共有される関係を明らかにする必要があり、それを無視すればドメイン間で統合不能なデータが生まれるから、という理由です。
3章：ドメインとテクノロジーアーキテクチャのマッピング
3 章では、問題空間を扱う「ドメイントポロジー」と、解決空間を扱う「ランディングゾーントポロジー」が整理されます。
ドメイントポロジーとして紹介されるのは 7 種類です。
| トポロジー | 特徴 |
|---|---|
| 完全連合型 | データメッシュ的。中央オーケストレーターなし、ピアツーピアでのデータ流通 |
| 統制ドメイン | 中央が一定の統制をかける |
| 部分連合型 | 連合と統制の中間 |
| バリューチェーン整合 | バリューチェーンに沿ってドメインを配置 |
| 粗視化 | 境界を粗く取る |
| 粗視化・部分統制 | 粗い境界＋部分的な中央統制 |
| 中央集権型 | 従来型に近い |
重要なのは、これらは排他的な選択肢ではないという点です。同一組織内で複数のトポロジーを混在させてよく、また最初に選んだトポロジーが最終形になるわけでもない、と著者は述べます。
選択の指針としては、
- 可能な限りきめ細かく境界を設定する（粗すぎるとアプリ間に望ましくない結合が生まれ、再利用性が損なわれる）
- ビジネスケイパビリティや機能上の関心事の境界を越えるなら、分離する
- 小規模・低成熟度の組織では中央集権から始め、将来的に連合型へ進む準備をする
が示されます。最初のデータランディングゾーンは 8〜16 週間で作る、完璧である必要も本番品質である必要もない、という実践的なアドバイスも印象的でした。
第2部：データを提供する側（4〜7章）
4章：データプロダクト管理
本書で最も分量が多く、最も議論的な章です。
まず著者は 「data as a product（プロダクトとしてのデータ）」と「データプロダクト」を明確に区別します。
- data as a product：考え方・マインドセット。データを他人のプロセスの副産物ではなく、自分が責任を持つプロダクトとして扱い、コンシューマをカスタマーとして扱う
- データプロダクト：アーキテクチャ上の構成要素
そして、データメッシュが提唱する「コード・データとメタデータ・インフラをひとまとめにパッケージ化したアーキテクチャ量子」という定義に対して、著者は論理エンティティとしてのデータプロダクトという立場を取ります。物理表現や基盤技術に寄せず、論理的な構成要素として定義せよ、という主張です。
技術的な核として登場するのが CQRS です。書き込み（コマンド）と読み出し（クエリ）を別モデルに分離するというお馴染みのパターンを、データプロダクト＝読み出し最適化されたレプリカとして再解釈します。
CQRS のメリットとして挙げられるのは以下です。
- 書き込みと読み出しで異なる種類のデータベースを使える（コマンド側は ACID、読み出し側は用途特化）
- 片方だけをスケールできる
- ユースケースごとに複数の読み出しモデルを作れる
一方で、2 つのモデルを同期するレイヤーが必要になり、複雑さと遅延が増すというトレードオフも明記されています。
データプロダクトの設計原則は 20 個以上列挙されますが、特に重要と感じたものを挙げます。
- リソース指向・読み出し最適化で設計する
- データプロダクトのデータは不変
- 提供側ドメインのユビキタス言語を使う
- ソースから直接取り込む（中継させない）
- 生データは使わない
- コンシューマに合わせない（特定利用者向けに歪めない）
- 意味的一貫性、不可分性、互換性を保つ
- 履歴化・再配信・上書きの方針を決める
「コンシューマに合わせない」という原則は、データ提供とデータ消費の関心事を厳密に分離するという本書の一貫した主張の表れです。
著者はデータプロダクトの細分化リスクにも触れています。マイクロサービスと同じく、細かすぎて数百カ所からデータを引っ張る羽目になりがちで、それを防ぐには標準の確立と中央組織による監督が要る、という指摘です。
5章：サービスとAPI管理
SOA の歴史（EAI、サービスオーケストレーション、コレオグラフィ、ESB、カノニカルデータモデル）を振り返ったうえで、現代的な API 管理として連合型責任モデル、API ゲートウェイ、プロダクトとしての API、API 契約、ディスカバラビリティが語られます。
ベストプラクティスとして印象に残ったのは次の点です。
- API 戦略をビジネスアーキテクチャと整合させる
- 内部アプリ開発用の API と、他ドメイン連携用の API でガイダンスを分ける（内部は技術的でもよいが、外部提供 API は安定・平易・利用しやすくあるべき）
- 他ドメイン向け API の設計は、データプロダクトの設計と整合させる（背後のデータベースは同一なのだから当然）
- API は自ドメインのユビキタス言語を使い、他ドメインのビジネスロジックを取り込まない
GraphQL や BFF（Backends for Frontends）といったエクスペリエンス API の話も出てきます。
6章：イベントと通知の管理
イベント駆動アーキテクチャの章です。通知と状態転送の違い、メッセージキューとイベントブローカー、イベントストリーミングプラットフォーム、イベントストアといった構成要素が整理されます。
ガイドラインとして提示されるのは以下です。
- イベントは起こったことの記録なので、定義上 不変
- プロデューサーは「少なくとも 1 回」の配信を保証し、コンシューマは「多くても 1 回」に対応する
- 各サービスは特定ドメインからのイベントストリームを所有する
- ドメイン境界を越えるデータ移動では結果整合性を推奨する
- 最初から自動化を意識する。すべてのイベントにスキーマを定義し、契約ファーストで進める
- イベント・通知・クエリ・コマンドを分離し、それぞれに原則を定める
そして著者は釘を刺します。イベントベースのアーキテクチャは複雑なので、組織に大きな価値をもたらす場合にのみ意味がある、と。スピードが求められていない場面でイベント駆動が使われる例を数多く見てきた、という一節は耳が痛いところです。
7章：すべてをまとめる
4〜6 章のパターンを統合する章です。ここで示される整理が非常に有用でした。
| 観点 | データ流通 | アプリケーション統合 |
|---|---|---|
| 目的 | データを利用可能にし、アプリ間で移動させる | アプリケーション（コンポーネント）をつなぐ |
| 管理 | DataOps | DevOps |
| 焦点 | データの管理とオーケストレーション | エンタープライズソフトウェア開発 |
この 2 つを混同すると設計が濁る、というのが著者の主張です。組織変革の話（チームトポロジー、組織計画）もこの章に含まれます。
第3部：横断的な関心事（8〜10章）
8章：データガバナンスとデータセキュリティ
ガバナンスフレームワーク、役割定義、ガバナンス組織、データ契約、そしてデータセキュリティ（信頼境界、データ分類とラベル、データ利用分類、ID プロバイダー）が扱われます。
実装アプローチとしては「まず小さく始めて短期間で成果を上げる」ことが推奨されます。小さなユースケースから始め、各データプロダクトについてオーナーシップを明確にし、並行してデータカタログを作り、メタデータを最初から収集する、という順序です。
そして繰り返されるのが、ガバナンス導入の大部分は技術ではなく組織変革であるという指摘です。
9章：メタデータによるデータの民主化
個人的に最も刺さった章です。
著者は メタレイク（メタデータレイク） ――あらゆる種類のメタデータを保存・管理する統合リポジトリ――の必要性を説きます。エンタープライズメタデータモデル、概念・論理・物理の各データモデル、データリネージ、カタログ、ナレッジグラフといった構成要素が整理されます。
そして、本書全体の主張を一言で表す一節がここにあります。
次世代アーキテクチャは、データメッシュとデータファブリックのハイブリッドである。
データメッシュには「インテリジェンス」が欠けており、ナレッジグラフと機械学習によってデータ間のパターンや関係を発見し、モデリングを支援し、データ品質を高め、自動分類する仕組み――すなわちデータファブリック的な要素――が必要だ、という論旨です。
さらに、消費を促す手段として データマーケットプレイス が提案されます。まず数種類のデータプロダクトから始め、アーキテクチャの成長に合わせて拡張する、という段階的アプローチです。
10章：最新のマスターデータ管理
データメッシュの議論では手薄になりがちな MDM を、正面から扱う章です。
- マスターデータ作成は エンタープライズレベル と ドメインレベル の両方で行える（スコープは重なることもある）
- 実装は最もシンプルな 「レジストリ」スタイル から始めるのが現実的
- スコープを絞る。全社データ統一という落とし穴にはまらず、顧客・契約・組織単位・製品など付加価値の高い対象から始める
- マスター管理する属性は 数百ではなく数十程度 にすべき
- 最終目標は「共存」――改善されたデータが元のソースシステムに戻る状態
「属性は数十程度に絞れ」という具体的な数字が出てくるあたりに、現場感が滲みます。
第4部：データを価値に変える（11〜12章）
11章：データを価値に変える
消費側のアーキテクチャを扱う章で、著者は ドメインデータストア（DDS） という新しいビルディングブロックを提案します。
データプロダクトと DDS の違いは、次のように整理できます。
| 観点 | データプロダクト（提供側） | DDS（消費側） |
|---|---|---|
| 言語 | 提供側ドメインのユビキタス言語を継承 | ユースケースに最適化 |
| 安定性 | 作成後も安定性・互換性を保つ | 必ずしも安定でなくてよい |
| 結合 | アプリケーションから分離 | ユースケースと緊密に結合 |
| 設計方針 | 読み出しやすさ重視 | 要件を最適に満たす構造・形式 |
著者が「消費側で作られたデータもデータプロダクトと呼ぶ」用法に反対するのは、この違いが曖昧になるからです。提供と消費で 2 種類のブループリントを使い、厳密に分離せよというのが結論です。
後半では、BI（セマンティックレイヤー、セルフサービス）と MLOps（プロジェクト開始、実験と記録、データエンジニアリング、モデル運用）が扱われます。バージョン管理・監視・デプロイを手作業でやらないこと、そして データアーキテクトは十分に訓練された経験豊富なソフトウェアエンジニアになる必要がある という主張は、本書の中でも印象的なメッセージでした。
12章：理論の実践
最終章は実装ロードマップです。3 つのフェーズが示されます。
- 戦略フェーズ：戦略的方向性を策定する
- 変換フェーズ：基盤を整備する
- 最適化フェーズ：ケイパビリティを高度化する
中央集権から始めるか非中央集権から始めるかについては、成熟度で判断せよ、と明快です。成熟度が低いなら中央集権から始めてよい。ただし、最終的な目標が非中央集権なら、エンジニアは最初からそれを知っておくべき――そうすればケイパビリティを疎結合に作れ、後で分散化しやすくなる、という指摘は実務的です。
そして、どのケイパビリティを中央に残し、どれを後で分散するかを事前に決めておくことで、将来の政治的対立を避けられる、と続きます。
最後にエンタープライズアーキテクトの役割が語られます。象牙の塔で図を描く人ではなく、ストラテジストであり、熟練したエンジニアであり、管理者であり、意欲的なリーダーである、という新しい像が提示されます。
エンジニアとして持ち帰ったもの
1. 「境界の内側は密結合でいい」という許可
本書が繰り返すのは、境界内では密結合してよく、境界を越えるときだけ分離せよという原則です。これは DDD の基本ですが、エンタープライズのデータランドスケープ全体に同じ原則を適用する、という視点は新鮮でした。
2. CQRS の射程が想像以上に広い
アプリケーション内のパターンだと思っていた CQRS が、組織横断のデータ流通アーキテクチャの基礎理論として使われます。「データプロダクト＝ドメインが公開する読み出し最適化レプリカ」という捉え方は、かなり応用が利きそうです。
3. 提供と消費を分ける、という一貫した規律
データプロダクト（提供）と DDS（消費）を分ける。データ流通（DataOps）とアプリケーション統合（DevOps）を分ける。API も内部用と外部提供用でガイドラインを分ける。関心事を分離する規律が、本書の全編を通じた通奏低音になっています。
4. 「非中央集権化はタダではない」という現実感
データメッシュ系の議論では見落とされがちな、分散化のコスト――標準の欠如による統合不能、人材不足、カルチャー変革の困難さ――が正面から論じられます。中央の権威を最初に立てよ、というのは反直感的ですが説得力があります。
こんな人におすすめ
- 複数チーム・複数システムにまたがるデータ連携の設計に関わっている方
- データメッシュを検討していて、その適用限界を知りたい方
- DDD をアプリケーション設計より上のレイヤーで使うことに関心のある方
- API / イベント / データ流通のパターンを、統一的な視点で整理し直したい方
逆に、特定ツールの実装手順を求める人には向きません。本書はアーキテクチャパターンと組織論の書であり、コードはほとんど出てきません。
また、著者自身が「複雑なトピックが多数あり、コンテキストに大きく左右されるため、ある程度割り切った記述になっている」と断っています。第 1 版が「抽象的すぎる」と批判されたことを受けて第 2 版では実例が大幅に増えたそうですが、それでもなお抽象度は高めです。読み進めるにはある程度の設計経験が要ると感じました。
まとめ
本書の主張を 3 行にまとめると、こうなります。
- 大規模データ管理の本質的な問題は技術ではなく、中央集権的な考え方にある
- しかし完全な非中央集権も機能しない。まず中央で標準と境界を定義してから連合する
- 次世代アーキテクチャは、データメッシュとデータファブリックのハイブリッドである
データメッシュの入門書を読んだあとの「2 冊目」として、あるいは実際に組織へ適用しようとして壁にぶつかったタイミングで読むと、最も価値が出る本だと思います。
著者は本書を、ヘリコプターでの飛行に例えて締めくくっています。神経質になる必要はない、空を飛ぶことは最も安全な旅行方法だ、と。データアーキテクチャの旅は始まったばかりだ、という前向きなメッセージで終わるのも、本書らしいところでした。