データモデリングは死んだのか？

私たちには今でもデータモデルが必要なのでしょうか？データモデルの真の価値とは何でしょうか？なぜ過去にデータモデリングは失敗してきたのでしょうか？どのようにデータモデルを設計し、そこから価値を生み出せばよいのでしょうか？以下のプレゼンテーションと解説では、これらの疑問に包括的にお答えします。

データモデリングは死んだのか？

ここで問うべき本質的な問いは、「データモデリングは死んだのか？」ということです。これは単なる仮説上の議論ではありません。数年前、米国のカンファレンスに参加した際、大手保険会社で30〜40年にわたりデータモデラーとして第一線で活躍してきた著名な専門家たちが「データモデリングは死んだのか？」と議論していました。彼らは自らの職務を果たし、確かに価値を生み出していたものの、もはや組織から正当に評価されていないと感じていました。データモデリングの価値が、以前ほど見出されなくなっていたのです。

まずはデータモデリングとは何か、そしてなぜそれが必要なのかを理解することから始めましょう。背景として、筆者はデータウェアハウス自動化ツール「Data Vault Builder」の開発元に携わっています。私たちはビジネスモデルを中心に取り組み、それを自動的に稼働可能なコードへと変換することを信条としています。これは筆者個人の経験に基づいた見解でもあります。

ここで筆者の職歴とデータモデリングの簡略化された歴史を共有させてください。筆者は2000年にデータウェアハウス領域でのキャリアを開始しました。当初は金融機関でデータリコンシリエーション（データ照合・整合性検証）に従事し、その後通信業界に移って電気通信事業者のデータマネジメントチームを率い、より複雑な課題に取り組みました。

2012年、アジャイルデータウェアハウスとニアリアルタイムデータウェアハウスの実現という大きな壁に直面しました。モデリングパラダイムとしてData Vault（データヴォールト）を試行したところ、非常に優れた成果が得られました。しかし同時に、それを真に効果的なものとするには「自動化」が不可欠であると痛感しました。この2012年の気づきがData Vault Builderの礎となりました。以来、私たちはソフトウェアベンダーとしてこのツールの開発を継続しています。

現在、筆者の役割はプリセールスおよびポストセールス活動、そしてコミュニティ内で知見を共有・推進するためのプレゼンテーションを行うことです。

データモデルとは何か？

では、モデルとは何を意味するのでしょうか？モデルとは、複雑な事象を抽象化・単純化することで意味を与えるものです。Wikipediaで「オントロジー（存在論・概念体系）」を調べると、クラスやコンセプト（概念）、プロパティ（属性）、リレーションシップ（関係性）、公理、制約といった要素が見つかります。データモデリングのこれら基本要素は、時代を超えて一貫しています。表現形式の違いはあれど、根底にある核となる考え方は変わりません。つまり、一度データモデリングの本質を習得すれば、何年先になっても将来にわたって通用する強力な武器となるのです。

木（樹木）の例を考えてみましょう。無数の葉や枝を持つ本物の木には、何千もの側面が存在します。本物の木をデータベースやファイルにそのまま完全に記録しようとすれば、データ量は膨大になり、分析目的やビジネスの文脈においては過剰で不要なものとなります。代わりに、主要な特徴を表すシンプルなモデルを作成します。例えば、緑色の部分（葉）、茶色の部分（幹）、そして樹木の輪郭というモデルです。このような単純化された表現であっても、その図を見れば誰もがそれが「木」であると理解できます。最もシンプルな表現であれば輪郭線だけでも十分です。それだけで木の数を数えることができます。多くのビジネスアプリケーションにとって、このレベルの単純化で十分なのです。

実物とそのモデルとの関係を如実に表す有名な絵画があります。

そこには「これはパイプではない（Ceci n’est pas une pipe）」と書かれています。それはパイプそのものではなく、パイプを描いた絵（二次元の単純化された表現）です。何であるかは一目で認識できますが、実物そのものではないことを忘れてはなりません。私たちはこのようなモデルを用いて、複雑な現実を単純化し、説明しているのです。

次に、森の風景を考えてみましょう。森の写真を見せられただけでは、「綺麗な森だが、結局何の話なのか？」と感じるかもしれません。

