データメッシュとは?

データメッシュは、分散アーキテクチャーフレームワークを使用するデータ管理手法です。

データメッシュの概要

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

データメッシュの定義

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

 

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

placeholder

 

 

データレイクの課題に対するデータメッシュの原則

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


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

 

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

 

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

 

1. 複雑な所有権 データを生成したり、アクセスしたりするプレーヤーが多すぎる場合、データレイクの所有権を定義するのが複雑になります。役割と責任が明確に定義されていない場合、同じデータセットをさまざまな関係者が異なる方法で管理し、利用を困難にするような不整合が生じてしまう可能性があります。同様に、他のデータも、最終的にそれを使用する人によって積極的に管理されていないと、放置されてしまう可能性があります。データメッシュアーキテクチャーを使うことで、データガバナンスをドメインごとに明確に分散することができ、各チームやドメインエキスパートが生成および使用するデータを管理できるようになります。これをバックアップするために、データメッシュでは連携型ガバナンス構造も使用し、データモデリング、セキュリティポリシー、コンプライアンスの集中管理も実現しています。

 

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

 

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

 

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

 

 

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

データメッシュアーキテクチャーの説明

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

 

データメッシュの実現方法をより深く理解できるように、データメッシュアーキテクチャーの 3 つの主要コンポーネントを以下で説明します。

 

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

 

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

 

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

placeholder

データメッシュの活用例:誰がなぜ使用するのか

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

 

一般的なビジネスユースケースを以下に示します。

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

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

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

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

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

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

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

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

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

 

データメッシュアーキテクチャーの主な利点は以下のとおりです。

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

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

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

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

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

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

データ民主化とは要するに、人々が日常業務で直面するデータの課題を解決することです。定義、原則、そして従業員が安心してデータ関連の質問を行い、回答を得られるようにする方法の詳細については、このブログを参照してください。

相互運用性とは、システムまたは製品が、ユーザー側で特別な努力をすることなく、他のシステムまたは製品と連携する能力と定義されます。Techtarget 社は、相互運用性により、組織は効率性を高め、情報とデータをより総合的に把握できるようになると付け加えています。詳細については、この Open MOOC レッスンで、データの相互運用性の基礎と、データの相互運用性のさまざまなタイプとレイヤーについて説明します。

 

データメッシュとデータファブリックは、企業のデータ管理戦略における異なるアーキテクチャーアプローチです。

 

データファブリックとは、AI、機械学習、高度なアナリティクスを統合することで、複雑なメタデータと非構造化情報をシームレスに管理する方法を見つけ出す技術中心のアプローチです。一方、データメッシュは、データファブリック内のすべての技術開発に依存しながらも、データ管理プロセスとそれに依存する人間のユーザーを統合して、人間の視点からデータアクセスや有用性を合理化/簡素化する方法を見つけ出すことに重点を置いています。

 

データメッシュとデータファブリックの間には、いわば鶏が先か卵が先かの関係があります。つまり、データ管理が必要なスピードで進化するには、常に進化するデータファブリックテクノロジーが必要です。しかし、人間のプロセスとや組織戦略の進化が伴わなければ、人々は進歩するデータファブリックテクノロジーを適切に活用することはできません。DOS や複雑なインターフェイスが、今日私たちが享受しているよりシームレスなコンピューターオペレーティングシステムに取って代わられたように、データメッシュやデータファブリックアーキテクチャーも、これらのプロセスとテクノロジーが進歩するにつれて、ますますシームレスに成長していくことになるでしょう。

placeholder

SAP データおよびアナリティクスソリューション

ビジネス全体で最も関連性の高いデータを特定、分析、変換します。

placeholder

ほかでは手に入らないアイデア

お客様のビジネスに役立つ情報を受信ボックスにお届けします。ぜひご登録ください。

twitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixeltwitter pixel