データメッシュの概要

データメッシュとは、情報の新しい見方です。データは、単にすでに起こったことを後から振り返って理解するために収集して分析するものではなく、実際にそれ自体が製品、ツール、目的達成の手段であるという概念から生まれたものです。

データメッシュの定義

データメッシュは、分散アーキテクチャーフレームワークを使用するデータ管理手法です。つまり、組織内のあるデータセットについて、そのデータが何を意味するのか、どうすればそのデータを最大限に活用できるのかについて専門知識を持っているユーザーに、そのデータセットの所有権と責任を分散します。

データメッシュアーキテクチャーは、データレイクやデータウェアハウスなどのさまざまなソースからデータを接続して取得します。その後、関連するデータセットをビジネス全体の適切なエキスパートやドメインチームに分散します。基本的に、中央のデータレイクにある大量のデータが分類され、管理しやすいチャンクに分割され、それを理解して活用するのに最適なユーザーに分散されます。

データメッシュの起源

データメッシュは、大規模で複雑な組織におけるデータアーキテクチャーの拡張という課題に応えて、2009 年頃に生まれました。データメッシュの核となる概念は、データの所有権とアーキテクチャーを分散し、データを製品として扱い、ドメイン指向のチームに責任を割り当てることです。データメッシュは、ドメイン駆動設計、プロダクト思考、セルフサービスインフラストラクチャーの原則を組み合わせることで、モノシリックボトルネックを生じさせずに組織がデータシステムを拡張できるようにします。

大規模組織においては、以下の理由により、一元化されたデータ管理モデルが失敗することがよくあります。

• 提供におけるボトルネック：単一の中央チームが過負荷になり、データアクセスと分析の速度が低下します。
• 所有権のギャップ：ドメイン全体でデータ品質に関する明確な説明責任がない場合、一貫性のない標準や信頼性の問題が生じます。
• スケーラビリティの問題：データ量や複雑さが増大するにつれ、一元化されたシステムは、膨大なオーバーヘッドなしで拡張するのが困難になります。
• ドメインに関する知識が不十分：中央のチームがビジネスドメインを深く理解していないため、データプロダクトの品質が低下したり、整合性が損なわれたりします。
• 俊敏性が限定的：単一チームによる調整が必要な変更は、進化するビジネスニーズに対する即応性を低下させます。

データメッシュのメリット

レガシーデータベースや制限のあるデータ管理インフラストラクチャーによって、データは単一のストレージに保管され、少数のデータ管理者の裁量で分配されるものであると認識されていました。現在、データはビジネスを推進する原動力です。競争の激しい時代だからこそ、それをどのように活用して利益を上げるかをよく知るスペシャリストに自由に提供されなければなりません。

データメッシュアーキテクチャーの主な利点は、以下の 3 つのカテゴリーにまとめることができます。

スケーラビリティと俊敏性

データアクセシビリティの向上：データメッシュにより、組織の適切な人材すべてが必要なデータにアクセスし、職務で最高の成果を上げることができます。

カスタマイズ可能なデータパイプラインとプロセス：成功に必要な独自のカスタマイズされたデータセットをキュレートするには膨大な手間がかかるため、最も収益性が高い可能性がある優れたプロジェクトの多くが棚上げされてしまっています。データメッシュを使用すると、チームはこれまでのように時間やリソースを無駄にすることなく、新しいプロジェクトモデルにすばやくアクセスし、テストすることができます。

ボトルネックの削減：これは、IT チームとデータ所有者双方にとって明らかなメリットです。また、不満や苛立ちの原因を削減することは、企業における健全なビジネス開発の妨げとなるサイロの解消にもつながります。

品質と信頼

アナリティクス機能の強化：データが毎日使用される製品とみなされるようになると、チームは計画と戦略に対してデータファーストのアプローチを取り始めます。これにより、エラーが減少し、主観的意見に左右されにくい、より客観的なビジネス開発のアプローチがもたらされます。

ドメインをまたいだコラボレーションと再利用

中央データ管理チームの負担軽減：バックログや不満を軽減するだけでなく、有能な IT チームがより専門的で興味深く、収益性の高い仕事に専念できるように、十分な時間を確保します。

データメッシュは、所有権を分散してデータを製品として扱うことで、組織がより迅速に行動し、インサイトへの信頼を築き、ドメイン全体でシームレスに拡張できるようにします。

データメッシュのコア原則

