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

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

休憩前のセッションで、情報定義書ができました。30個以上の情報が、いくつかのカテゴリに分類された状態です。

ここで問いかけです。あなたのチームのシステムは、それらの情報をバラバラに1個ずつ扱うでしょうか？

たとえば飲食店予約システムで、誰かが予約をするとき。システムは「予約日時」だけを単独で登録するでしょうか？——しませんね。「予約日時」「予約人数」「予約者」「対象店舗」をひとまとめにして、1件の「予約」として登録します。

この「ひとまとめ」こそが、今日の主役、情報モデルです。短い座学ですが、ここを押さえると明日からの外部設計・内部設計が一本の線でつながります。

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

• 情報定義書の情報1個 = 部品（ネジや歯車）
• 情報モデル = 部品を組み上げたユニット（エンジンやハンドル）

システムは、情報を「処理する」とき、必ず意味のあるまとまり単位で扱います。

• 会員登録する → 「会員名」「メールアドレス」「電話番号」がまとめて登録される → 会員情報という情報モデル
• 予約する → 「予約日時」「予約人数」「予約者」がまとめて登録される → 予約情報という情報モデル

コンビニのおにぎりに例えましょう。米・海苔・具は個々の情報です。でもレジで処理される（買われる）のは「おにぎり1個」という単位。バーコードが付くのはおにぎりであって、海苔単体ではありません。処理の単位にだけ、名前とまとまりが与えられる——これが情報モデルの感覚です。

ここで少し考えてみてください。「メールアドレス」は単独で情報モデルになるでしょうか？

——なりません。メールアドレスだけを単独で登録・更新する処理は普通ありません。「会員情報の一部として」処理されます。つまりメールアドレスは情報モデルの属性（構成要素）です。一方「会員情報」は、登録する・照会する・退会で削除する、という処理の単位になるので情報モデルに該当します。判断基準は常に「それ単位で処理するか？」です。

情報定義書から情報モデルへの対応例です。

「処理の例」の列に注目してください。情報モデル1つに対し、登録・変更・削除といった処理が自然に書ける——これが「処理の単位でまとまっている」証拠です。

• 情報モデルの判定基準は「それ単位で登録・参照・変更・削除するか」
• カテゴリ（意味のまとまり）と情報モデル（処理のまとまり）は近いが同じではない。カテゴリは出発点、処理の観点で再点検して情報モデルにする
• よくある間違い: 大きすぎる情報モデル（「システム情報」のような何でも入る箱）。処理の例が書けないまとまりは、情報モデルとして機能していない

「モデル」という言葉に身構えた人もいるでしょう。モデルとは「現実を目的に応じて単純化した模型」のことです。プラモデルの飛行機は飛びませんが、形を理解するには十分。地下鉄路線図は距離も方角も不正確ですが、乗り換えには世界一便利です。実はロンドン地下鉄の路線図（1933年、ハリー・ベック作）は、電気回路図の技師だったベックが「乗客に必要なのは正確な地図ではなく接続関係だ」と気づいて作った、情報モデリングの金字塔です。当初は「地理的に不正確すぎる」と上層部に却下されかけたとか。情報モデルも同じで、現実の全てではなく「システムが処理する観点」だけを切り取った模型なのです。

情報モデルは、この研修の後半全体の土台になります。予告編として、つながりを見ておきましょう。

• 明日（Day 5）外部設計: 情報モデルごとに「状態遷移」を考えます。予約情報なら、登録される（Create）→参照される（Read）→変更される（Update）→キャンセルされる（Delete）。この状態遷移が、そのまま画面と機能になります
• Day 7 内部設計: 情報モデルは、データベースのテーブルの候補になります。「会員情報」モデルが「会員テーブル」へ育つイメージです

つまり、今日の情報モデルの漏れは、明日の画面の漏れ、来週のテーブルの漏れに直結します。逆に言えば、ここを丁寧にやれば後工程は加速します。「タスクの関係を常に意識する」の最重要ポイントです。

非該当の例も押さえましょう。「ログイン画面」「検索ボタン」は情報モデルではありません。画面や機能は情報モデルを操作する側であり、まとまりそのものではないからです。逆に「画面に出てこないが処理される情報のまとまり」（例: 通知履歴）は、画面がなくても情報モデルに該当し得ます。

