特別寄稿ブログデータモデルは本当に必要か：第1回データモデルといっても多彩

2026-01-21

本ブログは、これまで多くのデータモデル案件をご一緒してきた、当社のベストパートナーである株式会社データアーキテクト真野正様にご寄稿いただきました。真野様は、一般社団法人データマネジメント・コンソーシアム（JDMC）をはじめとした業界団体での活動や、データマネジメント動向調査の執筆などを通じて、データマネジメントの普及・発展に継続的に取り組まれています。
本連載では、昨今多くのご相談をいただくデータモデルをテーマに、「データモデルは本当に必要か」という問いを起点として、データモデルを描かないことで生じる問題や、描くことで得られる価値を解説しています。全5回の連載を通じて、実務に役立つ考え方を段階的に学べる内容となっていますので、ぜひご覧ください。

はじめに

筆者は長年に渡って、データモデルはシステムを構想したり設計する際に重要なものですから、必ず作成しましょうと言ってきました。しかし、ITエンジニアの方には、「面倒くさいデータモデルなんか作成しなくても、DB設計はできるし、要件定義もやってきた」という方が大勢いらっしゃるのは事実です。

そこで、本ブログでは、データモデルを描かないとこんなことで困るのでは、データモデルを描くとこんな嬉しいことがあるといったことを1つでも2つでもお伝えして、少しでもデータモデルファンになってもらえればという思いで執筆しています。データモデルをどう作ったら良いか（いわゆる作成手順）や、こんなテクニック（考慮点）があるといった方法論について詳しくは触れない予定ですが、データモデラーを志す人にとっての心構えはお伝えできればと思います。

参考リンク：データモデルとは？　データマネジメント用語をわかりやすく解説

データモデルの受け取り方は千差万別

一口にデータモデルといっても、受け取り方は様々です。

データモデルといったときに、人によって受け取る印象は大きく変わりますが、四角と線でER図のようなものを描くことっていうところは一致するかと思います。しかし、そこで表わしているER図のようなものは、描く局面や目的によって大きく異なるということです。

単にテーブル間の主キー（PK)と外部キー（FK)の関係を表わしたものであれば、生成AIがきれいに描いてくれます。これではデータモデルというよりもテーブル関連図に過ぎません。このようなテーブル間の関係が図で明示されたとしても、データ取得のSQLを作成する時に少し便利かなという位で、データモデルを描こうという動機付けとしては低いですね。

データモデルを描く局面をいくつか挙げてみましょう。

DB設計の前哨戦としての役割

DB設計のために必要なものと筆者はずっと思ってきました。しかし、多くの開発現場で、データモデル無しでDB設計している現場があるのは事実です。

データ入力するどんな画面が必要か、画面ベースで進める設計では、画面単位で必要なテーブルを作成しているので、特にデータモデルも必要無いということになります。商品マスタや取引先マスタの参照関係は出てきますが、リレーションシップ付けして明示するほどのことでもないだろうという意見があります。

ちょっと待ってください。そのように画面中心でDB設計していたら、重複データがあちこちに現れてきます。極端にいうと、見積入力や受注入力といった画面単位でテーブルが出来てしまうことです。今トレンドとなっているノーコード、ローコードツールで簡単にアプリは作れるのですが、同じようなデータがあちこちに散在されることになりますので、それを承知した上で使っていきましょう。そこで、それら同じ値を持つと思われるデータ間を同期化していくことが必要になります。

図1-1.画面ベースでのDB設計

ビジネスを捉えるためのツールとして

この商品は、何処から仕入れて、誰向けに販売するものですか。このようなビジネス関係を別にデータモデルで表わさなくとも、PPTのポンチ絵で表わせばよいし、その方がシステムの発注先であるお客様とコミュニケーションも取りやすいと思ってますよね。

システム開発の上流である要件定義では良いのですが、設計に落とし込む際に、販売する得意先は、現場の事業所で、代金の請求は、本社の経理部、さらにコンタクト先は別部門ということは通常ですが、そうした時にDB上のデータ項目とアプリケーションの関係をデータモデル無しでうまく説明できるでしょうか。

図1-2.ビジネス関係を捉えるポンチ絵

AIへの学習データとしての品質向上

今では、生成AIがデータモデルを作成してくれますが、そのためには、ビジネスの実態を表わした学習データ（RAGを含む）を与えてあげる必要があります。

逆に、生成AIに販売予測を問い合わせたりする場合に、学習データを整備しておかないと、誤った答えを自信たっぷりに返してくることになります。AI-Readyデータが整備されていないという状態です。例えば商品コードが、事業所間で統一されていなかったら商品の販売予測が正しくできるでしょうか。AIに正しい情報として提示するための1つがデータモデルでもあります。品質の悪いゴミデータからは、生成AIといえどもゴミの結果が出力されるだけとなります。AIをエンタープライズレベルで使うには、データ整備が必要だということに皆気づいて、データマネジメントに取り組もうという企業が増えてきているわけです。

図1-3.データ品質向上

データの所在を明らかにするために

新たなアプリを作成しようとした時に、システムの入口となるデータが、社内に現存しているのか、それとも新たに登録しなければならないのかといったことがあります。また、出荷数量や売上実績から販売予測を行うために、何処にあるデータを使えば良いのかわからないといったこともあります。

その問題に対処するためには、何処にどんなデータが、どのような型式で存在しているのかを表わしたデータ地図があれば解決できます。

データ地図を基に、どの基盤のどのデータベースに格納されているのかを紐づけて見えることが必要です。このようなデータ地図の作成はデータアーキテクチャと呼ばれますが、そのためにデータモデルを描きます。地図を描くための第一歩は、ASISデータを把握することことに他なりません。

図1-4.データの所在を明らかに

データモデルでどこまで表現できるか

データモデルの現わし方として、エンティティの四角と関連で表わす場合、エンティティを識別するための主キーを定義して表わす場合、そしてエンティティを構成する属性を付加して表わすというやり方があります。

主キーや属性が定義されていないのは、データモデルではないといった見方もありますが、筆者はそうは思いません。エンティティ間の関係を大きく捉えるという点では、エンティティレベルで考えた方が関係者の理解が進みやすいと思います。例えば、組織と社員の関係では、ある組織には1人以上の社員が所属しているので、1：ｎ関係となります。逆に社員から見た場合、社員が複数の組織に所属することがあり得るという兼務がある場合には、社員と組織の関係は1：ｎとなります。即ち、組織と社員の関係は多対多関係ということになります。業務システムの要件を詰める最初の段階では、エンティティレベルでの多対多関係があるということが明らかになっていれば充分なのです。主キーや属性を付加したモデルとするには、1：ｎ関係に帰結する必要があるため一工夫が必要になって、モデル自身が少し煩雑になってしまうといったこともあります。