ここでも概念を単純化できます。

「森の中には多数の木がある。森林官が1つまたは複数の森を管理している。さまざまな樹種が存在し、森林には所有者がいる」とモデル化できます。このシンプルな概念モデルを見るだけで、ビジネスの基本構造を直感的に把握できます。

誰かが木から利益を得ようとしているものの、木が成長して後で活用できるように適切に管理する必要があるというビジネスコンテクストが見えてきます。これにより、モデルは強力な「コミュニケーションの手段」となります。同じ企業内の異なる事業部門の担当者が一堂に会し、共通の理解を持って議論できるようになります。互いの視点を定義し、状況を整理してコラボレーションを促進し、視点が乖離しがちなIT部門とビジネス部門の重要な架け橋となるのです。「お互いを十分に理解し、協力して進められる」共通基盤がここに生まれます。

では、これらはどこから始まったのでしょうか？リレーショナルデータベースの父と呼ばれるエドガー・F・コッド（Edgar F. Codd）は、1970年代に影響力のある論文を発表しました。データモデリングの手法を観察すると、これが決して真新しいものではないことが分かります。その後のあらゆるモデリングアプローチは、同じ基本原則に立脚しています。これは極めて重要なので繰り返し強調します。データモデリングとは、「モノを特定・識別し、記述し、それらの間の関係性を確立すること」です。さらに、データベースにおけるトランザクション処理を定義するACID特性（原子性、一貫性、独立性、永続性）や、正規化への取り組みでもあります。

正規化（Normalization）

私たちが注目すべき側面は正規化です。データを識別するための主キー（Primary Key）、関係性を確立するための外部キー（Foreign Key）、モノを記述するための属性（Attribute）に分割します。正規化の主要な目的の1つは、データの重複を排除することです。例えば、顧客ごとに顧客タイプの詳細な説明文を毎回重複して記録する代わりに、顧客タイプの別テーブルを作成し、リレーションシップを通じて参照します。ストレージやCPUが非常に高価だった時代、このアプローチはハードウェアコストを大幅に節約しました。保守性に一定のトレードオフが生じる場合があっても、コスト削減は極めて重要だったのです。したがって、「すべての属性は、キーについて、キー全体について、そしてキー以外の何ものでもない情報を提供しなければならない（So help me Codd）」という原則が重要になります。

ここでコッドが対象としていたのがオンライントランザクション処理（OLTP）システムであったことを理解する必要があります。OLTPは日常のビジネスプロセスの管理に特化しています。しかしその後、より包括的な全体像やレポーティング機能を提供するための新たなシステムが登場しました。単一レコードの登録・更新だけでなく、膨大なデータ量をクエリするため、全く異なる要件が生じます。データウェアハウスは長期間にわたり、過去の変更履歴を追跡する必要があるため、処理速度と履歴管理が極めて重要になります。

例えば、顧客の改姓や、リードが成約して顧客に転換するプロセス、顧客生涯価値（LTV）など、時間の経過に伴う変化を正確に把握しなければなりません。OLTPシステムでは、変更処理を簡素化するためにサロゲートキーや技術キーが多用されます。これらは時点ごとの整合性を保てば十分なため、長期的な安定性は必ずしも保証されません。

一方、データウェアハウスの世界では、たとえ業務システム（ITシステム）が刷新・置換されても永続的にエンティティを一意に識別できるよう、ビジネスキーへの移行が推奨されます。ただし、このアプローチにも課題があります。例えば結婚等で氏名が変わった場合、氏名と生年月日だけをキーにしていると、以前の自分が消滅して新しいエンティティとして再生成されてしまいます。モデルは決して完璧ではなく、「何を追跡したいのか」「どのように識別するのか」を常に考慮しなければなりません。不完全な現実世界では、改姓を新規顧客として誤認してしまうといったリスクも念頭に置く必要があります。

第3正規形（3NF）データウェアハウス

次に、分析の世界に焦点を移しましょう。1992年、データウェアハウスの父と呼ばれるビル・インモン（Bill Inmon）が登場しました。彼はデータウェアハウスを構築し、「意思決定を支援するための、サブジェクト指向、統合された、時系列の、不揮発性（削除・更新されない）データの集合体」と定義しました。この定義は今日においても多くのケースで真実を捉えています。

