データ管理は「目的に合わせる」から「ギャップを埋める」へ

　データは完全なものではなく、常に「部分」として存在する。そのため、たとえ大きなビジネスプロセスが存在していても、データアプリケーション構築の仕方は「分裂的」だ。すべてのデータアプリケーションはデータを部分に分割し、そのうちの一部分だけ取り込むよう設計されている。

　しかし、アナリティクスの段階では「分裂」から「融合」へ移行する。分割され、失われたデータ間の関係性を復元するということだ。ビジネスプロセスの中のデータは欠落している部分が多くあるため、いかにその穴を埋めるかがアナリティクスの鍵となる。

　データには、いわゆる「もつれ（エンタングル）」が存在する。「もつれ」とは量子力学の用語で、2つの要素が共鳴すると、その2つがどんなに離れても共鳴が維持される状態のこと。ビジネスプロセスにも「もつれ」は存在しており、どんなにまばらなデータや削除されたデータでも、「もつれ」を頼りに復元することができる。

　「ただ、それをするための方法を考えなければなりません」とベイヤー氏は話す。

データは「設計した通りにとどまらない」が当たり前

　「データには物理があり、データ管理にも物理があり、それがデータ管理環境に問題を引き起こします」とベイヤー氏は話す。

　最初にデータをキャプチャする時は、その時々の目的があり、目的に沿った形で収集するだろう。しかし、そのデータは、やがて異なる形・方法で再利用されるようになる。再利用する時の都合で便宜的にデータを接続することで、データは“固まって”しまい、各アセットの変更が難しくなる。

　そうなってしまう原因の1つに「データエントロピー」がある。データエントロピーとは、データがあちこちに飛散し（「疎」の状態）、設計した通りの形にとどまらない状態のことを指す。


　エントロピー状態を見ると「間違っている」「あるべき状態ではない」ように思えるかもしれないが、これはある意味で正常な状態だ。「CDAOは、データが完全になりえないことを受け入れる必要がある」とベイヤー氏はいう。

　エントロピーの発生には、大きく4つの要因がある。

　1つ目は、データをキャプチャする時。たとえばアプリケーションを2つ作ったとして、うち1つは図1にある右上の図の青いデータをキャプチャし、もう1つはオレンジ色のデータをキャプチャしたとする。どちらのデータも部分的であり、それぞれのアプリケーションの目的に沿った必要最低限のものだ。つまり、すでにこの時点で「意図的に疎」なデータが作られている。

　2つ目は、ビジネスプロセスの特性から来るものだ。ビジネスプロセスはそもそも変化するように設計されており、反転したり分岐したりと変化することが前提となっている。そのビジネスプロセスの変化に対応するうちに、データエントロピーが発生する。

　3つ目は、データの価値に関わることだ。データの価値は、特定の視点に基づいて定義される。特定の視点というのは「次のステップで何をするか」という視点だ。それを意識して「どのデータをキャプチャするか」を定義することになり、結果としてまたエントロピーが発生する。

　4つ目は、データの設計の寿命がデータそのものの寿命と異なることに起因する。たとえばあるシステムにおいて、特定のビジネスタスクのステータスの値が12個までしか持てない設計がされていたとする。しかし、後からビジネス部門が「15個まで持てるようにしたい」と言ってきたら、新しい値を組み込まなくてはならない。データはある観点で設計され、後から観点が変わることがあるということだ。そしてまた、エントロピーを抱えることになる。

　「これら4つのことを、念頭に置いてください。なぜなら、実はこれがビジネスシグナルが発生する由来だからです。データエントロピーは、ビジネスシグナルに関係しているのです」とベイヤー氏は説明した。 【次ページ】データ要件とデータ内のビジネスシグナルの違い