概念データモデリング：チームのための実践ガイド

営業マネージャーが週次レポートを開くと、ある売上高の数字が目に入る。経理責任者が帳簿を確認すると、別の数字が出てくる。どちらの数字も妥当に見えるが、一方はキャンセルされた注文を含んでおり、もう一方は決済後の売上のみを計上している。来週のプロモーションを決めるはずだった会議が、「売上」とは何を意味するのかという議論に変わってしまう。

このビジネスに本当に必要なのは、追加のデータでも新しいダッシュボードでもないかもしれない。すでに使っている情報についての共通の記述が必要なのだ。概念データモデリングはその記述を提供する。重要なビジネス概念に名前を付け、それらの関係性を示し、チームがレポートを作成したりシステムを接続したりする前に、重要な前提を可視化する。

これは、スプレッドシートを使っていようと、CRM、ERP、分析プラットフォームを使っていようと重要なことだ。始めるのにデータベースの知識は必要ないし、誰かが使えるようになる前に完璧な図を作る必要もない。小さく実践的なモデルがあれば、チームは定義について合意し、食い違うレポートを調査し、より自信を持って意思決定できるようになる。このガイドでは、身近なビジネス事例と、組織がすでに持っているデータを使いながら、段階的にモデルを構築する方法を紹介する。

なぜビジネスデータはパズルのように感じられるのか

営業マネージャーと経理責任者は、必ずしも間違いを犯しているわけではない。同じ言葉について異なる定義を使っている可能性がある。営業は顧客が注文を送信した時点でカウントするかもしれないし、経理は支払いが決済された時点でカウントするかもしれない。レポートがその違いを明確にしていなければ、両チームとも正確な計算を行いながら、異なる問いに答えてしまうことになる。

根本的な問題は、多くの場合データの不足ではなく、意味の共有の欠如である。あるチームはCRM内の誰に対しても「顧客」という言葉を使うかもしれないが、別のチームは購入したことのある人にのみそれを使うかもしれない。あるスプレッドシートでは企業を「アカウント」と呼ぶ一方、別のレポートではその企業の各連絡先を「顧客」として扱うこともある。こうした概念が整合していないと、システムを接続したりダッシュボードを追加したりすることで、混乱が解消されるどころか広がってしまう可能性がある。

見えない前提を可視化する

概念モデルは、チームが依拠するビジネス情報の共通の地図を提供する。顧客が注文を行い、注文には製品が含まれ、プロモーションが一定期間中の製品に適用される、といったことを示すことができる。このモデルはまた、人々が実用的な問いを投げかける場にもなる。顧客記録なしで注文が存在しうるか？一つのプロモーションが複数の製品をカバーできるか？「売上」とは注文総額を意味するのか、支払われた金額を意味するのか、それとも別の何かなのか？

これらの問いは技術的な些事ではない。チームがレポートを比較できるか、パフォーマンスを追跡できるか、どの製品を推進すべきか決定できるかに影響する。共通の語彙は、新しいデータ構造を構築する前に、ビジネス側と技術側の同僚が同じ概念について議論するのに役立つ。

意見の相違から始める： 二つのレポートがどのビジネス用語を異なって解釈しているかを問いかけてみよう。その問いが、モデルの最初の有用な部分を明らかにすることが多い。

同じ課題は、複雑なデータベースを抱える組織に限らず、多くの組織で見られます。チームが競合するレポート定義に取り組んでいる場合は、この競合するレポートを抱えるチーム向けガイドが、レポーティングの意味を共有するための別の視点を提供してくれます。重要なのは、食い違いを誰かの失敗の証拠としてではなく、ビジネスルールを明確にするきっかけとして捉えることです。

概念データモデリングの基本概念を理解する

建物の設計図を思い浮かべてください。部屋とその間を人がどう移動するかは示されますが、配管の直径や電気配線の詳細まで指定する必要はありません。概念データモデルも同じように機能します。データベースのテーブルやストレージ技術、クラウドプラットフォームを選ぶことなく、ビジネス上重要な事柄とそのつながりを記述するものです。

まずはエンティティ、つまりビジネスが扱う必要のある人、物、出来事、概念から始めます。小売業者であれば、顧客、注文、製品、プロモーションといったものを識別するかもしれません。これらはまだデータベースのテーブルではありません。人々が認識し、定義できる意味のあるビジネス概念です。

