Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

データメッシュ内のアーキテクチャと機能

Last reviewed 2024-09-03 UTC

データメッシュは、データをプロダクト（このドキュメントでは「データプロダクト」と呼びます）として扱うアーキテクチャおよび組織フレームワークです。このフレームワークでは、データを完全に理解し、組織全体の一連のデータガバナンス基準に従うチームによって、データプロダクトが開発されます。データプロダクトがデータメッシュにデプロイされると、組織内の分散チームは、ニーズに関連するデータを迅速かつ効率的に検出してアクセスできます。このようなデータメッシュを適切に機能させるには、まずこのドキュメントで説明するアーキテクチャコンポーネントと組織のロールの概要を理解する必要があります。

このドキュメントは、 Google Cloudでデータメッシュを実装する方法を説明するシリーズの一部です。ここでは、 Google Cloudで最新の分散データメッシュを構築するで説明するコンセプトをお読みになり、理解されていることを前提としています。

このシリーズは、次のパートから構成されています。

このシリーズでは、説明するデータメッシュは組織内部にあります。データメッシュアーキテクチャを拡張してデータプロダクトを社外に提供することは可能ですが、そのような拡張的な手法についてはこのドキュメントでは説明しません。データメッシュを拡張する場合は、組織内での使用だけでなく、その他の考慮事項も考慮する必要があります。

アーキテクチャ

このシリーズで説明するアーキテクチャコンポーネントを定義する際は、次の重要な用語を使用します。

データプロダクト: データプロダクトは、1 つ以上の関連データリソースの論理コンテナまたはグループです。
データリソース: データリソースは、構造化データを保持するストレージシステム内の物理アセット、または構造化データを生成するクエリを保存する物理アセットです。
データ属性: データ属性は、データリソースのフィールドまたは要素です。

次の図は、 Google Cloudに実装されたデータメッシュの主なアーキテクチャコンポーネントの概要を示しています。

データメッシュのアーキテクチャコンポーネント。

上の図は、次のことを示しています。

セントラルサービスを使用すると、データメッシュ参加者に影響を与える組織のポリシー、（Identity and Access Management グループによる）アクセス制御、インフラストラクチャ固有のアーティファクトなどのデータプロダクトの作成と管理が可能になります。このようなコミットメントと予約、データメッシュの機能を容易にするインフラストラクチャについては、プラットフォームコンポーネントとソリューションを作成するをご覧ください。
セントラルサービスは、Knowledge Catalog を使用して、データメッシュ内のすべてのデータプロダクトに Data Catalog を提供し、これらのプロダクトの潜在的なコンシューマーに対して検出メカニズムを提供します。
データドメインは明確に定義されたデータ消費インターフェースを通じて、データのサブセットをデータプロダクトとして公開します。これらのデータプロダクトにはテーブル、ビュー、構造化ファイル、トピック、ストリームなどがあります。BigQuery ではデータセット、Cloud Storage ではフォルダまたはバケットになります。データプロダクトとして公開できるさまざま種類のインターフェースが存在します。インターフェースの例として、BigQuery テーブルの BigQuery ビューがあります。分析目的で最も一般的に使用されるインターフェースの種類については、データメッシュでデータプロダクトを構築するをご覧ください。

データメッシュのリファレンス実装

このアーキテクチャのリファレンス実装は、data-mesh-demo リポジトリにあります。リファレンス実装で使用されている Terraform スクリプトは、データメッシュのコンセプトを示していますが、本番環境での使用は想定していません。これらのスクリプトを実行すると、次のことができるようになります。

プロダクトの定義と基礎となるデータを分離する。
プロダクトのインターフェースを記述するための Data Catalog テンプレートを作成する。
これらのテンプレートを使って、プロダクトのインターフェースにタグ付けする。
プロダクトの消費者に権限を付与する。

プロダクトのインターフェースについては、リファレンス実装では、次のインターフェースタイプを作成して使用します。

BigQuery テーブルの承認済みビュー。
Pub/Sub トピックに基づくデータストリーム。

詳細については、リポジトリの README ファイルをご覧ください。

データメッシュの機能

データメッシュを適切に動作させるには、データメッシュ内でタスクを実行するユーザーに明確なロールを定義する必要があります。所有権はチームのアーキタイプまたは関数に割り当てられます。これらの機能は、データメッシュで作業するユーザーのコアユーザージャーニーを保持します。ユーザージャーニーを明確に説明するために、ユーザーロールに割り当てられています。これらのユーザーロールは各企業の状況に応じて分割または結合できます。組織内の従業員やチームに直接ロールをマッピングする必要はありません。

