真のデータウェアハウスには意味の統合が必要

今の“データウェアハウス“が抱える問題

「データウェアハウスの父」とも呼ばれるビル・インモン氏が、最近LinkedIn上に公開した記事が議論を呼んでいる。

THE DATA WAREHOUSE BLUES（データウェアハウス・ブルース）

この記事の主旨を、私は次のように受け取った：

データウェアハウス/データウェアハウジングの本質とは、エンタープライズ（組織横断）でのデータの統合である
データの統合なしではデータ構造は瓦礫と化す
データウェアハウスを名乗り優れたデータ管理インフラを備えているツールであっても、データの統合は取り残されている
コンサルタントやベンダーがデータ統合を無視すると、役立たないデータ構造の責任は構築されたデータウェアハウスに押し付けられる

みなさんはどう思われるだろうか。長文だが、データウェアハウスやデータエンジニアリングに関わる方にはぜひ読んでいただきたい。

インモン氏が主張しているデータの統合とは、「データの意味の統合」である。

すなわち本来のデータウェアハウスとは、各事業や部門ごとに異なる視点で整備されたデータではなく、全社横断で意味が統合されたデータ（enterprise view）を提供することである、と述べている。

たとえば「顧客」「売上」「契約」といったデータの意味と関係性が、部門やシステムごとにずれていて一致しない。そのため部門やシステム横断した売上金額合計が、集計する人によってばらばらになる。みなさんもそんな経験があるだろう。

このようなデータをそのまま「データウェアハウス」ツールに大量に蓄積していても、意味がない。

それは“ウェアハウス”ではなく、信用できないデータを放り込んだデータ“沼”でしかない。

意味が統合されたデータがAI活用の鍵

データ沼を本来のデータウェアハウスにしなければ、データ利活用が準備できた状態とは言えない。

特にAIにデータを検索させ、適切な回答や洞察を得るのは難しい。

最近のAIの回答は、個人的な相談であればほぼ満足できる。

しかし世の中に知られていない、あなたの会社の過去の売上やそれを基にした需要予測について、適切で、できるかぎり正確な回答をもらうためには、AIにあいまいではなく明確な答えが出るデータ、すなわち意味が統合されたデータを提供する必要がある。

意味が統合されたデータの例：

データが適切なビジネス用語で命名されている、もしくは用語と紐づけられている
例：Aシステムの「CUSTOMER」テーブルとBシステムの「client」テーブルは、ビジネス用語の”契約者“のみ管理していて”見込客”は含まない
ビジネス上の関係性や制約が適切に表現されている
例：一件の受注内容を分割して出荷できる→「受注」データ：「出荷」データ＝１：多
値の単位が統一されている
例：金額は１００万ではなく、１，０００，０００円というように、日本円かつ単位を省略せずに表記する
レコードの重複がない、もしくは重複していることが明示されている
例：“米田太郎”の顧客データは“出田太郎”の改姓前のデータ

etc…

残念ながら、多くの組織ではこのような意味が統合されたデータは整備されていない。そのため、AIの回答もソースとなるデータも信頼できないことが多い。

最近システム情報誌の見出しに「AI-Ready」を見かける事が多いが、こうしたキーワードが流行るのは、このような状況の裏返しなのだろう。

論理データモデル図からはじめる意味の統合

データウェアハウスツールの中には、「セマンティックレイヤ」と呼ばれる機能を提供し、ビジネス指標や用語の定義を揃えることで意味の統合を支援するツールがある。多くはBI分析向けに、指標と関連するデータ項目、導出ロジック、集計軸（ディメンション）などを定義するものだ。指標と項目の名称は、日本語のビジネス用語を使って命名できるのでビジネスユーザからはわかりやすい。

これらが事前に整備・公開されていれば、ビジネスユーザは確認したい指標を選択し、必要な期間や集計軸を指定することで、集計結果が確認できる。

セマンティックレイヤは、部署やプロジェクトといった比較的小さな範囲で意味を統合するのはうまくいく。しかし様々な指標と、数千、ひょっとすると数万の関連するデータ項目を、事業や部門を横断して管理しようとすると、破綻する。なぜなら、必ずと言っていいほど同音異義語/異音同義語が出てきて、同じ名称の指標や項目が「同じ概念」なのか「粒度や前提が異なる別物」なのかが分からなくなるからだ。

それらを判定するには、導出ロジックだけでなく、その項目が属する業務実体や粒度、結合関係、参照データといった前提の確認が必要になる。そのために登録された定義を確認することになるが、テキストだけで表現された定義は、データの粒度やその関係性、集計軸などの解釈が人や部署ごとにぶれやすく、認識を統一するのは難しい。

そこで、これらの前提を図として明示し、整合性を担保する“設計図”として、論理データモデル図が有効になる。

また論理データモデル図は、データウェアハウスのデータ構造の基本設計成果物そのものだ。データ沼のデータについて改めてビジネスの前提を確認し、整合性のとれた論理データモデル図を描き、その結果を物理テーブル/ビューの設計に反映していけば、意味の統合が実現し、本当のデータウェアハウスを構築することができる。

論理データモデル図とデータ利活用の質を向上させるデータガバナンス

実は、意味の統合に終わりはない。組織がビジネスを継続する限り、新しいビジネス概念と用語が生まれ、関係性は変わり続ける。この変化をキャッチアップするためには、ビジネスとシステムを監視し、変化に基づき論理データモデル図を改訂し、物理実装へ反映し続ける全社的な仕組み、つまりデータガバナンスが欠かせない。ガバナンスをしなければ、エンタープライズビューが崩壊し、きれいなデータウェアハウスも沼に戻ってしまう。

もしあなたの組織の“データウェアハウス”が活用されず、データ利活用も停滞気味なら、意味の統合が実施されているのか確認してほしい。論理データモデル図とデータガバナンスを見直し、主要な指標に関連するデータ項目から段階的に統合していくことが、成功への第一歩となるだろう。