次に属性、つまりエンティティを説明するのに役立つ特性を特定します。顧客には名前や顧客ステータスがあり、注文には注文日やビジネスステータスがあるかもしれません。概念モデルでは通常、システムが最終的に保存するすべての項目を列挙しようとするのではなく、エンティティの意味を明確にする属性に焦点を当てます。

概念同士をリレーションシップでつなぐ

リレーションシップは、エンティティ同士がどのように関連しているかを表します。顧客が注文をする。注文には製品が含まれる。プロモーションが製品に適用される。リレーションシップを日常的な言葉で表現することで、業務担当者がそのモデルが実際の業務の進め方を反映しているかどうかを確認しやすくなります。

カーディナリティは、一方のエンティティのインスタンスが他方といくつ関連しうるかを表します。例えば、一人の顧客は複数の注文をすることがありますが、各注文は一人の顧客に属します。また、チームはそのリレーションシップが任意かどうかも検討する必要があります。顧客は注文をする前から存在しうるのか、それともすべての顧客が必ず一つの注文を持つ必要があるのか、といった点です。

モデルにはビジネスルール、つまりリレーションシップや定義を意味あるものにする条件も記述できます。ルールとしては、プロモーションは指定された期間中のみ適用されるとか、完了した注文には決済ステータスが必要であるといったものが考えられます。これらのルールはビジネスがどのように機能するかを説明するものであり、データベースがそれをどう強制するかを記述する必要はありません。

実務上の価値はコミュニケーションにあります。業務担当者は定義に異議を唱えることができ、アナリストはレポーティング上の前提条件を特定でき、技術チームは後で合意された概念をより詳細な設計に落とし込むことができます。モデルは、チームが共に考えられる水準にとどまります。

エンティティ・リレーションシップモデルの解説

エンティティ・リレーションシップ(ER)モデルは、エンティティ、属性、リレーションシップを表現するための、チームにとって馴染みのある視覚的な方法を提供します。オンライン小売業者を例に考えてみましょう。顧客はエンティティであり、名前は顧客の属性であり、「顧客が注文をする」はリレーションシップです。図にすることで、これらの概念を一枚の紙面上で可視化でき、データベースを設計する前に同僚たちがビジネス構造について議論できるようになります。

ピーター・チェンは1975年に開催された第1回International Conference on Very Large Data Basesで自身のERモデルを発表しました。彼の論文は1976年3月にACM Transactions on Database Systems創刊号に掲載されました。チェンのアプローチは、データベース設計のための構造的な基盤を提供しながらも、ビジネス言語でデータ要件を伝えやすくすることに貢献しました（論文の経緯とERモデリングの背景）。

図をビジネス上の文章として読む

シンプルなER図は、各つながりを文章に置き換えると読みやすくなります。「顧客が注文を行う」はひとつの関係を表しています。「注文が商品を含む」は別の関係を表します。エンティティ名はビジネスが追跡する必要のある対象を示し、属性は各概念に関する有用な詳細を提供します。

この図はまた、用語の一覧だけでは見えてこない疑問を投げかけます。ひとつの注文が複数の商品を含み、ひとつの商品が複数の注文に現れうるなら、そのつながりは多対多です。ひとつの注文に顧客がひとりしか紐づかないのであれば、モデルはその前提を明確にする必要があります。表記法はモデリング手法によって異なる場合がありますが、ビジネス上の意味は理解できるものでなければなりません。

よくつまずく点のひとつは、あるものをエンティティとして扱うべきか、それとも関係として扱うべきかを決めることです。プロモーションに固有の名称や期間、ルールがあるなら、それは単なるProductのプロパティではなく、エンティティとして表現する価値があるかもしれません。独立したビジネス上の意味を持たない短いラベルを記録するだけなら、属性で十分な場合もあります。答えは図の表記規則ではなく、ビジネスがその概念をどう使うかによって決まります。

ERモデルは、会話と設計をつなぐ役割を果たすため、今なお有用です。その考え方は、エンティティ・リレーションシップ図、論理スキーマ、データアーキテクチャの実践に影響を与えてきました。この図の読み方について実践的に解説したものとして、エンティティ・リレーションシップ図の解説を参照してください。図は、すべてのシステムのすべてのフィールドを網羅する一覧表にするのではなく、人々が下す必要のある意思決定に焦点を絞ったものにしておきましょう。