データドメインはビジネスユニット（BU）または企業内の機能と連携します。ビジネスドメインの一般的な例としては、銀行の住宅ローン部門や企業の顧客部門、流通部門、財務部門、人事部門などがあります。概念的には、データメッシュにはデータプロデューサーチームとデータコンシューマチームの 2 つのドメイン関連の機能があります。1 つのデータドメインが同時に両方の機能を処理する可能性が高いことを理解することが重要です。データドメインチームは、自身が所有するデータからデータプロダクトを生成します。また、チームはデータプロダクトを利用してビジネスに関する分析情報を入手し、他のドメインで使用するため派生データプロダクトを生成します。

データメッシュには、ドメインベースの機能に加えて、組織内の一元管理されたチームによって実行される一連の機能もあります。これらの一元管理されたチームは、クロスドメインの監視、サービス、ガバナンスを提供することで、データメッシュの運用を可能にします。これによりデータプロダクトの作成と消費におけるデータドメインの運用の負担が軽減され、データメッシュの運用に必要なクロスドメイン関係が容易になります。

このドキュメントでは、データメッシュ固有のロールを持つ機能についてのみ説明します。プラットフォームに採用されているアーキテクチャに関係なく、企業で必要なロールは他にもいくつかあります。ただし、これらの他のロールについてはこのドキュメントでは説明しません。

データメッシュの主な 4 つの機能は次のとおりです。

データドメインベースのプロデューサーチーム: ライフサイクル全体でデータプロダクトを作成し、維持します。これらのチームは多くの場合、データプロデューサーと呼ばれます。
データドメインベースのコンシューマチーム: データプロダクトを検出し、さまざまな分析アプリケーションで使用します。これらのチームは、データプロダクトを使用して新しいデータプロダクトを作成できます。これらのチームは多くの場合に、データコンシューマと呼ばれます。
一元管理されたデータガバナンスチーム: データプロデューサー間でデータガバナンスポリシーを定義して適用し、コンシューマに対してデータ品質とデータの信頼性を確保します。このチームは多くの場合に、「データガバナンスチーム」と呼ばれます。
一元管理されたセルフサービスインフラストラクチャプラットフォームチーム: データプロデューサーにセルフサービスデータプラットフォームを提供します。このチームは、データコンシューマとデータプロデューサーの両方が使用する、一元的なデータ検出とデータプロダクトのオブザーバビリティのためのツールも提供しています。このチームは多くの場合に「データプラットフォームチーム」と呼ばれます。

考慮する必要があるその他の任意の機能は、データメッシュのセンターオブエクセレンス（COE）の機能です。COE の目的はデータメッシュを管理することです。COE は、他の機能によって発生した競合を解決するための指定された仲裁チームでもあります。この機能は、他の 4 つの機能を接続する場合に活用できます。

データドメインベースのプロデューサーチーム

通常、データプロダクトはデータの物理リポジトリ（単一または複数のデータウェアハウス、レイク、ストリーム）の上に構築されます。従来のデータリポジトリを作成して維持するには、組織に従来のデータプラットフォームのロールが必要です。ただし、従来のデータプラットフォームのロールは通常、データプロダクトを作成するユーザーではありません。

これらの物理リポジトリからデータプロダクトを作成するには、データエンジニアやデータアーキテクトなど、さまざまな Data Practitioner が必要です。次の表に、データプロデューサーチームに必要なドメイン固有のユーザーロールを示します。

ロール	責任	必要なスキル	求めている結果
データプロダクトオーナー:	データプロダクトの主要なビジネス上の連絡先として機能します。プロダクトとして公開されるデータの定義、ポリシー、ビジネス上の決定、ビジネスルールの適用に責任を負います。ビジネス上の質問に関する連絡窓口としての枠割を果たします。そのためオーナーは、データコンシューマチームまたは一元的なチーム（データガバナンスとデータインフラストラクチャプラットフォーム）とミーティングを行うときに、データドメインを代表します。	データ分析データアーキテクチャプロダクト管理	データプロダクトがコンシューマへの価値を高める。データプロダクトのライフサイクルをしっかり管理でき、プロダクトを廃止するタイミングや新しいバージョンをリリースするタイミングなども決定できる。ユニバーサルデータ要素は他のデータドメインと調整される。
データプロダクトテクニカルリード	プロダクトの主な技術関連の連絡先として機能します。プロダクトのインターフェースの実装と公開について責任を負います。技術的な質問に関する連絡窓口としての枠割を果たします。そのためリードは、データコンシューマチームまたは一元的なチーム（データガバナンスとデータインフラストラクチャプラットフォーム）とミーティングを行うときに、データドメインを代表します。データガバナンスチームと連携して、組織内のデータメッシュ標準を定義して実装します。データプラットフォームチームと連携して、本番環境と消費環境で発生する技術的なニーズに合わせたプラットフォームの開発を支援します。	データエンジニアリングデータアーキテクチャソフトウェアエンジニアリング	データプロダクトがビジネス要件とデータメッシュの技術基準を満たす。データコンシューマチームがデータプロダクトを使用し、データプロダクトの検出エクスペリエンスによって生成された結果に表示される。データプロダクトの使用状況（1 日あたりのクエリ数など）を分析できる。
データプロダクトのサポート	本番環境サポートの問い合わせ先として機能します。プロダクトのサービスレベル契約（SLA）を維持する責任があります。	ソフトウェアエンジニアリングサイト信頼性エンジニアリング（SRE）	データプロダクトは所定の SLA を満たす。データプロダクトの使用に関するデータコンシューマの質問に対応し、解決する。
データドメイン対象分野の専門家（SME）	他のデータドメインの SME とミーティングを行い、組織全体に共通のデータ要素の定義と境界を設定する際のデータドメインを代表します。ドメイン内の新しいデータプロデューサーが商品スコープを定義する際に支援します。	データ分析データアーキテクチャ	さまざまなデータドメインの他の SME と協力して、組織内のデータと、データで使用されるデータモデルを包括的に理解し、維持する。組織全体のデータモデルに一致する相互運用可能なデータプロダクトの作成を容易にする。データプロダクトの作成とライフサイクル管理には明確な基準がある。データドメインからのデータプロダクトにはビジネス価値がある。
データオーナー	コンテンツ領域に関する責任があります。データの品質と精度に関する責任があります。アクセスリクエストを承認します。データプロダクトのドキュメント作成に貢献します。	あらゆるスキル。ただし業務に関する十分な知識が必要です。あらゆるスキル。ただしデータの意味と、データに関するビジネスルールを完全に理解している必要があります。あらゆるスキル。ただしデータ品質の問題に対して可能な限り最適な解決策を特定できる必要があります。	各部門で使用するデータが正確であること。ステークホルダーがデータを理解している。データの使用は利用ポリシーに従って行われる。

