情報モデル定義書の作成

• 日程: Day 4 / セッション 4
• 時間: [11:30-12:40]
• 形式: 実習
• ゴール: 情報定義書を元に、開発テーマの情報モデルを漏れなく洗い出し、情報モデル定義書を時間内に作成できる
• 学習形式: ハンズオン実習（AIサポートあり）

直前のセッションで「情報モデル＝処理の単位のまとまり」と学びました。今度は実際に作ります。

このセッションは、Day4の山場であり、企画フェーズ（Day1〜4）のラストです。情報モデル定義書が完成すると、明日のDay5から「外部設計」に進めます。逆に言うと、ここで作る情報モデル定義書が明日以降のすべての設計の原型になります。

70分の集中作業で、漏れなく・重複なく・処理単位として正しい情報モデル定義書を仕上げます。最後にAIにレビューしてもらって、抜けを発見・修正します。それでは始めましょう。

情報モデル定義書には、各情報モデルについて次の情報を書きます。

## 情報モデル: 取引

### 概要
- 説明: ユーザーが入力または自動連携で記録する1件の収支記録
- 処理単位の理由: 1件の取引として登録/参照/編集/削除されるため
- ライフサイクル: ユーザーが入力→保存→必要に応じて編集→削除/履歴化

### 含まれる情報項目
| 項目名 | 型（概念） | 必須 | 説明 |
|-------|----------|------|------|
| 取引ID | ID | 必須 | システム内一意 |
| ユーザーID | ID | 必須 | 取引の所有者 |
| 金額 | 数値 | 必須 | 円単位の整数 |
| カテゴリ | 文字列 | 必須 | 食費・交通費等 |
| 日付 | 日付 | 必須 | 発生日 |
| メモ | 文字列 | 任意 | 自由入力 |

### 関連する情報モデル
- ユーザー: 取引はユーザーに所属する（多対1）
- 予算: カテゴリ別の予算に紐づく（多対1）

このように「概要」「含まれる情報項目」「関連する情報モデル」の3ブロック構造で書きます。

型は『概念』レベルで書くこと。「VARCHAR(255)」のような実装詳細はDay7のテーブル定義書で決めます。今はID/数値/文字列/日付/真偽値/列挙といったレベルで十分です。

情報定義書のカテゴリから情報モデルを導く方法は3つあります。

カテゴリが既に処理単位と合致する場合は、そのまま情報モデルにする。

例: カテゴリ「予算」→ 情報モデル「予算」（1件の予算設定として処理）

カテゴリが大きすぎる場合は分割する。

例: カテゴリ「ユーザー情報」→

• 情報モデル「ユーザー」（基本情報・認証）
• 情報モデル「ユーザー設定」（通知設定・テーマ）
• 情報モデル「ユーザープロフィール」（自己紹介・アバター）

理由: ユーザー設定だけ頻繁に更新される、プロフィールは公開情報、など処理タイミングが違うため

別カテゴリでも、同時に処理されるなら統合する。

例: カテゴリ「商品」とカテゴリ「在庫」→ 情報モデル「商品」（在庫数も商品の属性として持つ）

ただし、これは慎重に。「同時に処理されるか?」を厳密にチェック。

ステップ4でAIに依頼する内容のテンプレ。

あなたへの依頼:
私たちの情報モデル定義書がこれです: [貼り付け]
ペルソナ: [貼り付けまたはサマリ]
CJM(To-Be): [貼り付けまたはサマリ]

次の観点でレビューしてください:
1. ペルソナの旅で発生する情報のうち、情報モデルに含まれていないものはありますか?
2. 情報モデルの粒度に問題はありますか? （粗すぎ/細かすぎ）
3. 情報項目の所属が不適切なものはありますか?
4. 情報モデル間の関連で抜けはありますか?

各観点で3件以内に絞り、具体的に指摘してください。

このレビューで出てきた指摘を、チームで判断して採用/却下します。AIの言うことを盲信せず、必ずチームで議論。

実際の業務システムでは、情報モデルがどう設計されているか、いくつか例を紹介します。

ECサイト（Amazon・楽天の単純化版）:

• 顧客、商品、カート、注文、配送、レビュー、お気に入り、ポイント

SNS（Twitter・Instagram風）:

• ユーザー、投稿、コメント、いいね、フォロー関係、通知、ダイレクトメッセージ

勤怠管理システム:

• 従業員、所属、勤怠記録、休暇申請、承認履歴、給与計算

このように、中小規模システムでも7〜10個の情報モデルで構成されます。多すぎず少なすぎず、ちょうど良い粒度を見つけるのが情報モデル設計のセンスです。

