データメッシュの進め方：中央チームの「依頼待ち」を、1つのドメインに責任を渡すところから崩す

社内のデータチームは5人。各部署から集計やデータ抽出の依頼が月に60件届き、着手まで3週間待ってもらうのが当たり前になっています。営業からは「先月の数字の定義が違う」と差し戻され、物流からは「その項目は去年から意味が変わっている」と指摘されます。そんな折、役員が講演で聞いてきた言葉を持ち帰りました。「うちもデータメッシュでいこう」。DX推進の担当者が営業部長に話を持っていくと、「データの面倒まで、うちに押しつける気か」と返されます。

データメッシュを、ツールを入れる話として受け取ると失敗します。中身は、データの責任を誰が持つかの組み替えです。いきなり全社で組み替えれば、こうした反発で止まります。だから小さく始めます。1つの部署に、1つのデータの責任を渡すところからです。

早見表：いま始めてよいか、まだ早いか

3行目の会社がいきなり分散させても、品質の低いデータが部署ごとに増えるだけです。中央でテストを回した経験のない組織が、同じことを各部署に求めても回るはずがありません。テストの組み方はdbt testsの実践、データ活用の推進体制そのものはデータ活用推進の進め方に書いています。

4つの原則を、会社で決めることに翻訳する

データメッシュは、Zhamak Dehghani 氏が2019年に martinfowler.com の記事で示し、2020年の続編で4つの原則として整理した考え方です。原則の名前だけを並べても動けないので、会社で決めることに置き換えます。

この順番は崩せません。1行目で「誰が持つか」が決まらなければ、2行目の約束をする人がいませんし、3行目の土台が無ければ、部署は約束を守る手段を持てないからです。

ドメインの境界は、「その数字が間違っていたら誰が直すか」で引く

ドメインとは、業務として一貫した領域のことで、組織図と一致するとは限りません。では、どう引くか。境界を引くときは、部署名から考えるより、データの項目ごとに次の2つを聞きます。

「この数字の意味をいちばんよく知っているのは誰ですか」「この数字が間違っていたとき、直すのは誰ですか」。

結果を表にすると、境界が見えます。

返品のように直す人が決まらない項目は、この時点で経営やDX推進が裁きます。放っておくと、どうなるか。間違いが見つかるたびに、部署どうしの押し付け合いが始まります。

顧客のように、同じ言葉が部署によって違う意味で使われるのは珍しくありません。営業にとっての顧客は取引先の会社と担当者、物流にとっては届け先、サポートにとっては問い合わせてきた人です。これを無理に1つの「全社顧客マスタ」へ寄せると、どの部署にとっても使いにくい表ができあがります。まず各ドメインが自分の意味の顧客を持ちます。部署をまたいで使う分だけを、別に組み立てます。

Dehghani 氏は2019年の記事で、データの発生元に沿ったドメインのデータ（source-aligned）と、使う側の用途に沿ったデータ（consumer-aligned）を分けて論じています。上の表でいえば、受注や出荷は発生元に沿ったデータ、部署をまたいで顧客をまとめたものは使う側に沿ったデータです。dbtの層に当てはめるなら、前者は中間の層、後者は最終の層に近くなります。層の分け方はdbtの3層構造とメダリオンアーキテクチャを参照してください。

データプロダクトは、利用者への約束を1枚に書く

ドメインが持つデータを「製品」として出すとは、利用者に約束をすることです。テーブルを公開しただけでは、製品と呼べません。受注ドメインが最初に出す製品を例に、約束の1枚を書くと次のようになります。

この1枚は、Dehghani 氏が挙げるデータプロダクトの性質（見つけられる、場所が決まっている、信頼できる、意味が自分で説明されている、全社の標準に沿っている、アクセスが管理されている）を、社内の言葉に置き換えたものです。数字は記入例です。自社の業務に合わせて決めてください。

約束には監視が要ります。更新時刻は鮮度の監視に、品質はdbtのテストに、見つけ方はカタログにつなぎ、約束が破られたら担当者に通知が届くようにしておきます。品質の仕組みはデータ品質ツールの選定、カタログはカタログツールの選定に書いています。

全社の決まりは少なく決め、守らせ方は仕組みに組み込む

任せるにも限度があります。個人情報の扱いや、他部署が使う表の壊し方まで、部署の自由にはできません。全社で守る決まりは、どの部署にも同じ意味がある少数に絞ります。そのうえで、人が目で確認するのでなく、仕組みが自動で止めるようにします。

dbt なら、こう書きます。受注ドメインが他部署に出す表に、契約と公開範囲を付けた例です。

groups:
  - name: order
    owner:
      name: 営業管理課
      email: order-data@example.co.jp

models:
  - name: fct_order_lines
    config:
      group: order
      access: public
      contract:
        enforced: true
    columns:
      - name: order_line_id
        data_type: int
        constraints:
          - type: not_null
      - name: amount
        data_type: numeric

部署ごとに dbt のプロジェクトを分け、他のプロジェクトの公開モデルを参照する機能もあります。ただし公式ドキュメントでは、これは dbt の Enterprise か Enterprise+ のプランで使える機能です（2026年10月17日参照）。1つのプロジェクトの中でグループを分けるだけなら、プランを問わずに始められます。

