データを扱う多くの活動において、データモデリングは重要な技術であり、DMBOKにおいても丸々1章が充てられています。
またデータモデリング・データモデルは非常に奥深いものであり、データ業界界隈？には自称他称問わず、データモデラーと呼称する方が多くいらっしゃいます（筆者も自称、その一人です）
今回取り上げたいのは、データモデルの用途・目的、そして産み出される価値についての時代的変遷です。
どの場面で活躍し、どのような価値を生むのか、それが時代とともに変化してきていると感じています。
なおデータモデルと言ってもレベル感が幾つかありますが、今回は概念データモデルを想定して話を進めます。 IT導入の上流工程などで使われるモデルです。
なお概念モデルとは何か・概念/論理/物理はどう使い分けるか等はここでは言及しません。諸説あり、神学論争であるとも言えます。
面白いネタは多数あり、いつか機会があれば述べたいところです（例えば 概念モデルにおいて業務コードを主キーとして記述すべきか、Relationshipに補記をいれるべきか等ノーテーションの違いなど）
データモデルの価値の時代的変遷
：これまで －新規システム開発のため
これまで多く語られてきた文脈は、やはりシステムの新規開発でした。
そのモチベーションは主に以下の2つです。
(A) データモデルを用い、より良い要件定義を
業務フローと画面イメージだけで、ユーザの表層的な要望の確認に終始するのはやめましょう。
そうではなく、 概念データモデルを通じて対象業務領域の情報の骨格を整理し、その本質的な課題を捉え、解決しようという考え方です。
対象システムの特性にもよりますが、特に企業の業務システムなど、対象領域が複雑であるほど効果を発揮するでしょう。
(B) データモデルを用い、より良い設計を
各画面に対応した全項目を含むテーブルをいきなり実装するのではなく、複数の機能からのデータ要求を集約・精査しましょう。
そしてデータ定義の揺らぎを解消・統一化した上で、重複がなくかつスリムな、必要十分なテーブル設計を行いましょう、という考え方です。
特に、大規模で複数領域を包含するシステム開発において特に効果を発揮します。
これらの価値は今でも全く色褪せるものではありません。
今後も新しい業務の姿に即したシステム新規開発が求められますし、システム再構築も定期的に必要となるためです。
背景の時代的変遷
：企業ITは新規開発から組み合わせへ
今回考察したい点として、背景としてのシステムに係る状況の変遷と、そしてデータモデルの用途・価値の変遷です。
一つ言えることとしては、ある業務領域全体を全く新規にシステム化するような、
「新規システム開発の比率は減っている」ということです。
その代わりに、機能の拡張／部分更改／データの利活用などの、
「組み合わせで価値を生むIT化」にテーマの主軸が移っています。
これは受託側のIT企業に居るとまだまだ実感が薄いかもしれません。
が、システム利用側の企業においては強く実感される方も多いと思います（もちろん企業ごと領域ごとの差はあると思います）
DXの影響－データの組み合わせ・連携パターンの多様化
またトレンドとして当然DXがあります。
DXとは何か？という考察は各所でされています。顧客視点(UX)/IOT/AI/業務改革などのキーワードもありますが、「データの連携・統合のレベルが高まることで様々な価値が生じること」もDXの本質の１つとも言われています。
DXの文脈でのデータ連携のパターンとしては、従来のような、
・ある業務領域からある業務領域へのデータ連携
・基幹系から情報系へのデータ連携
以外にも、 同一業務領域 におけるデータ連携も増えています。
領域間の連携（水平）に対し、 同一業務領域でDXを推進する機能を補完しあうケースは垂直連携とでも呼称すべきでしょうか。
例えば、
1. 顧客とのフロント接点のUX的機能を増強 (新設)
2. AI処理で一部データ補完 (新設)
3. バックエンドの既存システムに格納 (既存)
というような連携です。
これらがさらに、自社システムだけでなく、SaaSやパッケージ製品によって一部機能が実現されています。そのため自社システム → パッケージ →自社システム というような入り組んだデータ連携も増えています。
データ活用の潮流ー データ集約・組み合わせ範囲の多様化
データ活用も大きな潮流となっています。
基幹系・オペレーション系から情報系へデータを連携・集約する流れにおいて、出自の異なるデータ同士の組み合わせが必要となるケースが増えています。
従来は、ある業務領域に限定したデータ範囲に対しデータ分析・活用を行ったケースが多かったところ、
近年は、バリューチェーン上の複数機能領域にまたがるデータの集約・活用や、 主要商材や顧客が異なる複数事業にまたがったデータの集約・活用のケースが増えていると思います。
また外部のオルタナティブデータと自社データを組み合わせてのデータ活用のケースもあるでしょう。
これらの異なる出自のデータ同士を集約し組み合わせ統合する必要性が増えているのです。
データモデルの価値の時代的変遷
：これから－連携・統合のため
上記をふまえ、筆者は、今後の概念データモデルの用途は、 データ連携・統合を目的としたものに主眼が移ると考えています。
連携・統合のためには、各領域のデータ同士の「言葉」を合わせる必要があり、そのためにデータモデルが有効だということです。
以下に説明します。
領域同士のデータ定義のマッピングが必要
複数の領域やシステム間でデータ連携をするためには、当然データ定義のマッピングが必要となります。
異なる領域から持ってきたデータ同士は、基本的に「喋っている言葉が異なる」状態ですので、翻訳的な作業が必要になります。
具体例でいうと、
・領域Aの CustomerNumber という項目
・領域Bの Cust_ID という項目
これら２つはイコールなのか？
これが確認できて初めてデータ連携・統合が可能となります。
もちろんこれは単純な例であり、項目同士が１対１のマッピングが出来るとは限りません。
データのコンテキストを考慮したマッピング
－データ辞書だけでなくデータモデルが有効
上記の課題には、もちろんデータ辞書(メタデータ管理)も対応策となりえます。
データ辞書製品(データカタログ)の導入事例も増えてきていますし、データ連携製品もデータ辞書の機能を備えてきています。
しかしながら、連携が複数領域にわたり対象が複雑化していくと、データ辞書だけ、すなわち言葉による項目定義だけでは立ち行かなくなります。
例えば「顧客」と言った時に、見込み客を含むのか・契約のある既存客のみを含むのか、などのコンテキストまでは、一つのデータ項目に書くのは難しいのです。
勿論求められればデータ項目の定義として記述すれば良いです。が、求められるごとに補足を継ぎ足していくと、幹が無く枝葉がたくさん茂ったイビツなデータ定義記述が出来上がってしまいます。
データモデルにより、各対象領域のコンテキストを把握
ここで登場すべきはデータモデルです。
データモデルは概念間の関係性を表現するのが得意ですので、顧客というエンティティが他のどのようなエンティティと関連を持つかにより、上記のコンテキストを表現することが出来ます。
例えば領域Aでは「顧客ー見込客 の２つのエンティティがあり、商談 は見込客に関連線がひかれ、契約は顧客に関連線がひかれている」となると、ここでの顧客とは契約のある客を指すことが明確化されます。
関係性の中で、そのエンティティの定義が明確になるのです。
このように、ある領域のデータモデルを作成することで、その領域の業務の考え方・コンテキストと、キーとなる主要な用語の定義を明確化することが出来るのです。
領域A、領域Bのそれぞれのデータモデルが存在していれば、それぞれの主要な用語定義の同一性または差異を確認することが出来ます。
その上で、項目レベルの詳細についてはデータ辞書も活用することで、領域A-B間のデータ連携を適切に構築することが出来るでしょう。
なおここで必要となる詳細度は、冒頭に言及した概念データモデルのレベルで十分であり、属性項目を網羅した論理データモデルは必須ではありません。
今後のあるべき姿
上記のまとめです。
今後DXの進化とともに「連携や統合」の必要性は益々増大します。
そしてデータ連携・統合に対応するために、 各領域のデータモデルとデータ辞書を整備することの重要性が高まります。
データモデルは今後は、システム開発のためだけではなく、各領域の主要なデータを「意味的に把握できた状態」「他領域と会話できる状態」に保つために作成し整備していくことになるのです。
各領域のデータモデルはいつ作るべきか
ここで一つ課題があります。 この各領域のデータモデルをいつ作るのか？ という点です。
従来のシステム開発案件であればこの答えは明確でした。
「各案件の前半（＝上流工程）」 で作れば良かったのです。
しかしながら、上記に挙げたような 2領域間の連携・複数領域のデータ活用、というケースでは、各領域の中身までのデータモデル作成に時間を割くことは難しいかもしれません。
ではいつ作成すべきでしょうか？
理想的な答えは、
「あらかじめ、主要な領域のデータモデルを作成しておく」 です。
大上段な話にすると「エンタープライズデータモデルを整備しよう」という話になります。
これはそう簡単に可能なのでしょうか？
ここからの話は次の回に譲ります。