データドメインベースのコンシューマチーム

データメッシュでは、データプロダクトを使用するユーザーは通常、データプロダクトドメイン外のデータユーザーです。これらのデータコンシューマは、中央の Data Catalog を使用して、ニーズに関連するデータプロダクトを見つけます。ニーズは複数のデータプロダクトで満たされることもあるため、データコンシューマは最終的に複数のデータプロダクトにサブスクライブする可能性があります。

データコンシューマがユースケースに必要なデータプロダクトを見つけられない場合は、データメッシュ COE に直接相談する必要があります。データコンシューマは相談時にデータニーズについて提起し、1 つ以上のドメインでそのニーズを満たす方法についてアドバイスを求めることができます。

データコンシューマはデータプロダクトを探す際、永続的な分析ダッシュボードやレポート、個々のパフォーマンスレポート、その他のビジネスパフォーマンス指標など、さまざまなユースケースを実現できるデータを求めます。また、データコンシューマは人工知能（AI）や機械学習（ML）のユースケースで使用できるデータプロダクトを探している場合もあります。このようなさまざまなユースケースを実現するには、データコンシューマは次のようなデータ実務者ペルソナを組み合わせる必要があります。

ロール	責任	必要なスキル	求めている結果
データアナリスト	単一ドメインまたはクロスドメインのデータプロダクトを検索、識別、評価、サブスクライブして、ビジネスインテリジェンスフレームワークの運用の基盤を構築します。	アナリティクスエンジニアリングビジネス分析	データ可視化スペシャリストが使用できる、クリーンでキュレートされ、集約されたデータセットを提供する。データプロダクトの使用方法に関するベストプラクティスを作成する。ドメインの分析ニーズに合わせて、クロスドメインデータセットを集約してキュレートする。
アプリケーションデベロッパー	ドメイン内外の 1 つ以上のデータプロダクトでデータを使用するためのアプリケーションフレームワークを開発します。	アプリケーション開発データエンジニアリング	1 つ以上のデータプロダクトからデータを使用するアプリケーションを作成、提供、管理する。エンドユーザーが使用するデータアプリケーションを作成する。
データ可視化スペシャリスト	データエンジニアリングとデータ分析の専門用語を、ビジネス関係者が理解できる情報に変換します。データプロダクトからビジネスレポートを生成するプロセスを定義します。戦略的なビジネス目標を説明するレポートを作成してモニタリングします。組織内のエンジニアと協力して、データプロダクトから集約したデータセットを設計します。レポートソリューションを実装します。高レベルなビジネス要件を技術要件に変換します。	要件分析データの可視化	有効で正確なデータセットとレポートをエンドユーザーに提供する。開発されたダッシュボードとレポートによってビジネス要件が満たされる。
データサイエンティスト	データサイエンスのユースケース用のデータプロダクトを検索、識別、評価、サブスクライブします。複数のデータドメインからデータプロダクトとメタデータを抽出します。予測モデルをトレーニングしてデプロイし、ドメインのビジネスプロセスを最適化します。複数のデータドメインに対して可能なデータキュレーションとデータアノテーションの手法に関するフィードバックを提供します。	ML エンジニアリングアナリティクスエンジニアリング	ビジネスプロセスを最適化する予測モデルと規範的モデルを作成する。モデルのトレーニングとデプロイが適時に行われる。

