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

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

セッション2で、皆さんの情報モデルすべての状態遷移図ができました。
図の中には、操作のラベルがついた矢印がたくさんありますね。

ここで問いかけです。

「その矢印1本1本は、次のセッションで何に変身するでしょうか？」

答えは機能です。セッション1で学んだ通り、「情報を状態遷移させるのが機能であり、画面になる」。
矢印（状態遷移）= 機能の種、そして機能をユーザが操作する場所が画面です。

このセッションでは、状態遷移図を機能一覧と画面一覧に変換します。
思いつきは禁止。矢印との突き合わせだけで作ります。これが「前のタスクの成果物を利用する」というこの研修の鉄則です。

手順は機械的です。だからこそ漏れません。

1. 状態遷移図の矢印を1本ずつ見る
2. 矢印のラベル（操作）を「〜機能」という名前にして機能一覧に書く
3. Read（参照）を忘れずに追加する。図に矢印がなくても、「一覧を見る」「詳細を見る」機能は必要
4. すべての情報モデルの図について繰り返す

予約情報の状態遷移図から機能一覧を作るとこうなります。

ポイントは「元になった遷移」の列です。これがあると、全部の矢印が機能になったかを逆からチェックできます。

• 機能一覧は矢印との突き合わせで作る。矢印の数 ≦ 機能の数（Read分が加わるため）になるのが自然
• 機能名は「〜機能」で統一し、CRUDのどれかを必ず添える
• 「対応する情報モデル」列は必須。Day 8のCRUD図でそのまま使う

機能一覧の「漏れ」は、IT業界で最も高くつくミスの1つです。要件・設計段階の欠陥をリリース後に直すコストは、設計段階で直す場合の数十倍から100倍に膨らむという調査が昔から知られています（バリー・ベームの研究が有名）。「画面を1枚作り忘れた」が実装後に発覚すると、設計・実装・テスト・他画面への影響調査までやり直しです。矢印1本の突き合わせを面倒がらない人が、結果的に一番速いのです。

次に、各機能を「ユーザがどこで操作するか」を考えて画面に割り当てます。

ここで大事な感覚があります。機能と画面は1対1とは限りません。

• 「予約一覧画面」には、一覧参照（R）とキャンセルボタン（U）の2機能が載るかもしれません
• 「予約登録機能」には、入力画面と確認画面の2画面が要るかもしれません

予約システムの画面一覧の例です。

最後に、CRUD由来でない画面（メニュー画面、ログイン画面など）を補います。
「土台はCRUDで、入口系は最後に補う」でしたね。

• 全機能がどこかの画面に載っているか、機能ID側から逆引きチェックする
• 画面を増やしすぎない。「確認画面は本当に必要？」とペルソナの気持ちで考える
• 管理者（お店側）の画面を忘れがち。ペルソナ（お客様）だけでなく、運用する人のCRUDも思い出す

「確認画面は必要か」論争は、Web業界の定番ネタです。日本のECサイトは「入力→確認→完了」の3段構成が伝統ですが、海外サイトは確認画面なしの2段構成が主流です。Amazonにいたっては「1-Click注文」で全部すっ飛ばして特許まで取りました（2017年に失効）。確認画面は誤操作を防ぐ反面、購入完了率を下げるとも言われます。正解は1つではなく「ペルソナとってどちらが幸せか」で決める——まさに外部設計の腕の見せどころです。

実習中に迷ったら、AIに相談しましょう。たとえば：

• 「この状態遷移図から機能一覧を作ったので、漏れがないかチェックして」（図と一覧を貼る）
• 「この機能一覧に対して画面一覧を作りたい。画面の分け方の案を2パターン出して」
• 「管理者側に必要な画面が漏れていないか、この一覧を見て指摘して」
• 「確認画面を入れるべきか、ペルソナ（○○な人）の視点で意見を聞かせて」

セッション2で作成したすべての情報の状態遷移図を入力として、機能一覧と画面一覧を作成してください。

手順:

1. 状態遷移図の矢印を1本ずつ機能に変換する（15分）
2. Read（参照）機能を情報モデルごとに追加する
3. 機能を画面に割り当て、画面一覧を作る（15分）
4. CRUD由来でない画面（メニュー・ログイン等）を補う
5. 突き合わせチェック（10分）:

   • すべての矢印が機能になっているか（状態遷移図 → 機能一覧）
   • すべての機能が画面に載っているか（機能一覧 → 画面一覧）
6. チーム内で一覧を声に出して読み合わせる（5分）。「F01 予約登録機能、画面はS02とS03」のように読み上げ、全員で頷けるか確認する（話す＆行う）

• 「機能一覧」（機能ID・機能名・対応する情報モデル・CRUD・元になった遷移の列を含む）
• 「画面一覧」（画面ID・画面名・載る機能IDの列を含む）
• 突き合わせチェックで見つけた漏れと修正内容のメモ

• 機能の粒度に迷う → 「ユーザの1つの目的が達成される単位」が目安です。「予約する」は1機能、「氏名を入力する」は機能ではなく画面項目です
• 画面が多くなりすぎる → 似た画面（登録と変更など）は1画面にまとめられないか検討しましょう。AIに「この画面一覧、統合できる画面はある？」と聞くのも有効です
• 管理者側を忘れた → 状態遷移図の矢印のうち「お店側の操作」（来店記録など）を誰がどの画面でやるのか確認しましょう
• チェックの順番 → 必ず「状態遷移図→機能一覧」「機能一覧→画面一覧」の両方向で突き合わせます。片方向だけだと漏れが残ります
• AIへの依頼のコツ → 一覧を丸ごと貼って「漏れの指摘」を頼むと精度が上がります。「うちのシステムは○○で、ペルソナは○○」という前提も一緒に伝えましょう

今回学んだことを一言でまとめると、**「機能一覧と画面一覧は、状態遷移図の矢印から機械的に導く」**です。

• 矢印1本＝機能の種。Readは図にないので忘れず追加する
• 機能と画面は1対1とは限らない。対応表で必ずつなぐ
• 両方向の突き合わせチェックで漏れを潰す

これでDay 5の成果物（情報の状態遷移図・画面一覧・機能一覧）が揃いました。
次回Day 6は、画面一覧の画面たちを画面遷移図でつなぎ、画面仕様書を書いて外部設計書を完成させます。

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

• 状態遷移図から機能一覧を作る手順を、順番に説明できますか？
• 自チームの機能一覧で、CRUDのRに当たる機能はどれか指差せますか？
• 機能と画面が1対1にならない例を、自チームの成果物から1つ挙げられますか？

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

• 参考リンク: IPA「機能要件の合意形成ガイド」（機能一覧・画面一覧の実務サンプル）
• 発展課題: 自チームの機能一覧に「利用者（ペルソナ／管理者）」の列を追加し、誰のための機能かを整理してみる

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