機能とプレゼンテーションの抽出

• 日程: Day 2 / セッション 05
• 時間: 11:35-12:00
• 形式: 実習
• ゴール: 自チームの状態遷移図から、5種の機能（新規入力／1件表示／一覧表示／更新／削除）と、それぞれに対応するプレゼンテーション（画面）一覧を作成できる
• 学習形式: AI協働型（機能・画面の抜け漏れチェックをAIに依頼する）

前のセッションで状態遷移図を3つ以上作りました。状態遷移を書くと「機能と画面が自動で導き出せる」と説明したことを覚えていますか？このセッションでその効果を実感する番です。

「画面、何枚必要だっけ？」「機能、どこまで作ればいい？」と悩んだ経験はありませんか？このセッションを終えると、その悩みが消えます。状態遷移図さえあれば、必要な機能と画面は機械的に列挙できるのです。

午後のモックアップ作成、明日の設計、明後日の実装、すべてはこのリストを元に進みます。短い25分ですが、最重要のアウトプットです。

CRUDを、より実務的に分解すると次の5つになります。

ここで大事なポイントが2つあります。

• 機能と画面は1対1とは限らない：1つの機能に複数画面（例：入力→確認→完了の3画面）になることがある
• 5つの機能は情報モデルごとに必要：3つの情報モデルがあれば、合計15機能・15画面前後になる

「5機能 × 情報モデル数」が最初の見積もりです。実際にはもう少し増減しますが、まず基準を持つことで「画面が思いつかない…」と止まることがなくなります。

混同されがちですが、画面遷移図は「ユーザーがどう画面を渡り歩くか」、状態遷移図は「データがどう状態を変えるか」。前者はUI設計の道具、後者は情報設計の道具です。両方を別々に書き、相互に整合性をチェックするのが理想です。今日のセッションでは状態遷移図から機能・画面を導き、明日以降に画面遷移図を描いていきます。

機能一覧

プレゼンテーション（画面）一覧

機能IDと画面IDを必ず付けること。後で要件追跡（トレーサビリティ）が圧倒的に楽になります。「F-005はどの画面で使う？」と即答できる状態を維持します。

Session04で作成した3つの情報モデルそれぞれについて、機能一覧とプレゼンテーション一覧を作成する。

• 機能一覧（15機能以上）
• プレゼンテーション（画面）一覧（10画面以上）

AIプロンプト例（抜け漏れチェック）

私たちのチームでは情報モデル「レシピ」「ユーザー」「コメント」について
状態遷移図と機能一覧を作りました。

機能一覧：
[ここに表をコピペ]

新規入力・1件表示・一覧・更新・削除以外に、ペルソナの
「料理初心者の20代女性」が求めそうな機能の抜け漏れがあれば指摘してください。
例：検索、絞り込み、お気に入り登録、シェア、など。

• 「『一覧表示』だけど、検索や絞り込みは1機能扱い？別機能？」
• 「ログイン／ログアウトは情報モデルに紐づかないけど、機能一覧に入れる？」
• 「機能と画面が1対1にならない例を教えて」

機能一覧とプレゼンテーション一覧が完成しました。これでDay 2午前の成果物がすべて揃いました。

午後は「開発モデル」「非機能要件」「UI（モックアップ）」へと進みます。今までは「何を作るか（要件）」中心、午後からは「どう作るか（実装の準備）」に少しずつ視点が移ります。

• 機能一覧は15以上ありますか？
• 機能IDと画面IDを付けましたか？
• 「検索」や「ログイン」などの横断機能を見逃していませんか？

• 参考リンク：要件追跡マトリクス（RTM）の例
• 発展課題：機能一覧と画面一覧の整合性をチームメンバーで相互チェック