すれ違う時の中で「概念データモデル」とめぐり逢えた

はじめに

「概念データモデルについて、ビジネス部門と話が噛み合わない…」というシーンに遭遇しました。「そもそも概念データモデルって何？」って自分も最初思っていました。

そこで、データモデリングの基本である概念データモデル、論理データモデル、物理データモデルの役割と違いを、色々調べたので残します。

エグゼクティブ(経営層)、データガバナンス担当、ビジネス企画担当といった立場の方に向けて、この記事を会議前にチラッとでも目を通しておいてもらえたら、スムーズに議論が進むんじゃないかという期待を込めてまとめています。

もちろん、プロジェクトの規模や状況、開発手法（例えばアジャイル開発など）によっては、ここで紹介する3段階のモデリングをすべて行うことが最適とは限らないと思います。ただ、各モデルが持つ「目的」と「思考の段階」を理解しておくことは、関係者間の認識のズレが減って、データ活用の質を上げることに繋がるのではと思っているので、そういった観点で見てもらえたら嬉しいです！

データモデルとは？ なぜ3段階に分かれるの？

データモデルとは、現実世界の情報をコンピュータで扱えるように構造化した「設計図」 のこと。

この「設計図」作りをスムーズに進めるため、データモデルは目的や詳細度に応じて 「概念」「論理」「物理」の3段階に分けて作られます。なぜこのように段階を踏むのか、そのメリットや全体像について記載していきます。

「最初から物理データモデルを作ればいいのでは？」「もっとスピーディに進めたいのに、3段階も踏むのは現実的ではないのでは？」といった声も聞こえてきそうです。

ただ、このように段階を踏むことには、以下のようなメリットがあり、たとえ簡略化した形であっても、それぞれの段階で「何を考えるべきか」を意識することが、結果として手戻りを減らし、コミュニケーションを円滑にします。

1. 関心の分離 (Focus):

   • 概念モデルでは、「何が必要か」というビジネスの本質に集中できます。技術的な制約を一旦脇に置けるため、自由な発想で要件を洗い出せます。
   • 論理モデルでは、「どう構造化するか」に集中し、データの整合性や柔軟性を高めます。
   • 物理モデルでは、「どう効率的に実装するか」に集中し、パフォーマンスを追求します。
     このように、考えるべきことをステップごとに分けることで、それぞれの段階で最適な判断がしやすくなります。アジャイルな開発プロセスにおいても、スプリントの初期段階でビジネス要求をラフな概念図で共有したり、バックログアイテムから簡易的な論理構造を検討することもあるのでは。

2. 手戻りの防止 (Reduced Rework):

   • 初期段階（概念・論理）で関係者間の認識齟齬を解消し、仕様を固めることで、後の工程での大幅な手戻りを防ぎます。いきなり物理設計から入ると、後で「このデータも必要だった！」「あの部署のデータと繋げたい！」といった問題が発生し、修正が大変になります。家も、基礎工事が終わってから間取りを変えるのは困難ですよね。「急がば回れ」です。

3. 再利用性と柔軟性 (Reusability & Flexibility):

   • しっかりとした論理データモデルが作成されていれば、将来的に使用するデータベース製品を変更する場合（例: OracleからPostgreSQLへ移行）でも、論理データモデルはそのままに、物理データモデルの変更だけで対応しやすくなります。変化の速い現代においては、この柔軟性は重宝されるはず。

基本的には、概念データモデル → 論理データモデル → 物理データモデル の順に、段階的に詳細化しながら設計を進めていくのが理想ですが、プロジェクトの特性に応じて、各モデルの作成粒度やドキュメントの量を調整することが肝心です。まずは、この3つのモデルがどのように連携し、詳細化されていくのか、全体像を見てもらったらイメージしやすいかと思います！

3つのデータモデルの統合的な関係性

段階的な詳細化のイメージ

データモデルの三兄弟 ～段階的に詳細化されるデータの設計図～

