画面遷移図と画面仕様書の書き方

• 日程: Day 6 / セッション 1
• 時間: [9:30-9:55]
• 形式: 座学
• ゴール: 画面遷移図の表記ルールと画面仕様書に書くべき項目（レイアウト・入力項目・ボタンの遷移先等）を挙げられる
• 学習形式: 対話型解説、ケーススタディ

昨日、皆さんは画面一覧と機能一覧を完成させました。
画面の「部品リスト」はできたわけです。でも、部品リストだけでは家具は組み立てられませんよね。組み立て図が要ります。

ここで問いかけです。

「初めて使うアプリで『今どこにいるのか分からない』『戻れない』と感じた経験はありませんか？」

それは、画面のつながりの設計が悪いサインです。
今日学ぶ画面遷移図は画面のつながりの地図、画面仕様書は各画面の詳細図です。
この2つができれば、外部設計書が完成します。

画面遷移図は、画面一覧のすべての画面を矢印でつないだ図です。
表記ルールはシンプルです。

• 箱 = 画面（画面一覧の画面ID・画面名と一致させる）
• 矢印 = 遷移。何をしたら遷移するのか（ボタン名・操作）をラベルで添える
• 開始点 = ユーザが最初に到達する画面を明示する

良い例を見てみましょう。昨日の予約システムの例です。

では、分かりにくい遷移図とはどんなものでしょうか。対比してみます。

• 良い図は矢印に「確認ボタン」とラベルがあるので、何をしたら遷移するか分かります。悪い図はラベルなしの矢印だけで、見た人が推測するしかありません
• 良い図は画面一覧の画面が全部載っています。悪い図には画面一覧にない画面が突然登場したり、一覧にある画面が消えていたりします
• 良い図には「戻る」遷移が描かれています。悪い図は行きの矢印だけで、ユーザが行き止まりになります

ここで考えてみてください。上の図で、S06（予約変更画面）から保存せずにやめたくなったら、ユーザはどうなるでしょう？
……実は「戻るボタン」の矢印がありません。これが行き止まりの例です。良さそうに見える図にも穴はあります。だからチェックが要るのです。

• 矢印には必ず「きっかけ（ボタン名・操作）」をラベルで書く
• 画面一覧と画面遷移図の画面は完全一致させる（過不足は設計矛盾）
• 「行き」だけでなく「戻り」の遷移を確認する。行き止まり画面はユーザの迷子のもと

「ユーザを迷子にさせない」は、Webの世界では「ユーザビリティ」研究として蓄積されています。有名なのが「3クリックルール」——どんな情報にも3クリック以内で到達できるべき、という経験則です（科学的根拠は実は薄く、後の研究では「クリック数より迷わないことが大事」と反論されています）。また、デンマークのヤコブ・ニールセンは「ユーザは他のサイトで大半の時間を過ごしている。だからあなたのサイトも他と同じように動くべきだ」という法則を残しました。奇抜な画面遷移より「予想通り」が正義なのです。

画面遷移図が「地図」なら、画面仕様書は画面1枚1枚の「詳細図」です。
これを見れば、実装する人が質問しなくても画面を作れることがゴールです。

画面仕様書に書くべき項目はこれです。

たとえば「人数: 数値」は仕様として有効ですが、「人数: ちゃんと入れてもらう」は仕様ではありません。なぜなら、実装者が「ちゃんとって何？」と必ず質問することになるからです。数字・選択肢・画面IDで言い切れることが仕様の条件です。

画面遷移図と画面仕様書の関係も押さえておきましょう。

• 画面遷移図の矢印は、画面仕様書のボタン定義と必ず対応します
• 遷移図に矢印があるのに、仕様書にボタンがない → 矛盾
• 仕様書にボタンがあるのに、遷移図に矢印がない → 矛盾

つまり2つの文書は、互いに答え合わせができる関係です。この性質はセッション3の「クロスチェック」で活躍します。

ここで少し考えてみてください。皆さんの画面一覧の中で、入力項目が一番多そうな画面はどれですか？　その画面が、本日セッション3で最初に仕様書を書くべき「主要画面」の有力候補です。

• 画面仕様書のゴールは「実装者が質問せずに作れる」こと
• 入力項目には必須/任意と制約（型・桁・範囲）を必ず書く
• ボタンには「何が起きるか」と「どこへ遷移するか」をセットで書く。エラー時の挙動も忘れない

「仕様書に書いていないことはバグか仕様か」は、開発現場の永遠の論争です。古典的ジョーク——「それはバグではない、仕様だ（It's not a bug, it's a feature）」は、仕様書が曖昧だった時代の言い訳から生まれ、今ではTシャツのデザインになるほどの定番ネタになりました。画面仕様書を丁寧に書く本当の理由は、未来の自分やチームメイトを「これってどういう意味？」という不毛な議論から救うためなのです。

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「良い画面遷移図と悪い画面遷移図の違いを、別の例で見せて」
• 「入力項目の『制約』には他にどんな種類がある？　電話番号を例に教えて」
• 「画面仕様書のレイアウトはどこまで細かく描くべき？　手描きでもいい？」
• 「行き止まり画面を機械的に見つける方法はある？」

今回学んだことを一言でまとめると、**「画面遷移図は迷子にさせない地図、画面仕様書は質問させない詳細図」**です。

• 画面遷移図: 矢印にきっかけを書く、画面一覧と完全一致、戻り遷移と行き止まりをチェック
• 画面仕様書: レイアウト・入力項目（制約つき）・ボタンの遷移先を、言い切れる形で書く

次のセッションでは、自チームの画面一覧から実際に画面遷移図を作成します。CJM（To-Be版）を手元に準備しておいてください。

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

• 画面遷移図の矢印に必ず書くべきものは何ですか？
• 「分かりにくい画面遷移図」の特徴を2つ挙げられますか？
• 画面仕様書に書くべき項目を4つ以上挙げられますか？
• 「実装者が質問せずに作れる」ために、入力項目に何を添えるべきですか？

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

• 参考リンク: IPA「機能要件の合意形成ガイド（画面編）」（画面遷移図・画面仕様書の実務サンプル）
• 発展課題: 普段使うアプリの画面遷移を5画面ぶんだけ図に起こし、「行き止まり」や「ラベルにできない遷移」がないか観察する

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