JDMC会員による「リレーコラム」。
メンバーの皆さんそれぞれの経験・知見・想いをリレー形式でつなげていきます。
今回、バトンを受け取ったのは、データアーキテクトの真野正さんです。
メタデータはデータの証明書である
JDMCの活動が活発に行われていることが証明しているように、データマネジメントという言葉は広く普及してきている。ところが、データマネジメントといった場合、人によって受取り方は様々である。JDMC会員の中でも一様ではない。
少し前までは、「データ管理」と呼ばれることが多かった気がする。私がデータ管理という言葉を最初に耳にしたのは「IRM研究会」ではなかろうか。IRMは情報資源管理の略で、80年代半ばの、RDBが出始めの頃であった。オプティマイザの性能がよくないため、テーブル間のジョインを禁止したり、検索条件のちょっとした記述方法でインデックスが使われたり、使われなかったりという時代だ。
それでもRDBの登場は、データを一元管理するというデータベース本来の考え方を推進するものであった。RDB以前には、各プログラムでデータ定義をしていたのだが、RDBによりデータ定義は、DB側で行うべきものとなったわけである。
その頃のデータ管理というとRDBMSのディクショナリに近い、メタデータ管理のことを指すことが多かったように思う。私が業務としてDOA（データ中心アプローチ）でのシステム開発の推進や、メタデータ管理専用のデータベース（リポジトリィともいう）のコンサルティングをしていたせいかもしれない。そこでのメタデータ管理の目的はと言えば、DOA、システム開発・保守の効率化という側面が大きかった。
ある機能追加を行うために、データ項目の変更が必要となったケース、例えば、金額が今まで円単位でよかったのが、銭単位までの精度が求められるようになったとする。どのテーブルでその「金額」項目を使用していて、それらのテーブルを参照しているプログラム・モジュールは何か、あるいは、画面・帳票のどの項目にあたるか、どのバッチジョブに組み込まれているプログラムか等々と、その影響範囲を調べて、その保守に要する工数を算出するのに、メタデータは有効であった。
CASE（設計情報を元にプログラムを自動生成することおよびツールを指す）では、このメタデータをどのような構造で保持しているかが肝であった。即ち、メタデータは、システム開発や保守担当者のためのものであった。
その後、社内に蓄積された取引データを活用してマーケティング活動に利用しようということで、DWHの構築やBIツールが登場してきた。それらのツールにおいても、メタデータ定義としてのディクショナリが付属していた。しかし、それは、RDBMSのディクショナリのようにツールを動作させるためのものに過ぎなかった。即ち、データを利用しようとする人にとって必要な辞書とはなりえていなかった。
集計加工されたデータを利用しようとしている局面を思い描いていただきたい。そのデータ（例えば当月末在庫）は何処で作成されたものか。それは、特定の倉庫のものか、または全倉庫を集計したものか。全倉庫のものとすれば倉庫によって在庫の棚卸日が異なっていないか。関連物流会社で保管している在庫は含むのか等々……いざそのデータを利用しようという時に、様々な疑問が湧いてくる。
データ活用が喧伝されている現在、利用者が今利用しているデータが、何処で発生し、どのような変遷を経て、加工されて手元にあるのか、それを記したものが必要であることは明らかだ。
食品・流通業界に目を向けてみる。肉牛にICチップを付加した個体識別番号を付与し、スーパーなどでのパック詰めされた肉がどこで加工され、いかなる流通経路をたどって、どの生産者が飼育していた牛なのかまでを追跡できるトレーサビリティシステムが整備されている。
背景には、消費者に安心・安全なものを提供しなければならないということがある。少し前に、食品の産地を偽った偽装表示事件が相次いだ。外部データの流通が増えてきたが、データが正しいと言えるのか。また何をもって、正しい／正しくないをのかを判断するのかが肝心である。メタデータを使ってデータの出所を証明し、データのトレーサビリティが実現できるかもしれない。そうなれば、メタデータが添付されていないデータは正しいデータとは言えなくなる。
データの品質証明書としてのメタデータの属性としては、何が必要となるだろうか。初期のシステム部門向けだった時のように、意味定義、長さ、桁数、Oracle、Javaといった言語用名称だけでは不十分だ。トレース可能な、データの発生源から加工の変遷、データ鮮度を示す更新頻度、定義域等々が必須となろう。そして、そのメタデータと照合してデータが正しいことを証明する機関の証明書の添付が義務付けられるようになるだろう。社内であれば、IT部門からは独立したデータ監理部門が、社外データについては、専門機関の証明書が必要となってくるのではないか。
そのようなわけで、データ活用のためには、メタデータの整備を避けて通ることができなくなる。同じ意味のデータか異なったデータかをきちんと認識して、一つ一つのデータ項目の意味を定義していくという（気が遠くなるほど）地道な作業が必要だ。メタデータ定義のために、データモデリングが必要であることは言うまでもない。
真野 正（まの ただし）
株式会社データアーキテクト代表取締役。1983年よりCACにてシステム開発、データモデリング、IRMコンサル、技術調査・整備などに携わる。2005年同社を退職し、ITコンサルタントとして独立開業。データアーキテクチャ領域を中心としたコンサルティング、開発プロジェクト支援や執筆・講演などを主業務とする。専門は、データモデリング、データリポジトリィ・モデリングツール評価、データベース管理者（DBA）業務。著書に『実践的データモデリング入門』（翔泳社）、『独習DB設計』（翔泳社）ほか多数。
*～*～*～*～*～*～*～*～*
次回のコラムのバトンを受け取ったのは、小杉 潔さん（株式会社HGSTジャパン）です。お楽しみに！