データメッシュを勉強していく：データメッシュでの組織構造
分析屋の下滝です。
『Data Mesh』本を読みながらデータメッシュを勉強していきます。本来なら順番に解説していくのですが、全部読めていないし理解もしきれていないので、興味ある箇所から見ていきます。
これまでの記事の一覧はこちらのマガジンから。
今回は、データメッシュにおける組織構造に関して見ていきます。どのようなチームがあり、どのように関わり合うのか、です。
チームトポロジーとデータメッシュ
データメッシュでは、大前提として、ドメイン駆動設計が適用された組織である必要があります。つまり、組織はドメイン（境界づけられたコンテキスト）で分割されていなければなりません。
それを踏まえて、データメッシュでは、次のような組織構造になります。ドメインデータプロダクトチームの数は変動します。
『Data Mesh』では、チームトポロジーの用語をもとにデータメッシュにおける組織構造を説明しています。
チームトポロジーでは、4つのチームタイプと、チーム間でのインタラクションの種類を表す、3つのインタラクションモードを定義しています。
【チームタイプ】
・ストリームアラインドチーム
・イネイブリングチーム
・コンプリケイテッド・サブシステムチーム
・プラットフォームチーム
【インタラクションモード】
・コラボレーション
・X-as-a-service
・ファシリテーション
チームトポロジーとは、「組織設計のモデルであり、現代のソフトウェア集約型企業が、ビジネスや技術の観点で戦略の変更が必要だと感知したときに、技術にとらわれない重要なメカニズムを提供するもの」とされます（『チームトポロジー』, p.229）。
各チームと各インタラクションの説明を『チームトポロジー』から引用します。まずはチームです。
・ストリームアラインドチーム：単一の価値ある仕事のストリームに沿ったチームのこと。ストリームとは、ビジネスドメインや組織の能力に沿った仕事の継続的な流れのこと。ストリームとは、仕事やサービスの場合もあるし、機能一式のこともあり、ユーザージャーニーやユーザーペルソナの一つのような場合もある。
・イネイブリングチーム：特定の技術領域やプロダクト領域のスペシャリストから構成されているチームのことで、能力ギャップを埋める役割を果たす。
・コンプリケイテッド・サブシステムチーム：特別な知識に大きく依存しているシステムを構築、維持する責任を持つチームのこと。
・プラットフォームチーム：ストリームアラインドチームが相当な自律性のもとでデリバリーすることを可能にするチームのこと。
続いてインタラクションです。
・コラボレーション：チームが別のチームと密接に連携して働くこと
・X-as-a-service：最小のコラボレーションでプロデューサーとコンシューマーの関係を実現すること
・ファシリテーション：障害を取り除くために他のチームを支援したり、支援を受けたりすること
データメッシュは、これら４つのチームタイプと３つのインタラクションモードで表現される組織構造となります。
【チーム】
・ストリームアラインドチーム：ドメインデータプロダクトチーム
・プラットフォームチーム：マルチプレーンデータプラットフォームチーム
・イネイブリングチーム：ガバナンスチーム
・コンプリケイテッド・サブシステムチーム：図では表現されていませんが、マルチプレーンデータプラットフォームチーム内のチームとして存在することがあります。
【インタラクション】
・コラボレーション
・「ガバナンスチーム」と「マルチプレーンデータプラットフォームチーム」
・X-as-a-service
・「ドメインデータプロダクトチーム」と「ドメインデータプロダクトチーム」。どちからかが、プロデューサーになります。残ったほうがコンシューマーです。
・「マルチプレーンデータプラットフォームチーム（プロデューサーとしての役割）」と「ドメインデータプロダクトチーム（コンシューマーとしての役割）」。
・ファシリテーション
・「ガバナンスチーム」と「ドメインデータプロダクトチーム」。ガバナンスチームがファシリテーションする側となります。
最初に見せた図を再掲します。
今回は、ドメインデータプロダクトチームについて見ていきます。
ドメインデータプロダクトチーム
ドメインデータプロダクトチーム（ドメインロジカルチームとも表現されています）は、ロジカルなチームを表します。ロジカルなチームとは、チームのチームという意味のようです。
ドメインデータプロダクトチームは、一つまたは複数のストリームアラインドチームを持ちます。以下の二種類のチームです。
・アプリ開発チーム（通常は、マイクロサービスの開発を担当するチーム）
・データプロダクト開発チーム
ストリームアラインドチームは、組織における根幹となるチームです。単一のプロダクトやサービス、機能集合などのエンドツーエンドのデリバリーに責任をもちます。
データプロダクトのデリバリーは、エンドツーエンドの継続的なフローに焦点を当てます。データプロダクトの設計、モデリング、クレンジング、構築、テスト、提供、モニタリング、進化のフローです。
データプロダクト開発チームの数は、ドメインの複雑性とそのドメインでのデータプロダクトの数によって変わります。理想的には、ある小さなチームが、あるデータプロダクトに対して責任を持ちます。それぞれのデータプロダクトは、独立したフローと、デリバリーのライフサイクルを持ちます。
なお、今回の記事では議論しませんが、データプロダクト開発チームには、「データプロダクト開発者」と「データプロダクトオーナー」と呼ばれる役割をもつメンバーが存在します。
ソースアラインドデータプロダクトチームは、データのソース（生成元）となるアプリ開発チームとペアになります。ペアとなったチームでは、コラボレーションするアプリの内部データを、データ分析的な観点からデータプロダクトとしてどように表現するのかに関してコミュニケーションを行います。
なお、ソースアラインドデータプロダクトとは、データプロダクトの種類の一つで、業務データとやりとりするデータプロダクトとなります。他の種類には、以下があります。
・集約データプロダクト：上流のデータプロダクトから集約されたデータを扱います。
・目的特化（またはコンシューマーアラインド）データプロダクト：特定のユースケースのニーズにフィットするデータを扱います。
アプリ開発チームとデータプロダクト開発チームとのコラボレーションは、コストを伴うため、短期間であるとこが望ましいとされます。チームは、コラボレーションの労力を抑えるための方法を探す必要があります。たとえば、業務ドメインのイベントを公開するするためのコントラクトを開発チームが定義することで、ソースアラインドデータプロダクトチームが、分析データプロダクトのために、そのようなイベントを理解、処理、変換するためのコラボレーションのオーバーヘッドを減らすことができます。
データプロダクトチーム同士は、as-a-serviceインタラクションとして、どちからのデータプロダクトに接続してデータを取得する関係となります。図で示しているのはドメイン内でのインタラクションになります。パターンとしては、ドメイン内とドメイン間での2つのインタラクションがあります。
・ドメイン内での、データプロダクトチーム同士のas-a-serviceインタラクション
・ドメイン間での、データプロダクトチーム同士のas-a-serviceインタラクション
データプロダクトチームとガバナンスチームとのインタラクションに関しては、次回以降の記事で見ていきます。
今回の記事は以上です。
株式会社分析屋について
ホームページはこちら。
noteでの会社紹介記事はこちら。
【データ分析で日本を豊かに】
分析屋はシステム分野・ライフサイエンス分野・マーケティング分野の知見を生かし、多種多様な分野の企業様のデータ分析のご支援をさせていただいております。 「あなたの問題解決をする」をモットーに、お客様の抱える課題にあわせた解析・分析手法を用いて、問題解決へのお手伝いをいたします！
【マーケティング】
マーケティング戦略上の目的に向けて、各種のデータ統合及び加工ならびにPDCAサイクル運用全般を支援や高度なデータ分析技術により複雑な課題解決に向けての分析サービスを提供いたします。
【システム】
アプリケーション開発やデータベース構築、WEBサイト構築、運用保守業務などお客様の問題やご要望に沿ってご支援いたします。
【ライフサイエンス】
機械学習や各種アルゴリズムなどの解析アルゴリズム開発サービスを提供いたします。過去には医療系のバイタルデータを扱った解析が主でしたが、今後はそれらで培った経験・技術を工業など他の分野の企業様の問題解決にも役立てていく方針です。
【SES】
SESサービスも行っております。