コンプレックスデータの特徴とは

宇宙を「ライトマター」と「ダークマター」に分けられるように、データの世界も「シンプルデータ」と「コンプレックスデータ」に分けることができます。

宇宙において私たちが観測できるもののほとんどは、ライトマター（惑星、恒星、銀河など）です。コンセンサス理論によると、私たちに見えないもの（「ダークマター」）はその何倍も存在します。

エンタープライズITデータの世界において、私たちが扱うもののほとんどはシンプルデータ（表、行、列、フィールドなど）です。このシンプルなタイプのデータを組み合わせて結び付けることにより、かなり凄いことができます。

しかし、往々にして活用が進まないのがコンプレックス（複雑な）データです。これは私たちの周りのあらゆる場所に存在しています。契約書、研究ノート、メール、レポート、ログファイルなどがこれに該当します。また、シンプルながら標準にほとんど準拠していないデータが多数ある場合、これを結びつけた結果、複雑なものが生みだされます。

シンプルなデータでは上手くいく馴染みのツールやテクノロジーも、複雑なデータタイプはなかなか上手く扱えないということに、皆さんもどこかの時点で気づく（気付いた）ことでしょう。

思考実験

ここで、よくあるビジネス課題に対処しなければならないとします。あなたが勤めている銀行にはさまざまな部門があります（カスタマーサービス、法務、マーケティングなど）。ここにおいて複数の主要システム（振込口座、ローン、投資など）を対象として物事を包括的に把握しなければならないとします。

これらの業務部門のそれぞれは、関連する複数の主要システム（それぞれが若干異なる）すべてを対象とし、それらのデータを関連付けて把握したいと考えています。しかしこれらの主要システム内のデータはどれも、そもそもそのように関連付けられることが想定されていません。

例えば、ビジネスユーザーがKPIなどのシンプルデータをそれぞれの主要システムから取り出し、ダッシュボードなどで関連付ける場合を考えてみましょう。この場合、必要なデータを関連付けて表示させることは、それほど難しくないでしょう。

しかし、これらの主要システムに含まれている元のデータは、本来的に複雑なものです。例えば、ローンの文書、口座記録、処理ログのようなデータです。ここで話が面白くなるのは、各業務部門によってこれらのコンプレックスデータを関連付ける方法が、それぞれのニーズによって異なるということです。例えば、法務部門が求めるものは、マーケティング部門が求めるものとは違っているでしょう。

ここで見られるパターン

これと同じパターン（「コンプレックスデータの存在」および「複数のソース/利用者」）は、驚くべきほど多くの場所に出現します。例えば、金融サービス（銀行業、取引、保険など）でこういったことが発生することは容易に想像できるでしょう。彼らが扱う主要データは本来的に複雑なのですから。

さてそれでは、製薬について考えてみましょう。

例えば、自分のあらゆる研究活動において、「糖尿病」に関して知っていることすべてを整理したいとします。このユースケースでは興味深いことに、この1つのトピックから他のトピック（インシュリン、遺伝子など）へと話が展開していきます。

これも「多数のユーザーと多数のソース」という同じパターンですが、若干違うのは、「コンセプトが極めて構造化されている」ことと「その相互の関係性」です。

他の例としては、飛行機や精製所のような極めて複雑な製造業があります。あるいは、公共安全への取り組みなどがあります。または出版や不正検知もあるでしょう。こういった「本来的に複雑なデータ」にはパターンが存在しますが、これは皆さんに馴染みのシンプルデータの世界とはかなり違います。

関連付けをより優れたものに

それでは、コンプレックスデータとシンプルデータの違いは何でしょうか。これは「複数データソース間の関連付けの手法」に関わってきます。

データを関連付けるのは、そこから価値を生み出すためです。顧客のリストを関連付けることで、各人が何にどのくらいお金を遣ったのかわかるようにすれば、「優良顧客」および「何が購入されているのか」に関する、より価値の高いリストが得られます。

シンプルデータの場合、このような関連付けは「customer_id」などで行います。

