この記事は インフォマティカ Advent Calendar 2024 Day25 の記事として書かれています。

はじめに

データマネジメントのエバンジェリストをやっているもりたくです。

本日は、以前解説した「集中 vs 分散、データメッシュ（Data Mesh) とは？」の執筆から2年経過した今、「データメッシュ」が世の中にどのように組み込まれているのか、その実態や実践に活かせるプラクティスについて解説したいと思います。

もしデータメッシュの基礎的な内容を知りたいと思われている場合は、上記の記事をお読みください。

本記事は、「データメッシュの適用って難しいけど、より実践的な適用方法に関するヒントを考えたい」という人に向いています。そのような人の悩みを少しでも緩和できれば嬉しく思います。ただ、内容的に王道というよりは邪道に近いアプローチなので、教科書通りにデータメッシュをやりたいという人には向かない可能性がある点はご留意ください。

データメッシュにまつわる近年のトレンド

データメッシュに関しては、数年前の2022年のデータマネジメントの未来レポートの中で「データメッシュは厳しい現実に直面することになる」と予想されていました。

厳しい現実

それはなぜかというと、提唱されている知識や原則に対して実践的なプラクティスが不足していたからです。セルフサービスでデータプロダクトをメンテナンスしようとしても、開発からデータの選択、パイプラインの構築、アクセス制御の決定、データ品質の監視と管理、といった全ライフサイクルを事業ドメイン側でマネージするのは簡単ではないからです。当時はそれらをサポートするノーコード技術もまだ成熟しておらず、結局エンジニアリングの技術を持ち合わせていないとセルフサービスで運用できない世界であったとも言えます。

そして実際、その厳しい現実として失敗する企業もその後出てきています。Kazuya Iwamiさんの「re:Invent 2024: HelloFreshのデータ革命 - Data Meshから Tardisへの進化」のレポートを読む限り、HelloFreshは以下のような課題に直面したことが報告されています。

• Data Meshの取り組みを始めた後、私たちは結局、データの混乱状態に陥ってしまいました。
• 皆が熱心でしたが、実装のためのプレイブックがありませんでした。私たちはレシピもないまま料理を作ろうとしているような状態で、手探りの状態でした。
• 私たちはData Engineerのみをターゲットにしていました。これは大きな問題でした。というのも、同じボトルネックが続いていたからです。私たちは対象範囲を拡大できていませんでした。
• 私たちは主に、既存のものを分割して各ドメインに与え、人々がその場で学んでいくことを期待するというアプローチを取りました。これは完全な失敗に終わり、状況を改善するどころか、はるかに悪化させてしまいました。

以上のような話から読み取れることは、データメッシュの成功には、以下のような課題を解く必要があるということです。これを解決できないと、データメッシュのコンセプトに共感して推進しても苦労する可能性があるとも言えます。

• 実践方法に関するプラクティス
• Data Enginner以外のLOBに対するサポート
• Pull型だけではなくPush型の学習機会の提供
• セルフサービスを強力に支える技術

以上のようにまとめてみると、「実践に成功している企業はいないのか？」という疑問がわいてくるかもしれません。ただ実はそんなことはありません。Informaticaの2023、2024年の年次イベントであるInformatica Worldでは、多くのデータメッシュの成功事例が報告されています。

輝かしい成功

代表的な事例の一つとして、私が好きなのはブラジルで30年以上の歴史を持つBanco ABC Brazilの事例です。
彼らは規制の厳しい金融業界の中で、データ駆動型の文化を企業内に根付かせることを狙ってデータメッシュのアーキテクチャを採用しています。その実践はトップダウンとボトムアップのアプローチに支えられており、顧客のニーズに合わせた付加価値のある金融商品を提供するという使命、データ戦略を全社的に掲げながら、現場レベルではデータマーケットプレイス、それと連動するデータガバナンス＆カタログ、データ品質、APIやETL/ELTといったあらゆるパターンのデータ統合を支える技術をデータ基盤として実装しています。その結果、従業員の55％がデータを使用して業務を遂行し、データドリブンな意思決定の速度が40%加速し、事業部におけるセルフサービスBIの活用度も従来より400%向上したと言われています。

また世界有数のバイオテック企業の一つであるGileadの事例も私が好きな事例です。
こちらもコーポレート全体でデータドリブンの文化を高めるために、「クラウド、データ、アナリティクスの融合を通じてビジネスパフォーマンスの向上を実現する。信頼できるデータとアナリティクスへのアクセスを迅速かつ効率的に提供し、民主化することで、ビジネスの革新と差別化されたパフォーマンスの達成を可能にする」といった戦略を掲げながら、データメッシュのフレームワークの採用に成功しています。結果として、データプロダクトの数が500以上に増加、データプロダクトの開発スピードも従来の4倍に加速、データに係る間接ユーザーが4500人以上になったとも言われています。