データレイクやデータメッシュについて語るとき、その話題の本質はビッグデータにあります。データを「ビッグ」たらしめているのは、単にその量が膨大であるということだけではありません。他の基準では、ビッグデータは、複雑で、変化しやすく、急速に生成され、非構造化されているものと定義されることもあります。

線形データベースはスプレッドシートに似ています。列と行があり、すべてのデータコンポーネントが収まる不変のカテゴリーがあります。機械、センサー、業界ソースから生成されるデータの一部は構造化されており、線形データベースにきちんと収まります。処理しなければならないデータの量がどれほど多くても、それが 100% 構造化されている場合はビッグデータの基準を満たさず、線形データベースに格納できるため、フィルタリングと抽出が比較的簡単になります。

しかし、最新のビッグデータは、非構造化の傾向が強まっており、ビジュアルコンポーネント、自由形式のテキスト、さらにはビデオやリッチメディアで構成されるようになっています。こういった重要なデータは、多くの企業で数千テラバイトの情報になる可能性があり、標準的な線形データベースに保存することはできません。

データレイクに入れましょう。ビッグデータの量が増加したことで、複雑なデータを生データの形式で保存し、中央リポジトリーからアクセスできる場所としてデータレイクが開発されました。データレイクはビッグデータの問題に対する優れたソリューションですが、それでも弱点があります。データレイクには特定の分析機能がありません。取得、インデックス作成、変換、クエリ、分析機能については他のサービスに依存することになります。

データメッシュの 4 つの原則が、データレイクがもたらす課題に対応します。

1. ドメイン所有権

データを生成したり、アクセスしたりするプレーヤーが多すぎる場合、データレイクの所有権を定義するのが複雑になります。役割と責任が明確に定義されていない場合、同じデータセットをさまざまな関係者が異なる方法で管理し、利用を困難にするような不整合が生じてしまう可能性があります。同様に、他のデータも、最終的にそれを使用する人によって積極的に管理されていないと、放置されてしまう可能性があります。

データメッシュアーキテクチャーは、所有権を分散することでこれを解決します。データメッシュアーキテクチャーによって、データガバナンスをドメインごとに明確に分散することができ、各チームやドメインエキスパートが生成および使用するデータを管理できるようになります。これをバックアップするために、データメッシュでは連携型ガバナンス構造も使用し、データモデリング、セキュリティポリシー、コンプライアンスの集中管理も実現しています。データメッシュの所有権によって、説明責任が生み出され、データの操作性が向上します。

2. 製品としてのデータ

データ量が大きくなりすぎたり、中央データの管理者自身がデータを理解していなかったりする場合、データレイクではデータ品質を確保できない可能性があります。データメッシュアーキテクチャーは基本的にデータを貴重な製品として扱い、データの品質と完全性をデータ管理の最前線に配置します。おそらく各チームは、収集しているデータから推測する最も重要な基準や問題点を把握しているはずです。これらの基準と優先順位をアーキテクチャーに組み込むことで、データメッシュは、大規模なデータセットを扱う場合でも、クリーンで最新の完全なデータを継続的かつ優先的に提供することができます。そしてもちろん、機械学習アルゴリズムが適用されると、これらの基準と結果として得られるデータセットは時間の経過とともにますます正確で有用なものになっていきます。

3. セルフサービスデータプラットフォーム

ボトルネックデータレイクは、その集中型アーキテクチャーと、従来から困難であったデータ取得プロセスやプロトコルにより、ボトルネックを引き起こす可能性があります。つまり、これは統合された大量データの制御が単一の IT チームやデータ管理チームに集中してしまうことを意味します。データの量（およびその取得の需要）が増加するにつれて、IT チームの負担が大きくなっていきます。

さらに、コンプライアンスやデータガバナンスの原則を確実に遵守するには、データを適切に確認し、構造化しなければなりません。過度なプレッシャーに直面すると、これらのコンプライアンス段階を急いでしまう傾向があり、会社に潜在的なリスクや損失をもたらす可能性があります。データメッシュの原則は、セルフサービスデータプラットフォームを実現することでこれに対応します。組み込み型の厳格なセキュリティプロトコルを採用しながら、データに対してより大きな責務を持つ、権限のある専門ユーザーにアクセスと制御が与えられます。これにより、ボトルネックが軽減され、データの提供が迅速になります。

4. 連携ガバナンス