全社の決まりを決める会議は、各ドメインの責任者、中央チーム、情報セキュリティの担当で構成します。最初の会議では、上の表の4つ程度で足ります。欲張らないことです。決まりを足すたびに「これはどの仕組みで守らせるか」を同時に決め、守らせ方が無い決まりは足しません。

中央チームの仕事は「作る」から「作れる土台を配る」へ変わる

データメッシュにしても、中央チームは無くなりません。変わるのは仕事の中身です。

中央チームのメンバーにとっては、自分で作る仕事が減り、教える仕事と仕組みを整える仕事が増えるという、職種が変わるほどの変化になります。この変化を歓迎しない人もいます。役割の変更は、評価の項目と合わせて伝えます。共通の土台にするDWHの選び方はクラウドDWH入門、指標の定義を全社でそろえる仕組みはセマンティックレイヤーを参照してください。

依頼待ちの費用を、人件費で見る

経営への説明には、いまの手戻りの費用を使います。ここは数字で見せます。中央チームの5人がそれぞれ年収800万円とすると、会社の総コストは給与の約3倍で1人年2,400万円、年1,900時間で割った時給はおよそ12,600円です。

しかもこれは中央チームの側だけの費用です。3週間待たされる業務部署の損失は、入っていません。数字は説明のための例なので、自社の件数と年収に置き換えてください。最初のドメインに渡すデータは、この手戻りがいちばん多いものを選ぶと、効果が数字で見えます。

最初の6か月は、1つのドメインで回す

全社一斉は止まります。1つ目のドメインがうまく回れば、その部署の責任者が、次の部署を説得する役を引き受けてくれます。冒頭の営業部長のような反応には、最初から全員を説得しようとせず、1つ目の成功を見せて応えるほうが早く届きます。

よくある質問（FAQ）

データメッシュとデータレイクハウスは、どう違いますか?

層が違います。レイクハウスはデータをどう保存して処理するかという技術の構成、データメッシュは誰がデータの責任を持つかという組織の決め方です。同じ会社で両方を採ることもでき、レイクハウスを共通の土台として中央が用意し、その上で各ドメインが製品を出す形になります。

各部署に Snowflake や dbt を配れば、データメッシュになりますか?

なりません。道具を配っただけでは、品質の低いデータが部署ごとに増え、費用も増えます。変えるべきは、どのデータを誰が持ち、利用者に何を約束するかのほうで、道具はその約束を守るための手段として中央が配るものです。

中央のデータチームは、解体するのですか?

しません。中央チームは、共通のDWH・dbtのひな形・テストやカタログの仕組みを用意し、ドメインが自分でデータを作れる状態を保つ役に変わります。全社の決まりを仕組みに組み込むのも中央です。

ドメインはいくつに分ければよいですか?

最初は数を決めず、手戻りの多いデータを持つドメインを1つ決めれば足ります。聞き取りで「意味に詳しい人」と「直す責任を持てる人」が同じ部署にそろうところから切り出します。境界は後から変えられますが、変えるたびに所有者と約束の書き直しが要るので、1つ目を回してから広げるほうが手戻りは少なく済みます。

業務部署に、データを扱える人がいません。

責任だけを渡すと、失敗します。まず、その部署の業務に詳しい人を1人選び、本業から割く時間を決めたうえで、中央チームがdbtのひな形とテストの書き方を教えます。中央のメンバーが一時的にその部署を兼務する形でも構いません。並走は、担当者が自分でモデルを直せるようになるまで続けます。

出典

• martinfowler.com: How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh（Zhamak Dehghani）（2026-10-17 参照：2019年5月20日公開であること、発生元に沿ったデータと使う側に沿ったデータの区別、データプロダクトの性質（Discoverable・Addressable 等6項目））
• martinfowler.com: Data Mesh Principles and Logical Architecture（Zhamak Dehghani）（2026-10-17 参照：2020年12月3日公開であること、4原則の正式な名称、federated computational governance の意味）
• dbt Docs: Model contracts（2026-10-17 参照：contract の enforced: true で列名と型を定義し、合わなければモデルが作られないこと）
• dbt Docs: Model access（2026-10-17 参照：group と access（private/protected/public）、private を別グループから参照すると解析時にエラーになること、YAMLの書き方）
• dbt Docs: Model versions（2026-10-17 参照：versions と latest_version、deprecation_date による廃止の扱い）
• dbt Docs: Project dependencies（2026-10-17 参照：プロジェクトをまたぐ参照が dbt Enterprise / Enterprise+ プランの機能であること）
• Snowflake Documentation: Tag-based masking policies（2026-10-17 参照：タグに基づくマスキングと、Enterprise Edition が必要なこと）

中央チームへの依頼が積み上がり、営業や物流からは差し戻しが続く。その状態から、最初に責任を渡すドメインとデータを1つ選ぶところまで、壁打ちにどうぞ。初回相談（30分・無料）で一緒に整理できます。