データモデルは、こんなデータが欲しいなというビジネスの要望・アイデアから始まり、どんな情報をどんな構造で持つべきかの設計、そして具体的なデータベースの構築まで、段階を経て詳細になっていきます。
それでは、それぞれの団子三兄弟データモデルの三兄弟に一人ずつ出てきてもらいましょう。

1. 概念データモデル (Conceptual Data Model) ～ビジネスの「何を」扱うか、大きな絵を描く～

一言でいうと: ビジネスの世界で重要な「モノ」や「コト」（＝エンティティ）と、それらの「関係性」を、ビジネスの言葉を使って大まかに表現したモデルです。「どんなデータが必要か」を大まかに示す、ビジネス寄りの設計図と言えます。技術的なことは一切考えません。

• 定義: 実装手段から独立し、企業や業務に必要なデータおよびデータ同士のおおまかな関係性を記載したデータモデル。

• 誰にとって重要？

  • エグゼクティブ: 事業全体のデータ構造を俯瞰し、ビジネス戦略との整合性を確認できます。
  • ビジネス部門の企画担当: 自分たちの業務に必要な情報が何か、関係部署と共通認識を持つためのたたき台になります。
  • データガバナンス担当（初期段階）: 組織全体で管理すべき重要なデータは何かを把握し、スコープを定義するのに役立ちます。

• 何をするもの？ (目的・表現内容)

  • ビジネスの視点から、システムで扱うべき重要な情報（主要なエンティティ。例: 「顧客」「商品」「注文」「店舗」）を洗い出します。
  • それらの概念が互いにどう関連しているか（例: 「顧客」が「商品」を「注文」する）を示します。属性（データの詳細項目）はまだ意識しません。
  • プロジェクトの範囲を明確にします。

• 特徴:

  • 抽象度が最も高い: 細かい属性はまだ定義しません。
  • ビジネス用語が中心: IT用語は使いません。誰が見ても理解できる言葉で表現します。
  • コミュニケーションツール: 関係者間での認識合わせや、議論の出発点として使われます。技術的な制約を一旦脇に置けるため、自由な発想で要件を洗い出せます。
  • 技術独立性: 特定のデータベース製品や技術に依存しません。

• 例えるなら: 家づくりの最初の段階で、建築家がお客さんと「どんな雰囲気の家にしたいですか？」「家族構成は？」といった会話をしながら描く、手描きの間取りスケッチやコンセプトデザイン。

ビジネスにとっての価値:
「私たちのビジネスで本当に大事なデータって何だっけ？」という根本的な問いに答える手助けをしてくれます。部門間の壁を越えて、「ああ、あなたの部門では『顧客』をそういう意味で捉えているんですね」といった認識のズレを発見し、修正するきっかけにもなります。まずはビジネスの要求を捉え、関係者間で認識を合わせるための最初のステップです。

2. 論理データモデル (Logical Data Model) ～「何を」「どんな情報で」管理するか、詳細に設計する～

(エンティティ、属性、キー、関係を視覚化した論理データモデル)

一言でいうと: 概念データモデルをRDB（リレーショナルデータベース）で取り扱いやすいよう詳細化したモデルです。どのようなテーブルを作成し、各テーブルにどのような列を設けるべきかを具体的に設計します。

補足：NoSQLデータベースの場合
この記事では主にRDBを前提とした論理データモデルの設計について説明していますが、近年利用が増えているNoSQLデータベース（ドキュメント型、キーバリューストアなど）では、データ構造の考え方や設計アプローチがRDBとは異なる場合があります。例えば、正規化を重視するRDBに対し、NoSQLではデータの読み取り効率を優先して非正規化（データの冗長化）を行うこともあります。
論理データモデルの目的である「何を」「どんな情報で」管理するかを具体的に設計するという本質は同じですが、採用する技術によって最適な構造は変わる点にご留意ください。

• 定義: 概念データモデルのデータ構造を、DBMS（データベース管理システム）、特にRDBに合わせて整理した構造を記載したデータモデル。