中央データガバナンスチーム

データガバナンスチームによって、データプロデューサーとコンシューマは、組織にコンプライアンスリスクをもたらすことなく、セルフサービス方式でデータを安全に共有、集約、計算できます。

組織のコンプライアンス要件を満たすために、データガバナンスチームは次のようなデータ実務担当者で構成されます。

ロール	責任	必要なスキル	求めている結果
データガバナンススペシャリスト	コンプライアンスを一元的に管理および調整します。データの収集、データ保護、データの保持に関するメッシュ全体のプライバシーポリシーを推奨します。データスチュワードがポリシーについて把握し、ポリシーにアクセスできるようにします。必要に応じて最新のデータプライバシー規制について通知し、コンサルトします。必要に応じてセキュリティに関する質問を通知し、コンサルトします。内部監査を実施し、リスク計画と制御計画に関する定期的なレポートを共有します。	法務 SME セキュリティ SME データプライバシー SME	ポリシーのプライバシー規制が最新に保たれている。データプロデューサーにポリシーの変更がタイムリーに通知される。公開されているすべてのデータプロダクトについて、ポリシーの遵守状況に関するタイムリーなレポートを経営陣が定期的に受け取る。
データスチュワード（各ドメイン内）	データガバナンスのスペシャリストによって作成されたポリシーをコード化します。組織がデータプロダクト、データリソース、データ属性に検出やプライバシー関連のメタデータのアノテーションを付けるために使用する分類を定義して更新します。それぞれのドメイン内外のさまざまなステークホルダーと連携します。ドメイン内のデータプロダクトが組織のメタデータ標準とプライバシーポリシーを遵守していることを確認します。データプラットフォーム機能の設計と優先順位付けの方法について、データガバナンスエンジニアにガイダンスを提供します。	データアーキテクチャデータスチュワードシップ	ドメイン内のすべてのデータプロダクトに必要なメタデータが作成されており、ドメイン内のデータプロダクトが正確に記述されている。セルフサービスのデータインフラストラクチャプラットフォームチームが、データプロダクトのメタデータアノテーション、ポリシーの作成、検証を自動化する適切なツールを構築する。
データガバナンスエンジニア	すべてのデータドメインで使用できるデータアノテーションを自動生成するツールを開発し、それらのアノテーションをポリシーの適用に使用します。問題が見つかった場合にアノテーションとアラートの整合性を確認するモニタリングを実装します。アラート、レポート、ダッシュボードを実装して、組織内の従業員にデータプロダクトのステータスを確実に通知します。	ソフトウェアエンジニアリング	データガバナンスのアノテーションが自動的に検証される。データプロダクトはデータガバナンスポリシーを遵守している。データプロダクトの違反がタイムリーに検出される。

ロール

責任

必要なスキル

求めている結果

データガバナンススペシャリスト

コンプライアンスを一元的に管理および調整します。

データの収集、データ保護、データの保持に関するメッシュ全体のプライバシーポリシーを推奨します。

データスチュワードがポリシーについて把握し、ポリシーにアクセスできるようにします。

必要に応じて最新のデータプライバシー規制について通知し、コンサルトします。

必要に応じてセキュリティに関する質問を通知し、コンサルトします。

内部監査を実施し、リスク計画と制御計画に関する定期的なレポートを共有します。

法務 SME

セキュリティ SME

データプライバシー SME

ポリシーのプライバシー規制が最新に保たれている。

データプロデューサーにポリシーの変更がタイムリーに通知される。

公開されているすべてのデータプロダクトについて、ポリシーの遵守状況に関するタイムリーなレポートを経営陣が定期的に受け取る。

データスチュワード（各ドメイン内）

データガバナンスのスペシャリストによって作成されたポリシーをコード化します。

組織がデータプロダクト、データリソース、データ属性に検出やプライバシー関連のメタデータのアノテーションを付けるために使用する分類を定義して更新します。

それぞれのドメイン内外のさまざまなステークホルダーと連携します。

ドメイン内のデータプロダクトが組織のメタデータ標準とプライバシーポリシーを遵守していることを確認します。

データプラットフォーム機能の設計と優先順位付けの方法について、データガバナンスエンジニアにガイダンスを提供します。

データアーキテクチャ

データスチュワードシップ

ドメイン内のすべてのデータプロダクトに必要なメタデータが作成されており、ドメイン内のデータプロダクトが正確に記述されている。

セルフサービスのデータインフラストラクチャプラットフォームチームが、データプロダクトのメタデータアノテーション、ポリシーの作成、検証を自動化する適切なツールを構築する。

データガバナンスエンジニア

すべてのデータドメインで使用できるデータアノテーションを自動生成するツールを開発し、それらのアノテーションをポリシーの適用に使用します。

問題が見つかった場合にアノテーションとアラートの整合性を確認するモニタリングを実装します。

アラート、レポート、ダッシュボードを実装して、組織内の従業員にデータプロダクトのステータスを確実に通知します。