概念データモデル・論理データモデル・物理データモデルの違い

チームはしばしば「データモデル」という言葉を、異なる詳細レベルの設計を指すために使います。概念レベル、論理レベル、物理レベルを分けて考えることで、そのモデルがどの問いに答えるものなのか、そして誰がレビューすべきなのかを理解しやすくなります。

一つのアイデアから、詳細度を高めていく

概念モデルは、ビジネスの視点を捉えるものです。注文（Order）が顧客（Customer）によって発注される、ということを、どちらのレコードがどこに保存されているかを指定せずに表現できます。この技術的な独立性は意図的なものです。基盤となるシステムが変わっても、ビジネス上の意味は有用であり続けるべきだからです。

論理モデルは構造を追加します。チームはより多くの属性を定義し、識別子を明確にし、関係性を解決することができます。この段階でも、特定のデータベース製品にはまだ縛られません。この段階では、リレーショナル設計のルールが関係してくることがあります。例えば正規化は、ある属性が別のエンティティに属するべきかどうかを見極めるのに役立ちます。これにより、更新時に同じ情報の矛盾したコピーが生じることを防げます。OrderIDとProductIDで識別されるOrderLineリレーションにおいて、ProductNameは複合キー全体ではなくProductIDに依存しています。したがって、ProductNameはOrderLineの属性として繰り返すのではなく、Productに属するべきです（正規化のルールと例）。

次に物理モデルが、その設計を特定のデータベースにおける実装の詳細へと変換します。これには実際のテーブル、カラム、データ型、ストレージの選択が含まれます。これらの詳細は、システムを構築・運用する人々にとっては重要ですが、「顧客」とは何かという最初の議論を主導する必要はありません。

この3階層の区分には歴史的な背景があります。1975年、ANSI/SPARCの研究は、外部・概念・内部という階層を持つアーキテクチャを提唱しました。その概念スキーマは、物理的な保存やアクセス方法とは切り離された、企業全体にわたるデータの視点を描写するものでした。これは普遍的に実装される正式な標準にはなりませんでしたが、その用語法はビジネス上の意味と実装の詳細を区別するという考え方を確立するのに役立ちました（スリースキーマアプローチ）。概念レベルを省略すると、技術チームが推測に基づいてビジネス上の意思決定をしてしまう恐れがあります。

概念モデルを構築する実践例

ある小売業者が、プロモーションが売上にどう影響するかを把握したいと考えているとします。すでに週次プロモーションのスプレッドシート、顧客レコードを含むCRMのエクスポートデータ、そして販売システムからの注文データを保有しています。最初に取り組むべきことは、すべてのファイルを統合することではありません。まず、分析が表現すべきビジネス上の概念について合意することです。

ビジネス上の問いから始める

平易な言葉でシナリオを書き出します。「プロモーション期間中に発注された注文とそれ以外の注文を比較し、顧客がどの商品を購入したかを把握したい」。これにより、チームには情報をモデル化する理由が生まれ、最初の草案に何を含めるべきかを判断する基準ができます。

想定されるエンティティを特定します：

• Customer（顧客）、注文を行う個人または組織。
• Order（注文）、小売業者が分析したい購入イベント。
• Product（商品）、販売可能な品目。
• Promotion（プロモーション）、ビジネスルールが定義された施策。

次に、それらの概念を明確にするために必要な属性だけを追加します。顧客には顧客ステータスがあるかもしれません。注文には注文日とステータスがあるかもしれません。製品には製品名があるかもしれません。プロモーションには、名称、適用期間、オファーの種類があるかもしれません。これらは出発点として有用なものであり、スプレッドシートのすべての列を再現する必要があるわけではありません。

関係性をマッピングし、前提を検証する

次に、関係性を文章で説明します。顧客は注文を行う。注文には製品が含まれる。プロモーションは製品に適用されることがある。次に、それぞれの関係においていくつのインスタンスが関与できるかを問います。1人の顧客が複数の注文を行うことがあり、1つの注文に複数の製品が含まれることがあり、1つの製品が複数の注文に登場することがあります。プロモーションが複数の製品を対象にでき、各製品が時間の経過とともに複数のプロモーションに含まれうる場合、その関係は多対多となります。

