画面一覧・機能一覧の作成

• 日程: Day 5 / セッション 3
• 時間: 11:10-12:40（90分）
• 形式: 実習
• ゴール: 情報の状態遷移図から、画面一覧と機能一覧を漏れなく時間内に作成し、チーム内で読み合わせて整合性を確認できる
• 学習形式: ハンズオン実習（AIサポートあり）

直前セッションで状態遷移図ができました。ここから機能・画面を「機械的に」導けます。

問いかけ: 「予約済み → キャンセル」という遷移1つから、いくつ機能・画面が必要だと思いますか？

最低でも「キャンセルボタン（機能）」と「キャンセル確認画面（画面）」と「キャンセル完了画面（画面）」が出てきます。1つの遷移が複数の機能・画面に化けます。

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

1. 1つの状態遷移から画面・機能を導くデモ（15分）
2. 全状態遷移について分担して洗い出す（55分）
3. 読み合わせと整合性チェック（15分）

ルールは1つ。遷移1本につき「機能」を1つ以上、「画面」を1つ以上書き出す。

例: 「予約済み → キャンセル」という遷移を分解します。

ここから出てくるもの:

• Rの遷移（参照）は「一覧画面」「詳細画面」になりやすい
• Cの遷移は「入力フォーム画面」と「確認画面」と「完了画面」の3点セットになりやすい
• Uは「編集画面」、Dは「削除確認画面」が必要

• IDの体系を最初に決める（S-1xx は予約系、S-2xx は会員系、など）
• 同じ機能を複数画面が呼ぶことがある（一覧画面と詳細画面の両方が「予約参照」を使う）
• 共通機能（ログイン、ログアウト、エラー表示）も忘れずに

「入力 → 確認 → 完了」は、Webアプリ設計の定番パターンです。なぜ「確認」が要るのか？理由は2つ。誤操作防止と、入力内容の最終承認。重要な操作（決済、削除、退会）ほど確認画面が効きます。逆にメモアプリの「保存」のように軽い操作には不要です。「ペルソナがこの操作で後悔したら困るか？」で判断します。

• 「以下の状態遷移図から、画面と機能を網羅的に洗い出してください。[Mermaid貼付]」
• 「私たちの画面一覧に、よく忘れがちな画面（エラー、404、メンテナンス、利用規約）はありますか？」
• 「この機能一覧で、CRUDのRが漏れていそうな情報モデルはどれですか？」

すべての状態遷移図から、画面一覧と機能一覧を作成する。

1. ID体系を決める（5分）

   • 画面IDの命名規則（例: S-{機能カテゴリ}{連番}）
   • 機能IDの命名規則（例: F-{機能カテゴリ}{連番}）

2. 分担して洗い出す（35分）

   • 情報モデルごとに担当を決める
   • 担当の状態遷移から画面と機能を抽出
   • スプレッドシートまたはMarkdown表に記入

3. 共通画面・機能を追加（5分）

   • ログイン、ログアウト、トップ画面、エラー画面、404画面
   • 検索機能、通知機能（必要に応じて）

4. 読み合わせと整合性チェック（10分）

   • チームで一覧を画面投影し、1行ずつ読み上げる（話す＆行う）
   • 状態遷移↔画面・機能の対応漏れを確認

• 画面一覧.md（または表）
• 機能一覧.md（または表）

• 迷ったら「ペルソナがこの操作をする画面はどこか？」と問う
• 機能と画面が1対1だと思い込まない。1機能を複数画面が呼んでよい
• 「あったら便利」は今は書かない。状態遷移に必要なものに絞る

明日（Day6）は、この画面一覧から「画面遷移図」と「画面仕様書」を作ります。今日の成果物の質が、明日の作業時間を決めます。

• すべての状態遷移に対応する機能・画面がある
• 共通画面（ログイン、エラー）を含めた
• 機能と画面の対応関係（FとSのID）を明示した
• チームで読み合わせを行った
• AIに「漏れチェック」を依頼した

• 入力: 情報の状態遷移図（Day5 Session2）
• 出力: 画面一覧、機能一覧（Day6の入力）