業務・画面の設計学習記事全11節Design
画面を作る前に、役割ごとの操作と業務の流れを描く
この記事で身につくこと操作の前後で業務がどう変わるかを描く意味と、画面だけ先に作る危険を説明し、役割別シナリオと業務フローを描ける。
記事内目次（26項目）
この記事の会社・人物・数値はすべて架空の設定です。実在する会社や案件とは関係ありません。
この記事は何の話か。依頼者・承認者・運用管理者という3つの役割が、それぞれどう操作し、その前後で業務がどう変わるかをシナリオと業務フローに描く話です。
なぜ必要か。画面を先に作ってしまうと、「この操作の後、業務は誰の手に渡るのか」が曖昧なまま形だけが決まり、後から役割間の受け渡しに抜けが見つかって作り直すことになります。
この記事を読むとできるようになること。
- 操作の前後で業務がどう変わるかを描く意味と、画面だけ先に作る危険を説明できる
- 依頼者・承認者・運用管理者という3役割のシナリオと、状態が変わる業務フローを描ける
- シナリオから要件にない操作が見えた場合に、要件へ戻すか運用で扱うかを判断できる
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節→第4節→第5.2節の表→第9節。ここまでで「シナリオの描き方」と「業務フローの形」が分かり、ひな形を埋め始められます。
- 作って確かめる：上に加えて第6節（失敗例と直し方）→第7節。
- 設計判断を深める：上に加えて第8節（要件に戻す論点、適用限界）。
1. 今回の業務課題と完成するもの
この記事でやることは、依頼者・承認者・運用管理者という3役割について、それぞれの操作と、その操作の前後で業務がどう変わるかをシナリオに描くことです。
02-02で「何をするか」（機能）は決まりましたが、「誰が、どの状態のときに、何を操作し、その結果どうなるか」はまだ描かれていません。この記事では、それを役割別シナリオと業務フローとして描きます。
この記事を読み終えると、次のものが手元にできます。
- 役割別シナリオ（役割、開始状態、操作、結果の状態、業務上の変化）
- シナリオから見つかった、要件に戻すべき論点の一覧
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
操作シナリオ
一言でいうと、ある役割の人が、ある状態のときに何を操作し、その結果どうなるかを一続きの流れとして書いたものです。たとえば、「依頼者が下書きを提出し、状態が『提出済み』に変わる」という一続きです。
これがないと、画面の項目だけを先に決めてしまい、「提出した後、誰が何をするのか」という業務の流れが抜けたまま進んでしまいます。
業務上の変化
一言でいうと、操作の結果、その業務が次に誰の作業になるか、という変化です。依頼が提出されると、その業務は承認者の作業に変わります。
状態
一言でいうと、依頼が今どの段階にあるかを表す区分です。03-01・03-02で確認したとおり、この業務には下書き・提出済み・差戻し・承認済みの4状態があります。
読む順路：機能一覧は02-02が該当します。この業務の元々のやり取り（現状の業務フロー）は、記事Aの困り事の説明にある「メールや口頭でのやり取り」が該当します。次工程の画面原型・状態遷移の設計は04-02・05-02が該当します。この記事だけでも進められるように、必要な説明は本文に含めています。
3. 理解する：なぜ画面より先にシナリオを描くか
3.1 画面だけ先に作る危険
| 画面だけ先に作った場合 | シナリオを先に描いた場合 |
|---|---|
| 「提出」ボタンを押した後、誰が何をするか決まっていない | 提出後は承認者の作業になる、という業務上の変化が明確 |
| 差戻し後にどの画面に戻るか決まっていない | 差戻し後は依頼者が下書き状態から再提出する、という流れが明確 |
| 承認者以外が承認操作をできてしまう危険に気づきにくい | 役割ごとの操作を先に描くことで、権限の抜けに気づける |
3.2 3役割と4状態
| 役割 | 主な操作 |
|---|---|
| 依頼者 | 依頼の作成、提出、差戻し後の再提出 |
| 承認者 | 提出済みの依頼の確認、承認、差戻し |
| 運用管理者 | 一覧の閲覧、権限に関する確認（03-01・記事Aで確認済みの役割） |
4状態：下書き、提出済み、差戻し、承認済み（03-01・03-02ですでに確認済み）。
3.3 よくある誤解
「シナリオは画面ができてから考えればよい」。画面を先に決めると、業務の流れに合わない画面になっていても気づきにくくなります。この記事ではシナリオを先に描き、04-02で画面に落とし込みます。
「シナリオは依頼者の操作だけ描けばよい」。承認者・運用管理者の操作も業務の一部です。3役割それぞれのシナリオを描きます（完了条件）。
「差戻し後は依頼者がもう一度最初から作ればよい」。差戻し後に何が引き継がれるか（依頼の内容が残るか、承認者からのコメントが見えるかなど）を、シナリオの中で確認します。
「AIにシナリオを描かせればよい」。AIは一般的なシナリオの形を提示できますが、この業務の役割・状態に基づいた具体的なシナリオは、02-02の機能一覧と照らして人が確認します（第4.3節）。
4. 判断すること
4.1 何を確認すればよいか
| 確認すること | この記事での扱い |
|---|---|
| 3役割それぞれにシナリオがあるか | 第5.2節で確認する |
| 4状態の遷移が、シナリオの中で網羅されているか | 第5.2節・第5.3節で確認する |
| シナリオの中に、02-02の機能一覧にない操作が出てこないか | 第8節で確認する |
4.2 勝手に決めてはいけないこと
- 02-02の機能一覧にない操作を、この記事で新たに作りません。
- 03-01・03-02で確認した役割・状態を、この記事で変更しません。
- シナリオから見つかった要件にない操作を、この記事の中で勝手に「対応する」と決めません（第8節で論点として扱う）。
4.3 AIに任せる範囲
シナリオの一般的な書き方（開始状態・操作・結果状態の形）の提示はAIに任せられます。しかし、この業務の役割・機能に基づいた具体的なシナリオの内容は、人が確認します。
5. 作って確かめる：役割別シナリオを作る
5.1 準備
02-02の機能一覧、03-01・03-02で確認した役割・状態の一覧を用意します。
5.2 役割別シナリオ
| 役割 | 開始状態 | 操作 | 結果の状態 | 業務上の変化 |
|---|---|---|---|---|
| 依頼者 | （依頼なし） | 依頼を作成し、内容を入力する | 下書き | 依頼者の手元に下書きが残る。まだ承認者には見えない |
| 依頼者 | 下書き | 提出する | 提出済み | 業務が承認者の作業に変わる。依頼者は編集できなくなる |
| 承認者 | 提出済み | 内容を確認し、承認する | 承認済み | 業務が完了する。依頼者・運用管理者が結果を確認できる |
| 承認者 | 提出済み | 内容を確認し、差戻す（理由を添える） | 差戻し | 業務が依頼者の作業に戻る。差戻し理由が依頼者に見える |
| 依頼者 | 差戻し | 内容を修正し、再提出する | 提出済み | 業務が再び承認者の作業に変わる |
| 運用管理者 | （どの状態でも） | 一覧を閲覧し、依頼の状態を確認する | 変化なし | 運用管理者は状態を変更する操作は行わない（03-01・記事Aの役割の範囲） |
5.3 業務フロー（状態の遷移）
4状態は次のように遷移します。
（依頼なし）→[依頼者が作成]→ 下書き
下書き →[依頼者が提出]→ 提出済み
提出済み →[承認者が承認]→ 承認済み
提出済み →[承認者が差戻し]→ 差戻し
差戻し →[依頼者が再提出]→ 提出済み4状態（下書き・提出済み・差戻し・承認済み）のすべてが、上記のいずれかの遷移に含まれていることを確認します。
5.4 AIにシナリオの下書きを頼む
各役割の一般的なシナリオの形をAIに提示させ、下書きを作らせます。
依頼・承認管理アプリのシナリオを描きたいです。役割は依頼者・承認者・運用管理者、状態は下書き・提出済み・差戻し・承認済みです。02-02の機能一覧を渡します。
依頼：
1. 各役割について、開始状態・操作・結果の状態・業務上の変化を表にしてください。
2. 4状態すべてが遷移に含まれるようにしてください。
してはいけないこと：
- 02-02の機能一覧にない操作を追加しないでください。
- 権限（誰が承認できるか）を勝手に変更しないでください。6. 初稿・失敗例・修正
6.1 説明用の失敗例（AIの初稿という設定）
AIへの依頼の結果、次のような下書きが返ってきた、という設定にします（実際のAI出力を観測したものではありません）。
- 承認者のシナリオに「承認済みの依頼を後から編集する」という、02-02の機能一覧にない操作が追加されていた
- 運用管理者のシナリオが抜けていた
6.2 見つけ方と直し方
- 機能一覧にない操作が混ざっている：02-02の完了条件に合いません。この操作をシナリオから外し、要件にない操作として第8節で扱う論点にするという判断をします。
- 運用管理者のシナリオが抜けている：完了条件「3役割それぞれにシナリオがある」を満たしません。運用管理者のシナリオ（一覧閲覧）を追加します。
指摘：
1. 「承認済みの依頼を後から編集する」は02-02の機能一覧にありません。シナリオから外してください。
2. 運用管理者のシナリオが抜けています。追加してください。
変えないこと：
- 02-02・03-01・03-02の内容そのものは変更しないでください。6.3 修正後のシナリオ
修正後の役割別シナリオ・業務フローは、第5.2節・第5.3節のとおりです。
7. 確認結果
| 完了条件 | 確認結果 |
|---|---|
| 3役割それぞれにシナリオがある | 依頼者・承認者・運用管理者の3役割すべてにシナリオを記載 |
| 4状態の遷移が網羅されている | 下書き・提出済み・差戻し・承認済みの4状態すべてが第5.3節の遷移に含まれる |
| 要件に戻す論点が一覧化されている | 「承認済みの依頼を後から編集する」を論点として第8節に記載 |
残る制限：このシナリオは架空の業務に基づく一例です。この記事の本文と記入例はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 要件にない操作をどう扱うか
第6節のシナリオ作成中に、「承認済みの依頼を後から編集する」という、02-02の機能一覧にない操作が論点として見つかりました。
| 選択肢 | 内容 | 影響 |
|---|---|---|
| 要件へ戻す | 02-02の機能一覧に「承認後の編集」を新しい機能として追加する | 機能が増え、誰が編集できるかという権限の検討が新たに必要になる |
| 運用で扱う（採用） | 承認後に修正が必要な場合は、新しい依頼を作り直すという運用ルールとする | 機能を増やさずに済むが、依頼者・承認者に運用ルールとして周知する必要がある |
REQ-003（権限に関する要件）に新しい権限判断を追加すると、確認すべきことが増えます。今回は機能を増やさず、運用ルールとして扱うことを採用します。ただし、この判断は架空の設定であり、実際の業務では編集の必要性がどれだけあるかを踏まえて再検討する必要があります。
8.2 適用限界
この記事のシナリオは、架空企業「みらい業務サービス」の小規模な社内利用を前提にしています。役割が増える、あるいは承認の階層が増える場合は、シナリオを描き直す必要があります。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 役割別シナリオひな形（役割、開始状態、操作、結果の状態、業務上の変化） | templates/04-01-scenarios_template.md | templates/04-01-scenarios_example.md |
自分の業務に使うときの手順は次のとおりです。
- 前工程（02-02の機能一覧、役割・状態の一覧）を用意する
- 役割ごとに、開始状態・操作・結果の状態・業務上の変化を書く
- 状態の遷移をすべて洗い出し、4状態が網羅されているか確認する
- 機能一覧にない操作が見つかったら、要件へ戻すか運用で扱うかを論点として書く
10. 次工程への受渡し
次へ渡すもの：役割別シナリオ、業務フロー（状態の遷移）、要件に戻す論点の一覧。
次工程での使われ方：04-02（画面の原型を作る）では、このシナリオをもとに、依頼作成・一覧・詳細の画面を設計します。05-02（状態遷移）では、この業務フローをより詳細な状態遷移として設計します。
前工程へ戻る条件：シナリオから見つかった要件にない操作を「要件へ戻す」と判断した場合、02-02に戻って機能一覧を見直します。
11. 根拠と更新情報
- この記事の会社・人物・シナリオはすべて架空の設定です。
- 第6節の初稿は説明用の失敗例であり、実際のAI出力を観測した記録ではありません。
- 3役割・4状態は、記事Aおよび03-01・03-02ですでに確認済みの内容を前提にしています。01-02（現状フロー）の記事本文は本記事作成時点では未作成であり、独立した記事としての参照はできません。この記事では代わりに記事Aの困り事の説明を前提として扱いました。
- 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。人（ユーザー）による実読・内容確認は未実施です。
- 未確認事項：「承認済みの依頼を後から編集する」を運用で扱うという判断は、実際にその必要性がどれだけあるか確認しておらず、架空の仮定のまま進めている。