特に彼らが描く以下アーキテクチャは美しく、イベントで登壇した際には多くの喝采を浴びていたのが印象的でした。

以上のように、データメッシュはその実践が簡単ではないとは言え、適切な戦略とプラクティス、現場を支える仕組みと技術を備えることができれば卓越した成果も得られる、ということが読み取れます。

なお、Informaticaはデータメッシュもデータファブリックも両方実現をサポートできますが、Informatica Worldの事例としてはデータメッシュの方が圧倒的に多い印象です。その理由は私見になりますが、Informaticaを採用している場合にはそれだけデータファブリックの実践ができているとも言えてしまうため、データファブリックがイベント内で特別視されていないからかもしれません。一方データメッシュは、戦略的にデータの分散アーキテクチャやその原則を自社のデータ戦略の特徴とするケースが多く、それを自社のデータジャーニーの象徴としてアピールする企業が多いのかもしれません。

日本の事情

また日本ではどうかというと、「データメッシュやりたい！教えて！」の相談が2年前から増加しています。そして相談があった場合、私はデータファブリックとセットで、実践するためのアプローチ方法やテクノロジーを紹介しています。

一方、「これから実践します！実践してみました！」という事例はまだまだ少ないです。この理由は諸説あると思いますが、私としては以下が起因しているのではないかと考えています。

• データ＆AI活用の人気によって、5年前よりはデータマネジメントの存在を知り、取り組む企業が増えてる
• 実際、データマネジメントの部署を作る企業が増えてる
• 一方、データマネジメント成熟度は海外と比較するとまだ低い

ただこの辺の感覚は人によって異なるかもしれません。実際、私がSnowVillageユーザーグループのデタマネ会第8回「DataMeshLT」に参加させていただいた時、NTTデータ大山さんがデータメッシュの実践経験をお話してくれました。従って、私の知らないところで実践事例はじわじわ増えているのかもしれません。

以上のようなトレンドを見聞きして、多くのお客様と会話していった結果、私はデータメッシュのより柔軟で新しい適用方法があるのではないか、と考えるようになりました。前置きは長くなりましたが、以下から少しずつその新たな道について触れていきたいと思います。

データメッシュのあるある課題

そもそもデータメッシュの相談を受ける時、実態として、データメッシュを通じて何を目指したいのか、が不明確なケースが多かったりします。ヒアリングを続けていくと、「データメッシュ、データファブリックって言葉を聞いた」、「なんか凄そう」、「上からやれ！と言われた」といった声を聞くことが多かったです。

データマネジメントのエバンジェリストである私としては、正直、まず興味を持って貰えるだけでも嬉しく感じます。ただ一方で、以下のようなデータの分散管理が必要な課題を見極められていない場合、説明をしても「勉強になりました」という話だけで終わってしまうことが少なくないです。

• 技術のたゆまぬ進歩と採用の難しさ
• データ規制の遵守の複雑化
• クラウドサービス、API接続の増加と多様化
• データの量と種類が年々倍増
• データのRead/Writeの負荷の高まり
• 各事業部のDWHとBIのアーキテクチャの老朽化
• 非機能要件としてスケールが困難なアプリケーション
• LOBにて高まるセルフサービスのニーズ
• 全社的なデータガバナンスの必要性の向上
• 新たなビジネスモデル創出への期待
• 高まる運用コストに対する経営陣からのプレッシャー

データメッシュは手段であり目的ではない

皆さんわかっていると思いますが、データメッシュは手段であり目的ではありません。
まず企業として必要なのは、データ活用の課題、データマネジメント課題の把握になります。データメッシュもデータマネジメントの一部でしかないため、その課題を把握することが第一ステップになります。更に、その課題解決によって企業にどんなビジネスメリットがあるのか、この整理も必要です。

それが明確であれば、前に進むのは簡単になります。データメッシュが会社にとって最適な解なのか、それとも他の一般的なデータマネジメントアプローチを取るべきなのか、が見えてきます。従って、まず伝えたいのは、データメッシュという言葉に踊らされず、　基本となるデータマネジメントとその課題に目を向けて欲しい、ということです。当たり前の話ですが、この当たり前ができてないケースがまだ多い気がします。

他方で、手段としてデータメッシュに目を向けた時、その原則とプラクティス、関連するソリューションは参考になることが多いです。これが、新しいデータメッシュの便利な使い方、新たな道となります。

データメッシュの4原則を分解してベストプラクティスとして扱う

こういうケースが増えています。私が一般的なデータマネジメントの課題の相談にのっていると、データメッシュをプチ紹介したくなるのです。

