そのため、既存の複数のシステムからデータを引っ張り出してきて二次加工して使おうとしても、システムごとにデータのフォーマットが違うし、重複したデータもあり、しかも同じ名前のデータでもシステムによって意味が違ったりします。例えば「顧客」データがあったとして、ある部署ではそれが一般消費者を示すとしても、別の部署では販売店を指すことも考えられます。

1つの企業内でそんな感じですから、部品のサプライヤーや販売代理店といった企業間を結んでシステム間連携をしようとしても難しい。こうしたことはビジネスを阻害している1つの要因だと思います。

それでも基幹系の情報システムでは、それなりにきちんと考えられてデータ構造を設計し、メンテナンスもされているでしょうから、他のシステムと連携はある程度できるようになっています。技術的にいえば、以前からMQ（MQSeries）や、ETL（Extract/Transform/Load）のようなソフトウェアがありましたし、最近ではSOA（Service Oriented Architecture）のようにアプリケーション連携する方法もあります。

またかつては、ERPで企業内すべてのシステムを完結させてしまいましょう、という動きもありましたし、すべてのデータはリレーショナルデータベースに、と主張したベンダもありました。そうしたアプローチは現在まで生き残ってるとはいえませんけれど。

現在のシステムは分散傾向にあるのですから、物理的に分散したデータをいかに論理的に統合するのか、というのが俯瞰した場合の大きな課題だと思います。

現代のビジネスは、以前よりもずいぶん難しくなってしまったという点を指摘しなければなりません。例えば以前、自家用車の市場では「いつかはクラウン」ということがよくいわれました。これは、多くの消費者がいつかはクラウンのような高級車を購入したいという嗜好を端的に表した言葉です。かつては、消費者の嗜好は単純だったのです。しかし現在では消費者の嗜好が単純とはいえません。率直にいって消費者が何を好むのか分からないことが多い。市場ニーズがどう展開するか読めないし、もしもそれが読めたとしてもすぐ変わってしまいます。

こうした市場の変化に企業が追いつくためには、意志決定のスピードをあげていかないといけないのです。

ところが、多くの情報システムではデータを分析してあらかじめきまったレポートを作ることは簡単ですが、ちょっと分析の切り口を変えようとしてもできない、あるいは手間をかけなくてはならなくなります。

しかし市場の変化を読み取るにはさまざまなデータを集め、分析し、それに基づいて意志決定をする必要があります。そうした素早い意志決定を実現するために、柔軟で素早いデータ統合を行いたいという、ニーズが現れていると思います。

SOAのようにアプリケーションを疎結合にしておいて連携したり、サービスを再利用するとしても、例えばデータベースにデータの一貫性がない場合、値の日付をみて新しい方だけを採用するとか、単価が異なる場合に変換するとか、そういう対応をアプリケーションでしなければなりません。これをどんどんやっていくと、SOAで目指しているような変化に対して迅速で柔軟な対応というのが結局できなくなっていくんです。

SOAをうまく実現しようとすれば、結局アプリケーションとデータを切り離して、データを整理しなくてはいけません。データレベルでの整合性を実現するようなデータ統合をしないわけにはいかないのです。

もう1つ。プロセス連携では主にデータを小さく分割して、あるプロセスから別のプロセスに流すということになります。これは一度に大量のデータを処理し分析したいというニーズにはあまり向いていません。もっとデータに近いレベルでの統合が必要です。

特に基幹系で重要になってきているのはマスターデータ統合です。本来「マスター」は1つのはずなのですが、実際には企業内に複数のマスターが存在することがほとんどです。

似たようなデータが重複して存在するとき、どちらが正しいか、新しいのかなど、データのメンテナンスは面倒な作業です。しかし、それをデータレベルでマスターデータ統合せず、アプリケーションレベルでやろうとすると、先ほど説明したように効率はよくなく、データが増えることでストレージも追加購入しなくてはならなくなり、またデータベースのライセンスだって購入する必要が出てくるかもしれません。結局、無駄なコストが費やされてしまうのです。

マスターデータの統合で重複データを排除し、データ品質を高めることで、データの利用効率を高めることが実現するのです。