データレイクなどの最新のアプローチも、正しく実装されればこれらの要件を満たすことができます。しかし、一部のデータレイクはデータウェアハウスを完全に代替するには至っていません。特定の機能を代替することはできても、データウェアハウスの完全な機能を実現するには追加の仕組みが必要です。不可能ではありませんが、留意すべき点です。

データ統合、不揮発性、時系列対応のすべての要件を満たして初めて、全体像が完成します。インモンは、当時進化を遂げていた第3正規形（3NF）データベースを用いてデータ間の関係性を構築しました。主キー、外部キー、属性に加え、サロゲートキーを導入しました。これは、特定の主キーに関連する情報の異なるバージョン（履歴）を保持するためです。例えば氏名が変更された場合、その変更時点からの有効性を示す異なるバージョンの情報が保存されます。しかし、この3NFアプローチの最大の難点は「保守性（メンテナンス性）」にありました。

履歴を完全に保持するデータウェアハウスにおいて外部キーが張り巡らされている場合、顧客エンティティへの些細な変更（新規カラムの追加など）であっても、関連するエンティティ全体の履歴に連鎖的な影響を及ぼします。データモデル全体に波及するこのカスケード効果により、モデル変更のコストが天文学的に高騰します。エンタープライズDWHを第3正規形で構築し始めた当初はシンプルで整然としていますが、データソースが増加し要件が変化するにつれて、悪夢のような保守負担と化します。多くのDWHプロジェクトが華々しくスタートしながら徐々に開発速度を落とし、最終的には破綻して別システムへの刷新を余儀なくされる原因がここにあります。この課題を解決すべく登場したのが、ラルフ・キンボール（Ralph Kimball）が提唱したディメンショナルモデルです。

ディメンショナルモデル（次元モデル）

キンボールが提唱した「コンフォームド・ディメンション（適合ディメンション）」の目的を考えてみましょう。ストレージコストが急速に低下したことを受け、彼は異なる複数のITシステムの全データを単一の顧客ディメンションへと統合・非正規化しました。情報を非正規化することで、結合（JOIN）の数を劇的に減らし、クエリを大幅に簡素化できます。

キンボールのもう1つの手法は、様々なディメンションを参照するスリムなファクトテーブルの構築です。しかし、特に履歴を持つディメンションを扱う際、保守性の懸念は依然として残ります。当時、多くの組織がビジネス価値を精査することなくすべてのデータを履歴化（SCD）しようとしました。新規カラムを追加するたびに、ディメンションの履歴全体を再構築し、ファクトテーブルを書き直す必要が生じます。もっとも、非正規化されたオブジェクトであるため、影響範囲がファクトテーブルと該当ディメンション内に限定されるという利点はありました。

初期導入は比較的容易であり、連携するソースシステムが2〜3個程度であれば理想的な解決策に見えました。しかし、4つ目、5つ目と連携ソースが増えるにつれて、構築・保守コストは指数関数的に跳ね上がりました。

キンボールのもう1つの偉大な貢献は、データのクエリを極めて簡単にした点です。ファクトテーブルから各ディメンションへの「多対1」のリレーションにより、任意の2つ以上のディメンションで安全にフィルタリングでき、ファン・トラップ（Fan Trap）やデータの二重計上を回避しながら意味のある集計結果を得ることができます。また、非互換な階層構造の特定にも役立ちます。多くのBI・レポーティングツールがこのデータ構造に最適化されているため、キンボールのプレゼンテーション層の考え方は現在でも標準として生き続けています。

キンボールは保守性の根本問題を解決したわけではありませんでしたが、クエリの容易性を飛躍的に高めました。ここで登場するのがData Vaultです。Data Vaultは、「正規化されたコアレイヤーに立ち戻り、それを置き換えるのではなく改良すべきだ」と提案します。データのプレゼンテーション（分析クエリ）には依然としてディメンショナルモデルが最適ですが、それは正規化されたコアから仮想的または再現可能な形で導出すべきなのです。

