業務・画面の設計学習記事全11節Design
実装前に、下書きから承認済みまでの画面遷移を役割別にたどる
この記事で身につくこと正常系（想定どおりの操作）を利用者別にたどる確認の目的と、実装前に行う意味を説明できる。
記事内目次（18項目）
この記事の会社・人物・数値はすべて架空の設定です。実在する会社や案件とは関係ありません。
この記事は何の話か。04-02で作った画面の原型をもとに、依頼の作成から提出、承認者の確認、承認までの「想定どおりの流れ（正常系）」を、実装する前に紙の上でたどる話です。
なぜ必要か。実装してから画面のつながりの抜けに気づくと、作り直しの手間が大きくなります。実装の前にたどっておけば、紙の上での修正で済みます。
この記事を読むとできるようになること。
- 正常系を利用者別にたどる確認の目的と、実装前に行う意味を説明できる
- 依頼作成→提出→承認者の確認→承認までを画面遷移図でたどり、正常系確認記録に書ける
- たどる中で見つかった抜けを、画面追加・要件変更・運用対応のどれで扱うか判断できる
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節（実装前にたどる意味）→第4節（判断すること）→第5.2節（確認記録）→第9節。ここまでで、正常系を「手順番号・役割・画面・操作・期待表示」でたどる形が分かります。
- 作って確かめる：上に加えて第5.3節（発見事項と、抜けの見つけ方）→第6節（完了条件との照合）→第7節。
- 設計判断を深める：上に加えて第8節（発見事項を画面・要件・運用のどこで扱うか、適用限界）。
1. 今回の業務課題と完成するもの
この記事でやることは、04-02で作った依頼作成・一覧・詳細の3画面をもとに、依頼者が依頼を作成してから、承認者が確認して承認するまでの「想定どおりの流れ」を、手順を追ってたどり、正常系確認記録に書くことです。
04-02では画面の項目や操作ボタンを決めましたが、それらの画面が実際につながって一連の業務を実現できるかは、まだ確かめていません。この記事では、それを確かめます。
この記事を読み終えると、次のものが手元にできます。
- 画面遷移・正常系確認記録（手順番号、役割、画面、操作、期待表示、確認結果、発見事項）
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
正常系
一言でいうと、想定どおりの操作が、想定どおりの順番で行われる場合の流れです。たとえば、依頼者が必須項目をすべて入力して提出する、というのが正常系です。
これがないと、まず異常な操作（入力ミスなど）への対応から考えてしまい、そもそもの正しい流れが固まらないまま進んでしまいます。異常系は04-04で扱います。
画面遷移
一言でいうと、ある画面から次の画面へ移ることです。たとえば、依頼作成画面で「提出」を押すと、一覧画面に移る、というのが画面遷移です。
読む順路：画面の原型は04-02、操作シナリオは04-01が該当します。この記事の確認記録は、04-04（例外と使いやすさを設計する）、記事B（09-02）のシナリオの元になります。
3. 理解する：なぜ実装前にたどるか
3.1 実装前にたどる意味
| 実装前にたどらなかった場合 | 実装前にたどった場合 |
|---|---|
| 実装後に「承認者が割当依頼の一覧を見る画面がない」と気づき、作り直しになる | 紙の上で気づき、04-02の画面原型を修正するだけで済む |
| 各画面の遷移が途切れていても気づきにくい | 手順番号を追うことで、途切れがあれば分かる |
3.2 よくある誤解
「画面を作ってから動かして確認すればよい」。実装してからの手戻りは、紙の上での修正よりも手間がかかります。この記事は実装前（04-02の直後）に行います。
「正常系さえ確認すれば十分」。正常系の確認だけでは、入力ミスや通信失敗などの異常時の扱いは分かりません。それらは04-04で扱います。
「AIに画面遷移を確認させればよい」。AIは一般的な画面遷移の型を提示できますが、この業務で実際に画面がつながっているかは、04-02の画面原型に基づいて人が確認します（第4.3節）。
4. 判断すること
紙の上でたどるときに人が判断することは、次の3つです。
| 判断すること | なぜ判断が必要か | 仮置きしてよいか | 間違えた場合の影響 |
|---|---|---|---|
| どの役割の、どの操作から、どの操作までを1本の流れとしてたどるか | 流れの始点と終点が曖昧だと、途中の抜けに気づけない（第3.1節） | 可（この記事では「依頼者の作成→承認者の承認→依頼者の確認」を1本にする。差戻しの流れは別にたどる） | 承認者の手順を飛ばして「依頼者だけの流れ」をたどり、承認者の画面の抜けに気づかない |
| 各手順の「期待表示」を、画面原型のどの記述と照合するか | 期待表示は04-02の項目定義から書く。原型に無い表示を期待すると、確認ではなく願望になる | 不可。期待表示は原型の項目定義に根拠を持たせる | 原型に無い「割当先での絞り込み」を、あるものとして通してしまう（第5.3節がまさにこの抜け） |
| 見つけた抜けを、画面修正・要件変更・運用対応のどれに戻すか | 戻す先で、直す人と直し方が違う（第8.1節） | 可（対処先の候補を書き、決定は戻した先の記事で行う） | この記事の中で画面を勝手に足し、02-02の機能一覧や05-03の権限表と食い違う |
勝手に決めてはいけないこと：04-02にない画面や項目を、この記事で新しく作りません。発見した抜けは、対処先（04-02・02・運用）に戻して判断します。発見した抜けを、この記事の中で機能追加として即決しません。
AIに任せる範囲：手順の表への整理や、一般的な画面遷移の型の提示はAIに任せられます。しかし、この業務で実際に画面がつながっているかは、04-02の画面原型に基づいて人が確認します。AIは原型に無い画面を「あるはず」として補ってしまうことがあるため、期待表示の根拠が原型にあるかを人が見ます。
5. 作って確かめる：画面遷移・正常系確認記録を作る
5.1 準備
04-02の画面の原型（依頼作成・一覧・詳細の3画面）と、04-01の操作シナリオを用意します。
5.2 画面遷移・正常系確認記録
| 手順番号 | 役割 | 画面 | 操作 | 期待表示 | 確認結果 |
|---|---|---|---|---|---|
| 1 | 依頼者 | 依頼作成画面 | 件名・内容・承認者を入力し「提出」を押す | 一覧画面に遷移し、自分の依頼が「提出済み」で表示される | 一致 |
| 2 | 承認者 | 一覧画面 | 状態を「提出済み」で絞り込む | 自分に割り当てられた提出済みの依頼が表示される | 発見事項あり（第5.3節） |
| 3 | 承認者 | 詳細画面 | 依頼の内容を確認し「承認」を押す | 状態が「承認済み」に変わり、一覧に反映される | 一致 |
| 4 | 依頼者 | 一覧画面 | 自分の依頼の状態を確認する | 状態が「承認済み」で表示される | 一致 |
手順1〜4で、下書き（作成中）→提出済み→承認済みという状態の遷移がすべてたどれています。「確認結果」の列の「一致」は、期待表示が04-02の画面原型の項目定義と机上で一致したことを表します。実際に動く画面を観測した結果ではありません（第6節）。
5.3 発見事項
手順2で、一覧画面の「状態で絞り込む」機能だけでは、「自分に割り当てられた依頼だけ」を絞り込む方法が04-02の画面原型に明記されていないことに気づきました。
抜けの見つけ方は共通しています。手順ごとに「その画面で、その役割が、その操作をするために必要な表示・条件が、原型の項目定義に書いてあるか」を問います。手順2では、承認者が「自分に割り当てられた」依頼を見る必要がある（05-03の権限表、記事Aの役割表）のに、原型の一覧画面には「状態で絞り込む」しか無い、という食い違いとして見つかります。「たぶんあるだろう」で通さず、原型の記述を指せない期待表示は抜けとして記録します。
| 発見事項 | 対処先 | 対処内容 |
|---|---|---|
| 一覧画面に、承認者が「自分に割り当てられた依頼」を絞り込む方法が明記されていない | 04-02（画面の原型） | 一覧画面の項目定義に「割当先で絞り込む」条件を追加する（05-03の権限表とも整合させる）。対処の決定は04-02側で行い、この記事では候補まで |
6. 確認結果
第5.2〜5.3節の内容を、完了条件と照合します。
残る制限：この確認記録は架空の画面原型に基づく一例です。実際の画面が完成したあとの動作確認（08・09）ではなく、実装前の紙の上での確認であり、「一致」は原型の記述との机上の照合です。実際に動く画面での確認は10-01の受入確認で扱い、その時点では画面が未実装のため未確認として残っています。この記事の本文と記入例はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
7. よくある勘違いと直し方
- 発見事項をこの記事の中だけで解決しようとする：発見した抜け（割当先での絞り込み）は、04-02に戻して画面原型を修正するのが正しい対処です。この記事の中で新しい画面を勝手に作りません。
- 正常系だけを見て「もう完成」と思い込む：正常系の確認は、次工程（04-04）の異常系確認とセットで初めて実装に進める状態になります。
8. 設計を判断する
8.1 発見事項をどこで扱うか
| 選択肢 | 内容 | 適する場合 |
|---|---|---|
| 画面追加・修正（04-02へ戻す） | 画面の項目や表示条件を追加・修正する | 既存の機能一覧（02-02）の範囲内で対応できる場合 |
| 要件変更（02へ戻す） | 新しい機能や条件を要件として追加する | 機能一覧にない新しい業務ルールが必要な場合 |
| 運用対応 | 画面を変えず、運用のルールで対応する | 発生頻度が低く、画面変更の手間に見合わない場合 |
今回の発見事項（割当先での絞り込みがない）は、02-02の機能一覧にすでにある「一覧閲覧」機能の範囲内で対応できるため、04-02への画面修正で対処することを判断します。要件変更や運用対応は不要と判断します。
8.2 適用限界
この確認記録は、架空企業「みらい業務サービス」の3画面を前提にした一例です。画面数が増える場合は、同様の手順でたどり直す必要があります。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 画面遷移・正常系確認記録ひな形（手順番号、役割、画面、操作、期待表示、確認結果、発見事項） | templates/04-03-flow-check_template.md | templates/04-03-flow-check_example.md |
自分の業務に使うときの手順は次のとおりです。
- 前工程（画面の原型）を用意する
- 依頼作成から承認までの手順を、役割ごとに1つずつたどる
- 各手順の期待表示と実際の確認結果を書く
- 見つかった発見事項に、対処先（画面／要件／運用）を書く
10. 次工程への受渡し
次へ渡すもの：画面遷移・正常系確認記録、発見事項とその対処先。
次工程での使われ方：04-04（例外と使いやすさを設計する）では、この正常系の流れをもとに異常時の画面を設計します。記事B（09-02）では、この確認記録がシナリオの元になります。
前工程へ戻る条件：発見事項が04-02の画面原型の修正で対処できると判断したら、04-02に戻って修正します。