プチ紹介という意味は、データメッシュの４原則すべてを紹介するのではなく、4原則の内の1つか2つの原則とそのアプローチ方法を紹介することを意味しています。

例えば、「既に各事業部で自由に、AWSやらMSやら、色んなデータウェアハウスが使われています。そんな中、事業部横断でデータが欲しい、というリクエストも増えています。このような時にはどう対処したら良いのか？」というような相談です。この場合、私は Data as a Productという概念を取り入れてはどうか、それを実践するためのデータマーケットプレイス、というわかりやすいアプローチはどうかという紹介をして、前向きに検討してもらう流れになることが多いです。

この体験から私は発想を切り替えるようになりました。結局、データメッシュの4原則を完全に漏れなくやりきるのは簡単ではありません。だったら難しく考えるのは止めて、　「一つ一つの原則を分解して個別のベストプラクティスとして扱い、必要なもののみ必要なときに適用していけ良いのではないか」、という発想です。

（うんちく）データメッシュの4つの原則

ただ、この発想を説明する前にデータメッシュの4つの原則をおさらいしておきましょう。
データメッシュは、主に以下の4つの原則に従うことと定義されています。

No	Principles	規律	概要
1	Domain-oriented decentralized data ownership and architecture	ドメイン別オーナーシップとデータ分散アーキテクチャ	データの所有権を個々の事業ドメインに負わせ、管理の自主性を促進する。データレイクやDWHは各ドメインで好きなものを使う。
2	Data as a product	データのプロダクト化	データは個別のプロダクトとして管理されるべきで、これにより品質や管理の重要性の意識が高まる。
3	Self-serve data infrastructure as a platform	セルフサービス型データプラットフォーム	ビジネスユーザーやアナリストなどが自由にデータにアクセスし、収集、統合、クレンジング、プロダクトとして安全に公開できることを目指す。
4	Federated computational governance	連邦的なデータガバナンス	全社の戦略を決めながらも、各事業ドメインで責任を持って自律した運用ができるよう、最低限のルール下でガバナンスの取れた運用体制を構築する。

この４原則を個別の独立したプラクティスとして捉えることで、新しい視点が見えてきます。

データメッシュの4つのベストプラクティス

例えばもし、データを物理的に一箇所に集めて、中央集権の管理が難しい課題を抱えていたとします。この場合、エンタープライズデータウェアハウス全盛の昔だったら、頑張って無理やりデータを一箇所に集めるしか選択肢がありませんでした。しかし今はそうするのではなくて、事業ドメイン別にデータを分散管理するを選択を受け入れ、データマネジメントすることもできます。

また、データの提供者と消費者が複雑に絡み合っていて、データの活用がうまく推進できない課題を抱えていたとします。この場合、データプロダクトという概念を取り入れて、データの提供者と消費者で責務の分解点を設けて、データマネジメントする解決策を取ることができます。

中央集権の組織ですべてのデータマネジメントをサポートするのが難しい課題を抱えている場合はいかがでしょう。各事業ドメインの中で、責任もって、データ整備をお願いする選択を取ることができ、そのために必要なセルフサービスのデータ基盤を実装することで解決することができます。

最後に、ドメイン横断のデータ活用を活発に推進したい、そんな課題を抱えているとします。この場合、必要最低限のルールだけ決めて、各事業ドメインの自由度を認める連邦型のデータガバナンス、の運用スタイルを選択することができます。

要は、「データメッシュやるぞ！」と気張って４原則をすべて完璧にこなそうと考えるのではなく、普通にデータマネジメントを推進していき、データメッシュのプラクティスの実践が必要そうな課題に直面したら、その時にそれを解決できるベストプラクティスを1つずつ選択していくというアプローチです。

結果、最終的に全部取り入れることになるのではないか、という声もあるかもしれません。しかし、このデータマネジメントの世界における様々な選択肢の提供こそが、データメッシュの新たな魅力、とも言えるんじゃないか、と最近感じています。　原則と言われるとカタいイメージですが、個別のベストプラクティスであれば簡単に採用できそうな気がしてきます。

実際、冒頭で紹介したBanco ABC BrazilやGileadの事例講演の中では、特に「原則が・・・」とかそういう説明はありませんでした。セルフサービスの基盤要件や、データプロダクトの必要要件等に関する説明はあったものの、ドメイン別オーナーシップや連邦型データガバナンスなどを取り上げて説明する話は聞きませんでした。

以上より、データメッシュの実践としては邪道かもしれませんが、４つの原則をそれぞれ独立したベストプラクティスとして取り扱うことを、原則から拓く新たな道として本記事で示したいと思います。

データメッシュのベストプラクティスを簡単に実践できるデータマネジメント基盤

この新たな道を採用する上でお薦めのアプローチの一つは、その実践を簡単にする技術を採用し、そこから運用のスキームを学ぶことです。

