🪜

データモデリング―第4部　次世代への提言（後編）

に公開
ER 図
データモデリング
idea

📘 第4部：次世代への提言（後編） ― 意図（Intent）レイヤの提言

第3部で挙げた課題のうち、残るものが次の4つめである。

  1. 構造と意図（Intent）を並走させ、意図が自然に残る運用を前提にすること

これは構造そのものではなく、「意味や判断理由をどう残すか」という課題であり、
モデルの変更耐性・継承性に関わる別のレイヤ（Intent Layer）である。

📘 第9章：Intent ― モデリングに“理由”を与える技術

次世代モデリングにおける最後の提言は、
“意図（Intent）”をデータモデルと並走させるという考え方 である。

ER図が誕生してから約50年。
多くの現場が「構造だけは残っているのに、理由はどこにもない」
という問題に悩まされ続けてきた。

Intent は、この“理由の欠落”を埋めるための新しい技術である。

✨ 9.1 なぜ Intent が必要なのか ― モデルに残らない“判断の痕跡”

データモデルは 構造だけ を残す。
「なぜその構造にしたのか」は図にもテーブルにも残らない。

ここで、胸に手を当てて思い出してほしい。
いままで、「なぜこの構造にしたんだ？」 と――

  • 1か月前の自分に聞きたい
  • 前任者に聞きたい
  • 最初の設計者に聞きたい

そんな瞬間は、ありませんでしたか？

その答えがどこにもないまま、現場では次のような事態が日常的に発生する。

  • なぜ、正規化していないのか意図がわからず、触れない“聖域テーブル”が生まれる
  • 中間テーブルにどんな業務意図があったのか誰も説明できない
  • 「その制約は要るのか？」が判断できず、変更が止まる
  • 誰が見ても“整った模型”なのに、なぜこの形なのかが伝わってこない

構造は残るが、理由は1ヶ月で消える。
理由が消えると、変更コストだけが肥大化する。

Intent は、この“理由の空白”を埋めるためのものだ。

✨ 9.2 Intent とは何か ― 判断理由を“残せる形”にするための補助レイヤ

Intent は、データモデルの構造そのものではない。
構造を決めたときの判断理由を、後から追える形で残すための補助情報である。

データモデルだけでは、次が残らない。

  • なぜこのEntityを分けたのか
  • なぜこの属性を持たせたのか
  • なぜこの関係にしたのか
  • なぜこの制約や実装を採用したのか

Intent の目的はシンプルだ。

「なぜそうしたか」を、未来の自分や次の担当者が迷わず理解できる状態で残すこと。

Intent はモデルに混ぜない。
図を汚さず、モデルの横に並走させる。
そして、“判断の要点だけ”を短く残す。

つまり Intent は、
データモデルを“構造だけの記録”で終わらせず、変更できる状態で保つための仕組みである。

📘 9.3 Intent の使い方 ― どこに、何を、どう残すか

Intent が“必要である理由”と“Intentとは何か”を理解したところで、
次は実際にどう使うかを整理する。

Intent は「大量に書くもの」ではない。
判断が発生した場所に、判断の理由を短く残す。
これだけで十分に効く。

Intent が生まれるのは、設計者が一人で判断した瞬間だけではない。
相談・会議・レビューの場で「この形で行こう」と合意された判断も、
同じくらい未来に効く Intent になる。

議事録や課題管理に理由の詳細が残っているなら、
Intent 側には要点だけを書き、
参照先（会議日付／議事録／課題番号）へリンクしておけばよい。

Intent の使い方は、次の3つのステップに集約できる。

9.3.1 判断が発生した“場所”を特定する

Intent は、判断が起こった粒度に対応させて残す。
判断の粒度は大きく5種類ある。

  • Entity（実体）
  • 属性（カラム）
  • 関係（リレーション）
  • 物理構造（テーブル・ビュー・インデックスなど）
  • 全体方針（ID体系・履歴方式など）

どの粒度で判断が起こったのか。
まずそこを特定することが出発点になる。

9.3.2 “何を残すか”を決める（抽象／論理／物理の三層）

Intent の内容は、判断の種類に応じて三層に分かれる。

  • 抽象 Intent（意味の理由）
    概念境界、責務、業務上の意味の判断
  • 論理 Intent（構造の理由）
    正規化／非正規化、関係、制約、属性の扱い
  • 物理 Intent（実装の理由）
    インデックス、パーティション、生成列などの最適化

判断の“質”によって、どの層の Intent かが決まる。

9.3.3 “どう書くか” ― 最小限の1行でよい

Intent は長文である必要はない。
判断の理由が未来の読み手に届く最小限でよい。

書き方の基本は次の3つだけ。

  1. 判断の要点を書く（例：非正規化した理由）
  2. 背景が Issue や議事録にあるなら参照先だけ残す
  3. 削除条件・再検討条件があれば書く

例（論理 Intent）：

顧客名フラグを保持：検索性能のため非正規化（Issue #210）
将来、検索API移行後に見直し予定

例（物理 Intent）：

