前回の続きと、この講義の役割
前回のH-05では、入力値を検証するバリデーションを、利用者への親切と、データを守る防御に分けて学びました。今回は視点を1つの画面の内側へ移します。画面は、何も入力されていない状況や、送信を待っている状況など、複数の状態を行き来しています。この講義の役割は、その移り変わりを「状態」という設計対象として、漏れなく扱えるようにすることです。
このスライドのポイント
- H-05: バリデーションを「利用者への親切（クライアント側）」と「データを守る防御（サーバー側）」に分けて学んだ
- 今回は視点を1つの画面の内側へ移す
- 画面は「未入力」「送信中」など複数の状況を行き来している
- 役割: その状況を「状態」という設計対象として扱えるようにする
状態と状態遷移とは
状態とは、画面がいま置かれている状況に付けた名前です。たとえば、未入力、入力中、送信中、成功、失敗といった区分です。状態遷移とは、利用者の操作や処理の結果によって、ある状態から別の状態へ移ることを指します。H-03で学んだ画面遷移が、画面と画面をつなぐ地図だとすれば、状態遷移は1つの画面の中を描いた地図です。扱う範囲の縮尺が違うだけだと考えると、わかりやすいはずです。
このスライドのポイント
- 状態＝画面がいま置かれている状況に付けた名前（未入力／入力中／送信中／成功／失敗）
- 状態遷移＝操作や結果によって、ある状態から別の状態へ移ること
- H-03の画面遷移が「画面間の地図」なら、状態遷移は「1画面の中の地図」
- 違いは縮尺
なぜ状態の設計が必要か
状態を設計しないと、定番の不具合を見逃します。たとえば、送信中という状態を用意しないと、利用者はボタンを何度も押せてしまい、同じ申請が二重に登録されます。逆に、失敗という状態を用意しないと、処理に失敗しても画面が何も変わらず、利用者は成功したと誤解したまま画面を閉じます。状態を言葉にできていれば、こうした抜けを、AIが生成した画面の中に具体的に指摘できるようになります。
このスライドのポイント
- 状態の考慮漏れは、定番の不具合を生む
- 送信中の状態がない → ボタンを何度も押せて二重申請
- 失敗の状態がない → 失敗しても画面が変わらず、利用者は成功と誤解
- 状態を言葉にできると、AIの生成物の抜けを指摘できる
1画面が取りうる状態を並べる
1つの画面が取りうる状態を、順に並べてみます。最初は未入力、入力が始まると入力中、申請ボタンを押すと送信中へ移ります。送信中は結果を待つ状態で、ここではボタンを無効にします。結果が返ると、成功なら完了表示へ、失敗ならエラー表示へ移ります。失敗した場合は、利用者が直せるように入力中へ戻せるようにします。状態を並べてみると、抜けている状況が見えてきます。
このスライドのポイント
- 未入力 → 入力中 → 送信中 → 成功／失敗、の順で並ぶ
- 送信中は結果を待つ状態。ここではボタンを無効にする
- 成功なら完了表示へ、失敗ならエラー表示へ
- 失敗した場合は、修正できるよう入力中へ戻す
具体例: 経費申請の申請ボタン
経費申請の申請ボタンで考えます。送信中の状態を設けないと、通信を待つあいだに利用者が反応がないと感じ、ボタンを連打してしまいます。その結果、同じ申請が二重に登録されます。また、失敗の状態を設けないと、通信に失敗しても画面が変わらないため、利用者は申請できたと思い込んで画面を閉じます。どの状態を用意するかを1つずつ決めておくことが、こうした事故を防ぐ設計になります。
このスライドのポイント
- 送信中の状態がないと、通信待ちのあいだに連打が起き、二重申請になる
- 失敗の状態がないと、失敗しても画面が変わらず、利用者は成功と誤解して画面を閉じる
- 状態を1つずつ用意することが、こうした事故を防ぐ
- 責任範囲: どの状態を用意するかは、AIではなく人間が仕様として決める
技術サンプル: 状態遷移図
サンプルは、画面の状態遷移をそのまま図にしたものです。読み方は2つあります。1つは、すべての状態に対して、その状態のときの見た目と、可能な操作を決めることです。もう1つは、送信中の状態でボタンを無効にする一点が、二重申請を防ぐ要になっていることです。AIへは、この画面が取りうる状態をすべて挙げ、状態ごとの表示とボタンの有効か無効かを表にしてほしいと頼むと、抜けを洗い出せます。
このスライドのポイント
- 種別: diagram
- 目的: 1画面の状態と、その移り変わりを漏れなく確認する
- サンプル本体:
混同しやすい: 画面遷移と状態遷移
混同しやすいのは、H-03で学んだ画面遷移と、今回の状態遷移です。画面遷移は、一覧から入力、確認、完了へと、画面と画面のあいだを移っていく地図でした。状態遷移は、同じ1つの画面の中で、未入力から入力中、送信中、成功や失敗へと移っていく地図です。扱う範囲の縮尺が違うだけで、どちらも経路を漏れなく描いておくという考え方は共通しています。両方をそろえて、はじめて利用者は迷わず操作を終えられます。
このスライドのポイント
- 画面遷移（H-03・画面間）: 一覧→入力→確認→完了、と画面と画面のあいだを移る
- 状態遷移（H-06・画面の中）: 未入力→送信中→成功／失敗、と同じ画面の中で移る
- 違いは縮尺。どちらも経路を漏れなく描く点は同じ
- 両方そろって、利用者は迷わず操作を終えられる
バイブコーディングでの確認点
バイブコーディングで画面を作らせるときは、送信中と失敗時の状態がどう表示されるかを、仕様として先に渡します。AIは指定がないと、正常に動いた場合だけを作りがちだからです。なお、状態を実際にコードでどう保持し、どう切り替えるかという実装方法は、カテゴリIで学びます。この講義では、その実装の前に必要な、状態そのものの設計に絞って考えています。設計を渡してから作らせる、という順番が大切です。
このスライドのポイント
- 画面を作らせるときは「送信中と失敗時の状態がどう表示されるか」を仕様として先に渡す
- AIは指定がないと、正常に動いた場合だけを作りがち
- 状態をコードでどう保持・切り替えるかの実装方法はカテゴリIで学ぶ
- この講義は「実装の前の状態の設計」に絞る
まとめと次回
一問一答です。二重申請を防ぐ状態設計は何でしょうか。（間）答えは、送信中の状態を設け、そのあいだボタンを無効にすることです。30秒まとめです。画面は複数の状態を行き来しており、その移り変わりが状態遷移です。未入力から送信中、成功と失敗まで、状態を漏れなく並べておくことが、定番の不具合を防ぎます。次回は、待ち、空、失敗という3つの状態の画面設計へ進みます。関連資料は「画面設計チェックリスト100」と「テスト観点プロンプト50」です。
このスライドのポイント
- 一問一答: 「二重申請を防ぐ状態設計は？」→ 送信中状態でボタンを無効にする
- 30秒まとめ: 画面は複数の状態を行き来する。状態を漏れなく並べることが定番の不具合を防ぐ
- 次回: 「待ち・空・失敗」の3状態の画面設計へ
- 関連資料: 「画面設計チェックリスト100」「テスト観点プロンプト50」
