今回の「３分で分かるデータマネジメント」ブログのテーマは「データ統合と相互運用性」です。DMBOK2では新しい知識領域として追加されており、その背景にはデータ駆動型経営へ転換するために、構造化/非構造化データを問わず様々な種類のデータを統合し、そこから価値を引き出すことが重視されている状況があるようです。今回は、データマネジメントに関する知識の中で「データ統合と相互運用性」の領域に該当する内容を書いていきます。（そもそも“データマネジメントとは？”“DMBOK2とは？”という方は、こちらの記事『データマネジメントとは何か』もご覧ください。
注)本記事に書かれている内容は、引用部分を除きすべて独自の解釈・主張です。弊社の知見に基づいた独自の視点で、読む人により解釈が大きく分かれるDMBOK2の内容を「こう理解すればいい」とお勧めしています。
データ統合と相互運用性について、DMBOK2では以下のように定義しています。
データ統合と相互運用性（DII：Data Integration and Interoperability）は、データストア、アプリケーション、組織などの内部とそれらの相互間で実行される、データの移動と統合に関するプロセスを表している
『データマネジメント知識体系ガイド 第二版』DAMA International編著、DAMA日本支部・Metafindコンサルティング株式会社訳、日経BP社、2018
ここでいう「データ統合」とはデータを（物理的、仮想的を問わず）一貫した形式に統一することだと考えられます。また、(データの)「相互運用性」とは、様々なシステムがどの程度情報を連携できるかを表しているのだと考えられます。
単にデータHUBシステムを作れば良いという事ではなく、全社視点で統合されたデータ設計に基づくフォーマットを用意して、周辺システムへ整合の取れたデータを提供する必要があるようです。
一般的にデータをアプリケーション間で連携する際には、抽出（Extract）・変換（Transform）・取込（Load）が行われます。ソース（連携元）システムから必要なデータを抽出し、コードやフォーマットを変換した上で、ターゲット（連携先）となるシステム/データストアに取り込みます。これらの頭文字を取ってETLと呼ばれることが多く、製品カテゴリの１つとして存在しています。
その他にもEAIや仮想データ統合などの、システム間連携をサポートする製品カテゴリはいくつか存在しますが、それはレイテンシ許容範囲の違いに拠ります。レイテンシとは「ソースシステムで生成されたデータが、ターゲットシステムで利用可能になるまでの時間の差」を指します。レイテンシは（一般的に）連携データ量と相反する関係にありますので、レイテンシの異なる全てのI/Fを単一の基盤上で扱おうとすると、他のデータ量の多いI/F処理の影響を受けて、「10分間隔で起動するI/F処理が10分以内に終了せず、次回処理が開始できない」などの事象が発生してしまいますので、注意が必要です。
最近では、アジャイル化/DataOpsの傾向が強まっており、まずターゲットシステム上にデータを取り込んで（生データとして実体化して）から、必要に応じて変換を行なうアプローチ（ELTと呼ばれます）も増えています。（DataOpsに関しては、別の機会に考察をしてみたいと思います。）
DMBOK2では以下のように書かれています。
データ統合と相互運用性の活動により、人とシステムが必要とするフォーマットと時間枠でデータを提供し、モデルとI/Fを共有することでソリューションを管理するコストと複雑さを削減する。
『データマネジメント知識体系ガイド 第二版』DAMA International編著、DAMA日本支部・Metafindコンサルティング株式会社訳、日経BP社、2018
データ相互運用性の複雑さとサポートコストを削減するためには、システム間接続方式とI/Fフォーマットの標準化が必要です。つまり、I/Fデータを発行/購読する全てのシステムは中央のHUBシステムのみと連携し、ハブシステムに定義した共通のメッセージフォーマットを介してデータ変換を行なう必要があります。
DMBOK2の中には、データHUBについて、以下のように記されています。
数百または数千のシステムを有するITポートフォリオを管理するためには決定的に重要になる
『データマネジメント知識体系ガイド 第二版』DAMA International編著、DAMA日本支部・Metafindコンサルティング株式会社訳、日経BP社、2018
すなわち、データHUBがないとシステム間I/Fが増えたときに管理できなくなるということです。
ところで、近年データHUBの必要性が前より取り上げられるようになった理由はなんでしょうか？おそらく理由として、これまでは基幹系システムを中心に周辺システムとのI/Fをファイル転送方式で構築してきた企業においても、昨今ではベンダーからアプリケーションを購入するケースが増えていることが挙げられます。その場合、基幹系システムのデータ構造だけを参照してシステム間連携処理を開発する訳にはいかなくなります。基幹系システムとその外付けシステムだけで成り立つ世界ではなく、SFAなどの別の思想を持ったシステムが企業情報システムに参加してきます。そのような状況下で、ポイント・ツー・ポイントによる開発を継続し、数千から数百万のI/Fを管理し続けられる組織はそれ程多くないと思われます。
一方、HUBシステムを導入すると、I/F管理の複雑さを軽減できます。それによって、そこに従事していたサポート要員を（デジタル化対応等の）他の優先事項へ効率的に配分することも可能になります。
DMBOK2では、計画と分析→設計→開発→実装と監視 の４つのアクティビティが定義されています。ただし、DMBOK2の内容は様々なデータ連携モデルやソリューションにも当てはまるように書かれており、抽象度が高く理解が難しくなっています。
そこで、本記事ではデータHUB（パブリッシュ・サブスクライブモデル）に限定して、必要なアクティビティを筆者経験から説明します。
プロジェクト企画を進める上では、投資対効果を明確にすることが求められます。データ相互運用性のサポートコストが、中長期的にどの程度削減できるのかを定量化する必要があります。I/F開発コストと保守運用コスト（影響範囲調査や日程・要件調整を含む）に分けて、整理すると良いと思います。また、他のプロジェクト（SFA導入など）と関連付けて、効果を訴求することも求められます。
また、企業内に存在するI/F一覧や定義書の収集も大仕事になります。I/F一覧フォーマットの統一から始まり、システム単位にI/F情報を収集し、データ種別に整理する所までは済ませておきたいところです。その上で、全社システムを範囲として大まかなシステム間連携図を作成しておくことで、次工程をスムーズに開始することが可能になります。
まず、データHUBシステムを経由するI/Fを見極め、データHUBを含むシステム間連携図をデータ種（マスタであれば顧客や品目、トランザクションであれば購買・製造・販売などのレベル）で作成します。どのデータやシステムをデータHUB経由で連携させるかについては、大まかには「全社で共有すべきデータに絞って、HUBを経由させる」という事になります。
続いて、データHUB内に保持するデータ構造を設計します。システム間連携図を作成する過程で、データ種・エンティティ別の発生源システムが明確になっているはずですので、発生源システムにおけるデータ構造を基本としてデータ視点課題を解決し、全社標準に相応しいデータ構造をデザインします。
データHUBを経由するI/F一覧の作成も忘れずに行います。（発行側システムとデータHUB,データHUBと購読側システムに分けてI/Fを明確にします。）
I/F設計は導入するETL製品を意識しつつ、IN/OUTのデータストア間関係を（データ種別に）１枚で表すような図と、IN/OUT間のデータ項目マッピング表（変換ルール含）をセットで作成します。
ETL製品にI/Fが実装されるのを管理するのと並行して、データ辞書を構築したい所です。その品質を担保するデータ管理組織立ち上げも重要です。
「SFAをクラウドで立ち上げるのに合わせて、データHUBも導入したい」というご要望をお伺いするケースが増えています。ソフトウェアベンダーから提供されるアプリケーションを導入するためにはデータ構造・意味の異なる既存システムとのデータ連携が必要になります。SFA導入コンサルティングにおいては「SFAに合ったデータを周辺システムから取り出すのは、責任範疇外である」とされるケースも多いようですので、ベンダーに依存せず、企業が主体となってデータを統合し、データHUBを経由した周辺システムとのデータ連携に取り組む必要があります。
今回は「データ統合と相互運用性」にテーマを絞り込んでご紹介しましたが、企業のデジタル化を進める上では情報の利活用により新たなビジネスチャンスを得る必要があり、そのためには利活用したい情報・データをしっかりマネジメントし続けることが不可欠です。今後もブログを通して、企業のデジタル化を進めるためのデータマネジメントをわかりやすく伝えていきたいと考えています。
データの本来あるべき姿を定義し、守らせるための組織・制度を設計し、これらを基に、プロジェクト現場に実際に守らせる...その役目を担うのがDA（データアーキテクト）です。
本コースでは、データアーキテクトとして求められる役割と、その実践ノウハウを学ぶことができます。