はじめに
DX による競争優位の確立こそが、最も優先度の高い経営課題の一つであることに疑問の余地はありません。DX は、『データとデジタル技術を活用して変革を起こす』ことですが、デジタル技術を活用するのはともかく、「データの活用」できてますか？
活用できていない理由は、データがバラバラだから ではありませんか？
- データが管理されている場所がバラバラ
- データへのアクセス方法がバラバラ
- データの形式がバラバラ
DX という言葉が登場する以前から、情報システム部門などの自社のデータマネジメント業務を行ってきた方々は、バラバラのデータと戦い続けてきたのではありませんか？
- 統合データベースを作ろう（最近は MDM などと呼ばれているかもしれません）
- 分析用のデータウェアハウスを作ろう
- ETLツール（またはエンタープライズ・サービス・バス）を導入しよう
- 全部データレイクに入れることにしよう（今度こそ…）
こんな歴史だったのではありませんか？ そして、今、どうなっていますか？
- 時間がかかりすぎる（完成したときには要件が変わっている）
- お金がかかりすぎる（初回はなんとかなっても、メンテナンスや拡張までは無理…）
- いつもヒトがいない（要件を考える人も、設計する人も、開発する人も、活用する人も）
- ●●用のデータレイクなど、バラバラに複数のデータレイクができてしまった…
Data Fabric
この言葉を誰がいつから使い始めたのか、いろいろなサイトにいろいろな記述がされています。真偽がわからないので、ここでは引用しませんが、Gartner社の「2022年の戦略的テクノロジのトップ・トレンド」が、この言葉を広めたことは間違いなさそうです。
コンセンサスのとれた定義があるわけでもないようなのですが、
データがバラバラであっても、『欲しいデータを』『欲しい時に』『欲しい場所で』入手できる
というコンセプトは概ね共通のようです。この記事では、また、弊社、株式会社 ROBON では、これを Data Fabic の定義としたいと思います。
「データがバラバラのままで良い？」
「データ統合せずに、データ活用できるの？」
「そんなことをどうやって実現するの？」
答えは、DX です。これまで苦労してきたデータマネジメント業務でも『データとデジタル技術を活用して変革を起こす』のです。
DX できていないのは、データが活用できていないから…
データが活用できていないのは、データマネジメントができていないから…
では、もしも、DX で、データマネジメントができたとしたら？
Metadata
Data Fabric では、データとデジタル技術を活用して、データマネージメントに変革を起こす。
だって DX だもの。
ここで、活用するデータとは、いったい、どのようなデータになるのでしょう？
活用すべきデータは、もちろん「興味のある対象についてのデータ」です。データマネジメントで興味のある対象は、もちろん「データ」ですから、「（興味のある対象＝）データについてのデータ」を活用する必要があります。
「データについてのデータ」のように、なんらかの概念について、その概念自体を対象とする同じ種類の概念を表す英語の接頭辞が
metaなので、英語では「データについてのデータ」のことを「メタデータ（metadata）」と呼びます。
データマネージメント業務を DX で改革するために活用すべきデータは「メタデータ」です。
つまり、デジタル技術で「メタデータ」を活用して、データマネジメント業務を改革しよう！
ということになります。
Metadata Management
さて、一階層メタになりました。メタデータ を マネジメント できていますか？
ここで言う「メタデータ」とは、例えば、リレーショナルデータベースの「テーブル仕様書」だったり、コンピュータ上や送受信されるデータファイルの「ファイル定義書」「項目定義書」のようなデータを説明するドキュメント（＝データ）のことです。
こんな状態ではありませんか？
- そんなものは無い
- どこにあるかわからない
- 印刷された仕様書がリアルなファイルに綴じられて書庫のキャビネットのどこかにある
- 「バラバラに開発されたシステム」の「バラバラな開発ベンダー」から「バラバラの書式の EXCEL ファイル」で納品されたものが、「CD-ROM やファイルサーバのどこかに」バラバラに保存されている
- 開発当時のものはあるが、その後の改修や追加開発では更新していない。変更分だけが別にファイルとして納品されているので、解読する必要がある
だとすると、どうせ メタデータ は、
- 欲しい時には見つからない
- 見つかったとしても正しいかどうかもわからない
そんな メタデータ をわざわざ作ったり、メンテナンスなんてしたくもない。なぜなら、そんなことをしてたら、
- 時間がかかりすぎる
- お金がかかりすぎる
- そもそもヒトがいない（だれがやるんだよ。おれか？）
あらあら、はじめに の最後の問題に戻ってしまいました。
ですが、仮に、人間によるメタデータ・マネジメントは崩壊していたとしても、マネジメントされているメタデータは存在します。それは、データをマネジメントしているツールの中 です。ご承知と思いますが、RDBMS というのは、Relational DataBase Management System の略です。RDBMS は、データをマネジメントするために、自分のデータのメタデータを持っていて、使っています。ですから、「このテーブルのこの項目を抽出せよ」という SQL の命令を正しく処理することができるのです。
他のデータを管理しているツールも同様に管理しているデータのメタデータを保持しています。ですから、最新の正しいメタデータは、それぞれのツールが持っているものをベースにすれば良い のです。
全てのツールからメタデータを収集してくれるツールがあれば、 今のバラバラなデータに対する正しいメタデータを揃えることができます。システムが自動的に収集してくれれば、「時間はかからず」「お金もたいしてかからず」「ヒトを必要とせず」にメタデータを作ったり、直したりできます。
これまでのヒトが EXCEL ファイルにテーブルの定義を入力するというメタデータ・マネジメントから、データを管理するツールとメタデータを管理するツールの連携によって、メタデータをマネジメントする という新しい業務へ変革を行いませんか？
バラバラなデータを管理するそれぞれのツールからメタデータを収集して、一元管理すると、全てのデータのメタデータを使って、『欲しいデータ』を見つけることができます。『欲しいデータ』は、まだ見つけていないのですから、ボンヤリとしていて正確な名前もわかりません。それを 人工知能（AI）や機械学習（ML）を使って見つけるための支援をする こともできます。AI や ML は蓄積したデータを使って精度を高めることができますので、正しいメタデータをたくさん集めれば集めるほど、どんどん効率が良くなっていきます。
このように、「わざわざ作りたくない」「メンテナンスしたくない」メタデータのマネジメント業務を改革することで、Data Fabric の定義の最初の一つ『欲しいデータ』を発見できます。
同時に『欲しいデータ』に対するデータ、メタデータも入手することができます。
データレイクにもメタデータを管理しているデータカタログのようなツールがありますので、それらのツールからもメタデータを収集することで、マルチクラウドであったり、複数のデータレイクが存在している場合にも、その全てのメタデータを収集することが可能です。
その先へ
メタデータをマネジメントすることで『欲しいデータ』を見つけることが可能になります。このメタデータを管理するツールを全ての関係者に共有すれば、だれでも『欲しいデータを』『欲しい時に』『欲しい場所で』見つけることができます。
でも、見つけられるだけでなく、また、関係者という人間だけでなく、『必要としているシステムが動いている場所で』『必要としている時』にデータを持っているシステムとデータを必要としているシステムの間でデータの連携を行う必要があります。
ここで問題になるのは、欲しいデータのボリュームと鮮度です。大量データの場合、データの受け渡しそのものにも時間が必要となるので、最新のデータを要求することは難しいかもしれません。必ずしも最新である必要がなければ、現時点で有効なデジタル技術を活用すれば良いと思います。例えば、それはデータレイクかもしれません。
ご承知と思いますが、ETL というのは、元データを持っているシステムから抽出・収集（Extract）したデータを変換・加工（Transform）して、そのデータを必要としているシステムへ配信・送出（Load）を行うツールです。このうち、設計や開発に時間が必要なのは、主に Transform だと思います。データレイクを中継する場合、元データを持っているシステムから Extract したものをそのままデータレイクへ Load します。そのデータを必要としているシステムが必要な Transform をすれば連携することができます。
必ずしも、最新データである必要がない大量データの受け渡しのケースでは、この ETL とはちょっとだけ順番の違う ELT ツールをデータレイクと組み合わせるパターンが、もう一つの問題である「レガシーシステムへの影響」 を最小限にでき、比較的実現しやすいものと考えます。
一方、データのボリュームは小さいけれども、鮮度の高さが要求される場合もあるでしょう。少し古いですが、経済産業省で公開されている 対話に向けた検討ポイント集 第3章 を読む前なら、「リアルタイム連携であれば、WebAPI が良いと思います」で終了していたかもしれませんが、この国の DX が進まない大きな理由の一つがレガシーシステムにあるのであれば、ブラックボックス化し技術的負債となってしまったレガシーシステムからのリアルタイム連携をどのように実現するかについても、大きな変革が必要だと考えています。それをどのように実現するかについては、別途、考えを記事にまとめたいと思います。
おわりに
株式会社ROBON では、この記事で説明した Data Fabric を実現するための仕組みを提供していきます。ご期待ください。
【2023/8/4追記】
この記事のコンセプトで開発されたメタデータ管理サービスをローンチしました。ご興味のある方は、是非、お試しください。
Discussion