分散化が鍵を握る一方で、組織はガバナンスを放棄することはできません。データメッシュでは、連携ガバナンスモデルを使用して自律性と一貫性のバランスを保ちます。つまり、各ドメインは自部門のデータプロダクトを管理しますが、組織全体のセキュリティ、コンプライアンス、相互運用性に関する共有標準は遵守する必要があります。このデータメッシュガバナンスのハイブリッドアプローチにより、信頼性や規制遵守を犠牲にすることなく俊敏性が確保されます。

データメッシュの課題が存在する一方で、分散化および民主化されたデータ管理アーキテクチャーにより、適切なデータが適切な人に、必要なときに必要な場所で即座に提供されるようになり、ビジネスのスマート化、俊敏性と正確性の向上が実現しました。データメッシュは、製品としてのデータを実現し、障壁を減らして情報の価値に優先順位をつけることで、チームが重要なデータに迅速かつ妨げられることなくアクセスできるようにします。

データメッシュアーキテクチャーとフレームワーク

データメッシュがデータを重要なビジネス管理ツールとして扱う分散型のデータアーキテクチャーであることは、これまで述べてきました。そして重要なのは、独立したチームが、中央で決定されたデータ管理慣行を遵守しながら、それぞれの業務と専門知識の範囲内でデータを処理する責任を負っていることです。この発想の転換がデータメッシュの中核を成しています。

データメッシュアーキテクチャーの全体像

データメッシュにおいて、ドメインはデータの主要な生産者および消費者であり、それぞれがデータを製品として所有し、品質と関連性を確保します。セルフサービスプラットフォームは、これらのデータプロダクトを公開、発見、使用するためのインフラストラクチャーと、自動化されたセキュリティ機能およびコンプライアンス機能を提供します。ガバナンスは連携モデルで運用され、相互運用性とセキュリティに関するグローバル標準とローカルの自律性のバランスを確保して、ドメインが組織全体での信頼性と一貫性を保ちながらイノベーションを実現できるようにします。

データメッシュアーキテクチャーの全体像をより良く理解するために、3 つの主要なコンポーネントについて詳しく見ていきましょう。

データソース

データソースは、主要な生データが供給されるリポジトリー（データレイクなど）を表します。クラウド IIoT ネットワーク、顧客フィードバックフォーム、スクレイピングされた Web データのいずれから収集されたものであれ、これはネットワーク全体でユーザーが必要に応じて参照し、処理する生の入力データです。データレイクアプローチでは、すべてのデータを 1 つの中央の場所に集めますが、データメッシュ方法論では、生データの取り込み、保存、処理、抽出の責任を一連の責任あるドメイン内に分散させます。

データメッシュインフラストラクチャー

情報は個別の部門ドメイン内で分離されるだけでなく、確立されたデータガバナンスガイドラインに準拠しながら、組織の運用ネットワーク全体で任意に共有することもできます。これは、データメッシュの主要な 2 つの柱（セルフサービスデータプラットフォームと連携型ガバナンス）の直接的な結果です。セルフサービスデータプラットフォームは、各ドメインがデータを普遍的に収集、変換、処理、およびサービスするために必要なツールとインフラストラクチャーを提供します。一方、連携型ガバナンスの原則によって組織全体での標準化が確保され、すべてのドメインチーム間でのデータの相互運用性が容易になります。

データ所有者

データ所有者は、データメッシュの最終コンポーネントであり、各部門のデータにコンプライアンス、ガバナンス、分類プロトコルを適用する責任を負います。例えば、人事ファイルは、特定のセキュリティプロトコルを使用して保存する必要があったり、特定の目的に使用してはならなかったり、特定の人物にのみ公開する必要があったりします。もちろん、各部門には、それぞれの部門や目的に固有のデータカテゴリーやデータタイプが存在します。データレイクシステムにおいて、IT チームはレイクにデータを投入したすべての異なるデータ所有者のさまざまなプロトコルやカテゴリーに対応しなければなりません。一方、データメッシュアーキテクチャーでは、ドメイン所有者にこれらの事項に対する完全な権限と制御が与えられます。自分たちのデータを管理し、品質基準を満たすには、対象領域のエキスパート以上の適任者はいないからです。

データメッシュ運用モデル

