画面遷移図の作成

• 日程: Day 6 / セッション 2
• 時間: [9:55-11:00]
• 形式: 実習
• ゴール: 画面一覧のすべての画面を含む画面遷移図を時間内に作成できる
• 学習形式: ハンズオン実習（AIサポートあり）

前のセッションで、画面遷移図の表記ルール（矢印にきっかけを書く・画面一覧と完全一致・行き止まりをなくす）を学びました。
いよいよ自チームの画面遷移図を作ります。

その前に1つ、思い出してほしい成果物があります。

「Day 3で作ったCJM（To-Be版）には、ペルソナが満足にたどり着くまでの道のりが描かれていましたね。
その道のりは、皆さんの画面の上では何画面ぶんの旅になるでしょうか？」

画面遷移図は、ただ画面をつなぐパズルではありません。
ペルソナの旅の地図です。CJM（To-Be版）を必ず手元に開いてから始めましょう。

いきなり全画面をつなごうとすると、矢印だらけのスパゲッティ図になります。
おすすめの手順は「背骨から描く」です。

1. 背骨を描く（メインルート）: ペルソナが最初に画面に触れてから、目的を達成するまでの最短経路を1本の流れで描く。CJM（To-Be版）の道のりと一致するはず
2. 枝を生やす: 背骨以外の画面（管理側の画面、変更・キャンセル系など）を背骨につなぐ
3. 戻りを描く: 各画面から「戻る」「キャンセル」の遷移を加える
4. チェックする: 画面一覧と突き合わせ、過不足と行き止まりを確認する

予約システムなら、背骨はこうなります。

ペルソナ（お腹を空かせた忙しい会社員）は、この4画面で目的を達成できます。
この背骨が長すぎたら——たとえば10画面あったら——ペルソナは途中で離脱するでしょう。背骨の長さは、システムの使いやすさそのものです。

• 最初に背骨（ペルソナの最短経路）を描き、CJM（To-Be版)と突き合わせる
• 枝・戻りは後から。描く順番を守るとスパゲッティにならない
• 背骨の画面数を数えてみる。長いと感じたら画面の統合を検討する

「背骨の短さ」を極限まで追求した有名な例が、Amazonの「1-Click注文」です。通常は「カート→住所→支払い→確認→完了」の5画面のところを、ボタン1つ（実質1画面）にしました。この特許のライセンスを受けてAppleもiTunesに採用したほどで、「画面遷移を1つ減らすことは機能を1つ増やすより価値がある」ことを世界に証明しました。皆さんも枝葉を増やす前に、まず背骨を1画面でも短くできないか考えてみてください。

描き終わったら、次の4点をチームとAIでチェックします。

• 網羅性: 画面一覧のすべての画面が遷移図に載っているか。逆に、遷移図にだけ存在する画面はないか
• 到達性: 開始画面からたどって、すべての画面に到達できるか（孤島の画面はないか）
• 帰還性: どの画面からも、メニュー等の起点に戻れるか（行き止まりはないか）
• ラベル: すべての矢印に、きっかけ（ボタン名・操作）が書かれているか

• チェックは「画面一覧 → 遷移図」と「遷移図 → 画面一覧」の両方向で行う
• 孤島と行き止まりは、図を指でなぞると見つかる。目視より確実
• 見つかった矛盾は遷移図だけでなく、必要なら画面一覧側も直す（成果物間の整合性を保つ）

「すべての画面に到達できるか」「戻れるか」という問いは、数学のグラフ理論の「到達可能性」問題そのものです。Webの世界では、どこからもリンクされていないページを「オーファン（孤児）ページ」と呼び、SEO業界では検索エンジンにも見つけてもらえない「存在しないも同然のページ」として恐れられています。せっかく作った画面が孤児にならないよう、矢印でちゃんと家族にしてあげましょう。

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

• 「この画面一覧から画面遷移図のたたき台をMermaidで作って」（画面一覧を貼る）
• 「この遷移図に行き止まりや孤島の画面がないかチェックして」（図を貼る）
• 「ペルソナは○○な人。この背骨（メインルート）は長すぎないか意見が聞きたい」
• 「Mermaidの構文エラーが出た。このコードのどこが悪い？」（コードを貼る）

昨日作成した画面一覧のすべての画面を含む画面遷移図を作成してください。

手順:

1. CJM（To-Be版）を開き、ペルソナの最短経路（背骨）を確認する（5分）
2. 背骨を描く（10分）
3. 残りの画面（枝）と戻り遷移を描く（20分）
4. 4観点（網羅性・到達性・帰還性・ラベル）でチームチェックする（10分）
5. AIに図を見せてレビューしてもらい、指摘を反映する（10分）

ルール:

• すべての矢印にきっかけ（ボタン名・操作）のラベルを書く
• 画面IDと画面名は画面一覧と完全一致させる
• チェックで画面一覧側の不備が見つかったら、画面一覧も併せて修正する

• 「画面遷移図」（画面一覧の全画面を含む1枚。大規模な場合は系統ごとに分割し、つながりを明示）
• 背骨（ペルソナの最短経路）がどのルートかを示すメモ（色分けや太線でも可）
• チェック・AIレビューで見つけた指摘と修正内容のメモ

• どこから描くか迷う → 必ず背骨（ペルソナの最短経路）から。CJM（To-Be版）の「行動」の行が、そのまま背骨の画面の並びになっているはずです
• 矢印が交差して読めない → 画面の配置を「左から右へ時間が流れる」ように並べ替えると激減します。それでもダメなら系統ごとに図を分割しましょう
• 管理者側の画面のつなぎ先が分からない → 管理者用のメニュー画面（または管理者ログイン）を起点として独立した背骨を作るのが定石です
• Mermaidでエラーが出る → ラベルの引用符の閉じ忘れが定番です。「このMermaidコードがエラーになる」とコードごとAIに貼れば直してもらえます
• 時間が足りない → 完璧な配置より全画面・全矢印の網羅を優先。レイアウトの美しさは外部設計書の完成（セッション3）後に余裕があれば調整します

今回学んだことを一言でまとめると、**「画面遷移図は背骨（ペルソナの最短経路）から描き、4観点でチェックする」**です。

• 背骨 → 枝 → 戻り、の順で描くとスパゲッティにならない
• CJM（To-Be版）との突き合わせで、ペルソナの旅として自然かを確認する
• 網羅性・到達性・帰還性・ラベルの4観点チェックで完成度を上げる

次のセッションでは、主要画面の画面仕様書を書き、画面一覧・機能一覧・画面遷移図と合わせて外部設計書を完成させます。

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

• 自チームの背骨（ペルソナの最短経路）は何画面ですか？　すぐ答えられますか？
• 完成チェックの4観点（網羅性・到達性・帰還性・ラベル）をそれぞれ説明できますか？
• CJM（To-Be版）と画面遷移図がどう対応しているか、チームメイトに説明できますか？

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

• 参考リンク: Mermaid公式ドキュメント「Flowcharts」（flowchart記法・方向指定）
• 発展課題: 自チームの背骨を1画面減らせないか検討し、減らした場合のメリット・デメリットをAIと議論する

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