• 誰にとって重要？

  • データガバナンス担当: データの標準化、品質管理、データ辞書の整備など、ガバナンス活動の具体的な設計図となります。
  • データベース設計者、システム開発者、ビジネスアナリスト: システム開発の要件定義や、データベース設計の基礎情報として利用します。
  • ビジネス部門の企画担当（詳細検討時）: 自分たちの業務に必要なデータ項目が漏れなく定義されているか、データの意味合いが正しいかを確認します。

• 何をするもの？ (目的・表現内容)

  • 概念データモデルを元に、RDBで実装可能な構造に変換します。エンティティはテーブル（表） として表現されます。
  • 具体的な属性（データ項目、カラム/列） を追加します。（例: 「顧客」エンティティに「顧客ID」「氏名」「住所」「メールアドレス」など）
  • 主キー（PK）、外部キー（FK） を設定し、テーブル間の関連性（リレーションシップ）を明確化します。
  • データの重複をなくし、整合性を保つための「正規化」を行います。
  • データ・エンティティ、属性、キー、関係を視覚化することで、データ構造を明確にします。一般的にER図 (Entity-Relationship Diagram) で表現されます。

論理データモデルの主要な構成要素

論理データモデルは、以下の4つの主要な要素で構成されます（主にRDBを想定）：

構成要素	説明	例
🗂️ データ・エンティティ	データを格納するテーブル	顧客テーブル、注文テーブル、商品テーブル
📊 属性（列）	エンティティが持つ具体的なデータ項目 ・データ型（文字列、数値、日付など） ・NULL許可の有無 ・一意性の定義	顧客ID、氏名、メールアドレス、注文日
🔑 キー	・主キー（PK）: レコードを一意に識別 ・外部キー（FK）: テーブル間の関係を定義	顧客ID（PK）、注文の顧客ID（FK）
🔗 関係	エンティティ間の関連性 ・1対1、1対多、多対多	1人の顧客が複数の注文を持つ（1対多）

概念モデルから論理モデルへの詳細化プロセス

概念データモデルを論理データモデルに変換する際は、以下のステップを踏みます（主にRDBを想定）：

1. エンティティをテーブルに変換 - ビジネス概念を具体的なテーブル構造へ
2. 属性（列）を定義 - 各テーブルが持つべきデータ項目を洗い出し
3. キー（主キー・外部キー）を設定 - データの一意性と関連性を定義
4. 関係を正規化 - 多対多の関係は中間テーブルを作成して解決

例：「顧客が商品を注文する」という概念モデルの関係は、論理モデルでは「顧客テーブル」「注文テーブル」「注文明細テーブル」「商品テーブル」という4つのテーブルと、それらを結ぶ外部キーによって表現されます。

• 特徴:

  • 概念モデルより具体的: 詳細なデータ項目や、それらのデータ型（文字、数値、日付など、ただし汎用的な表現）、キー情報などが定義されます。
  • RDBの原則に従う: テーブル形式でデータを管理し、SQLで操作可能な構造を意識します。
  • 技術独立性 (ある程度): 特定のデータベース製品の物理的な特性には依存しませんが、RDBの概念を前提とします。

• 例えるなら: 家のスケッチを元に、各部屋の正確な寸法、柱の位置、窓の種類や数などを詳細に描いた設計図（ブループリント）。ただし、どのメーカーの柱を使うかまでは指定しない段階です。

ビジネスにとっての価値:
「必要なデータ項目はこれで全部かな？」「このデータは、他のシステムのあのデータと同じ意味だよね？」といった具体的な議論を可能にします。「どう構造化するか」に集中し、データの整合性や柔軟性を高める重要なステップであり、後々のシステム開発やデータ分析の効率を大きく左右します。

3. 物理データモデル (Physical Data Model) ～「どこに」「どうやって」データを格納するか、最終決定～

(データベーススキーマ図：DBMS用の物理的なテーブル構造と制約)