Data Vaultモデリング

私たちは再び、「モノを定義し、特定する」という原点に戻ります。Data Vaultでは、不変のビジネスキーのみを保持する「ハブ（Hub）」と呼ばれるオブジェクトを使用します。履歴を伴う属性情報は別個のデータベーステーブルである「サテライト（Satellite）」に格納され、エンティティ間の関係性は独立した関係テーブル「リンク（Link）」に格納されます。データの機能を明確に別々のオブジェクトへと分離することで、ダン・リンステッド（Dan Linstedt）は抜群の保守性を達成しました。

このアプローチが実用化したのは、テーブル結合の処理能力、コンピューティングリソース、メモリが手頃なコストで利用できるようになった2000年頃のことです。

スタースキーマやスノーフレークスキーマほど物理的な格納効率が高くない場合もありますが、保守性の面で圧倒的な優位性を持っています。超高スループットを要求される極端なシステムではData Vaultの物理モデルをそのままクエリするのは最適ではない場合もあります。

しかし、大企業であっても通常そこまで極端なデータ量にならないマスターデータや主要ビジネス領域において、Data Vaultモデルは完璧に機能します。わずかなハードウェア・コンピューティングリソースを追加投資するだけで、開発と保守に要する膨大な人的工数を削減できるため、費用対効果は極めて高くなります。データをより小さな構成要素に分解するアプローチ自体はオントロジーで既に定義されていたものですが、物理データベース上にこの形で永続化する点に革新性がありました。

第3正規形からData Vaultモデルへの進化を経ても、分析クエリには依然としてディメンショナルモデルが利用されます。ただし、Data Vaultコアから仮想ビュー（情報マート）として柔軟かつ非破壊に構築されます。

この仕組みは極めてシンプルであり、「何を達成したいか」を定義するだけで自動化が可能です。この実現には、初期から変わらないステージング層が必要です。ソースシステムのデータを抽出し、Data Vaultコアへマッピング・変換する処理も、ビジネスキーの定義と非正規化ルールを用いることで完全に自動化できます。

その他のモデリングアプローチ

これらのアプローチのほか、アンカーモデリング（Anchor Modeling）について詳しく知りたい方は、数々の革新的なアイデアを持つラース・ローンベック（Lars Rönnbäck）の文献を一読することをお勧めします。彼はData Vaultモデリングで自動化が難しかったいくつかの課題に取り組み、属性と単一テーブル構造を駆使した興味深い手法を考案しました。

これはFCO-IM（Fully Communication Oriented Information Modeling：完全コミュニケーション指向情報モデリング）に着想を得た、全く異なるデータモデリングアプローチです。FCO-IMの根底にあるのは、データモデリングの専門知識を持たないビジネスユーザーであっても、「学生は都市に住んでいる」といった自社のビジネスに関する事実の文を表現できるという考え方です。こうした自然言語の文言からデータモデルをリバースエンジニアリングし、モノ、関係性、属性を抽出します。このプロセスを自動化するツールも存在し、非常に示唆に富んでいます。

さらに、筆者自身の経験は少ないものの、多くの同僚が推薦している「BEAM（Business Event Analysis & Modeling）」アプローチや書籍もあります。

また、アンサンブル論理モデリング（Ensemble Logical Modeling）もあります。これは構造化されたワークショップを通じてビジネスユーザーから業務知識を引き出し、イベント、人、場所、モノに分解して属性を割り当て、モデルを構築していく手法です。

いずれの手法でも共通しているのは、「まず概念モデルから始め、モノを特定し、後から関係性と属性を追加していく」という本質です。この基本原則を理解していれば、どのようなデータモデリング手法にも柔軟に対応できるようになります。

データモデリングは死んだのか？

それでは最終的な問いに戻りましょう。これまで振り返った歴史を踏まえて、「データモデリングは死んだのか？」

筆者の結論はこうです。「紙や作図ツール上だけでデータモデルを作成し、稼働するコードや実装と自動的に連動せず、ビジネスユーザーが実際に利用して恩恵を実感できる価値を直接示せないモデリング」は、もはや通用しません。コード生成を自動化しなければ、開発者はデータモデルの真の価値を理解できず、開発の足かせとみなしてしまうでしょう。したがって、従来の旧態依然としたアプローチは確実に終焉を迎えています。

