情報モデルとは〜処理の単位で情報をまとめる

• 日程: Day 4 / セッション 3
• 時間: [11:10-11:30]
• 形式: 座学
• ゴール: 情報モデルの定義（情報を処理する単位のまとまり）を説明し、情報定義書のカテゴリから情報モデルの候補を挙げられる
• 学習形式: 対話型解説

休憩明けに、少し質問させてください。

午前中に作った情報定義書を見てください。「ユーザー情報」「収支記録」「予算」のようなカテゴリで情報が分類されているはずです。

ここで疑問。「カテゴリ＝そのままシステムで扱う単位」でしょうか?

答えはNOです。カテゴリは「人間が理解しやすいように分けた」もので、システムが「処理する単位」とは別物です。

具体例。家計簿アプリで「収支記録」というカテゴリに「金額・カテゴリ・日付・メモ」が入っています。これらは「1件の取引として一緒に保存し、一緒に表示し、一緒に編集する」=つまりまとめて処理する単位です。これが「情報モデル」です。

このセッション（20分）では、「カテゴリと情報モデルの違い」「処理の単位とは何か」を整理し、午後の実習で「情報モデル定義書」を作る準備をします。明日からの外部設計・内部設計の入り口です。

情報モデルとは、情報を処理する単位のまとまりです。

「処理の単位」は次のように定義できます。

• 一緒に作成される: 同じタイミングで生まれる
• 一緒に取得される: 同じタイミングで読まれる
• 一緒に更新される: 同じタイミングで書き換えられる
• 一緒に削除される: 同じタイミングで消える

CRUD（Create/Read/Update/Delete）操作の単位、と言い換えられます。

「ユーザー情報」と「ユーザー」が違うことに注目。

• カテゴリ「ユーザー情報」: 人間の便宜的分類。氏名や好みなど雑多に入る
• 情報モデル「ユーザー」: 処理単位。氏名・メール・パスワードが「1ユーザーとしてまとまる」

1カテゴリ＝1情報モデルになることもあれば、1カテゴリ＝複数の情報モデルになることもあります。カテゴリは出発点であって、ゴールではありません。「処理単位として正しいか?」で再編成します。

情報モデルには「良い切り方」と「悪い切り方」があります。

• 凝集度が高い: モデル内の情報が「同じ目的」でまとまっている
• 結合度が低い: 他のモデルへの依存が最小限
• 単一責任: そのモデルが「1つの役割」しか持たない

情報モデルは、明日（Day5）以降の設計の「主役」になります。

• 状態遷移図（Day5）: 各情報モデルが「どんな状態を持ち、どう遷移するか」
• 画面一覧（Day5）: 各情報モデルの「CRUD画面」（一覧/詳細/編集/削除）
• テーブル定義書（Day7）: 各情報モデルが「1テーブル」に対応するのが基本
• ER図（Day7）: 情報モデル間のリレーション

つまり、今日午後に作る情報モデル定義書は、Day7までの設計成果物すべての原型なのです。ここで雑に切ると、後で全部の設計をやり直すことになります。

「情報モデル」という言葉は分野によって呼び方が違います。データベース設計では「エンティティ（実体）」、オブジェクト指向プログラミングでは「クラス」、業務分析では「ビジネスオブジェクト」と呼ばれることが多いです。

歴史的にはエンティティ概念が最も古く、1976年にPeter Chen（ピーター・チェン）がER図（Entity-Relationship Diagram）を提唱した時に体系化されました。Chenは「現実世界は『エンティティ（モノ）』と『リレーションシップ（関係）』で表現できる」と主張し、これが後のデータベース設計の基礎になります。

その後、1990年代にオブジェクト指向プログラミングが普及すると、エンティティは「クラス」として再解釈され、振る舞い（メソッド）も持つようになりました。さらに2000年代のDDD（ドメイン駆動設計）では「エンティティ」「値オブジェクト」「集約」という概念に細分化されています。

豆知識：「情報モデル」という呼び方は、特定の実装技術（DB or オブジェクト指向）に依存しない中立的な言い方です。本研修では、まだ実装技術を選定していない段階なので、この呼び方を使います。明日以降、テーブル設計に入ったら「エンティティ」、もしオブジェクト指向で実装するなら「クラス」と呼び替えます。

• 「情報モデルとデータベースのテーブルは同じもの? 違いがあれば教えて」
• 「『処理の単位』を見極めるコツを、別のたとえで説明して」
• 「私たちの情報定義書のカテゴリ『○○』から、どんな情報モデルが導けそう?」
• 「1つのカテゴリが複数の情報モデルに分かれる例を3つ挙げて」

20分の座学で学んだことは、次の3点。

1. 情報モデル＝処理の単位のまとまり: CRUDで一緒に扱う情報がモデルになる
2. カテゴリと情報モデルは別物: カテゴリは人間の理解用、情報モデルはシステムの処理用
3. 情報モデルは下流設計の原型: テーブル・画面・状態遷移すべての原型

次のセッション（11:30-）から、午前の情報定義書を「情報モデル定義書」に再編する実習に入ります。70分の集中作業で、明日からの設計の土台を仕上げます。

「カテゴリそのままで良いんじゃない?」と思った人もいるかもしれません。多くの場合、それでは細かすぎる/粗すぎるのです。「処理の単位」という新しい目線で、いったん壊して組み立て直してください。

• 情報モデルの定義を、自分の言葉で30秒で言えますか?
• カテゴリと情報モデルの違いを、別の例で説明できますか?
• 「処理の単位」とは何か、CRUDの4文字を使って説明できますか?
• 情報モデル定義書が、明日以降のどの設計成果物の原型になるか言えますか?

• 参考書籍: Peter Chen「The Entity-Relationship Model」（1976年論文）
• 参考書籍: Eric Evans『ドメイン駆動設計』
• 参考書籍: 渡辺幸三『業務システムのための上流工程入門』
• 発展課題: 身近なサービス（メルカリ・LINE）の情報モデルを推測してみる