第 IV 部統合ケース 違和感を、公開判断まで運ぶ
第 19〜25 章では、観察、仮説、比較、ブラウザ、DevTools、人の行動、反復を学びました。第25章が読者自身の制作習慣と内省を扱ったのに対し、本ケースは、別担当者へ渡せる根拠資料を作る演習です。架空の権限申請サービス「Michi Access」にある一つの違和感を、思いつきの修正で閉じず、公開・保留・取り消しの判断まで運びます。
題材は「申請ボタンを押した後、画面が変わらない」です。以下はすべて著者が作成した画面条件と未実施の観察計画であり、実利用者の結果ではありません。
1 記録条件を固定する
trial_id=P4-T01、ビューポート 1280×800、ズーム 100%、標準申請データ、通信遅延 4 秒、送信前状態を残します。スクリーンショットだけでなく、DOM、算出済みスタイル、アクセシビリティツリー、通信条件、コンポーネント版も記録対象です。
最初の違和感は「押せたか分からない」でした。これは評価です。観察へ書き換えます。
送信前と送信後 500ms の画面記録を比べると、ボタンの見た目とラベル、見える状態表示、フォーカス表示に差がない。
ボタンが実際に操作可能か、クリックイベントの発火、サーバー受付、支援技術への通知は画面記録だけでは不明です。
2 複数仮説と反証を残す
| 仮説 | 必要な根拠 | 弱まる結果 |
|---|---|---|
| 見えるフィードバック不足で再押下する | 同じ遅延での最初の再押下、状態説明 | テキスト追加後も変化なし |
| クリックイベントが発火しない | イベントリスナー、コンソール、イベントログ | イベントとリクエストが毎回記録される |
| 応答が失われ、結果不明になる | リクエスト／操作 ID、サーバーログ | クライアントとサーバーが成功へ同期する |
| 支援技術への状態通知が不足する | アクセシビリティツリー、支援技術での通知 | 適切な名前／役割／状態と通知を確認 |
| ラベルが送信結果を予測させない | 行動後発言、別ラベル比較 | ラベル変更で理解が変わらない |
「フィードバックの問題」と名前を付けても、五つの仮説は区別されません。
3 一軸比較を作る
比較 ID P4-C01-DISPATCH-VISIBLE では、「クライアントから送信中の見える表示」という一つの実験要因を操作します。その実装差は、可視領域の新設と「送信しています」というテキストの追加です。これはサーバー受付済みを意味しません。ボタンの操作可能性、スピナー、色、位置、支援技術への通知、通信遅延、内容は元の画面と同じく固定します。
これは「処理中の可視差」という仮説だけを見る診断用の差分で、公開候補ではありません。完成案 P4-SM01 では、未送信、クライアントから送信中、サーバー受付済み、処理中、成功、失敗、結果不明、再照会、回復を別状態にします。見えるテキスト、ボタン操作、支援技術への状態通知、二重送信防止を状態ごとに同期し、診断用の差分とは別 ID で評価します。
4 ブラウザを動かす
320、768、1280px、200% ズーム、長い申請名、エラー、オフライン、権限差を一条件ずつ変えます。ブレークポイントの一覧を消化するのでなく、状態表示がボタンから離れる、再配置で順序が変わる、長文が操作を押し出す地点を記録します。
横幅と通信条件を同時に変えた記録から原因を決めません。再現条件を表へ残し、壊れなかった条件も記録します。
5 DevTools で実装を監査する
見る前に予想します。「ボタンはフォーム送信、送信中状態はコンポーネント内で所有、状態表示は DOM に存在するが空」と仮説化します。その後、Elements、Computed、イベント、通信、アクセシビリティツリーで答え合わせします。
著者が定義した元の画面条件では、ボタンはクリック処理からリクエストを送る一方、送信中状態を持たず、状態表示領域は DOM にありません。これは実製品を DevTools で測った結果ではありません。診断用の差分は新しい可視領域を挿入します。CSS だけで直そうとせず、クライアント／サーバー／アクセシビリティの状態所有者を表にします。サーバーログは DevTools で直接観察したものとせず、別の権限・出所を持つ根拠として参照します。
6 人を対象にする前の確認条件
イベント未発火、DOM 欠落、状態機械の矛盾は、まず実装監査と自動テストで確かめられます。状態の理解、再押下、結果不明からの回復は、人の行動を見る価値があります。
人を対象にする場合は、目的、募集条件、タスク、成功・中止、介入、同意媒体、データ保持、撤回、権力関係、組織審査を先に通します。本ケースでは値が未確定なので、収集許可は未確定です。実アカウントや本番環境へ接続せず、障害注入は架空環境だけで行います。
観察計画は無発話条件で最初の再押下、状態説明、回復操作を記録し、発言は終了後に聞きます。募集条件、タスク、成功／中止、ヘルプ、条件の割り付け、順序、分析単位、分母、欠測、反証条件を実施前に固定します。参加者数はリスク、利用者の多様性、目的、推定精度から決め、「5 人」を普遍ルールにしません。
7 判断記録で閉じずに区切る
| 欄 | P4-D01 |
|---|---|
| 観察 | 画面記録では送信前後 500ms で可視差なし。操作可能性と支援技術への状態通知は監査前不明 |
| 技術的な根拠 | 著者定義の元の画面条件では送信中状態と状態表示 DOM なし。実測結果ではない |
| 介入 | 診断用 P4-C01-DISPATCH-VISIBLE。公開候補は状態機械 P4-SM01 |
| 譲れない確認条件 | 重複業務処理を防ぐ。状態を知覚可能にする。実データを使わない |
| あり得る結果 | 支持、混合、変化なし、操作不成立、悪化 |
| 判断責任者 | プロダクトオーナー。アクセシビリティ、セキュリティ、運用責任者の承認を別記 |
| 公開 | 確認条件未達なら非公開。限定公開時は対象と期限を明記 |
| 監視 | 重複リクエスト、結果不明、サポート到達、支援技術での状態検査 |
| 取り消し／再開 | 重複処理、回復不能、重大な状態通知不全で取り消し。問い合わせ増加で再開 |
| Unknowns | 低速回線、再訪、別言語、支援技術組合せ |
反復は「改善するまで続ける」ではありません。十分な根拠で公開する、リスクのため止める、変更を戻す、問いを保留する、別の責任者へ渡す、という区切りを含みます。第25章ではこの判断を自分のループへ戻しました。本ケースでは、次の担当者が記録条件、出自、未確認事項、確認条件を再現できる形で渡すことを成果とします。
問い
- 最初の記述のどこが観察で、どこが評価ですか。
- 五つの仮説を見分ける最小の根拠は何ですか。
P4-C01-DISPATCH-VISIBLEで固定すべき条件は何ですか。- ブラウザと DevTools だけで結論できる問い、人を見る必要がある問いを分けてください。
- どの条件なら公開せず、どのシグナルで問いを再開しますか。
答えの例
「押せたか分からない」は評価を含みます。送信前後で可視差がないことは画面記録で確認でき、クリック発火や支援技術への状態通知は別の根拠です。まずイベントと通信を監査し、操作成立を確かめます。見えるフィードバックの仮説には、クライアントから送信した直後の「送信しています」という可視差だけを変える比較を使い、「受付済み」とは表示しません。
画面条件の仕様で状態表示 DOM が存在しないことは、人を呼ばずに仕様検査できます。一方、その変更で再押下や状態理解が変わるかは、適切な倫理・プライバシー確認の後に行動を観察します。診断用の差分自体は公開せず、状態機械 P4-SM01 で支援技術への状態通知、二重送信防止、結果不明からの回復を満たさなければ公開確認を通しません。
別の答え方
業務上、受付直後に取消できることが最重要なら、再押下より取消への到達を主な結果にできます。その場合も、タスク目的とリスクが違うことを明記し、同じ結果表へ混ぜません。
よくある考え方
フィードバックがないのでスピナーを付ける。
注意点
スピナーは処理中を表す候補ですが、受付、結果不明、再照会、回復を区別しません。イベント未発火や重複処理も直しません。変更前に、どの状態を誰へ伝えるかを定めます。
セルフチェック
- 記録条件と根拠の層を残した
- 観察、解釈、評価を分けた
- 最低二つの代替仮説と反証条件を残した
- 診断用の差分と完成案を分けた
- 一度に一条件を動かした
- 画面、コード、人から得た根拠を代用しなかった
- 人を対象にする前に倫理・プライバシー確認を通した
- 公開、保留、非公開、取り消し、再開条件を記録した
参考
本ケースは第 19〜25 章の根拠メモと図版設計を参照する。特に ISO 9241-210、ISO 9241-11、WCAG 2.2、WAI-ARIA 1.2、HTML、CSSOM View、ResizeObserver、コンテナクエリ、NISTIR 7741 を、各主張の適用範囲とともに確認する。