豆知識：1990年代に流行した「業務システムの典型パターン集」では、「ヒト・モノ・カネ・場所・出来事」の5観点で情報モデルを洗い出す手法が紹介されていました。ヒト=顧客・従業員、モノ=商品・在庫、カネ=決済・予算、場所=拠点・配送先、出来事=取引・履歴です。このパターンで自分たちのテーマを見直すと、抜けが発見できることがあります。

• 「私たちの情報モデル定義書を見て、抜けている情報モデルを3つ挙げて」
• 「『ヒト・モノ・カネ・場所・出来事』の5観点で、私たちのテーマに必要な情報モデルを再点検して」
• 「この情報モデルの『関連』に不自然なものはある?」
• 「明日の外部設計で、この情報モデル定義書から何が導けるか想像して」

午前中の情報定義書をもとに、開発テーマの情報モデルを洗い出し、情報モデル定義書を完成させる。

1. 情報定義書のカテゴリ一覧を見ながら、情報モデル候補を列挙
2. アプローチA/B/Cのどれが当てはまるかチームで議論
3. 候補は付箋またはMarkdownに「モデル名+30字説明」で書く

1. 各候補について「処理単位として正しいか?」を1つずつ検証
2. CRUDの4観点で「同時に作成?同時に取得?同時に更新?同時に削除?」を確認
3. 分割が必要なものは分け、統合できるものはまとめる
4. 最終的な情報モデル数は3〜10個に収める

1. 各情報モデルについて、フォーマットに沿って詳細を記入
2. 情報項目は情報定義書から該当するものを移動
3. 「型（概念）」は ID/数値/文字列/日付/真偽値/列挙 から選ぶ
4. 「関連する情報モデル」を簡潔に記入（多対1・1対多・多対多）

1. 完成した情報モデル定義書をAIに見せる
2. 上記の定型プロンプトで4観点レビューを依頼
3. 指摘をチームで議論し、採用するものを修正

1. チーム全員で読み合わせる
2. 「明日Day5でこれを使って画面・機能を導ける感触があるか?」を確認
3. 完成宣言

情報モデル定義書（Markdownファイル1つ）。

# 情報モデル定義書 - [開発テーマ名]

## 情報モデル一覧
1. ユーザー
2. 取引
3. 予算
4. 通知
5. 分析レポート

## 情報モデル間の関連図
（Mermaid記法で関連を図示）

## 詳細

### 1. ユーザー
...

### 2. 取引
...

• 粒度に迷ったら: 「これ単独で意味のある業務操作になる?」で判断。なるなら独立、ならないなら統合
• 関連が複雑すぎる: 設計が破綻のサイン。情報モデル数を増やすか、関連を見直す
• 明日の入力になることを意識: 「この情報モデルの一覧画面・詳細画面・編集画面を作るとしたら…」と想像
• 時間が足りない: 詳細記入を主要モデル3つに集中。その他は概要だけでもOK
• チーム内で異論: ペルソナとCJMに戻る。「鈴木さんが使うか?」「To-Beのどのフェーズで使うか?」

完成おめでとうございます。あなたのチームは、企画フェーズ（Day1〜4）の全成果物を手にしました。

Day1〜4の成果物まとめ:

• Day1: チーム計画書
• Day2: 取り組む課題、開発テーマ
• Day3: ペルソナのプロフィール、CJM（As-Is版・To-Be版）
• Day4: 情報定義書、情報モデル定義書

これだけ揃うと、明日からの外部設計（Day5〜6）に必要な入力がすべて整っています。

明日のDay5は「情報の状態遷移図」と「画面一覧・機能一覧」の作成です。今日作った情報モデル1つ1つが、どんな状態（未登録/登録中/有効/無効/削除済み等）を持ち、どう状態遷移するかを設計します。そこから画面と機能が導かれます。

ここまで来た自分たちを誇りに思ってください。情報設計は地味ですが、ここの精度がそのまま製品の品質を決めます。明日からは、その土台の上に「目に見える形」を建てていきます。

• 情報モデルを3〜10個の範囲で定義できましたか?
• 各モデルが「処理の単位」として正しいか説明できますか?
• 情報モデル間の関連を図で描けますか?
• AIレビューの指摘を採用・却下した理由を説明できますか?
• 明日の状態遷移図・画面一覧の作成イメージが湧きますか?

• 参考書籍: 渡辺幸三『業務システムのための上流工程入門』
• 参考書籍: Martin Fowler『アナリシスパターン』
• 参考: IPA「業務システム設計ガイドライン」
• 発展課題: 完成した情報モデル定義書をER図（簡易版）に変換して整合性を確認