データメッシュ運用モデルは、人、プロセス、テクノロジーを統合して、大規模な分散型データ管理を可能にします。このコラボレーションにより、単一の一元化されたチームに依存することなく、組織全体でデータがシームレスに流れ、信頼性、俊敏性、再利用が促進されます。データメッシュは、共有標準を適用し、共通のプラットフォーム、一貫性のある書式と検索用語、データプロダクトの公開と利用に関するガバナンスルールを提供することで、相互運用性と発見可能性を実現します。データカタログやレジストリのようなデータメッシュツールにより、チームは組織全体でデータプロダクトを迅速に検索し、安全にアクセスし、使用することができます。

データメッシュを現代の都市と考えてください。現地のニーズを最もよく把握しているのは各地区（ドメイン）であるため、各地区が自ら公益事業とサービス（水、電気、廃棄物など）を管理します。市が、道路や公共交通機関（セルフサービスプラットフォーム）および安全基準（ガバナンス）などの共有インフラを提供するため、各地区は混乱することなくつながり、市のリソースにアクセスし、協力することができます。このようにして、都市全体にリソースが自由に流れ、誰もが共通ルールに従い、都市全体がスムーズに機能しながら、地域でイノベーションが促進されます。

データメッシュの活用例：事例とユースケース

データ管理ソリューションが進化し、より成功を収めるには、幅広いアプリケーションやオペレーションで使用可能かつ関連性のあるものでなければなりません。データメッシュアーキテクチャーとユーザーの利便性が向上するにつれ、製品/ツールとしてのデータへの安全で分散されたアプローチによって組織が強化できるビジネス機能の幅が広がっています。

データメッシュの一般的なビジネスユースケースをいくつか見ていきましょう。

販売

セールスチームにとっては、リードの獲得、育成、成約が何より重要です。セールスチームのメンバーがデスクで事務作業に費やす時間が長くなるほど、新規顧客との関係構築に使える時間は少なくなります。セールスチームのユーザーは、データメッシュアーキテクチャーを活用することで、データ管理や取得のエキスパートでなくても、最も強力で関連性の高いデータセットや組み合わせをすぐに利用できるようになります。セールス部門が分析すべき適切なデータをすべて入手することで、より実用的なインサイトや戦略を得ることができます。

セールスデータメッシュの例：地域または製品固有のセールスチームは独自の CRM およびパイプラインデータドメインを所有し、中央の IT チームを待つことなく、正確な予測やリアルタイムのダッシュボードを実現できます。

サプライチェーンとロジスティクス

現代のサプライチェーンは、さまざまな混乱に対して脆弱です。企業は、迅速に方向転換を行い、脅威と機会の両方に等しく俊敏に対応できれば、競争優位性を獲得することができます。今日のグローバルサプライチェーンのデータは、顧客からのフィードバックから IIoT ネットワーク、デジタルツインに至るまで、急速に増加しています。経験や知識が豊富なサプライチェーンマネージャーが、それらのデータセットをリアルタイムでキュレートして詳細に分析できるようになると、企業は強力なインサイトや判断力を得ることができます。

サプライチェーンデータメッシュの例：サプライチェーンの最適化には、在庫レベル、サプライヤーのパフォーマンス、ロジスティクスデータに関するリアルタイムの可視性が必要です。データメッシュは、各ドメイン（調達、倉庫管理、輸送）にデータプロダクトの所有権を与えて、迅速な意思決定とコスト効率の高い業務を可能にします。

製造

サプライチェーンの一環として、企業の製造業務は、市場の急速な変化や不安定な顧客需要に対して同様に脆弱です。これまで、設計チームや研究開発チームは、他の部門から提供される過去の顧客データに頼らねばなりませんでした。現在では、データメッシュにより、設計段階、研究開発チームやテストチーム、さらには製造現場にいたるまで、あらゆるユーザーがライブデータにアクセスできるようになりました。リアルタイムの顧客フィードバックは製品開発に即座に伝えられ、IIoT ネットワークとデジタルシミュレーションからの最新の情報により、工場の安全性、高速化、効率化を実現できます。

製造データメッシュの例：プラントレベルのチームはセンサーや機械のパフォーマンスデータを所有し、分散型アナリティクスを通じて予測保全を実現し、ダウンタイムを削減できます。

マーケティング