月次増分が多いためBRIN Index採用（Issue #551）

例（抽象 Intent）：

見積と契約は概念が異なるため実体を分離

例（会議／相談 Intent）：

「受注と契約を分離」：境界レビューで合意（MTG 2025-09-12 / Issue #381）

9.3.4 どこまで残すべきか ― 残すもの／残さないものの基準

Intent は“効かせ薬”であり、すべての判断に書く必要はない。
未来の読み手が迷う判断にだけ、短く残すのが基本である。

✅ 残した方がいいもの（Intent候補）
  • 見ただけでは理由が推測できない構造
    • 非正規化・特殊な中間テーブル・クセのある制約など
  • 議論やトレードオフがあった判断
    • A案/B案で迷った、会議やレビューで合意した、など
  • 変更コストが高い土台系の判断
    • 境界の置き方、ID体系、履歴方式、分割/統合方針
  • 期限付き／将来見直す前提の判断
    • “予備”として作ったテーブル・ビュー・インデックスは
      削除条件や再検討条件とセットで残す
🚫 残さなくていいもの
  • 誰が見ても自明な判断
    • 王道どおりの正規化、一般的な1:N関係、素直な辞書テーブルなど
  • 短期の作業メモで終わるもの
    • その場限りの試験・移行用構造（ただし残骸化するなら削除条件だけ残す）
  • 好みの範囲に留まり、構造の理解や変更判断に影響しない“こだわり”
    • 趣味の設計メモまで Intent にすると、Intent 自体が読めなくなるため
🎯 迷ったときの判断基準

1か月後の自分／次の担当者が
「なぜ？」と止まりそうなら残す。
止まらなそうなら残さない。

Intent は“全部に貼るラベル”ではなく、
つまずきポイントにだけ置く標識である。

✨ 9.4 Intent 導入の効果 ― モデルが“読めて、変えられる”状態へ

Intent を導入すると、データモデルは単なる“構造図”ではなく、
誰が見ても判断の継続ができる資産へと変わります。

現場で得られる主な効果は、次のとおりです。

✔ 1. 変更判断が正確かつ速くなる

Intent が無いと、変更のたびに次のような迷いが生まれます。

  • 「この制約は消していいのか？」
  • 「この中間テーブルは何のため？」
  • 「この非正規化は本当に必要？」

Intent があれば、判断理由を追う作業が不要になります。
変更の影響範囲も把握しやすくなり、判断のスピードと精度が大幅に向上します。

✔ 2. レビューが“形”から“理由”を見る場に変わる

レビューが設計の正当性ではなく「図の綺麗さ」に寄ってしまうのは、
理由がどこにも残っていないからです。

Intent によってレビューの焦点は、

「この理由は妥当か？」
「この判断は今の状況でも有効か？」

という 本質的な議論 に移ります。

レビューの質が上がり、合意形成も容易になります。

✔ 3. 技術負債の発生源を潰せる

Intent が無いモデルでは、使われなくなった構造が残りがちです。

  • 謎の補助テーブル
  • 昔のままのインデックス
  • 意味不明なビュー
  • 消しづらい“予備”テーブル

Intent で「なぜ作ったか」「いつ消せるか」を残しておけば、
不要な構造を安心して整理でき、技術負債の発生を抑止できます。

✔ 4. 属人性が減り、引き継ぎが容易になる

Intent は、判断の理由を外部化する仕組みです。
そのため――

  • 担当者が変わっても意図が途切れない
  • 新メンバーでも判断が再現できる
  • “最初の設計者だけが知っている判断”が消える

など、組織としてモデルを維持する力が高まります。

Intent があるモデルは、誰が引き継いでも継続して改善できるモデルになります。

✔ 5. モデルの寿命が延びる

Intent が無いモデルは“構造だけの化石化”が始まり、
数年後には誰も触れなくなります。

その背景には、データベース特有の“寿命の長さ”があります。
実際のシステムでは、データベースの寿命はアプリケーションより長くなることが珍しくありません。
アプリケーションは数年ごとにリプレースされても、データベースだけは
「互換性のためにそのまま残す」という運用が続きます。

プログラム側には設計書があり、コードにはコメントもあります。
しかしデータベースには、そうした“理由の記録”がほとんど残りません。
このアンバランスさこそが、後年の保守を難しくする大きな要因です。

Intent を適切に残しておけば、データベース側にも
「何のためにこの構造になっているのか」という判断理由が残り、
アプリケーションの世代交代が起きても、モデルだけが置き去りになることを防げます。
つまり Intent は、DBにとっての「設計コメント」に相当します。

Intent があるモデルは、理由が残るため、

  • 読める
  • 判断できる
  • 改善できる

というサイクルが維持され、
モデルの寿命が圧倒的に長くなります。

✨ 9.4 まとめ：Intent がもたらすもの

Intent を導入することで、データモデルは“構造の記録”から一歩進み、
判断の連続性を保てる資産へと変わります。

  • 変更判断が速く、正確になる
  • レビューが「形」から「理由」へ移り、議論が深まる
  • 技術負債の発生源を抑えられる
  • 属人性が減り、引き継ぎが容易になる
  • モデルの寿命が長くなり、長期運用でも読み解ける

