情報モデルと状態遷移
概要
- 日程: Day 2 / セッション 03
- 時間: 10:10-10:40
- 形式: 座学
- ゴール: 情報モデルを「属性・関係・制約」の3要素で定義でき、状態遷移を定義する意義を「機能とプレゼンテーションが導き出せる」観点で説明できる
- 学習形式: AI協働型（具体例をAIに何度も生成させて理解を補強する）
導入（5分）
前のセッションでは「コンビニの商品」のような身近な物から、属性・関係・制約を取り出しました。「これがモデルなんだ」という感触はつかめたはずです。
このセッションでは、その体験を情報モデルという正式な用語で定義し直し、さらに状態遷移という新しい武器を加えます。
なぜ状態遷移を学ぶのか？答えは衝撃的です。状態遷移を定義すると、必要な機能（Create・Read・Update・Delete）と、必要な画面（プレゼンテーション）が機械的に導き出せるのです。「画面、何種類いるんだろう？」と悩む必要がなくなります。
午後のモックアップ作成も、明日の設計も、明後日の実装も、すべての出発点がここにあります。
本編（20分）
1. 情報モデルの正式な定義
情報モデルとは、**「ある対象物を、コンピュータで扱うために必要な情報項目と、項目間のつながり、成立条件を整理した構造」**です。
3つの構成要素を再確認します。
| 要素 | 意味 | 例（書籍） |
|---|---|---|
| 属性 | 対象が持つ情報項目 | タイトル、著者、ISBN、出版日 |
| 関係 | 他の対象との繋がり | 著者と1対多、貸出履歴と1対多 |
| 制約 | 成立のためのルール | ISBNは13桁、出版日は本日以前 |
属性: タイトル/ISBN/出版日"] Author["著者
属性: 氏名/プロフィール"] Loan["貸出
属性: 貸出日/返却予定日"] Book --|書いた|--> Author Book --|貸し出された|--> Loan
ここがポイント
情報モデルは「要件」と「実装」の橋渡しです。Day 1で作った情報定義書（要件レベル）を、明日以降のコード（実装レベル）に繋ぐ唯一の手段です。これが曖昧だと、コーディング段階で必ず手戻りします。
コラム：ER図とPeter Chen
情報モデルを書く代表的な記法に「ER図（Entity-Relationship Diagram）」があります。1976年、台湾系アメリカ人の研究者Peter Chenが発表しました。当時は「データはバラバラのファイルに保存するもの」が常識で、「実体と関係を分離して描く」という発想は革命的でした。発表から50年経った今も、現役で使われ続けています。良いモデルは陳腐化しないという好例です。
2. 状態遷移とは何か
**状態（State）**とは、ある対象物が時間の流れの中で取りうる「位置」のことです。
たとえば「注文」は次のように状態が変わります。
各状態の間には遷移（Transition）があり、必ず何らかのイベント（注文する・発送する など）が引き金になります。
ここがポイント
状態遷移は「動詞」を見つける作業です。情報モデル（名詞中心）と組み合わせることで、システムが扱う世界が完全に表現できます。名詞（情報モデル）と動詞（状態遷移）の両輪、と覚えてください。
コラム：自動販売機が世界を変えた話
状態遷移の説明で必ず登場する題材が「自動販売機」です。「待機中→金額投入中→商品選択可能→商品排出中→お釣り返却中→待機中」。1970年代、コンピュータサイエンスの教育者たちはこの題材を発見し、「複雑な現象を有限個の状態で表現する」という概念を学生に伝えるのに使いました。今でも世界中の大学で「自動販売機の状態遷移を書け」という課題が出題され続けています。情報処理技術者試験にも頻出します。
3. なぜ状態遷移を定義するのか：機能と画面が自動で出てくる
状態遷移を書くと、次のことが自動的に決まります。
(CRUD)"] ST --> P["必要な画面
(プレゼンテーション)"] F --> Code["実装"] P --> Mock["モックアップ"]
機能（CRUD）の導出
| 状態の変化 | 必要な機能 |
|---|---|
| 何もない → 未確定 | Create（新規作成） |
| 各状態を見たい | Read（参照） |
| 状態を変えたい | Update（更新）／状態遷移そのもの |
| 不要になった | Delete（削除） |
画面（プレゼンテーション）の導出
| 業務操作 | 必要な画面 |
|---|---|
| 新しい注文を入力する | 新規入力画面 |
| 注文の詳細を確認する | 1件表示画面 |
| 注文の状況を一覧で見る | 一覧表示画面 |
| 注文内容を変更する | 更新画面 |
| 注文を削除する | 削除確認画面 |
ここがポイント
状態遷移なしに「画面を何種類作ろうか？」と議論するのは無意味です。状態遷移が決まれば画面の種類は自動で決まります。逆に言うと、状態遷移をサボると後で「画面が足りなかった！」と必ず気付きます。
コラム：CRUDという略語の起源
CRUD（クラッド）はJames Martinという英国人がデータベース設計の文脈で1983年に提唱しました。彼は「データに対する操作は突き詰めると4つしかない」と看破した。それから40年、Webでも、モバイルでも、IoTでも、操作は基本的にCRUDです。「Create・Read・Update・Delete」を「ク・ラ・ッ・ド」と呟いて覚えましょう。実務で1日100回は使う言葉です。
💬 AIに聞いてみよう
- 「自分の開発テーマ『○○』の主要な情報モデルの状態遷移を、たたき台として書いて」
- 「状態遷移と業務フロー図はどう違う？」
- 「『状態がない』ような対象物（例：マスタデータ）でも状態遷移は必要？」
まとめ（5分）
このセッションの核心は**「情報モデル（名詞）＋状態遷移（動詞）＝ システムが扱う世界の完全表現」**です。そして状態遷移を書けば、機能と画面が自動的に導き出せます。
次のセッション（Session04）は45分の実習です。自チームの開発テーマで、情報モデルを3つ以上抽出し、それぞれの状態遷移図をdraw.io等のツールで実際に作成します。手を動かす番です。
🔄 振り返りチェック
- 情報モデルの3要素を空で言えますか？
- 状態遷移を定義する2つの効果は何ですか？
- CRUDの4文字を、それぞれ日本語と紐づけて言えますか？
補足資料
- 参考リンク：Peter Chen『The Entity-Relationship Model』(1976)、UML状態遷移図仕様
- 発展課題：「カート」「ユーザー」「クーポン」のうち1つ選び、頭の中で状態遷移を組み立てる
学習ガイド
想定される質問と回答例
| 質問 | ヒント |
|---|---|
| 状態遷移は全部の情報モデルで必要？ | 「マスタデータ」のような変化しないものは簡略化可。だが「ライフサイクル」がある対象には必須 |
| 状態の数はいくつが適切？ | 業務的に意味のある区切りで分ける。多すぎても少なすぎても害になる |
| 業務フロー図と何が違う？ | 業務フローは「人の行動」を中心に描く。状態遷移は「対象物の状態」を中心に描く |
つまずきやすいポイント
| つまずきポイント | ヒント |
|---|---|
| 状態と機能を混同する | 状態は「名詞的」（未確定／確定）、機能は「動詞的」（注文する／発送する） |
| 完璧な状態遷移を最初から目指す | お客様視点でレビューして何回も書き直す前提 |
| 全部の業務を1枚に詰め込む | 1つの情報モデルにつき1枚を基本にする |