その観点で、Informaticaのデータマネジメントクラウドはお薦めのソリューションです。ゼロからやると大変だけど、データメッシュの思想が組み込まれたInformaticaを使うと、簡単にDatabricksやSnowflakeを含むマルチクラウドデータ基盤上で、データメッシュが実践できます。

ドメイン別の分散したデータ管理 ＝ マルチクラウド対応のデータマネジメント

ドメイン別に責任を分散したデータ管理を実践したければ、マルチクラウド対応のデータマネジメント・サービスが役に立ちます。

Snowflakeで全事業ドメインの環境を統一、集約できていたら嬉しいけど、ある事業部はAWSのRedshift、海外アメリカではGoogleのBigQuesry、といったように複数のデータレイク、データウェアハウスを使っていたとしても問題ありません。

Informaticaならば、まるでシステムや技術の違いが無いかのように、オンプレミスやマルチクラウドを横断するデータパイプラインの作成や監視、メタデータ管理を同じIFで横断的かつ簡単に管理ができます。

プロダクトとしてのデータ管理 ＝ データマーケットプレイス対応のカタログ

データプロダクトの概念を取り入れた管理を実践したければ、データマーケットプレイス対応のデータカタログが役に立ちます。

リネージュや個人情報の分類、データ品質のオブザーバビリティ、規制などの管理ができる、エキスパート向けのデータガバナンス対応カタログはもちろん必要です。しかし、それだけでなく、LOBなども含むビジネスユーザーのサポートとして、厳選されたデータプロダクトのみを公開し、利用申請のワークフロー管理などを兼ね備えた、ビジネスユーザー向けの、データマーケットプレイスを提供することが重要です。

この仕組みを使えば、自然と通常のデータとデータプロダクトを区別して管理し、安全な共有管理まで実践することが可能です。

セルフサービスのデータ基盤 ＝ ローコードノーコードで実現するデータ整備

プログラミングのできない事業部の人たちに、セルフサービスでデータ整備をお願いしたければ、ローコードノーコードに対応しているデータエンジニアリングのソリューションが役に立ちます。

例えば、SAPやSnowflakeからSnowflakeやDatabricksなどのレイクハウスにデータを取り込みたければ、このGIFイメージのように、接続先、使用するプロトコル、対象スキーマ、テーブルのネーミングルールを指定するだけで、レプリケーションが実現できます。特に、スキーマドリフトにも対応しているため、元のテーブルの変更も自動的に受け入れることが可能です。

更に、それらのレイクハウス上でデータ変換、ELTをしたければ、GUIの操作で部品を組合せてデータ変換も簡単に実現できます。特に、実行時には各レイクハウス上で稼働するSQLを自動生成して実行できるため、各レイクハウスの高速なコンピューティングリソースを使った高性能な処理も合わせて実現できます。

以上のように、あらゆるデータマネジメントの作業を、すべてローコードノーコードで非エンジニアにも任せられるデータマネジメント基盤が、セルフサービスの実現には重要になります。

連邦型のデータガバナンス　＝ 分析軸を統一するデータ品質、マスタデータ管理

最後に、連邦型のデータガバナンス。これは何をすべきか一つのソリューションで解決できない難しいプラクティスですが、データ品質とマスタデータ管理はその解決に寄与する重要なピースとなります。

例えば、各事業ドメインの顧客や取引先マスタがバラバラの場合、各ドメインの顧客データを単に集めるだけでは、同じ顧客が特定できず、ドメイン横断の顧客分析に成功できません。この問題解決には、各マスタのデータ品質フォーマットをクレンジングし、名寄せして関連付けて、各ドメインのトランザクションデータが一つのゴールデンマスターを軸に360°繋がるように整備することが求められます。これは、サプライチェーンを横断する製品やサプライヤーの分析をする上でも同様です。事業横断のデータ活用を成功させるためには、あらゆるデータ、マスタデータに対して同様のアプローチが必要となります。

以上のように、データ品質、マスタデータ管理のアプローチは、事業横断のデータ活用に必須のアプローチであり、連邦型の最低限のガバナンスの中で必ず抑えておきたいポイントになります。

おわりに

本記事では、「データメッシュの適用って難しいけど、より実践的な適用方法に関するヒントを考えたい」についてご紹介しました。

というのも今、データメッシュの個別プラクティスをサポートできる技術が市場に揃ってきています。従って、この技術の力に頼りながら、必要なときに必要なデータメッシュの原則を、気軽にデータマネジメントに組み込んでいくのはいかがでしょうか。

やや邪道なアプローチになるかもしれませんが、一つの現実解として何かしらお役に立てるヒントを提供できていれば幸いです。

最後までお読みいただき、ありがとうございました。