• 情報モデル → 状態遷移 → 画面・機能 → テーブル、と一本の線でつながる
• 情報モデルの名前は「〜情報」の形にすると揃えやすい（会員情報・予約情報・店舗情報）
• よくある間違い: 画面ありきで考えて、画面に表示されない情報モデル（履歴・ログ系）を見落とす

「情報モデルの漏れが後工程に響く」ことを示す格言に、ソフトウェア工学の「欠陥修正コストの法則」があります。要件・設計段階で見つけた欠陥の修正コストを1とすると、実装段階では数倍〜数十倍、リリース後には100倍にもなるという経験則で、1980年代にバリー・ベームが大規模調査で示しました。家づくりで言えば、図面の段階で「トイレがない！」に気づけば消しゴム1個で直りますが、完成後に気づいたら壁を壊す工事になります。みなさんが今日、付箋と表でカチャカチャやっている作業は、未来の自分たちを壁壊し工事から救う作業なのです。

最後に、次セッションへの橋渡しとして、頭の体操をしておきましょう。情報定義書のカテゴリは、情報モデルの有力候補ですが、そのまま全部が情報モデルになるとは限りません。

ここで少し考えてみてください。次の3つのカテゴリは、それぞれ情報モデルとしてそのまま使えるでしょうか？

1. 「予約に関する情報」（予約日時・予約人数・キャンセル理由）
2. 「お店と予約に関する情報」（店名・営業時間・予約日時・予約人数）
3. 「会員の基本情報」と「会員の連絡先」（常に一緒に登録・変更される）

答え合わせです。

1. 予約登録・予約変更・キャンセルという処理の単位が書ける → そのまま情報モデルにできる
2. 店舗の登録と予約の登録という別系統の処理が混ざっている → 「店舗情報」と「予約情報」に分割する
3. 常に一緒に処理されるなら、2つに分けておく意味が薄い → 「会員情報」に統合する

つまり、カテゴリ（意味のまとまり）を、処理のまとまりへ翻訳し直す作業が次セッションの中心です。

• カテゴリは「意味が似ている」、情報モデルは「一緒に処理される」。基準が違う
• 分割のサイン: 1つのまとまりに別系統の処理（店舗の登録と予約の登録など）が混ざっている
• 統合のサイン: 2つのまとまりが常に同時に登録・変更される

「分けるか、まとめるか」は、ソフトウェア設計の永遠のテーマです。設計の世界には「高凝集・疎結合」という有名な言葉があります。関係の深いものは1か所にまとめ（高凝集）、まとまり同士の依存は最小に（疎結合）——1970年代の構造化設計の時代から、最新のマイクロサービスまで、形を変えて生き続ける原則です。みなさんが「このカテゴリ、分ける？まとめる？」と悩むその議論は、世界中のアーキテクトが半世紀やってきた議論の入口に立っているということ。胸を張って悩んでください。

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「情報モデルと情報定義書のカテゴリの違いを、別の例で説明して」
• 「『〜は情報モデルになる？』をクイズ形式で5問出して。答えと理由も」
• 「情報モデルとデータベースのテーブルは何が違うの？」
• 「『高凝集・疎結合』って何？情報モデルとどう関係するの？」

今回学んだことを一言でまとめると「情報モデルとは、情報を処理する単位でまとめたもの」です。

• 判定基準は「それ単位で登録・参照・変更・削除するか」
• 情報定義書のカテゴリを出発点に、処理の観点で再点検して情報モデルにする
• 情報モデルは明日の画面・機能、来週のテーブルへつながる土台

次のセッションでは、自分たちの情報定義書から情報モデルを洗い出し、「情報モデル定義書」を作成します。Day 4の総仕上げです。

以下の問いに答えられるか確認してみましょう：

• 情報モデルの定義を一言で言えますか？
• 「メールアドレス」が情報モデルにならない理由を説明できますか？
• 情報モデルが後工程（画面・機能・テーブル）にどうつながるか説明できますか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

• 参考リンク: Day4_Session02成果物（情報定義書）、Day 5の予習として「CRUD」という言葉をAIに聞いてみるのもおすすめ
• 発展課題: 銀行ATMを題材に「情報モデルは何か」をAIと議論してみましょう（口座情報？取引情報？カード情報？）

このセクションは、受講者が理解を深めることをサポートする参考情報です。