ソフトウェアエンジニアリング

データガバナンスのアノテーションが自動的に検証される。

データプロダクトはデータガバナンスポリシーを遵守している。

データプロダクトの違反がタイムリーに検出される。

一元的なセルフサービスデータインフラストラクチャのプラットフォームチーム

セルフサービスのデータインフラストラクチャプラットフォームチームまたは単にデータプラットフォームチームは、一連のデータインフラストラクチャコンポーネントの作成を担当します。分散データドメインチームは、これらのコンポーネントを使用してデータプロダクトを構築し、デプロイします。またデータプラットフォームチームは、ベストプラクティスを推進し、新しいテクノロジーを導入する際に分散しているチームの認知負荷の軽減に役立つツールと手法を紹介します。

プラットフォームインフラストラクチャはグローバルなオブザーバビリティ、計測、コンプライアンスの自動化のための運用ツールと簡単に統合できる必要があります。また分散型チームを成功に導くために、そのような統合を容易にできるようにする必要があります。

データプラットフォームチームには、分散ドメインチームと基盤となるインフラストラクチャチームと共有する責任の共有モデルがあります。このモデルは、プラットフォームの利用者に期待される責任と、データプラットフォームチームがサポートするプラットフォームコンポーネントを示します。

データプラットフォーム自体が内部プロダクトであるため、すべてのユースケースがサポートされているわけではありません。データプラットフォームチームは代わりに、優先順位の高いロードマップに従って新しいサービスと機能を継続的にリリースします。

データプラットフォームチームは、開発中の標準のコンポーネントセットを用意している場合があります。ただしデータプラットフォームが提供するニーズがチームのニーズと一致しない場合、データドメインチームは別の固有のコンポーネントセットを使用する可能性があります。データドメインチームが別のアプローチを選択する場合は、チームが構築して維持するプラットフォームインフラストラクチャが、セキュリティとデータガバナンスに関する組織全体のポリシーとガードレールを遵守していることを確認する必要があります。中央データプラットフォームチームの外部で開発されたデータプラットフォームインフラストラクチャの場合、データプラットフォームチームは、共同投資するか、独自のエンジニアをドメインチームに組み込みます。データプラットフォームチームがエンジニアの共同投資を選択するか、エンジニアを組み込むかは、組織にとってのデータドメインプラットフォームインフラストラクチャの戦略的重要性によって決まります。組織はデータドメインチームによるインフラストラクチャの開発に常に関与することで、将来の再利用に向けて開発中の新しいプラットフォームインフラストラクチャコンポーネントを再パッケージ化するために必要な調整と技術的な専門知識を提供できます。

データメッシュのスケールアップについて関係者からの承認を得ることを主な目的としている場合は、データメッシュの作成の初期段階で自律性を制限することが必要な場合があります。ただし自律性を制限すると、中央データプラットフォームチームにボトルネックが発生するリスクがあります。このボトルネックがデータメッシュのスケーリングを妨げる可能性があります。そのため、一元化に関する決定は慎重に行う必要があります。データプロデューサーにとって、限られた利用可能なオプションセットから技術的な選択を行うほうが、自分で無制限のオプションリストを評価して選択するよりも望ましい場合があります。データプロデューサーの自律性を促進することは、管理されていないテクノロジー環境を構築することではありません。選択の自由と標準化の適切なバランスを取り、コンプライアンスとプラットフォームの導入を促進することが目標になります。

最後に、優れたデータプラットフォームチームは、社内の他のメンバーに教育やベストプラクティスを提供する中心的な情報源となります。中央データプラットフォームチームに推奨される、特に影響の大きいアクティビティは次のとおりです。

新しい機能プロジェクトの定期的なアーキテクチャ設計のレビューを促進し、開発チーム全体に共通の開発方法を提案する。
知識と経験を共有し、共同でベストプラクティスとアーキテクチャガイドラインを定義する。
エンジニアが適切なツールを導入して、コードの問題やバグ、パフォーマンスの低下などの一般的な落とし穴を検証、チェックできるようにする。
開発チームが内部ツールのニーズに対する要件を明確にできるように、内部のハッカソンを開催する。

中央データプラットフォームチームの役割と責任の例を次に示します。