難しい判断となりがちなのは、ある概念がエンティティなのか属性なのかという点です。プロモーションは、ビジネス側が独自の日付、ルール、適用条件を管理している場合、エンティティである可能性が高くなります。「プロモーション」が製品に付随する短いラベルに過ぎず、独立したライフサイクルを持たない場合、チームは異なるモデル化を行うかもしれません。この問いを推測で片付けてはいけません。プロモーションを作成する担当者に、それをどのように定義し、変更し、評価しているのかを尋ねてください。

解釈に影響を与えるルールを記録してください。例えば、プロモーションは注文日に基づいて適用されるのか、支払日に基づいて適用されるのか。1つの注文に、プロモーションの適用条件が異なる製品を含めることはできるのか。プロモーションの成果を測定する際に、キャンセルされた注文は含まれるのか。これらの判断は、レポートが何を意味しうるかに直接影響します。

最後に、ドラフトをスプレッドシートやCRMエクスポートの実際の例と照らし合わせて検証します。想定された関係に当てはまらない注文、重複した顧客ラベル、複数の製品や期間にまたがるプロモーションレコードがないか確認してください。目的は最初のダイアグラムを網羅的にすることではありません。business users（業務担当者）が早い段階で修正できるように、前提を早期に明らかにすることです。

概念モデルが放棄される理由と、それを避ける方法

正式なモデリングは、計画会議の中では価値があるように聞こえても、日々の業務が本格化すると消えてしまうことがあります。485人のデータベース専門家を対象とし、34件のインタビューで補足されたある調査では、それが役立つと考えていた場合でも、正式な概念データモデリングを一貫して使用していたのは40%未満であることが分かりました。ホワイトボードのみでの議論を代替手段として報告したのは45.1%、時間不足が障壁になっていたのは42.1%でした（モデリングの実践と導入に関する調査）。

中小企業にとっての教訓は、すべてのチームが大規模なモデリングプロジェクトを計画すべきだということではありません。むしろ、プロセスを人々がすでに働いているやり方に合わせる必要があるということです。作成や維持に時間がかかりすぎるモデルは、すぐに陳腐化してしまいがちです。誰も見返さない洗練されたダイアグラムよりも、現在進行中のレポート上の論争を明確にするシンプルなドラフトの方が、より役立つことがあります。

実用最小限のモデルを構築する

1つのビジネス上の問いに必要な概念から始めましょう。財務部門と営業部門が注文収益について意見が一致しない場合、まずは顧客、注文、関連する収益の定義、そして注文がいつカウントされるかを決定する日付に焦点を当ててください。分析に必要になった時点で、製品やプロモーションを追加します。新しい問いが生じるたびに、モデルを拡張していくことができます。

既存の資料は実践的な出発点になります。すでに使われているスプレッドシート、CRMのエクスポートデータ、レポートなどを見直してみましょう。繰り返し現れるビジネス用語に印をつけ、2つの列が同じことを意味しているように見える箇所に印をつけ、チームによって異なるラベルが使われている箇所をメモします。そうした気づきを、そのプロセスを担当する人たちとの短いディスカッションに持ち寄りましょう。

モデルは、ページを埋めることではなく、意思決定を解決することによってその存在価値を得ます。

ドキュメントは、解釈に影響する選択に焦点を絞りましょう。エンティティが何を意味するか、他の概念とどう関係するか、その関係が任意かどうか、どの日付やステータスが指標を左右するか、といった点です。実装の詳細は後から技術チームに加えてもらえばよいのです。こうすることで、ビジネスユーザーにデータベース設計を求めることなく、初期段階のモデリングを有用なものに保てます。

進捗は、人々がレポートを突き合わせられるか、指標を一貫して説明できるか、誤解を減らしながら新しいデータを議論に持ち込めるか、によって測りましょう。モデルが役立たなくなったら、改訂してください。それはビジネス上の意味についての実務上の合意であって、手を加えてはならない図ではないのです。

概念モデルが現代のアナリティクスとAIを支える仕組み

しっかりと定義されたモデルは、複数のシステムをまたぐ安定した意味論レイヤーとして機能し得ます。ERPは注文を追跡し、CRMは顧客関係を追跡し、財務システムは決済を記録するかもしれません。各システムが異なるフィールド名を使っていたとしても、組織は各システムをマッピングする前に、顧客、注文、収益が何を意味するかについて合意しておくことができます。

