大規模データ分析・AI基盤の目指すべき姿を“データの視点”から考える

　前回は、大規模なデータ分析基盤の構築にあたって、5つの注意点を解説しました。今回からは、その注意点に対応するための目指すべき方向性について、解説していきます。

　McKinsey＆Companyは、生成AIを組織化し管理するためにするべきこととして、最近の記事の中で以下のように述べています。

　さらに、次のようにも述べています。

　大規模なデータ分析基盤において、信頼できるAIの実現には、まずそのインプットとなるデータが信頼できなければなりません。今回は、目指すべきデータガバナンスとデータアーキテクチャについて考えましょう。

データガバナンス

　データガバナンスとは「データとアナリティクスの作成、使用、評価、管理における適切な行動を決定し、説明責任の枠組みを規定すること」です。データを確実に管理することを保証するものであり、通常、目的に沿うようにデータを管理するデータマネジメントと組み合わせて実施されることで、安全で信頼できるデータを得ることができます。そのデータガバナンスのアプローチは、以前とは変わってきています。

図2-1 データガバナンス　3つのアプローチ

　クラウド以前の時代では、単一の中央チームがデータガバナンスのあらゆる側面に責任を持つ、中央集権的なガバナンスのアプローチが主流でした。そのモデルは、小規模／少量のデータや単一のストレージロケーションを扱っていたときにはうまく機能していました。しかし今や、このアプローチをとるにはデータ管理のスコープが広くなりすぎ、新しいアプローチが必要となっています。

　そこで、データと分析の民主化という名目の下で、多くの企業が中央集権とは逆のアプローチである分権型（分散型）ガバナンスを検討しています。中央ではなく、各ビジネスドメインがデータの主権を保有し、自分たちの手でデータを管理するというものです。しかし、このアプローチでは、各領域で重複した取り組みが必要となり、多くの場合、過剰なコストと一貫性のない信頼できないデータが発生するという問題が発生します。さらに、各ドメインのスキルやリテラシーがかなり高い場合にのみ成り立つアプローチあり、そうでない場合は無政府状態、つまりカオスになる危険性が高いものです。

　そこで考えるべきは、どちらにも傾きすぎない中間のアプローチです。個々のビジネスドメインが従うべき、言語、ライフサイクルステップ、標準、コンプライアンスなど、いくつかの側面における共通の原則や基準を、中央のチームが最低限のレベルで定義し、各ドメインはそれらに合意するものの、運営にはある程度、各ドメインの自主性を残すというものです。そのバランスは、組織の規模や、各ドメインのリテラシーおよび自律性などにより、決定します。このアプローチは、データの所有権と管理責任を“フランチャイズ化”するという言葉で表すとイメージしやすいと思います。

　これからのデータガバナンスは中央とドメインのバランスをうまく保ちながら、徐々にドメインの自律化（フランチャイズ化）を促すことでスピード化をはかる連合型ガバナンスのアプローチを目指していくべきでしょう。

未来対応型データアーキテクチャ

　かつて、18世紀ヨーロッパで人口急増による需要を支えるため、技術革新が進み産業革命が起こりました。それにより、それまでの手工業から機械工業への移行が進み、生産性が飛躍的に向上しました。21世紀の現代では、AI技術の進化が進み、データの爆発的な増加とその需要を支えるために、データの生産性を飛躍的に向上させる仕組みが必要です。そのためには、データがどのようなものかを定義し、どのように作成されるのかの枠組みを捉え、将来的な自動化にも耐えられるよう、組織で共通のデータの設計図を描いておく必要があります。それがデータアーキテクチャです。

　データは、以前は資産として備蓄することが一般的でしたが、貨幣とは違い、貯めるだけでは価値がありません。使うことで初めて価値をもたらします。ですが、前回お話ししたように、そのままではさまざまな用途にすぐ使える状態ではありません。ビジネス価値を提供するという目的のために、すぐ利用できるよう製品としてのデータを作成するという考え方が現在は主流となっています。その考え方（コンセプト）を「データ製品」と言います。

　製品としてのデータの大量の消費を満たすためには、これまでのように一つ一つのユースケースごとに中央組織が請け負ってデータを作っていたのでは間に合いません。少しでも早くするために、Zhamak Deghaniは、中央組織が一括して管理するのではなく、業務ドメインに所有権と管理責任を移管し、各ドメインがそれぞれデータ製品を作成するというData Meshのコンセプトを打ち出しました。ですが、単純に管理責任を分散するだけでは、前項でも示した通り、労力の分散と冗長化につながり、データ品質が低下します。ドメイン指向と同時に考えるべきは、ドメイン間で無駄なくコスト効率よくコラボレーションするための原則や基準です。