今日、顧客の需要や期待は、かつでないほどのペースで未来を形作り、変化し、成長しています。1 つのブランドには、通常、ソーシャルメディア、ターゲットを絞ったデジタル広告、オンラインおよびオムニチャネルショッピングポータルなど、無数の消費者との接点が存在します。現在の市場では、迅速なカスタマイズ、製品ライフサイクルの短縮、多数の選択肢や競争に対する要望が高まりを見せています。現代のマーケティング担当者がこれらのトレンドを理解し、一歩先を行くには、さまざまなデータセットにリアルタイムで同時にアクセスでなければなりません。これまでは他の部門にこういったデータを要求（そして待機）しなければなりませんでした。しかし、データメッシュを設定すれば、マーケティング担当者は自分の条件に応じて、これらデータをその場でキュレートしてアクセスできるようになります。

マーケティングデータメッシュの例：顧客をあらゆる角度から把握するには、電子メール、ソーシャル、有料広告など複数のチャネルからのデータを統合する必要があります。データメッシュにより、各チャネルがデータプロダクトを所有できるようになり、パーソナライズされたキャンペーンや優れたカスタマーエクスペリエンスのための、正確なリアルタイムのインサイト獲得が可能になります。

人事

人事チームは、非常に複雑で機密性の高い大量のデータを管理する必要があります。また、リモートワークやハイブリッドワークの増加傾向に伴い、データは日々複雑化し、地理的にも多様化しています。言うまでもなく、人事チームは絶えず変化するコンプライアンスや法的な問題に迅速に対応する必要があります。人事リーダーは、採用から退職まで、あらゆる組織で最も広範な異種データセットを検証、評価、分析できなければなりません。データメッシュアーキテクチャーにより、適切なセキュリティプロトコルと厳密に制限されたアクセスが可能になります。同時に、権限のある人事ユーザーは、複雑な内部プロトコルや複数部門にわたる官僚主義に依存することなく、データや情報に迅速にアクセスできるようになります。

人事データメッシュの例：採用、給与計算、パフォーマンス管理チームは、それぞれのデータドメインを統制して、コンプライアンスの強化と、戦略的意思決定のためのリアルタイムの要員分析を実現することができます。

金融

人事部門と同様に、財務および経理チームも極めて重要かつ機密性の高いデータに責任を負っています。最新の ERP システムは、インメモリーデータベーステクノロジーを使用し、最新のレポート、分析、予測をカスタマイズすることで、財務に革命をもたらしました。しかし、たとえ財務チームが最良のデータベースや ERP を使用していても、長年にわたって硬直化した文化、頑強なサイロ、官僚的で旧式のプロセスのせいで、依然としてさまざまな障害に直面しています。データメッシュアーキテクチャーは、財務データの見方と管理方法に根本的な変化をもたらします。また、組織がチームに独自の古いデータプロセスを所有し、修正する権限を与えた場合に起こり得る、停滞した思考を揺るがすこともできます。

財務データメッシュの例：財務計画チームは、収益、支出、投資データドメインを所有し、単一の中央チームに依存することなく、正確な予測および俊敏なシナリオモデリングを実現できます。

データメッシュが単なる流行語ではなく、真剣に受け止める必要のあるデータ戦略のトレンドであることは明らかです。あらゆる規模や業界の企業がデータメッシュを使用し、データを活用してインサイトや価値を生み出す方法を模索しています。

データメッシュの代替案

データメッシュはデータ管理に対する分散型アプローチを提供しますが、唯一のオプションではありません。データレイクやデータウェアハウスなど従来のアーキテクチャーは、大量のデータの一元化や保存に引き続き広く使用されており、多くの場合、構造化データ機能と非構造化データ機能を融合したデータレイクハウスと組み合わせて使用されています。データファブリックなどの他のモデルは、さまざまなシステム間でのデータ統合やデータオーケストレーション向けの統合レイヤーの構築に重点を置いています。各代替案は、スケーラビリティ、ガバナンス、アクセシビリティに異なる方法で対応しており、組織はニーズや成熟度に応じて選択を行います。

データメッシュの代替案を比較してみましょう。

データメッシュとデータレイク/レイクハウス

データメッシュとデータウェアハウス

データメッシュとデータファブリック

データメッシュの導入

データメッシュの導入には、分散化と共有標準のバランスを取る戦略的アプローチが必要です。以下に、データメッシュの主なステップを示します。

