情報の状態遷移図の作成

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

直前セッションでCRUDから機能・画面を導く手順を学びました。今度は実際に手を動かします。

問いかけ: 「会員情報」は「未登録 → 登録済み → 退会済み」の3状態だけでしょうか？「仮登録」「メール認証待ち」は要らない？

情報の状態は、ペルソナの体験を支える「裏側のリアルさ」です。雑に書くと後で必ず手戻りが発生します。今のうちに丁寧に。

このセッションの進め方:

1. チーム全員で「1つの情報モデル」を一緒に書く（20分）
2. 残りの情報モデルを分担して書く（30分）
3. AIにレビューしてもらい修正（10分）

MermaidのstateDiagram-v2を使います。最低限のルールは4つ。

1. 初期状態は [*] から矢印で示す
2. 終了状態は [*] への矢印で示す
3. 状態は名詞または形容詞（例: 予約済み、未確認）
4. 遷移ラベルは「CRUD: 操作名」（例: C: 予約する）

ポイント:

• すべての状態に「入り方」と「出方」がある（孤立しない）
• 「終売」は終了状態なので [*] に向かう
• 同じ遷移が複数の状態から発生してOK

書いたら必ず自問する5つ。

• すべての状態に「入る矢印」がある？
• すべての状態に「出る矢印」がある？（永続状態は除く）
• CRUDの4文字すべてが少なくとも検討された？
• 異常系（キャンセル・エラー・タイムアウト）は考えた？
• ペルソナの体験で必要な状態は揃っている？

削除がない情報モデルは意外と多いです。「予約履歴」「購入履歴」などは消さずに残すことが価値になります。逆に「カート情報」は購入完了とともに消えるのが自然。Deleteの有無は「業務の意味」で決めます。

レビュー依頼の例:

• 「以下の状態遷移図をレビューしてください。状態の抜け、遷移の抜け、異常系の漏れを指摘してください。[Mermaidを貼り付け]」
• 「この情報モデルで、ユーザが操作できる遷移と、システムが自動で行う遷移を分けて教えて」
• 「『退会済み』からの遷移がありませんが、本当に再登録は別情報として扱ってよいですか？」

チームの情報モデル定義書（Day4成果物）に書かれたすべての情報モデルについて、状態遷移図を作成する。

1. 全員で1つ目を書く（20分）

   • 一番複雑そうな情報モデルを選ぶ
   • ホワイトボードまたは共有エディタで全員が見ながら書く
   • 5つのレビュー観点を必ず確認する

2. 分担して残りを書く（15分）

   • 1人1〜2モデルずつ担当
   • Mermaid記法で書く
   • 担当外のメンバーは別モデルの相互レビューに回る

3. AIレビューと修正（5分）

   • 各自の状態遷移図をAIに貼り付けてレビュー依頼
   • 指摘を受けて修正

• 情報モデル定義書の各情報モデルに対応する状態遷移図（Mermaid記法）
• 1つのファイルに集約し、情報モデル名を見出しに

• 状態が思いつかないとき: 「この情報は最初どうやって生まれる？」「最後はどうなる？」「途中で変わる状況は？」をペルソナの言葉で考える
• 状態が多すぎるとき: 状態を「上位状態（公開中）」と「下位状態（在庫切れ）」に分けられないか検討
• CRUD全部が要らないとき: 無理に当てはめない。マスタは「C・R・U」、ログは「C・R」など割り切る

状態遷移図は次セッションの「画面一覧・機能一覧」の入力になります。「遷移1つ＝機能1つ＝画面のどこかに登場」と覚えてください。

• 全情報モデルの状態遷移図を書いた
• 5つのレビュー観点をすべて満たしている
• AIに1回以上レビューを依頼した
• 各遷移にCRUDのラベルがついている
• チームメンバーの図を読んで、修正提案を1件以上した

• 入力: Day4成果物「情報モデル定義書」
• 出力先: 状態遷移図ファイル（次セッションの入力）
• Mermaid Live Editor: 図のプレビューに便利