　このように、①データ製品、②ドメイン指向、③コラボレーションを中心としたデータアーキテクチャへのシフトが、AIの進化に対応し、信頼性を育むためには重要です。

図2-2 未来対応型データアーキテクチャイメージ

③コラボレーションの実現

　では、コスト効率の良いコラボレーションを実現するために、どのような原則や基準が必要なのか、例を挙げてみてみましょう。

a.データ製品の原則

　例えばTeradataでは、データ製品としてあらかじめ共通に合意しておくべき9つの原則を定めています。

図2-3-1 データ製品9つの原則

　原則というのは、一般的なガイドラインであり、強制されるものではありませんし、全てのデータ製品が9つ全てをカバーするわけではありませんが、このような原則を設けておくことで、アーキテクチャ策定、ベストプラクティスの設定、基準の設定、問題の解決時などの重大な意思決定時の基礎となりえます。全てのドメインがこれら原則に則り、データ製品を作成、管理する責任を負うことを想定しています。

b.データ製品の共通基準

　ドメイン間でデータ製品の相互運用性を確保するには、ある程度の共通基準が必要です。以下に例を示します。

・命名基準：命名、略称などの統一基準
・データタイプ・書式：特定データ項目やデータドメイン（日付、時間、金額など）のデータ型や書式の統一基準
・参照コード：ソースシステムやアプリケーションごとに異なるコード値の統一基準
・統合キー：ドメインニュートラルな方法によるサロゲートキー構築の基準
・品質測定基準：データ品質に関する指標の定義や、継続的な改善プログラム実施など
・セキュリティ基準：データ保護グレード、アクセス方法、監査ログ取得など
・技術の選択：データの格納場所、テクノロジー、ツールなど

c.論理統合メカニズムの設計

　さまざまなドメインのデータ製品間の論理統合は、非常に重要でありながらその方法を論じていることが非常に稀であり、難易度も高いと思われているトピックです。大規模なデータの論理統合を行うにあたって、エンタープライズデータモデルはその統合メカニズムとして、重要な役割を果たします。

図2-3-3 エンタープライズデータモデルによる統合メカニズムのイメージ

　エンタープライズデータモデルは、定期的に再利用される可能性のある、ドメイン横断で共通のデータ概念を特定するために使用されます。これらのデータ概念は例えば、顧客、商品、口座といったような企業のコアとなる情報の概念です。これらのドメイン間で共通に必要なデータ概念をエンタープライズモデルとして集約し、結びつきを整えておくことで、さまざまなデータとの論理統合を実現します。その結びつきの整備には、キーの定義や共通データ項目に関する合意などの軽度なガバナンスプロセスが必要です。

　エンタープライズに集約された項目以外のドメイン固有のデータ群は、各ドメインが管理責任を負い、自由に定義可能な部分になります。

　このように、中央（エンタープライズ）と各ドメインのデータ管理責任を明確化し、同時に品質を確保しながら論理統合を行うメカニズムとして、エンタープライズデータモデルが利用されます。

　ここに挙げた以外にも、データ製品のライフサイクルを定義する、その役割と責任を明確化する、End-to-Endのデータ製品のキュレーション・フレームワークを確立するなど、コラボレーションと信頼できるデータ提供のためにできることはたくさんあります。

　今後AIにも対応可能な、大規模なデータ分析基盤の構築にあたっては、適切なデータガバナンスとデータアーキテクチャ、特にコラボレーションのためのデータ設計に取り組むことをお勧めします。

＊＊＊＊＊

　次回最終回は、プラットフォーム観点での考えるべきポイントについて解説します。

日本テラデータ株式会社　ワールドワイド・データ・アーキテクト　藪 公子

日本テラデータのデータ分析プラットフォームにおける、リファレンス・アーキテクチャ策定の責任者。ワールドワイドなデータアーキテクチャチームの一員としてインフォメーション・アーキテクチャの分野において日本をリードしている。

金融、通信、自動車、製薬など多岐にわたる各種業界において、将来を見据えたデータ活用の目的やデータ管理などのコンサルティングを行い、企業のデータ統合・分析基盤のアーキテクチャ策定や構築を支援。