1. パイロットドメインの特定：明確なビジネス価値と高い成熟度を持つ 2 つまたは 3 つのドメインを選択して、小さい規模から始めます。これらのチームは早期導入者として機能し、組織全体に規模拡大する前にデータメッシュモデルを実証します。
2. プラットフォームの構築：データプロダクトを公開、発見、使用するための共通ツールを提供するセルフサービスデータプラットフォームを構築します。これには、ドメインチームの摩擦を低減するためのデータカタログ、API、自動セキュリティ機能が含まれます。
3. 連携ガバナンスの定義：セキュリティ、コンプライアンス、相互運用性に関するグローバル標準を徹底させつつ、ドメインの自律性を確保するガバナンスポリシーを作成します。ガバナンスには、明確な役割、データプロダクトの定義、期待される品質を含める必要があります。

回避すべきアンチパターン

データメッシュが自然な組織パターンに従わずに不適切に構築された場合、混乱や不和を招く可能性があります。データメッシュのアンチパターンとは、役に立つように見えるが、結局はアーキテクチャーのコア原則を損なう、反復的なアプローチまたは実践です。回避すべきアンチパターンには次のようなものがあります。

• データメッシュを、単なるもう 1 つの一元化されたデータレイクとして扱う。
• 文化的な変化を無視する—テクノロジーだけでは、所有権の問題は解決されません。
• ビジネス価値を実証する前に、プラットフォームをオーバーエンジニアリングする。
• データ品質に関する明確な説明責任が欠如している。
• パイロットドメインでデータメッシュモデルを検証せずに、規模拡大を急ぎ過ぎる。

データメッシュに関する 5 つのベストプラクティス

1. 小さく始めて反復する：パイロットドメインを使用して、規模を拡大する前にプロセスを改善します。
2. データを製品として扱う：すべてのデータセットの所有権、SLA、およびユーザビリティ標準を定義します。
3. 共通ツールに投資する：ドメインチームが容易に公開および発見できるようにします。
4. ガバナンスを早期に組み込む：最初から、自律性とコンプライアンスのバランスを取ります。
5. ビジネス成果を重視する：データプロダクトを技術的目標だけでなく、測定可能な価値に整合させます。

ドメイン所有権、堅牢なプラットフォーム、連携ガバナンスを組み合わせることで、従来の集中型モデルのボトルネックを発生させずに、俊敏性、信頼性、ドメインをまたいだコラボレーションを向上させることができます。

測定と指標

成功を評価するには、技術的なパフォーマンスとビジネス成果のバランスを取るデータメッシュ指標が必要です。これらの指標には、以下のようなものがあります。

• データプロダクト品質の SLO/SLA：必須ですが、画一的に適用するのではなく、各ドメインの状況に合わせて調整する必要があります。データプロダクト KPI の例：

  • データの鮮度：合意された時間枠内（毎時、毎日など）に更新されたデータプロダクトの割合
  • 完全性：データセット全体で入力された必須フィールドの割合
  • 可用性：データプロダクトの稼働時間（99.9% など）

• 消費者の採用と再利用：価値の強い指標になり得ますが、正確に測定するには、チーム全体での使用パターンとフィードバックの追跡が必要なことがよくあります。消費者の採用と再利用 KPI の例：

  • データプロダクトごとの一意の消費者数
  • クロスドメイン再利用率：複数のドメインで使用されるデータプロダクトの割合
  • 調査またはフィードバックから得られた顧客満足度スコア

• インサイト獲得までの時間とサービス提供コスト：集中型モデルと比較した効率性向上を強調します。ただし、これらの改善は、組織の成熟度とベースラインプロセスに左右されます。インサイト獲得までの時間とサービス提供コスト KPI の例：

  • データ要求から実用的なインサイト獲得までの平均時間
  • 集中型モデルと比較した運用コストの削減率
  • データ要求のバックログ減少率

• 把握すべき一般的な競合他社とのギャップ：競合他社が苦戦している領域に焦点を当て、データメッシュの原則を使用して競合他社を上回ります。把握すべき競合他社とのギャップ KPI の例：

  • 特定した競合他社の弱点をデータプロダクト機能によって対処した件数（発見可能性の向上、データアクセスの迅速化など）
  • 競合他社に対する、新たなデータプロダクトの市場投入までの時間的優位性
  • 競合他社の見積と比較した、セルフサービス導入率の増加

これらの指標を総合することで、画一的なベンチマークを前提とせずに、データメッシュが俊敏性、信頼性、拡張性を提供しているかどうかを示すインサイトを得ることができます。

データメッシュに関する FAQ