第２回 データ管理されていないと何が問題か
データ管理の取り扱う範囲も時代と共に、拡充している。データ管理の知識体系（DMBOK)を出版しているDAMAインターナショナルでは、改訂版を7月にリリースしたが、600ページを超えるボリュームとなっている。ビッグデータやデータサイエンスはもちろん、昨今のデータ漏洩の世評も反映してか、データ取扱倫理、データ管理の成熟度や組織、役割、チェンジマネジメントといった項が追加されている。データ管理として取り組むべきことを再認識する際にリファレンスしてみるのも良いのではないか。
さて、今回は、データ管理されていないことによりどのような問題が発生してきたかを振り返ってみよう。どの企業システムでも良く見られた事例ではなかろうか。
一つ目は、データの二重入力によるデータ不整合が発生しているという問題。1990年代後半から2000年代にかけて、基幹システムの構築においてERPの導入が盛んに行われた時代で散見される。A社では、ERPを導入した新システムを構築したが、一部のデータは、既存のレガシーシステムから入力せざるを得ない状況が続いており結果としてERPとレガシーシステムとの間でデータの二重入力が発生している。二重入力故に、レポート間で数値が違っているということが時々発生している。その結果、新システムで全ての業務を賄うことができず、レガシーシステムの一部を残さざるを得ない状況だ。
一部の特定のレポートが、既存システムからしか出力することができないため、このような現象となった。ERP導入時に、新システムで必要とするデータは、データモデルを作成して分析していたのに何故このようなことになってしまったのか。これは、既存システムのリバースが適切に行われていなかったといえばそれまでだが、新システム構築後の、データアーキテクチャをきちんと描いていなかったことが要因ではなかろうか。
データアーキテクチャとは、企業内の何処で、そんなデータが発生し、いかなる変遷を経て蓄積されているかが論理、物理レベルで可視化したものである。
これと類似した事例として、基幹系システムでの取引明細と財務データを元にした情報系システムでの集約データでの不一致がある。即ち、財務会計上の部門単位の売上と部門ごとの販売管理システムでのトランザクションを積み上げたものが一致しないということである。データの鮮度やデータの源泉がどこかという二つ目の問題とも絡むが、企業内の何処でどのようなデータが蓄積され、その流通経路を明示したデータアーキテクチャ不在による部分システム化の顛末ではなかろうか。
二つ目は、現存するDWHから出力されるデータが、事業部毎に異なったものであるということ。そのため、各事業部のデータを単純集計できないといった実体があるという。例えば、売上データの計上基準が異なっていたり、締め日が異なっているといったことが挙げられる。基幹系システムの再構築が一段落した後に蓄積されたデータを活用するために、ユーザ部門からの要請によりDWHの構築が盛んに行われたが、企業内で類似したDWHが乱立していった時代だ。
事業部毎にDWH上に蓄積するデータのメタデータ定義はきちんと行われているのだが、DWH上の売上データがどのデータを源泉として、どのように加工出力されているのかが分からなくなっているという「データリネージ」問題が浮き彫りになってきた。
例えば、DWH上の売上金額、請求金額がどのような過程を経てきたかが解らなくなっているということだ。請求金額は出荷金額を請求月単位で集計したものであり、さらに出荷金額は複数の受注を1回の出荷単位でまとめたもの、そして受注金額は受注明細を受注単位で合計したもの。そして１つの受注明細金額は、商品単位の単価と注文数量によって決まってくるわけだ。このように、あるデータがどのような変遷を経てきたかを明らかにすることにより、利用者にとって欲しいデータが売上金額なのか請求金額なのかわかる。また、受注金額が何処に影響してくるかもわかる。
現行システムを解析してデータの変遷を明らかにしておくことは非常に有益なことで、明らかにされた基幹システムのアウトプットデータを入力源として各種次元で集約した戦略的なDWHが構築できる。
メタデータ管理は、RDBの登場と共に必要に迫られて発生してきた。その定義は、DBMSでのシンボリック名（カラム名）、型、桁数とその論理名、その属性の意味定義。それとホスト言語でハンドリングするための名称、型・桁の定義などが主であった。そして、それらの属性が、どのプログラムやどの画面・帳票で参照されているかといったシステム保守時に必要な情報を定義していた。
ところがDWHなどで、蓄積されたデータを活用するという局面で見ると、そのデータが何処で生成され、いかなる変遷をへて加工されて作成されたデータなのかのリネージ定義が求められるようになった。ETLツールを使っていれば、大丈夫という声があるが、あくまでもツール内での限定された範囲でしか解らない。
三番目の事例は、グローバルに工場を持つ企業において、同一商品にも関わらず工場で異なったコードが振られているという実態があり、これでは、全社での商品別の売り上げが把握できない。この現象は企業買収や合併などにより、工場ごとに個別のシステムが稼働していることによる。ビジネスを継続しながら、拡大を続ける上でやむ追えない選択肢であるが、データ分析・活用という視点では、問題があるということだ。ビジネスの拡大、新たなビジネスモデルを迅速に立ち上げるためのM&Aが盛んに行われてきた結果だ。
コードの不統一や同じ実体を指すマスターが複数存在するという事実は、多くの企業で起こっており、マスターデータ管理をやらねばというのが、ビッグデータ登場以前の一大ムーブメントであった。データ管理上、マスターデータを一元管理するなど最も基本的な要件と思われるが、なぜそれができなかったのか。ERPを導入すれば、リソースは一元管理でき業務プロセスも標準化できるとの謳い文句に載った結果、企業あるいは企業グループ内に、ERPシステムが乱立した、そしてERPシステム毎にマスターを持った孤島システムが乱立した。
システムインフラの変遷による要因も考えられる。メインフレーム中心でシステム構築していた時代に、データ管理を行っていた企業でも、オープンシステムの乱立により、データ管理が行き届かなくなり無法地帯が増えていったということだ。
マスター管理は、システム内での統一からシステム間、そして企業内、企業グループ内そして企業間での必要性に迫られている。業界内での標準データモデルやデータ交換書式の統一化などが行われてきたが、データ流通は業界内に留まらず、寧ろ業種を超えてのデータ交換のためのメタデータが必要となっている。
このような状態を見るや「マスターデータ管理が必要です」ということで、MDMツールを提案してくるというベンダー戦略に、苦渋をなめたユーザ企業も多いだろう。マスターデータ管理は、1つの事実を認識するためのメタデータ定義、統一的なコード定義、そして、それらを維持していくためのビジネスプロセスを確立することが重要であり、ツールの導入だけで解決できる問題ではなかった、と気づいた時には後の祭りであった。
ビッグデータや深層学習に隠れているが、MDMは依然として大きなテーマとなっている。今表面化していなくても、MDMができていないと、ビッグデータの活用時に、困ったということに気づくことになる。
以上、データモデルに基づくデータアーキテクチャ、メタデータ管理、マスターデータ管理というデータ管理に起因した問題を歴史的に振り返った。現在も例示のような問題を抱えている企業も多いのではないだろうか。ビッグデータの活用やAI利用が全てを解決してくれるわけではない。それ以前に、企業内に蓄積された業務データの整備にも目を向ける必要があるのではないだろうか。
以上
（連載）
第１回 なぜ今データ管理が必要なのか －データ管理の歴史を振り返る （こちら）
第２回 データ管理されていないと何が問題か
第３回 改めてデータ管理とは何か、そして今データ管理に何が求められているか
■著者プロフィール
真野 正（まのただし）株式会社データアーキテクト 代表取締役
大手SI会社勤務（株式会社シーエーシー他）を経て2005年データアーキテクトとして独立。システム基盤はメインフレーム、C/S、Web系を経験、RDB黎明期より携わり、データモデリングは、概念レベルにとどまることなく、実装を意識した設計を心掛けている。モデリングからDBA、SQL性能改善までと幅広くデータ系全般をカバー領域として多くのプロジェクトに携わる。主な著書に、実践的データモデリング入門（2003年翔泳社刊）、ITエンジニアのためのデータベース再入門（2017年リックテレコム刊）がある。