例えば、顧客への請求書（PDF）を渡され、前述のような優良顧客を見つけるようにと言われたとします。これはそんなに簡単にはできないでしょう。

この場合、まずPDFをスキャンしてテキストに変換したあと、主要フィールドに検索を実行し、必要な内容を抽出することになるでしょう。ここで重要なのは「データを活用するには、関連付けをしなければならない」ということです。

ここにおいて、「データに関するデータ」である「メタデータ」が登場します。ほとんど構造がないバイトのシーケンスから顧客の名前のように見えるものなどを選択することで、メタデータが生みだされます。

典型的なメタデータの例としては、図書館のカード目録があります。このメタデータは、図書館で本を探す際に役に立ちます。

メタデータの活用方法として人気があるのが検索です。Googleなどは、インターネットをクローリングし検索インデックスを構築することで、メタデータを抽出しています。これはネット上で何かを探す際に役に立ちます。

しかしGoogle的な技術には限界があります。ユーザーのコンテキストや意図に関する理解が限られているからです。例えば「主要顧客」という特定の語を使う際に、その意味を正確に定義しておければ本当は理想的です。自分が探しているもの同士の関係性を理解したいでしょうし、どれが使えそうなのかも知りたいでしょうから。

これを行うには、事前に抽出したメタデータをエンリッチおよび強化しておく必要があります。これを行えば行うほど、利用可能なあらゆるデータに対する関連付けが改善されます（より役に立つようになります）。

複雑なものはシンプルなことができるが、シンプルなものは複雑なことができない

コンプレックスデータ用のデータ管理ツールは、シンプルデータ用のものと異なることは容易に想像できるでしょう。コンプレックスデータ用のものを使うと、当然のことながら、複雑なエンティティ間の複雑な関係性をモデリングできます。

シンプルデータ用のデータ管理ツールをコンプレックスデータに使おうとしても、あまりうまくいきません。

発生する問題の1つとして「表の増殖」があります。つまり、エンティティの新しい関係を表現するたびに新しいリレーショナルテーブルが必要になります。

これはリレーショナルデータベースが得意な人にとっては素晴らしいことに思えるでしょうが、依存関係が強いテーブルが数十から数百、そして数千個に増えてしまったら、方向性が間違っていたことに気付くでしょう。またそれに付随して他の問題が発生してくることも避けられません。

一方、コンプレックスデータ用のデータ管理ツールがあれば、必要に応じて容易にデータをシンプルに表現できます（SQLクエリなど）。

コンプレックスデータか否かをどう判断するのか

ここで「自分が扱っているのはコンプレックスデータであり、コンプレックスデータ用のデータ管理ツールが必要」なことをどう判断するのかという疑問が湧くでしょう。

これに一言で答えるならば「今使っているツールでうまくいっているかどうか」ということになります。

お客様などからMarkLogicに声が掛かるのは、通常、IT部門が馴染みのあらゆるデータ管理ツールを試した後です。ここで試されたツールはすべて、シンプルデータ用のものであることが多いです。

シンプルデータ用のツールでコンプレックスデータを扱おうとした結果、「扱いにくく結果がでない環境ができてしまい、技術的負債がどんどん積み上がっていく」か、「既存のツールで扱えるようにデータをもの凄く単純化してしまう」という誤った努力がなされてしまいます。

いずれの場合も、ユーザーが満足できる結果は得られません。コンプレックスデータは、シンプルデータとは別物なのです。

今後の展開

企業のデータアーキテクト全員が、「コンプレックスデータは本来的にシンプルデータとは違う」ということを理解している訳ではありません。コンプレックスデータは極めてリッチであり、課題にきちんと取り組んでいる人々に対して、永遠にビジネスバリューを提供し続けるものなのです。

コンプレックスデータのきちんとした扱い方を学習することで、「未来のデータ管理」を準備できます。今後シンプルデータよりもコンプレックスデータの方が多くなるだけではなく、そこから得られる価値あるインサイトも増えていくことでしょうから。

とにかくここで必要となるのは、データを関連付けることなのです。