もう1つの問題は、実装を開始する前にデータモデルの設計だけに何ヶ月も費やし、初期段階でビジネス価値を一切生まないことです。これはアジャイルな現代の開発において持続不可能なやり方です。私たちが目指すべきは「アジャイルデータモデリング」であり、概念モデル、論理モデル、物理実装を自動化されたパイプラインでシームレスに結合することです。このアプローチこそが、ビジネスユーザーと開発者の双方に絶大なメリットをもたらし、進むべき正しい道です。

概念・論理・物理モデルの連携

では、データモデルを現実の実装へとどのように直結させることができるでしょうか。その前に、各層の定義を簡単に整理しておきましょう（層の境界線は文脈により多少異なります）。概念モデルとは、モデリングパラダイムに基づいて概念、クラス、エンティティを捉えるものであり、モノ、場所、そこで生じるアクションを包含します。

例えば、「顧客とは何か」「製品とは何を表すのか」を定義することです。従来のデータモデリングでは、モデルの種類ごとに別々のツールを使い分けることが一般的でした。概念モデルを作成してエクスポートし、論理モデルツールにインポートして調整し、さらにそれを繰り返して物理モデルを作成していました。しかし、モデル間が自動的に連動していないため、深刻な同期ズレが生じます。だからこそ、すべてのモデル層を「1つの場所」で一元管理することが不可欠なのです。

筆者にとって、概念モデルは論理モデルの出発点であり、そこに関係性やキーの定義を順次追加していきます。段階的に肉付けすることで、概念モデルは論理モデルへと自然に昇華します。これらは別々のツールや分離した成果物ではなく、同一のワークフローの一部であるべきです。アジャイルに作業を進める過程で、モデルの一部はまだ概念層にあり、別の部分は既に論理層まで詳細化されているという状態が当然発生します。

重要なのは、概念から論理へ、そしてデータベース上のテーブル、カラム、インデックスといった物理実装へと直接的かつ双方向に連携していることです。このプロセスは完全に自動化されるべきです。過去において各層の分断が「データモデリングは死んだ」という誤解を招く最大の要因でした。

かつて概念モデルから論理モデル、物理モデルへの移行には数ヶ月を要し、ビジネスユーザーにとっては成果が見えず理解困難でした。アジャイルパラダイムの強みを活かし、この変換プロセスを自動化して即座に動作する成果物を生み出す必要があります。

もう1つの重大な問題は、ワークフローが一方通行だったことです。本番環境で障害や緊急対応が発生し、エンジニアがデータベースに直接変更を加えた場合、データモデルには反映されませんでした。結果としてモデルと実態が乖離して信用を失い、深刻な負債となりました。したがって、「双方向の同期」が不可欠です。データモデルを真に価値あるものにするには、概念から論理、物理へとリアルタイムで反映されると同時に、物理層での変更がデータモデルへと正しくフィードバックされなければなりません。

これこそが、ビジネス価値を創出し、実装側にも恩恵をもたらす、データモデルを現代に蘇らせる鍵です。

CI/CD（継続的インテグレーション／継続的デリバリー）

これを安全に実現するには、開発環境、テスト環境、本番環境の厳密な分離が必要です。モデルを変更して本番環境に直接反映するような運用は破滅を招きます。バージョン管理とガバナンスが欠如し、通常遵守すべきITIL標準にも違反してしまいます。

一方で、本番障害に迅速に対処するためのクイックフィックス手順も確保しなければなりません。これは変更を開発環境に確実にマージバックすることで達成できます。通常、これにはITILに準拠した統制プロセスが用いられます。

真のアジリティを獲得するには、GitとGitFlowを活用した分散開発アプローチを採用します。これにより、機能やユーザーストーリーを独立したブランチで並行開発し、デプロイ順序を自由に決定できます。完全なバージョン管理とトレーサビリティを確保でき、この手法はJava等のソフトウェア開発者によって長年確立されてきたベストプラクティスです。