この合意は、アナリティクスが異なる粒度の情報を組み合わせる際に重要になります。注文レベルの収益は個々の購入を表し、顧客・月単位の属性は一定期間にわたる顧客の情報を要約します。これらの概念を、その粒度を明示せずに結合すると、もっともらしく見えるものの、間違った問いに答える結果を生み出しかねません。モデルは、各指標が何を表しているか、どの期間が適用されるか、関係性をどう解釈すべきかをチームが問い直す助けになります。

定義を追跡可能な場所に置く

概念モデリングは、メタデータガバナンスも支えます。メタデータとは、ビジネス上の定義、所有者、有効な値、ソースへのマッピングなど、データに関する情報のことです。ISO/IEC 11179-3:2023は、再利用可能な項目を識別、定義、登録、分類するための構造を備えたメタデータレジストリのメタモデルを規定しています。関連する拡張仕様は、データ要素概念、概念ドメイン、値ドメインを対象としています(ISO/IEC 11179-3:2023)。

実務的に言えば、チームは「純売上高」のようなビジネス概念を、その定義、単位、所有者、ソースフィールドに結び付けることができます。これにより、純売上高と総売上高、あるいは注文日と決済日を区別しやすくなります。このモデルはアナリティクスが正しいことを保証するものではありませんが、指標を組み合わせたり比較したりする前に、アナリストや自動化されたプロセスがチェックすべきより明確な定義を提供します。

この基盤は、組織がセマンティックレイヤー、自動化されたレポーティング、AI支援分析を活用するようになるにつれ、ますます重要性を増しています。概念モデル作成に関する研究では、繰り返し発生する判断上の課題が指摘されています。特に、関係タイプの決定、カーディナリティの割り当て、関係の命名です。自然言語によるリクエストは、こうした選択を覆い隠すことがあります。「プロモーション期間中に購入した顧客」という表現では、何が購入としてカウントされるのか、どの日付が「期間中」を定義するのか、そして顧客が複数の注文を通じて条件を満たせるのかどうかが曖昧なままです(概念モデリングにおける課題に関する研究)。

分析業務の成熟度を高める計画を立てているチームには、Appliedのデータドリブンチームのためのロードマップが、このモデリング作業と合わせて役立つ情報を提供してくれるでしょう。構造化の度合いが低いデータソースを扱うチームは、ELECTEによる半構造化データに関する知見も参考にできます。どちらの場合も原則は同じです。自動化された結果を信頼する前に、ビジネス上の意味を定義することです。

重要なポイントと次のステップ

概念モデルはコミュニケーションのためのツールであり、技術的な成果を誇示するためのものではありません。レポートの背後にある人物、イベント、製品、測定指標について、それらがシステムや自動分析に組み込まれる前に、同僚間で合意を形成する助けとなります。

まずは、2つのチームが異なる売上を報告しているのはなぜか、といった現実のビジネス上の疑問を1つ取り上げることから始めましょう。その上で:

• 中核となる概念に名前を付ける: その疑問に関係するエンティティを特定します。
• 言葉を定義する: 重要な用語それぞれについて、簡潔なビジネス上の定義を書きます。
• 概念をつなぐ: 関係性を平易な文章で説明し、それが任意かどうか、一対多かどうかを明確にします。
• 実際の事例を確認する: 草案をスプレッドシート、CRMのエクスポートデータ、取引記録と照らし合わせ、例外を見つけます。
• ビジネスの変化に合わせて見直す: 新たな意思決定やレポーティングのニーズが生じたら、詳細を追加します。

完璧なドキュメントや専用のモデリングプログラムを待つ必要はありません。最初の草案は、いくつかの定義と明確に示された未解決の疑問を含む、小さな図で構いません。それをデータを利用する人々のもとへ持って行き、意思決定に影響する前提条件を確定させ、ビジネスが変化したらモデルを更新しましょう。

ELECTEは、中小企業向けのAI搭載データ分析プラットフォームであり、ビジネスデータを接続し、チームがインサイトの探索、予測、レポート作成を行えるよう支援します。より信頼性の高い分析のために、より明確な定義を構築しようとしているなら、ELECTEを訪れて、このプラットフォームがあなたのチームをどのように支援できるかをご覧ください。