企業は会計システムがコアですから、基本的には会計データをベースにして、そこに関連するデータを整理していくのが順当なのではないでしょうか。お金のデータは商品にひも付けられますし、誰が売ったかというデータは社内の部署や担当者に、どこに売ったかというデータは顧客に、という形で順次関連データを整理していくのがよいと思います。

定型データはこうしたセオリーがあるとして、いまもう1つの課題は非構造化データをどうするかです。最近の企業では従業員一人一人が何らかのデータを作成し、あるいは更新しています。その多くはExcelやWordのファイルだったりするのですが、こういったデータは形式も内容もほとんど無法地帯のようなもので、それを集計したり現状を表すためのデータとして分析したいとしても、非常に苦労すると思います。

そうです。以前は企業も戦略というかシナリオが組めました。3年程度のシナリオを考えることができ、それに基づいて計画を立てればよかった。しかしいまではそんなことをしていたら市場のニーズの変化に対応できず、ものが売れないし、不良在庫を抱えてしまうことになるでしょう。

ですから、市場に関するデータをすばやく生産や設計にフィードバックしなければいけないのです。ということは、いままでのような過去5年くらいのデータをBIで分析して過去の傾向はどうだった、ということをしていたのでは追いつきません。

いま現場と接している営業の人、フィールドにいる人の情報をインプットとして分析し、フィードバックしていかなければ。それは電子メールだったり営業日報だったりと、非構造化データであってもインプットとしていかなければならないでしょう。

構造化データと非構造化データを、共通のマネジメントスタイルで管理ができることでしょう。入れ物は同じである必要はありません。SQL ServerやOracleやファイルサーバなどに分散していていい。それをちゃんと管理できるかどうかです。分散したデータに対して、リポジトリをしっかり用意して、そこで論理統合されていればよいでしょう。

そういう機能を提供できることが大事だと思います。

それから、企業の情報システムを考えたときには、コストとスピードの面でクラウドを抜きにして、これからのビジネスは考えられません。CRMはクラウド上のSaaSを利用するとしても、勘定系はオンプレミスで行うことが多いでしょう。そうしたとき、それらをどうやって連携させるか、そうした機能も不可欠になります。

また、今後はいまでいうESB（Enterprise Service Bus）やEI（Enterprise Integration）、そしてETLなどの機能は徐々に同じものに近づいていくはずです。そういう視点も意識する必要があります。

ESBは分割して小さくしたデータをリアルタイムで連携させる仕組みで、ETLはバッチ処理的な仕組みです。

ETLを例にとると、いままでのバッチ処理は1日1回、夜間に、といった具合で、またデータウェアハウス用途が多く可用性もそれほど求められていませんでした。

しかし最近では1日に2度も3度もETLでバッチ処理し、データ分析を行い、それをトラックの配送計画やその日の生産量にすぐにフィードバックする用途が増えてきており、ETLが止まれば配送や生産が止まってしまうため、リアルタイム性や可用性が求められるようになっています。

一方でESBやEIに対しても、非構造化データを扱いたいというニーズや、アプリケーション間だけの連携ではなく、もっと大きなデータ単位で処理したいというニーズも出てきています。

両者のニーズは近づいており、いずれマージされていくものではないかと思います。

企業内で統合的にデータ提供をサービスとして提供するような機能、Information as a Service、あるいはInformation Fabricというものに行き着くのだと思います。

いまは企業が垂直統合的ではなくなってきています。アップルは製造拠点を持っておらず、PCベンダーの多くは台湾などのEMS企業に生産を委託しており、販売やマーケティングと製造が分かれています。さらにこの流れは自動車などの他の製造業にも広がりつつあります。

こうした時代に、1つの製品に関わる情報を1つの企業内のデータベースにいれることは不可能です。ビジネスが分散化しているときには、データも分散せざるを得ません。しかしそれを論理的に統合するレイヤを設け、アプリケーションからデータにアクセスするときには物理的にそのデータがどこにあるかは気にせずにアクセスできる。

そうしたデータ統合レイヤを設ける形が、データ管理の望ましい姿だと思います。そしてそれは、リアルタイム処理やバッチ処理の両方に対応したものであるべきです。今後のデータ統合製品は、さらにこの形が進化していく、とわたしは考えています。