写真：クラウド Watch

　前回は、大規模なデータ分析基盤の構築にあたって、5つの注意点を解説しました。今回からは、その注意点に対応するための目指すべき方向性について、解説していきます。 【画像】図2-2 未来対応型データアーキテクチャイメージ 　McKinsey＆Companyは、生成AIを組織化し管理するためにするべきこととして、最近の記事の中で以下のように述べています。 "データをどのように整理するか、データアーキテクチャはどうするか、ロードマップはどうするかを考えなければならない。" 　さらに、次のようにも述べています。 "適切に構成されたクラウドプラットフォーム、データアーキテクチャ、データガバナンスを持つことで、企業はよりコスト効率よくソリューションを拡張することができる。" McKinsey & Company "The six questions CEOs ask about gen AI"by Alex Singla https://www.mckinsey.com/~/media/mckinsey/email/rethink/2024/10/2024-10-16d.htmlより抜粋翻訳 　大規模なデータ分析基盤において、信頼できるAIの実現には、まずそのインプットとなるデータが信頼できなければなりません。今回は、目指すべきデータガバナンスとデータアーキテクチャについて考えましょう。 【特集】AI時代の大規模なデータ分析基盤構築における、陥りやすい罠と考えるべきポイント ▼【第1回】大規模なデータ分析基盤の構築時に待ち受ける“落とし穴” ▼【第2回】大規模データ分析・AI基盤の目指すべき姿を“データの視点”から考える（本記事） ▼【第3回】データ製品を活用するために必要な、プラットフォームのアーキテクチャ設計はどうすべきか？（12月20日公開） ■ データガバナンス 　データガバナンスとは「データとアナリティクスの作成、使用、評価、管理における適切な行動を決定し、説明責任の枠組みを規定すること」です。データを確実に管理することを保証するものであり、通常、目的に沿うようにデータを管理するデータマネジメントと組み合わせて実施されることで、安全で信頼できるデータを得ることができます。そのデータガバナンスのアプローチは、以前とは変わってきています。 　クラウド以前の時代では、単一の中央チームがデータガバナンスのあらゆる側面に責任を持つ、中央集権的なガバナンスのアプローチが主流でした。そのモデルは、小規模／少量のデータや単一のストレージロケーションを扱っていたときにはうまく機能していました。しかし今や、このアプローチをとるにはデータ管理のスコープが広くなりすぎ、新しいアプローチが必要となっています。 　そこで、データと分析の民主化という名目の下で、多くの企業が中央集権とは逆のアプローチである分権型（分散型）ガバナンスを検討しています。中央ではなく、各ビジネスドメインがデータの主権を保有し、自分たちの手でデータを管理するというものです。しかし、このアプローチでは、各領域で重複した取り組みが必要となり、多くの場合、過剰なコストと一貫性のない信頼できないデータが発生するという問題が発生します。さらに、各ドメインのスキルやリテラシーがかなり高い場合にのみ成り立つアプローチあり、そうでない場合は無政府状態、つまりカオスになる危険性が高いものです。 　そこで考えるべきは、どちらにも傾きすぎない中間のアプローチです。個々のビジネスドメインが従うべき、言語、ライフサイクルステップ、標準、コンプライアンスなど、いくつかの側面における共通の原則や基準を、中央のチームが最低限のレベルで定義し、各ドメインはそれらに合意するものの、運営にはある程度、各ドメインの自主性を残すというものです。そのバランスは、組織の規模や、各ドメインのリテラシーおよび自律性などにより、決定します。このアプローチは、データの所有権と管理責任を“フランチャイズ化”するという言葉で表すとイメージしやすいと思います。 　これからのデータガバナンスは中央とドメインのバランスをうまく保ちながら、徐々にドメインの自律化（フランチャイズ化）を促すことでスピード化をはかる連合型ガバナンスのアプローチを目指していくべきでしょう。 ■ 未来対応型データアーキテクチャ 　かつて、18世紀ヨーロッパで人口急増による需要を支えるため、技術革新が進み産業革命が起こりました。それにより、それまでの手工業から機械工業への移行が進み、生産性が飛躍的に向上しました。21世紀の現代では、AI技術の進化が進み、データの爆発的な増加とその需要を支えるために、データの生産性を飛躍的に向上させる仕組みが必要です。そのためには、データがどのようなものかを定義し、どのように作成されるのかの枠組みを捉え、将来的な自動化にも耐えられるよう、組織で共通のデータの設計図を描いておく必要があります。それがデータアーキテクチャです。 　データは、以前は資産として備蓄することが一般的でしたが、貨幣とは違い、貯めるだけでは価値がありません。使うことで初めて価値をもたらします。ですが、前回お話ししたように、そのままではさまざまな用途にすぐ使える状態ではありません。ビジネス価値を提供するという目的のために、すぐ利用できるよう製品としてのデータを作成するという考え方が現在は主流となっています。その考え方（コンセプト）を「データ製品」と言います。 　製品としてのデータの大量の消費を満たすためには、これまでのように一つ一つのユースケースごとに中央組織が請け負ってデータを作っていたのでは間に合いません。少しでも早くするために、Zhamak Deghaniは、中央組織が一括して管理するのではなく、業務ドメインに所有権と管理責任を移管し、各ドメインがそれぞれデータ製品を作成するというData Meshのコンセプトを打ち出しました。ですが、単純に管理責任を分散するだけでは、前項でも示した通り、労力の分散と冗長化につながり、データ品質が低下します。ドメイン指向と同時に考えるべきは、ドメイン間で無駄なくコスト効率よくコラボレーションするための原則や基準です。 　このように、①データ製品、②ドメイン指向、③コラボレーションを中心としたデータアーキテクチャへのシフトが、AIの進化に対応し、信頼性を育むためには重要です。 □①データ製品の定義とカテゴリー 　データが製品として成り立つためには、やみくもに作られるのではなく、きちんとその利用目的や仕様が定義されたうえで作成され、消費者が利用しやすいようにそれらの情報が明確でなければなりません。よって、データ製品は、特定の目的のために正しく構築され提供されるデータそのものだけでなく、意味、コスト、品質、可用性、パフォーマンスなどの概要を示す詳細なメタデータを伴った、包括的な実体と定義づけられます。 　データ製品にはさまざまな種類が存在し、ガバナンスや使用目的などのレベルに応じて、大まかに、以下の4つのカテゴリーに分類されます。 ・生データ：さまざまなソースシステムから収集された未修正のデータ。主にデータエンジニアがまずその安全性や品質確認で利用。 ・探索可能：履歴化、書式統一など軽度の標準化、キー付与など軽度の統合など、最低限企業として利用可能で安全な形式に設計したデータ製品領域。データサイエンティストやデータサイエンスのアプリケーションがデータ探索に利用。 ・再利用可能：企業のコアとなるビジネスコンセプトを体現する層であり、正規化・非正規化、コード統一、共通のビジネスロジック適用による計算や集約などの処理により、データが論理統合可能な状態となり、品質が高く一貫性を保証した、再利用性の高いデータ製品の領域。ビジネスアナリストがアドホックな分析などに利用するほか、柔軟な組み合わせで次の消費可能データを完成させる役割も持つ。 ・消費可能：一般的なデータマートや分析データセット、業務ファンクション用データセット、フィーチャーストアやベクトルストアなど、特定の分析目的専用に設計されたデータ製品領域。AIや意思決定のために的を絞った洞察を提供するが、専用のユースケース以外での利用は限られている。 　この4つのカテゴリーに当てはまらない特殊なデータ製品の種類として、メタデータがあります。メタデータは「データのデータ」ですが、充実させればさせるほど、付随するデータ製品の品質と安全が確保され、公開され可視化されることにより、ユーザーは安心してデータ製品を利用できるようになります。 　メタデータには以下のようなさまざまな種類があり、それぞれキャプチャする必要があります。 ・テクニカル・メタデータ：構造、データタイプ、アクセス権、プロファイリング、品質、データの場所の定義など ・ビジネス・メタデータ：ビジネス定義、所有権、コンプライアンス、使用ポリシーなど ・セマンティック・メタデータ：データの意味、文脈、相互関連性など ・オペレーショナル・メタデータ：データの流れ/ソースとターゲット/依存関係/変換を示すリネージデータ、データの利用状況、ジョブ実行ログなど 　メタデータは、データカタログツールなどを利用して管理している企業も多いと思いますが、メタデータ自体はデータと共に発生するものであり、データ基盤の信頼性や使い勝手を大きく左右する重要なデータの一種であるため、メタデータもデータ製品の一種として、他のデータ製品と共に注意深く管理・保存する必要があります。そうすることで、たとえツールが変更されたときでもデータが失われることなく、再ロードしてデータアーキテクチャの知識を維持することができるようになります。そして、それらのメタデータを統合的にエンタープライズ・データカタログとして、公開、利用できるような基盤を作っておくことで、ツールに依存しない、より信頼性の高いデータ基盤となります。 　また、最近は「アクティブ・メタデータ」という考え方も浸透してきています。これはガートナー社が盛んに提唱している考え方ですが、AI/MLをメタデータに適用することで、メタデータを活性化させ、データの価値を引き出したり、最適化を行ったりすることです。分析やAIを効果的におこなうには、メタデータは単にカタログ上ではなく、製品としてデータプラットフォーム上に保存することが必要になります。 □②ドメイン指向 　データはソースシステムから収集され生データとして取り込まれてから、データパイプラインの処理により次のカテゴリーへと順番に、より品質の高い高次元のデータ製品へと形を変えていきます。 　このとき、データ製品は、そのデータを一番よく知るドメインによって所有、開発、管理されます。ドメインとは、部署やプロセスや商品など、そのデータを管理するのにふさわしい単位を指し、組織がドメインを定義することにより、データ製品の所有と管理責任も明確に定義されることになります。 　データ製品はドメインごとに設計、開発、生産、運用することで、中央組織によるボトルネックがなくなり俊敏性を実現します。しかし、そのパイプラインが完全に分離したままだと、単なるサイロを増やす結果となり、これまでのサイロ化問題の解決にはなりません。未来対応型でもっとも重要なのはドメイン間のコラボレーションをいかに効率よく、品質良く行うかにかかっています。そのためには、プラットフォームの接続性を上げるのと同時に、データ製品の相互運用性と整合性を維持し、再利用性を上げるよう、全ドメイン共通の原則と基準の制定および合意が必要です。その統一されたガバナンスに基づき、コラボレーションを確保することは、組織全体の責任となります。 □③コラボレーションの実現 　では、コスト効率の良いコラボレーションを実現するために、どのような原則や基準が必要なのか、例を挙げてみてみましょう。 a.データ製品の原則 　例えばTeradataでは、データ製品としてあらかじめ共通に合意しておくべき9つの原則を定めています。 　原則というのは、一般的なガイドラインであり、強制されるものではありませんし、全てのデータ製品が9つ全てをカバーするわけではありませんが、このような原則を設けておくことで、アーキテクチャ策定、ベストプラクティスの設定、基準の設定、問題の解決時などの重大な意思決定時の基礎となりえます。全てのドメインがこれら原則に則り、データ製品を作成、管理する責任を負うことを想定しています。 b.データ製品の共通基準 　ドメイン間でデータ製品の相互運用性を確保するには、ある程度の共通基準が必要です。以下に例を示します。 ・命名基準：命名、略称などの統一基準 ・データタイプ・書式：特定データ項目やデータドメイン（日付、時間、金額など）のデータ型や書式の統一基準 ・参照コード：ソースシステムやアプリケーションごとに異なるコード値の統一基準 ・統合キー：ドメインニュートラルな方法によるサロゲートキー構築の基準 ・品質測定基準：データ品質に関する指標の定義や、継続的な改善プログラム実施など ・セキュリティ基準：データ保護グレード、アクセス方法、監査ログ取得など ・技術の選択：データの格納場所、テクノロジー、ツールなど c.論理統合メカニズムの設計 　さまざまなドメインのデータ製品間の論理統合は、非常に重要でありながらその方法を論じていることが非常に稀であり、難易度も高いと思われているトピックです。大規模なデータの論理統合を行うにあたって、エンタープライズデータモデルはその統合メカニズムとして、重要な役割を果たします。 　エンタープライズデータモデルは、定期的に再利用される可能性のある、ドメイン横断で共通のデータ概念を特定するために使用されます。これらのデータ概念は例えば、顧客、商品、口座といったような企業のコアとなる情報の概念です。これらのドメイン間で共通に必要なデータ概念をエンタープライズモデルとして集約し、結びつきを整えておくことで、さまざまなデータとの論理統合を実現します。その結びつきの整備には、キーの定義や共通データ項目に関する合意などの軽度なガバナンスプロセスが必要です。 　エンタープライズに集約された項目以外のドメイン固有のデータ群は、各ドメインが管理責任を負い、自由に定義可能な部分になります。 　このように、中央（エンタープライズ）と各ドメインのデータ管理責任を明確化し、同時に品質を確保しながら論理統合を行うメカニズムとして、エンタープライズデータモデルが利用されます。 　ここに挙げた以外にも、データ製品のライフサイクルを定義する、その役割と責任を明確化する、End-to-Endのデータ製品のキュレーション・フレームワークを確立するなど、コラボレーションと信頼できるデータ提供のためにできることはたくさんあります。 　今後AIにも対応可能な、大規模なデータ分析基盤の構築にあたっては、適切なデータガバナンスとデータアーキテクチャ、特にコラボレーションのためのデータ設計に取り組むことをお勧めします。 ＊＊＊＊＊ 　次回最終回は、プラットフォーム観点での考えるべきポイントについて解説します。 日本テラデータ株式会社　ワールドワイド・データ・アーキテクト　藪 公子 ・日本テラデータのデータ分析プラットフォームにおける、リファレンス・アーキテクチャ策定の責任者。ワールドワイドなデータアーキテクチャチームの一員としてインフォメーション・アーキテクチャの分野において日本をリードしている。 金融、通信、自動車、製薬など多岐にわたる各種業界において、将来を見据えたデータ活用の目的やデータ管理などのコンサルティングを行い、企業のデータ統合・分析基盤のアーキテクチャ策定や構築を支援。