LASSIC Media らしくメディア
データメッシュ(Data Mesh)導入を外注で進める
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- データメッシュ提唱者Zhamak Dehghani氏の原典に基づき、中央集権型データ基盤が抱える構造上の限界と、データメッシュが示す4つの原則を整理します。
- データメッシュはツール導入ではなく組織のオーナーシップ移管を伴う取り組みであることを説明し、小さく始める進め方を示します。
- データカタログ・MDM・データ契約との関係を整理したうえで、外注に委託できる範囲と発注前に社内で準備すべき事項をまとめます。
目次
データメッシュとは——中央集権型データ基盤が限界を迎えた背景
データメッシュ(Data Mesh)とは、企業内の分析用データの所有と提供を、単一の中央データチームに集約するのではなく、データを生み出す事業ドメインごとに分散させる組織・アーキテクチャの考え方を指します*1。データウェアハウスやデータレイクに代表される中央集権型基盤の限界を克服する目的で、ThoughtWorksのZhamak Dehghani氏が2019年に提唱しました*1。
Dehghani氏はThoughtWorksの技術系メディアで、既存の中央集権型データプラットフォームについて「絶えず失敗を繰り返すETLジョブと、迷路のように複雑化し続けるデータパイプライン」という状況が生じていると指摘しました*1。中央のデータエンジニアリングチームは、データを生み出す事業ドメインの業務理解を十分に持たないまま大量のデータソースを引き受けることになり、データを提供する側にも質の高いデータを整備する動機が働きにくいという問題です*2。
結果として、データを利用したい事業側チームは中央チームへの依頼を待つ形になり、応答までのリードタイムが延びやすい構造が生まれます*2。データソースの数や利用目的が増えるほど、中央集権型の体制は対応しきれなくなるというのが、データメッシュが提示する課題認識です*1。
分散所有・製品化・セルフサーブ・連合ガバナンス——4原則の中身
Dehghani氏は2020年の論考で、データメッシュを構成する4つの原則を整理しています*3。第一に「ドメイン指向の分散データ所有とアーキテクチャ」です。分析用データの所有と提供責任を、それを生み出す事業ドメインのチームに委ねる考え方です*3。
第二に「プロダクトとしてのデータ（Data as a Product）」です。各ドメインが提供するデータを内部の副産物ではなく、他チームが使う「製品」として扱う考え方です*2。ThoughtWorksの論考では、製品として満たすべき特性として、データを見つけられること（発見可能性）、共通の命名規則で一意にアクセスできること（アドレス可能性）、データの正確さについて許容可能なサービスレベル目標を持つこと、スキーマや意味が自己説明的であること、相互運用のための標準に従うこと、アクセス制御が統一されていることの6点が挙げられています*2。
第三に「セルフサーブ型のデータ基盤（プラットフォームとして提供）」です。各ドメインが同じようなデータ基盤機能を個別に作り直す重複を避けるため、ドメインに依存しない共通機能をプラットフォームとして抽出し、ドメインチームが自分たちで使える形にする考え方です*2。ThoughtWorksの論考では、この基盤整備の成否を測る指標として「新しいデータ製品を作るまでのリードタイムの短縮」が挙げられています*2。
第四に「連合型計算ガバナンス（Federated Computational Governance）」です。データ製品ごとの自律性を保ちながら、相互運用性のための標準を組織横断で合意し、可能な範囲で自動化して適用する考え方です*2。ThoughtWorksの論考は、異なるドメインで扱う共通の概念（例として「アーティスト」という識別子）を統一的に扱えるようにすることが、ドメイン間でデータを相関させるための基盤になると説明しています*2。
技術だけでは実現しない——組織のオーナーシップ移管という論点
データメッシュの4原則を読むと、技術基盤の話に見えるかもしれません。しかし核心にあるのは、データの所有権と説明責任を中央のデータチームから事業ドメイン側へ移すという組織上の変更です*3。Dehghani氏は分析データの所有と提供のあり方について、事業ドメインの区分を尊重すべきだと述べています*3。
この移管には失敗コストがあります。ドメインチームにデータ所有権を渡しても、データエンジニアリングのスキルやデータ品質に対する責任意識が伴わなければ、品質の低いデータが分散して増えるだけの結果になりかねません。国内の実務者による分析でも、データメッシュを実現するには各事業部門の内部に相応のデータエンジニアリング人材を配置する必要がある点が、日本企業にとっての導入障壁として指摘されています*4。
内製でこの体制を構築する場合に必要になるのは、ドメインごとのデータプロダクトオーナーの任命、データエンジニアリングスキルを持つ人材の各ドメインへの配置、そして共通基盤チームとドメインチームの役割分担の設計です。これらを並行して進めるには、データ基盤の技術知識と組織設計の両方の経験が求められます。
専門家との差分が表れやすいのはこの組織設計の部分です。技術基盤だけを外部に発注し、ドメイン側の役割分担や評価指標を曖昧なままにすると、共通基盤は整っても実際にデータを製品として提供する動きが定着しない状態に陥りやすくなります。技術支援と組織設計の両輪を意識した進め方が必要です。
小さく始める進め方も現実的な選択肢です。全社一斉の移行ではなく、優先度の高い一つの事業ドメインを選び、そのドメインでデータ製品化とセルフサーブ基盤の利用を試したうえで、得られた知見を他ドメインへ広げる段階的な進め方が、ThoughtWorksの論考でも前提として置かれています*2。
データカタログ・MDM・データ契約との関係——構成要素としての位置づけ
データメッシュは、既存のデータ管理施策を置き換えるものではなく、それらを組織的な枠組みの中に位置づけ直す考え方です。データカタログ、マスタデータ管理（MDM）、データ契約は、いずれもデータメッシュを実現するうえでの構成要素になり得ます。
データカタログは、各ドメインが提供するデータ製品を「発見可能」にするための仕組みとして機能します。ドメインごとにデータが分散していても、カタログを通じて全社から検索・参照できる状態を保つ必要があるためです*2。
MDMは、顧客や商品といった複数ドメインにまたがる共通概念の識別子を統一する役割を担います。連合型計算ガバナンスが目指す「ドメイン間でデータを相関させる」ためには、共通の識別子体系が前提になります*2。
データ契約は、ドメインが提供するデータ製品のスキーマや品質保証をプロデューサとコンシューマの間で明文化する仕組みであり、データ製品の信頼性という原則を具体化する手段の一つに位置づけられます。データメッシュは思想・組織原則の集合であり、データカタログ・MDM・データ契約はその実装を支える個別の技術要素という関係にあります。
外注する場合の委託範囲と発注前に詰めておくこと
データメッシュ導入を外注で進める場合、委託先に依頼できる範囲は主に技術基盤の構築と、組織設計を支援するファシリテーションの二つに分かれます。技術基盤側では、セルフサーブ型のデータ基盤の設計・構築、データカタログやアクセス制御の仕組みの整備、ドメイン間の連携を支える共通コンポーネントの実装が委託範囲になります。
組織設計側では、対象ドメインの選定支援、データプロダクトオーナーの役割定義、ガバナンス標準の合意形成プロセスの設計といった支援が委託範囲になります。ただし、実際に誰がデータの所有者になるか、各ドメインにどれだけの人員を配置するかという意思決定そのものは、発注元の経営・事業部門が担う事項です。
| 準備事項 | 発注前に整理しておく内容 |
|---|---|
| 対象ドメインの選定 | 全社一斉ではなく、最初に着手する事業ドメインを一つ決めておきます。データ量・利用頻度・関係者数から優先度を検討します。 |
| データ所有権の当事者 | 選定したドメインで、データ製品の説明責任を負う担当者・部署を仮でも決めておきます。決まっていないと外注先の設計が進みません。 |
| 既存データ基盤の棚卸し | 現行のデータウェアハウス・データレイク・ETL資産を洗い出し、どこまで再利用しどこから作り直すかの前提を共有します。 |
| 成功指標の仮設定 | 新しいデータ製品を作るまでのリードタイムなど、基盤整備の効果を測る指標を仮でも用意しておきます*2。 |
失敗コストの面では、対象ドメインの選定とデータ所有権の当事者が未確定のまま外注を開始すると、要件のすり合わせが繰り返され、当初の想定より長い期間を要する事態につながりやすくなります。技術基盤の設計に着手する前に、この二点だけは発注元側で仮決めしておくことが、外注先との認識合わせを円滑にします。
まとめ——データメッシュ導入判断の3つの軸
本稿ではデータメッシュの背景・4原則・組織面の論点・外注時の委託範囲を整理しました。要点を3つに集約すると次の通りです。第一に、データメッシュは中央集権型データ基盤の限界を背景に、分散所有・製品化・セルフサーブ基盤・連合ガバナンスという4原則で構成される考え方だという点です*1*3。第二に、技術基盤の整備だけでなく、データの所有権を事業ドメインへ移す組織設計が伴わなければ定着しないという点です*3。第三に、外注では技術基盤構築と組織設計支援の両輪を委託できますが、対象ドメインの選定とデータ所有権の当事者決定は発注元が担う事項だという点です。
よくある質問
データメッシュとデータファブリックは何が違いますか。
データメッシュは組織のデータ所有権をドメインごとに分散させる思想・組織原則を指すのに対し、データファブリックは異なるデータソースを統合的に扱うための技術アーキテクチャを指す概念として語られることが多く、両者は焦点の置き所が異なります。本稿ではDehghani氏が提唱した組織原則としてのデータメッシュを扱っています*1*3。
データメッシュは小規模な組織でも導入できますか。
事業ドメインの数が少なく、データを利用するチームが限られる組織では、分散所有による調整コストの削減効果が相対的に小さくなります。ThoughtWorksの論考も、複数ドメインが並行してデータを生成・利用する規模の組織を主な対象として想定しています*2。自社の事業ドメイン構成を踏まえて要否を検討することが大切です。
データメッシュの導入にはどのくらいの期間がかかりますか。
全社の事業ドメイン数や既存データ基盤の複雑さによって幅があり、一律の期間を示す公表データは確認できていません。ThoughtWorksの論考が示す段階的な進め方に沿えば、まず一つの事業ドメインでデータ製品化とセルフサーブ基盤の利用を試し、そこで得た知見をもとに他ドメインへの展開期間を見積もる進め方が現実的です*2。
外注先に技術基盤だけを任せれば導入は進みますか。
技術基盤の構築だけでは、データの所有権や説明責任を事業ドメイン側に移す組織上の変更が伴わないため、基盤は整っても実際の運用が定着しにくくなります*3。技術支援に加えて、対象ドメインの選定やデータプロダクトオーナーの役割定義といった組織設計の支援を合わせて依頼することが望まれます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Zhamak Dehghani「How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh」ThoughtWorks Insights（2019年）https://martinfowler.com/articles/data-monolith-to-mesh.html
- *2 出典：同上（各原則の詳細説明部分）
- *3 出典：Zhamak Dehghani「Data Mesh Principles and Logical Architecture」martinfowler.com（2020年）https://martinfowler.com/articles/data-mesh-principles.html
- *4 出典：大川真輝「データメッシュという『幻想』の正体──現場のアーキテクトが警鐘を鳴らす理由」note（実務者による分析記事・参考情報として付記）https://note.com/masaki_ohkawa/n/ndcff989cf0ab