役割	責任	必要なスキル	求めている結果
データプラットフォームプロダクトオーナー	データインフラストラクチャとソリューションのエコシステムを構築し、分散したチームがデータプロダクトの構築を支援します。導入への技術的な障壁を低減し、ガバナンスを組み込み、データインフラストラクチャの技術的負債を最小限に抑えます。リーダー、データドメインオーナー、データガバナンスチーム、テクノロジープラットフォームのオーナーと連携して、データプラットフォームの戦略とロードマップを策定します。	データ戦略と運用プロダクト管理関係者の管理	適切に動作するデータプロダクトのエコシステムを確立する。本番環境には膨大な数のデータプロダクトが存在する。データプロダクトのリリースにより、実用最小限の製品化までの時間と製品版リリースまでの時間が短縮される。データプロデューサーとデータコンシューマの最も一般的なニーズに対応できるように、一般化されたインフラストラクチャとコンポーネントのポートフォリオが用意される。データプロデューサーとデータコンシューマの満足度スコアが高い。
データプラットフォームエンジニア	テンプレート、デプロイ可能なアーキテクチャブループリント、デベロッパーガイド、その他のドキュメントを使用して、データの取り込み、保存、処理、消費のための再利用可能なセルフサービスデータインフラストラクチャとソリューションを作成します。また Terraform テンプレート、データパイプラインテンプレート、コンテナテンプレート、オーケストレーションツールも作成します。データ共有、パイプラインのオーケストレーション、ロギングとモニタリング、データガバナンス、ガードレールを組み込んだ継続的インテグレーションと継続的デプロイメント（CI / CD）、セキュリティとコンプライアンスのレポート、FinOps のレポートなど、部門横断的な懸念事項に対するプロセスを標準化するための中央データサービスとフレームワークを開発し、維持する。	データエンジニアリングソフトウェアエンジニアリング	データプロデューサーがデータの取り込み、保存、処理、キュレーション、共有を行うための標準化された再利用可能なインフラストラクチャコンポーネントとソリューション、そして必要なドキュメントが用意されている。コンポーネント、ソリューション、エンドユーザードキュメントのリリースはロードマップに沿って行われる。ユーザーから高い顧客満足度が寄せられる。データメッシュ内のすべての関数に対して堅牢な共有サービスがある。共有サービスの稼働時間が長い。サポート応答時間が短い。
プラットフォームとセキュリティエンジニア（ネットワーキングやセキュリティなど、一元管理された IT チームの代表者。データプラットフォームチームに組み込まれています）	データプラットフォームの抽象化が、企業全体のテクノロジーフレームワークと意思決定に沿ったものになるようにします。データプラットフォーム配信に必要なテクノロジーソリューションとサービスをコアチームで構築することで、エンジニアリング活動をサポートします。	インフラストラクチャエンジニアリングソフトウェアエンジニアリング	プラットフォームインフラストラクチャコンポーネントがデータプラットフォーム用に開発される。コンポーネント、ソリューション、エンドユーザードキュメントのリリースはロードマップに沿って行われる。中央データプラットフォームエンジニアから高い顧客満足度が寄せられる。データプラットフォームで使用されるコンポーネント（ロギングなど）のインフラストラクチャプラットフォームの健全性が改善される。基盤となるテクノロジーコンポーネントの稼働時間が長い。データプラットフォームエンジニアに問題があった場合のサポートの応答時間が短くなる。
エンタープライズアーキテクト	データメッシュとデータプラットフォームのアーキテクチャを企業全体のテクノロジーおよびデータ戦略と一致させます。データプラットフォームとデータプロダクトアーキテクチャの両方について、アドバイス、設計権限、保証を提供し、エンタープライズレベルの戦略とベストプラクティスを確実に遵守します。	データアーキテクチャソリューションのイテレーションと問題解決コンセンサスの構築	十分な数のデータプロダクトを含む優れたエコシステムが構築されており、実用最小限の製品の作成と本番環境へのリリースにかかる時間を短縮できる。アーキテクチャ標準は、メタデータ管理とデータ共有アーキテクチャの共通基準の確立など、重要なデータジャーニー向けに確立されている。

データメッシュに関するその他の考慮事項

分析データプラットフォームのアーキテクチャには複数のオプションがあり、オプションごとに前提条件が異なります。各データメッシュアーキテクチャを有効にするには、このセクションで説明するベストプラクティスに従うことをおすすめします。

プラットフォームの資金調達

ブログ投稿「If you want to transform start with finance」で説明されているように、プラットフォームは完了していません。常に優先順位の高いロードマップに基づいて動作しています。したがって、プラットフォームは固定エンドポイントを持つプロジェクトではなく、プロダクトとして資金を調達する必要があります。

データメッシュの最初の導入者が費用を負担します。通常、費用はデータメッシュを開始する最初のデータドメインを形成する企業と、一般に中央データプラットフォームチームを擁する中央技術チームとで分担されます。

財務チームが中央プラットフォームの資金調達を承認するよう説得するには、一元化されたプラットフォームの価値が徐々に実現されることを示すビジネスケースを作成することをおすすめします。その価値は個々のデリバリーチームに同じコンポーネントを再実装することで得られます。

データメッシュに必要な最小限のプラットフォームを定義する

データメッシュに実用最小限のプラットフォームを定義するために、1 つ以上のビジネスケースで試験運用とイテレーションを行うことをおすすめします。試験運用で必要なユースケースと、結果として得られるデータプロダクトを採用する準備ができているコンシューマが存在するユースケースを見つけます。ユースケースではデータプロダクトを開発するための資金がすでにあるはずですが、技術チームからの情報提供が必要になるはずです。