Intent の効果は、短期よりも 数ヶ月後・数年後に強く現れます。
未来の自分や次の担当者が、迷わず走り出せる“継続可能なモデル”になること――
これが Intent の本質的な価値です。

📘 9.5 Intent は必須ではない ― しかし導入すれば劇的に効く

Intent は CLM の必須要素ではありません。
理由はシンプルで、Intent の効果は 環境・文化・道具の成熟度 に大きく左右されるからです。

✔ 1. 設計環境によって残せる量が変わる

  • ホワイトボードではほぼ残らない
  • 紙では重要な要点だけ残る
  • ツールでは UI 次第で残せる／残せない

どんな環境でも必須にしてしまうと、
“形だけ書かれた Intent” が量産され、かえって形骸化します。

✔ 2. チーム文化によって書きやすさが異なる

  • 理由を言語化する文化
  • レビューをする文化
  • 合意形成を残す文化

こうした基盤が無い現場で Intent を義務化すると、
“とりあえず書いた文章” が増えて品質が下がります。

✔ 3. Intent は“適切な判断にだけ”効く薬である

Intent の本質は、
未来が止まらないようにするための補助レイヤ です。

すべてに書く必要はありません。
残すべき判断は 9.3.4 の基準（迷いそうな判断・期限付きの判断など）に絞れば十分です。

✔ まとめ：Intent はオプションだからこそ機能する

Intent は義務ではありません。
しかし、必要な場所に適切に残せば、現場の“継続性”を劇的に改善する力があります。

  • 使える環境なら使う
  • 必要な判断だけに残す
  • 適度な粒度で未来に渡す

この “選択制” こそが、Intent を正しく機能させる前提です。

🎯 第9章まとめ

Intent は、構造の裏側にある “判断の理由” を残す技術である。
意味 → 構造 → 実装のどこで何を考えたかを記録し、
データモデルが“読めて、変えられる”状態を未来に残す。

必須ではない（環境と文化に依存するため）。
だが導入すれば、変更・レビュー・引き継ぎの質を底上げし、
モデルの寿命を劇的に延ばす。

📘 終章：4部作の総括 ― データモデリングの再定義

本書の序章から第4部まで、私たちは「データモデリングの50年」を
さまざまな角度から見てきた。

  1. 序章では、データモデリングとは
    “意味 → 構造 → 実装” をつなぐ技術であることを確認した。

  2. 第1部（誕生） では、
    現実世界を概念として捉えるための理論（ERモデル）が誕生し、
    世界中のシステムの共通言語となった歴史を見た。

  3. 第2部（盛衰） では、
    分散・柔軟性・NoSQL・多構造化という時代の変化により、
    ER図だけでは世界を表現しきれなくなった過程を整理した。

  4. 第3部（再構築） では、
    “抽象・論理・物理” を明確に分け、
    基底関係図とビューを中心とする CLM（Canonical Layered Modeling） を提案した。

  5. 第4部（Intent） では、
    構造だけでは残らない“判断の理由”を
    Intent として並走させることで、
    モデルの寿命と変更耐性を飛躍的に高める手法を示した。

🎯 4部作を通じてたどり着いた結論

データモデリングとは、
“意味 → 構造 → 理由 → 実装” を
一貫して扱うための体系である。

かつては ER図1枚で十分だった。
しかし今は、抽象・論理・物理・Intent の4レイヤが必要である。

それは複雑化したからではない。
複雑な世界を“壊れない形で扱う”ために必要な最低限の構造が
この4レイヤになったということだ。

🔧 モデルは構造だけでは動かない

  • 抽象がなければ「何を扱うか」が揺らぐ
  • 論理がなければ「どう構成するか」が定まらない
  • 物理がなければ「どう実装するか」が動かない
  • Intent がなければ「なぜそうしたか」が消えていく

4つのレイヤがそろって初めて、
データモデルは“読めて、変えられる”ものになる。

🚀 次世代モデリングの核心

次世代のデータモデリングに必要なのは、

  • 意味を軽視しない抽象レイヤ
  • 構造を正しく具現化する論理レイヤ
  • DB固有の癖を扱う物理レイヤ
  • 判断の理由を残すIntentレイヤ

この4つが独立し、
しかし一貫してつながっていること。

🔚 最後に

本書をここまで読み進めてくださり、ありがとうございました。

本書が扱ったのは、技術の変遷ではなく、
“変化に強いデータモデルとは何か”という問いへの回答です。

時代がどう変わっても、
意味 → 構造 → 理由 → 実装 の一貫性が守られていれば、
データモデルは必ず未来に耐えると確信しています。

4部作を通じて示した CLM はまだ“提案段階”であり、
これから具体化していく余地が多く残されています。
あなたの現場で感じた違和感や改善案があれば、
ぜひコメントで教えてください。

皆さまからの声が、この枠組みをより実践的なものへと育てていく力になります。

Discussion