Java開発者はローカル端末上の作業フォルダ、ローカルGit、中央Gitリポジトリを駆使し、ブランチをチェックアウトして特定機能の開発を進めます。

しかし、データウェアハウスの世界にはこれまでこれに直接相当する仕組みがありませんでした。私たちはデータベースと実データを扱うため、別の実現方法が必要です。Javaの世界の作業フォルダに相当するものが、DWHにおいては「サンドボックス（開発専用スキーマ/環境）」です。サンドボックスを統合開発環境と同期させ、GitFlowベースのCI/CDプロセスにどのように組み込むかを確立する必要があります。

パイプライン・アズ・コード（Pipelines as Code）

近年提示された代替ソリューションの1つが、「パイプライン・アズ・コード（コードとしてのデータパイプライン）」です。すべてをSQLやコードとして管理すれば、開発者は作業フォルダやファイルを扱い、完全なGitFlowプロセスを適用できます。ブランチを作成し、基本テストを経てマージし、自動テストやプルリクエストを実行してデプロイ順序を柔軟に制御できます。これはCI/CDの観点からは極めて有用です。しかし、dbtやdbt-vaultなどに代表されるこのアプローチには、重大な欠陥があります。プロセスに「意味」を与える「モデリングの視点」が完全に抜け落ちているのです。

ビジネス要件に焦点を当てる代わりにテクノロジー（コード）が主役に躍り出てしまい、結果としてビジネスの意味が埋没してしまいます。モデリングの意図がコードの奥深くに埋もれてしまい、全体の構造を把握するにはコードのリバースエンジニアリングを強いられます。熟練したエンジニアにとっては扱いやすいかもしれませんが、「モデリングの価値を損なうことなく、同じCI/CDのアジリティを達成できないか？」「データモデルをいかにしてCI/CDに適合させるか？」という本質的な課題が残ります。

データモデルを再び活性化させる（Bringing the models back alive）

第一歩は、「アジャイルデータモデル」を確立することであり、ここでData Vaultが真価を発揮します。Data Vaultは、新しい要素をシームレスに追加でき、異なるモデルをマージする際にも競合（コンフリクト）を起こさないという基本思想に基づいています。小さく始めて変更コストを低く抑えることが肝要であり、プロジェクトが進展しても変更コストが増大することはありません。各要素が疎結合であるため独立性が担保され、任意の順序でデプロイ可能です。モデルの異なる領域から同時にモデリングを開始し、後から統合しても破綻しないため、モデリングの観点から理想的な結果が得られます。

第二のステップは、モデリング成果物から物理成果物への変換を自動化することです。幸いなことに、データの機能を異なるモデル要素（識別、記述、関連付け）に既に分離しているため、このプロセスは自動化に極めて適しています。その結果、ハブをデータベーステーブルなどの物理表現へと決定論的（確実）に変換できます。

同様に、物理テーブルから論理オブジェクトへの変換も可能です。メタデータを効果的に捕捉・永続化するために、データモデルをGitの要件に適合するファイル形式として表現します。各ハブ、リンク、サテライトがそれぞれ単一のファイルに対応します。これらのファイルを人間が読める形式（Human-readable）に保つことで、コンフリクトの解消や内容の把握が容易になります。これらのファイルを適切にソート・フォーマットすることで、論理モデルレベルでのブランチ運用やマージを自在に行うことができます。

これにより、コード中心のデータパイプラインと同様の利点を享受しながら、ビジネスの「意味のレイヤー」を強固に保持できます。データモデル内の関係性を明確に説明するコミュニケーションとドキュメントの手段が手に入ります。ビジネス関係者と効果的に協業し、メタデータをレポートやBIへ自動連携して、彼らの知見がデータモデリングにもたらした価値を具体的に証明できます。これにより開発者とビジネス部門の溝を埋め、データモデルに新たな生命を吹き込むことができるのです。

これこそがData Vaultメソドロジーの真髄です。Data Vault Builderがどのようにして「モデリングからコードへの完全自動化プロセス」を実現しているかを、わずか数分間のデモでご紹介できます。データモデルをすべての基盤とし、それ以外のあらゆる反復作業を自動化することで、迅速なデプロイと運用効率化を実現する具体的な方法をお見せします。