試験運用を実装するチームが、データメッシュの運用モデルを次のように理解していることを確認してください。

バックログ、サポート、メンテナンスはビジネス（データプロデューサーチーム）が行う。
中央チームはセルフサービスパターンを定義し、ビジネスによるデータプロダクトの構築を支援するが、完了したデータプロダクトの実行と所有を企業に任せる。
主な目標は事業運営モデル（ドメインによる本番環境、ドメインでの使用）を証明することである。2 つ目の目標は、技術的な運用モデル（中央チームが開発したセルフサービスパターン）を証明することである。
プラットフォームチームのリソースは限られているため、トランクチームとブランチチームモデルを使用して知識をプールし、専用のプラットフォームサービスとプロダクトの開発を可能にする。

また、次のことをおすすめします。

サービスや機能を有機的に進化させるのではなく、ロードマップを計画する。
取り込み、保存、処理、分析、ML にわたる実用最小限のプラットフォーム機能を定義する。
データガバナンスを個別のワークストリームとしてではなく、すべてのステップに組み込む。
ガバナンス、プラットフォーム、バリューストリーム、チェンジマネジメント全体で最小限の機能を実装する。最小限の機能とはビジネスケースの 80% を満たす機能。

データメッシュと既存のデータプラットフォームとの共存を計画する

データメッシュを実装する多くの組織には、データレイク、データウェアハウス、またはその両方の組み合わせなどの既存のデータプラットフォームがすでに存在する可能性があります。データメッシュを実装する前に、データメッシュの成長に合わせて既存のデータプラットフォームを進化させる方法を計画する必要があります。

このような組織は、次のような要因を考慮する必要があります。

データメッシュで最も効果的なデータリソース。
既存のデータプラットフォーム内に留める必要があるアセット。
アセットを移動する必要があるかどうか、既存のプラットフォームで維持したままデータメッシュに参加できるかどうか。

次のステップ

クラウドトポロジの設計と運用の詳細について、Google Cloud Well-Architected Framework で確認する。
Cloud アーキテクチャセンターで、リファレンスアーキテクチャ、図、ベストプラクティスを確認する。

ロール	責任	必要なスキル	求めている結果
データプロダクトオーナー:	データプロダクトの主要なビジネス上の連絡先として機能します。プロダクトとして公開されるデータの定義、ポリシー、ビジネス上の決定、ビジネスルールの適用に責任を負います。ビジネス上の質問に関する連絡窓口としての枠割を果たします。そのためオーナーは、データコンシューマチームまたは一元的なチーム（データガバナンスとデータインフラストラクチャプラットフォーム）とミーティングを行うときに、データドメインを代表します。	データ分析データアーキテクチャプロダクト管理	データプロダクトがコンシューマへの価値を高める。データプロダクトのライフサイクルをしっかり管理でき、プロダクトを廃止するタイミングや新しいバージョンをリリースするタイミングなども決定できる。ユニバーサルデータ要素は他のデータドメインと調整される。
データプロダクトテクニカルリード	プロダクトの主な技術関連の連絡先として機能します。プロダクトのインターフェースの実装と公開について責任を負います。技術的な質問に関する連絡窓口としての枠割を果たします。そのためリードは、データコンシューマチームまたは一元的なチーム（データガバナンスとデータインフラストラクチャプラットフォーム）とミーティングを行うときに、データドメインを代表します。データガバナンスチームと連携して、組織内のデータメッシュ標準を定義して実装します。データプラットフォームチームと連携して、本番環境と消費環境で発生する技術的なニーズに合わせたプラットフォームの開発を支援します。	データエンジニアリングデータアーキテクチャソフトウェアエンジニアリング	データプロダクトがビジネス要件とデータメッシュの技術基準を満たす。データコンシューマチームがデータプロダクトを使用し、データプロダクトの検出エクスペリエンスによって生成された結果に表示される。データプロダクトの使用状況（1 日あたりのクエリ数など）を分析できる。
データプロダクトのサポート	本番環境サポートの問い合わせ先として機能します。プロダクトのサービスレベル契約（SLA）を維持する責任があります。	ソフトウェアエンジニアリングサイト信頼性エンジニアリング（SRE）	データプロダクトは所定の SLA を満たす。データプロダクトの使用に関するデータコンシューマの質問に対応し、解決する。
データドメイン対象分野の専門家（SME）	他のデータドメインの SME とミーティングを行い、組織全体に共通のデータ要素の定義と境界を設定する際のデータドメインを代表します。ドメイン内の新しいデータプロデューサーが商品スコープを定義する際に支援します。	データ分析データアーキテクチャ	さまざまなデータドメインの他の SME と協力して、組織内のデータと、データで使用されるデータモデルを包括的に理解し、維持する。組織全体のデータモデルに一致する相互運用可能なデータプロダクトの作成を容易にする。データプロダクトの作成とライフサイクル管理には明確な基準がある。データドメインからのデータプロダクトにはビジネス価値がある。
データオーナー	コンテンツ領域に関する責任があります。データの品質と精度に関する責任があります。アクセスリクエストを承認します。データプロダクトのドキュメント作成に貢献します。	あらゆるスキル。ただし業務に関する十分な知識が必要です。あらゆるスキル。ただしデータの意味と、データに関するビジネスルールを完全に理解している必要があります。あらゆるスキル。ただしデータ品質の問題に対して可能な限り最適な解決策を特定できる必要があります。	各部門で使用するデータが正確であること。ステークホルダーがデータを理解している。データの使用は利用ポリシーに従って行われる。

