情報の状態遷移図の作成

• 日程: Day 5 / セッション 2
• 時間: [10:00-11:00]
• 形式: 実習
• ゴール: 情報モデル定義書の各情報モデルについて、状態遷移図を時間内に作成できる
• 学習形式: ハンズオン実習（AIサポートあり）

前のセッションで「情報を状態遷移させるのが機能であり、画面になる」という核心を学びました。
このセッションでは、いよいよ自分たちの情報モデル定義書を使って情報の状態遷移図を作ります。

ここで1つ問いかけです。

「皆さんの情報モデルの中で、一番『一生』が波乱万丈なのはどれだと思いますか？」

予約情報のように生まれて・変わって・消える情報もあれば、マスタ的にほとんど変わらない情報もあります。
情報モデルごとに一生は違います。だからこそ、1つずつ丁寧に状態遷移を追う価値があるのです。

今日の状態遷移図は、このあとの画面一覧・機能一覧（セッション3）、さらにDay 8のCRUD図の源流になります。ここでの漏れは下流すべてに波及します。逆に言えば、ここを丁寧にやれば後がぐっと楽になります。

書き方はシンプルです。情報モデル1つにつき、次の3点を図にします。

1. 状態（丸や四角で書く）: その情報がとりうる状態。例:「予約済み」「来店済み」「キャンセル済み」
2. 遷移（矢印で書く）: 状態から状態への変化。矢印にはきっかけとなる操作を添える
3. 始まりと終わり: 情報が生まれる点（Create）と消える点（Delete）

レストラン予約システムの「予約情報」のお手本です。

注目してほしい点が2つあります。

• 「キャンセル」を即Delete（物理削除）にせず、「キャンセル済み」という**状態への遷移（Update）**にしています。お店側は「キャンセルされた」という事実を後から見たいからです
• Read（参照）は状態を変えないので図に矢印は描きません。ただし「どの状態を誰が見るか」をメモ欄に書いておくと、セッション3で画面を洗い出すときに効きます

• 状態は「〜済み」「〜中」のように名詞で言い切れる形にする。「予約する」は操作（遷移）、「予約済み」が状態。混ぜない
• 矢印には必ず「きっかけとなる操作」を書く。この操作が次セッションで機能になる
• 削除には2種類ある。データを本当に消す物理削除と、「削除済み」状態にして残す論理削除。どちらにするかはチームの設計判断

状態遷移図のルーツは、数学の「有限オートマトン」理論（1940-50年代）です。エレベータ、自動販売機、信号機など、世の中の機械はほぼ状態遷移図で設計されています。自動販売機は「お金を入れる→投入額の状態が遷移→ボタン点灯」という状態遷移の塊です。ゲーム業界では敵キャラのAI（待機→発見→追跡→攻撃）も状態遷移図で作られており、「設計書が書けるなら敵キャラも作れる」と言われるほど応用範囲の広い図法です。

進め方は3ステップです。最初の1つは必ずチーム全員でやってください。

1. 全員で1つ（20分）: 一番中心的な情報モデルを1つ選び、全員で状態遷移図を書く。書き方の認識を揃える
2. 分担して残り（30分）: 残りの情報モデルを役割分担して作成する。1人1〜2モデルが目安
3. AIレビューと相互確認（15分）: 各自の図をAIとチームメンバーにレビューしてもらい、修正する

実習中、行き詰まったらAIを頼りましょう。たとえば：

• 「『会員情報』という情報モデルの状態遷移図の例を、Mermaidで書いて」
• 「この状態遷移図を見て、抜けている状態や遷移がないか指摘して」（自分の図を貼る）
• 「この情報は削除されない設計にしたんだけど、本当に削除不要か一緒に検討して」
• 「『〜済み』の形にできない状態があるんだけど、命名を手伝って」

情報モデル定義書にあるすべての情報モデルについて、情報の状態遷移図を作成してください。

各図に含めること:

• 情報モデル名（タイトル）
• 状態（名詞で言い切る形）
• 遷移の矢印と、きっかけとなる操作（CRUDのどれかを添える）
• 情報が生まれる点（Create）と、消える点または「削除しない」という判断のメモ
• Read（誰がどの状態を参照するか）のメモ

進め方:

1. 中心的な情報モデル1つをチーム全員で作図し、書き方を揃える
2. 残りを分担して作図する
3. 完成した図をAIに見せて、状態の抜け・遷移の抜けを確認してもらう
4. チーム内で相互レビューし、指摘を反映する

• 「情報の状態遷移図」（情報モデルごとに1枚、チームの全情報モデル分）
• 各図には作成者名と、AI・チームレビューで修正した点のメモを添える

• 状態が思いつかない → その情報の「一生」をペルソナの行動で追ってみましょう。CJM（To-Be版）を横に置き、「ペルソナがこの操作をしたとき、この情報はどうなる？」と考えると状態が見えてきます
• 遷移がCreateとDeleteしかない → 本当にUpdateがないか疑いましょう。「登録内容の修正」「ステータスの変更」は典型的なUpdateです。逆に、本当にシンプルな情報モデルなら、それで正解のこともあります
• 削除を忘れがち → 「この情報は永遠に増え続けていい？」と自問してください。AIに「削除されない情報は本当に削除不要か」を確認してもらうのが今日の定石です
• 状態か操作か迷う → 「〜済み」「〜中」と言えるなら状態、「〜する」なら操作（矢印のラベル）です
• Mermaidの書き方が分からない → AIに「stateDiagram-v2で○○の状態遷移図を書いて」と頼み、出てきた図を直しながら学ぶのが早道です。エラーが出たら「このMermaidコードがエラーになる」とコードごと貼って相談しましょう

今回学んだことを一言でまとめると、**「情報モデルの一生を、状態と遷移で漏れなく描き出す」**です。

• 状態は名詞で言い切る形、遷移には操作を添える
• 削除されない情報も「検討した上での判断」として記録する
• 最初の1つを全員で書き、認識を揃えてから分担する

次のセッションでは、この状態遷移図の矢印1本1本を機能に変換し、画面一覧・機能一覧を作ります。矢印の数が、皆さんのシステムの機能の数の出発点になります。

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

• 状態と操作（遷移）の違いを、自チームの情報モデルの例で説明できますか？
• 自チームの中心的な情報モデルの状態遷移を、何も見ずに口頭で説明できますか？
• 物理削除と論理削除の違いと、自チームでどちらを選んだ情報モデルがあるか言えますか？

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

• 参考リンク: Mermaid公式ドキュメント「State diagrams」（stateDiagram-v2の記法）
• 発展課題: 信号機・自動販売機・エレベータのいずれかの状態遷移図を描いてみる（状態遷移図の感覚をつかむ練習に最適）

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