一言でいうと: 論理データモデルを元に、実際にデータを格納するデータベースの種類（例: Oracle, MySQL, PostgreSQLなどのDBMS(Database Management System)）に合わせて、物理的な格納方法を具体的に設計したモデルです。「データをどうやって保存するか」を示す、実際のデータベース構築の指示書となります。

• 定義: (論理データモデルのデータ構造を) 物理的に格納するために整理した構造を記載したデータモデル。

• 誰にとって重要？

  • データベース管理者 (DBA)、開発者（実装担当）、データエンジニア: データベースの構築、パフォーマンスチューニング、運用管理の直接的な設計図となります。

• 何をするもの？ (目的・表現内容)

  • 論理データモデルを元に、特定のデータベース製品上で実際にデータベースを構築し、最適なパフォーマンスが出るように詳細を定義します。
  • テーブル名、カラム名（場合によってはDBMSの命名規則に合わせて変更）。
  • 各カラムの具体的なデータ型（例：VARCHAR(255), INTEGER, DATEなどDBMS固有のもの）。
  • NULLを許容するかどうか、デフォルト値などの制約。
  • インデックス、パーティショニングなどのパフォーマンスチューニングに関する設定。
  • 格納領域の割り当て、ファイル配置など、物理的な保存方法。

論理モデルから物理モデルへの変換 - 3つの観点

物理データモデルを設計する際は、以下の3つの観点で論理モデルを具体化します：

観点	内容	変換例
🔧 物理名の決定	論理名を実装に適した物理名に変換 ・命名規則の適用（英小文字、スネークケース等） ・テーブル名は複数形に	論理名：顧客 → 物理名：customers 論理名：顧客ID → 物理名：customer_id
📏 型・制約の決定	汎用的なデータ型を具体的なDBMS型に変換 ・制約の追加（NOT NULL、UNIQUE、CHECK、DEFAULT）	論理型：文字列 → 物理型：VARCHAR(100) 論理型：整数 → 物理型：INT AUTO_INCREMENT
⚡ パフォーマンス最適化	検索・更新性能を考慮した物理設計 ・インデックスの設計 ・パーティショニング ・ストレージエンジンの選択	PRIMARY KEY、INDEX idx_email 日付による範囲パーティション InnoDBエンジンの選択

物理モデル設計のポイント

物理データモデルは、論理モデルを「どのDBMSで」「どのように効率的に」実装するかを決める重要な工程です。特に以下の点に注意が必要です：

• DBMS固有の機能活用: 各DBMSが持つ特有の機能（MySQL のAUTO_INCREMENT、PostgreSQLのシーケンスなど）を適切に使用
• パフォーマンスと保守性のバランス: インデックスを増やせば検索は速くなりますが、更新処理は遅くなります
• 将来の拡張性: データ量の増加やアクセスパターンの変化を見越した設計

• 特徴:

  • 最も具体的で技術的: データベース製品の仕様に強く依存します。
  • 実装のための最終設計図: このモデルに基づいてデータベースが作成されます。
  • 技術依存性: 特定のデータベース製品に完全に依存します。

• 例えるなら: 詳細な設計図を元に、「この柱はA社のXという製品を使う」「壁紙はB社のYパターン」といった、具体的な材料や工法まで指定した施工計画書。

ビジネスにとっての価値 (間接的):
ビジネスユーザーが直接このモデルを見ることは少ないかもしれませんが、システムの安定稼働、データの高速な読み書き、データの安全性確保といった、ビジネス活動を支える上で非常に重要な役割を果たします。このモデルがしっかりしていないと、「どう効率的に実装するか」が考慮されず、「システムが遅い」「データが壊れた」といった問題が発生しやすくなります。

DDL（Data Definition Language）スクリプト例

物理データモデルは、最終的にこのようなDDL（Data Definition Language）スクリプトとして表現され、データベースを構築します。以下はMySQLを想定した例です。

MySQL用DDLサンプルコード (クリックで展開)

-- MySQL用の物理データモデル（CREATE TABLE文）