役割	責任	必要なスキル	求めている結果
データプラットフォームプロダクトオーナー	データインフラストラクチャとソリューションのエコシステムを構築し、分散したチームがデータプロダクトの構築を支援します。導入への技術的な障壁を低減し、ガバナンスを組み込み、データインフラストラクチャの技術的負債を最小限に抑えます。リーダー、データドメインオーナー、データガバナンスチーム、テクノロジープラットフォームのオーナーと連携して、データプラットフォームの戦略とロードマップを策定します。	データ戦略と運用プロダクト管理関係者の管理	適切に動作するデータプロダクトのエコシステムを確立する。本番環境には膨大な数のデータプロダクトが存在する。データプロダクトのリリースにより、実用最小限の製品化までの時間と製品版リリースまでの時間が短縮される。データプロデューサーとデータコンシューマの最も一般的なニーズに対応できるように、一般化されたインフラストラクチャとコンポーネントのポートフォリオが用意される。データプロデューサーとデータコンシューマの満足度スコアが高い。
データプラットフォームエンジニア	テンプレート、デプロイ可能なアーキテクチャブループリント、デベロッパーガイド、その他のドキュメントを使用して、データの取り込み、保存、処理、消費のための再利用可能なセルフサービスデータインフラストラクチャとソリューションを作成します。また Terraform テンプレート、データパイプラインテンプレート、コンテナテンプレート、オーケストレーションツールも作成します。データ共有、パイプラインのオーケストレーション、ロギングとモニタリング、データガバナンス、ガードレールを組み込んだ継続的インテグレーションと継続的デプロイメント（CI / CD）、セキュリティとコンプライアンスのレポート、FinOps のレポートなど、部門横断的な懸念事項に対するプロセスを標準化するための中央データサービスとフレームワークを開発し、維持する。	データエンジニアリングソフトウェアエンジニアリング	データプロデューサーがデータの取り込み、保存、処理、キュレーション、共有を行うための標準化された再利用可能なインフラストラクチャコンポーネントとソリューション、そして必要なドキュメントが用意されている。コンポーネント、ソリューション、エンドユーザードキュメントのリリースはロードマップに沿って行われる。ユーザーから高い顧客満足度が寄せられる。データメッシュ内のすべての関数に対して堅牢な共有サービスがある。共有サービスの稼働時間が長い。サポート応答時間が短い。
プラットフォームとセキュリティエンジニア（ネットワーキングやセキュリティなど、一元管理された IT チームの代表者。データプラットフォームチームに組み込まれています）	データプラットフォームの抽象化が、企業全体のテクノロジーフレームワークと意思決定に沿ったものになるようにします。データプラットフォーム配信に必要なテクノロジーソリューションとサービスをコアチームで構築することで、エンジニアリング活動をサポートします。	インフラストラクチャエンジニアリングソフトウェアエンジニアリング	プラットフォームインフラストラクチャコンポーネントがデータプラットフォーム用に開発される。コンポーネント、ソリューション、エンドユーザードキュメントのリリースはロードマップに沿って行われる。中央データプラットフォームエンジニアから高い顧客満足度が寄せられる。データプラットフォームで使用されるコンポーネント（ロギングなど）のインフラストラクチャプラットフォームの健全性が改善される。基盤となるテクノロジーコンポーネントの稼働時間が長い。データプラットフォームエンジニアに問題があった場合のサポートの応答時間が短くなる。
エンタープライズアーキテクト	データメッシュとデータプラットフォームのアーキテクチャを企業全体のテクノロジーおよびデータ戦略と一致させます。データプラットフォームとデータプロダクトアーキテクチャの両方について、アドバイス、設計権限、保証を提供し、エンタープライズレベルの戦略とベストプラクティスを確実に遵守します。	データアーキテクチャソリューションのイテレーションと問題解決コンセンサスの構築	十分な数のデータプロダクトを含む優れたエコシステムが構築されており、実用最小限の製品の作成と本番環境へのリリースにかかる時間を短縮できる。アーキテクチャ標準は、メタデータ管理とデータ共有アーキテクチャの共通基準の確立など、重要なデータジャーニー向けに確立されている。

データメッシュ内のアーキテクチャと機能 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。