-- 顧客テーブル
CREATE TABLE customers (
    customer_id INT AUTO_INCREMENT PRIMARY KEY,
    full_name VARCHAR(100) NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    phone VARCHAR(20),
    address TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_email (email),
    INDEX idx_created_at (created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

-- 店舗テーブル
CREATE TABLE stores (
    store_id INT AUTO_INCREMENT PRIMARY KEY,
    store_name VARCHAR(100) NOT NULL,
    location VARCHAR(255) NOT NULL,
    business_hours VARCHAR(100),
    INDEX idx_location (location)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

-- 商品テーブル
CREATE TABLE products (
    product_id INT AUTO_INCREMENT PRIMARY KEY,
    product_name VARCHAR(200) NOT NULL,
    category VARCHAR(50) NOT NULL,
    price DECIMAL(10,2) NOT NULL CHECK (price >= 0),
    stock_quantity INT NOT NULL DEFAULT 0,
    store_id INT NOT NULL,
    FOREIGN KEY (store_id) REFERENCES stores(store_id),
    INDEX idx_category (category),
    INDEX idx_store_product (store_id, product_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

-- 注文テーブル（パーティショニング付き）
CREATE TABLE orders (
    order_id INT AUTO_INCREMENT,
    customer_id INT NOT NULL,
    order_date DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    total_amount DECIMAL(12,2) NOT NULL DEFAULT 0.00,
    delivery_status ENUM('pending', 'processing', 'shipped', 'delivered') 
        DEFAULT 'pending',
    PRIMARY KEY (order_id, order_date),
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id),
    INDEX idx_customer_date (customer_id, order_date),
    INDEX idx_status (delivery_status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
PARTITION BY RANGE (YEAR(order_date)) (
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION p2025 VALUES LESS THAN (2026)
);

-- 注文明細テーブル
CREATE TABLE order_details (
    detail_id INT AUTO_INCREMENT PRIMARY KEY,
    order_id INT NOT NULL,
    product_id INT NOT NULL,
    quantity INT NOT NULL CHECK (quantity > 0),
    subtotal DECIMAL(10,2) NOT NULL,
    FOREIGN KEY (order_id) REFERENCES orders(order_id),
    FOREIGN KEY (product_id) REFERENCES products(product_id),
    INDEX idx_order_product (order_id, product_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

(このように、具体的なテーブル名、カラム名、データ型、制約などがDBMS固有の構文で記述されます)

3つのモデルの違いを一覧で見てみよう

ここまで各データモデルについて詳しく見てきました。ここで、3つのデータモデルの違いを一度整理します！

特徴	概念データモデル	論理データモデル	物理データモデル
目的	ビジネス要件の把握、関係者間の合意形成	データベース構造の設計	データベースの物理実装、パフォーマンス最適化
詳細度	低（概要）	中（詳細）	高（具体的）
表現内容	主要エンティティ、おおまかな関係	全エンティティ、全属性、キー、リレーションシップ、正規化	テーブル、カラム、データ型、インデックス、制約、格納方法など
対象者	ビジネスユーザー、経営層、業務担当者、アナリスト	データベース設計者、開発者、データガバナンス担当	データベース管理者、開発者（実装担当）、データエンジニア
技術依存度	独立	DBMSの種類に依存 (例: RDB)	特定のDBMS製品に完全に依存
例えるなら	間取りスケッチ、コンセプトデザイン	設計図（ブループリント）	施工計画書

---

3つのデータモデルの詳細な変換プロセス

各モデルで定義される内容の比較

概念データモデルレビュー ～立場別チェックリストで認識のズレを防ぐ～

概念データモデルは、ビジネスの初期段階でその方向性を定めるために重要ですが、異なる立場の関係者間での認識合わせは簡単ではありません。
「具体的にどこを見ればいいのか？」「どのような視点で意見を出せばプロジェクトに貢献できるのか？」といった疑問はつきものです。

このセクションでは、概念データモデルのレビューをより効果的かつ建設的に進めるために、それぞれの立場に応じた「レビューの観点（チェックリスト）」を紹介します。会議前やレビューの際に、ぜひ参考にしてみてください。（クリックで展開できます）

A. ビジネス企画・営業・マーケティング部門の方向けチェックリスト

エンティティ（ビジネスの「モノ」や「コト」）について:

• 図に示されている「顧客」「商品」「キャンペーン」「店舗」といった主要な要素は、あなたの業務やビジネス戦略で重要視しているものと一致していますか？
• あなたの部門で日常的に使っている重要なビジネス用語（例：見込み客、ロイヤルカスタマー、サブスクリプション契約など）で、このモデルに表現されていないものはありますか？
• このモデルのエンティティ名は、部門内で共通認識が持てる、分かりやすい名称になっていますか？
• 将来的に計画している新しいサービスや事業展開を考えたとき、このモデルで表現しきれない重要な概念はありますか？

リレーションシップ（「モノ」や「コト」のつながり）について:

• 「顧客が商品を注文する」「店舗が商品を販売する」といった関係性は、実際のビジネスの流れや顧客の行動と合っていますか？
• 表現されていない、ビジネス上重要なエンティティ間のつながり（例：営業担当者が顧客をフォローする、顧客がイベントに参加するなど）はありますか？
• このモデルを見ることで、私たちのビジネスの全体像や、部門間の連携がイメージしやすくなっていますか？

その他:

• このモデルは、私たちのビジネス目標（例：顧客満足度向上、新規市場開拓など）を達成するために必要な情報を捉える基盤となりそうですか？
• 不明な点、もっと詳しく知りたい点はありますか？

B. システム開発・運用部門、データベース管理者（経験者）の方向けチェックリスト

エンティティ（将来のテーブル候補）について:

• ビジネス部門が挙げている主要なエンティティは、現行システムや将来構想において、データとして管理すべき実体として妥当だと思われますか？
• ビジネス要件として挙げられているエンティティ間で、明らかに統合できるもの、あるいは逆に分割すべきものはありそうですか？（概念レベルでの判断でOKです）
• このエンティティの粒度は、将来的に論理モデル、物理モデルへと落とし込む際に、大きな手戻りを生じさせない程度に適切だと思われますか？

リレーションシップ（将来の外部キーや関連）について:

• エンティティ間の関係性は、将来的なデータ整合性や参照整合性を考慮したときに、大きな矛盾や複雑性を生まないように見えますか？
• パフォーマンスや拡張性の観点から（まだ概念段階ですが）、特に注意が必要そうな関係性（例：非常に多くのデータが紐づく可能性のある関係）はありますか？

技術的な観点（概念レベルでの懸念）:

• この概念モデルをベースにした場合、既存システムとのデータ連携で大きな課題となりそうな点はありますか？（詳細なIF仕様ではなく、概念的なつながりとして）
• （もしあれば）過去のプロジェクトで、概念設計の不備が原因で後工程に影響が出た経験を踏まえ、このモデルで懸念される点はありますか？

その他:

• このモデルは、ビジネス要件を技術的に実現可能なデータ構造へと落とし込むための、良い出発点となりそうですか？
• 不明な点、もっと詳しく知りたい点はありますか？

C. データガバナンス・データマネジメント担当の方向けチェックリスト

エンティティ（管理対象データ）について:

• 図に示されているエンティティは、全社的に管理すべき重要なデータドメイン（例：顧客、商品、組織、契約など）を網羅しているように見えますか？
• 各エンティティの定義は、全社的なデータ標準や用語集（もしあれば）と整合性が取れていますか？または、今後定義すべき重要な概念として認識できますか？
• データのオーナーシップや責任範囲を明確にする上で、このエンティティの粒度や定義は適切ですか？

リレーションシップ（データの関連性・整合性）について:

• エンティティ間の関係性は、データのライフサイクル管理（生成、更新、参照、廃棄）において、整合性を保つ上で重要なものが捉えられていますか？
• データ品質やセキュリティの観点から、特に注意深く定義・管理すべきエンティティや関係性はありますか？

ガバナンスの観点:

• この概念データモデルは、組織全体のデータ戦略やデータ活用方針と整合していますか？
• 将来的にデータカタログを整備したり、データリネージを追跡したりする上で、このモデルは有用な基礎情報となりそうですか？

その他:

• このモデルを基に、データ辞書やビジネスグロッサリーを整備していく上で、追加で明確にすべき定義やルールはありますか？
• 不明な点、もっと詳しく知りたい点はありますか？

これらのチェックリストはあくまで一例です。プロジェクトの状況や目的に応じて、適宜項目を追加・修正して活用してくださいね。

どのモデルに注目すべき？ ～立場別・データモデル活用ガイド～

3つのモデルは、ビジネスのアイデアから具体的な実装へと、上流から下流へ具体化されていくイメージです。それぞれの立場で注目するポイントが異なります。

• エグゼクティブ:

  • 主に概念データモデルに関心を持ちます。「我々のビジネスの全体像はこうなっているのか」「この新しい事業は、既存のデータとどう連携できるのか」といった戦略的な視点で活用できます。ビジネスの骨子を捉え、関係者と大局的な議論をする際の共通認識のベースとなります。

• データガバナンス担当:

  • 概念データモデルで全社的なデータのスコープを把握し、組織が持つべき重要なデータ資産を定義します。
  • 論理データモデルでは、データの標準化、品質基準、セキュリティポリシーなどを具体的に定義・検証し、データ辞書やビジネスグロッサリー整備の基礎とします。
  • 物理モデルの設計原則策定にも関与し、データが組織のルールに従って適切に管理される体制を構築します。

• ビジネスサイドの企画担当:

  • 概念データモデルを通じて、自分たちのビジネス要件やアイデアをIT部門や関係者に伝え、共通認識を形成します。「こんなデータが見たい」「あのデータとこのデータを組み合わせて分析したい」といった要望を、視覚的に分かりやすく示すことができます。
  • 論理データモデルのレビューに参加し、「この項目は必須だ」「このデータの意味はこう解釈してほしい」といった具体的な意見を出すことで、本当に使えるシステム作りに関わることができます。必要な情報が漏れなく、かつ正確に定義されているかを確認する重要な機会です。

このように、自身の役割に応じて注目すべきモデルや関与の仕方は異なります。

まとめ: データモデルは、みんなの「共通言語」

概念データモデル、論理データモデル、物理データモデル。これら3つのモデルは、それぞれ役割と詳細度が異なりますが、すべては「質の高いデータを、ビジネスに活かすため」という共通の目的を持っています。

• 概念データモデル： ビジネス視点の「何が欲しい？」のスケッチ
• 論理データモデル： データベースの構造を決める「どう作る？」の青写真
• 物理データモデル： 実際に格納するための「具体的にどう置く？」の施工計画書

そして何より、これらのモデルは、異なる専門知識を持つ人々（経営層、ビジネス部門、IT部門、データ専門家など）が、データについて同じ方向を向いて議論するための「共通言語」 としての役割を果たします。

「うちのプロジェクトでは、こんなに丁寧にできないよ」と感じた方もいらっしゃるかもしれません。確かに、3段階のモデリングは理想的な姿であり、すべてのプロジェクトで適用できるとは思いません。ただ、各モデルが目指す「思考の整理」や「コミュニケーションの円滑化」という本質は、どのような規模や手法のプロジェクトであっても役立つはずです。

データに関する会議で「今、どのレベルの話をしているんだろう？」と戸惑うシーンが発生するのは仕方がないことだと思います。概念自体の抽象度の高さは、立場や役割など人によって様々なので、「前提情報をすり合わせること」に時間を割くことが大事だよな、でもそんな時間も中々ないよな、ということもリアルな実態だと思います。

そこで、他の人がどんな役割でどんなことに関心があるのか、解像度高く分かると、前提情報のすり合わせに役立つのでは？という思いがあったので、登場人物多めでの長文になってしまいました。ここまで辿り着いた方、最後までありがとうございます！