Implementation
修正前後スキャンで改善を確認する
改善は主観だけで判断しません。修正前後の証拠を残し、同じURL・同じviewport・同じ重要導線で比較します。
ui.design: monitorui.design: report-quality
まず確認する症状
- 修正後にスコアが上がった理由や残課題が説明できない。
- 別条件のスキャンを比較してしまい、差分が信用できない。
- レビュー所見は理解できるが、開発者やコーディングエージェントが触る範囲と完了条件を判断できない。
- 修正、検証、再スキャン、残課題化の流れが分かれておらず、1つの大きな依頼になっている。
なぜ問題か
- Before/Afterは顧客への説明と内部PDCAの両方に必要です。
- 再スキャン差分があると、次の自動コーディングタスクを優先しやすくなります。
- AI実装では、曖昧な改善案よりも、対象、制約、受け入れ条件、検証コマンドが揃った小さなタスクが成功しやすくなります。
- 成果物をMarkdownやJSONで残すと、別の人や別のエージェントが途中から再開しやすくなります。
診断で見る指標
同一URL
同一viewport
所見数差分
ロードマップ残数
スクショ証跡
対象URL/画面/コンポーネント
非目標と触らない範囲
自動検査と目視確認
再スキャン結果
残課題Issue化
同一条件比較
解消/残存/新規所見
証拠画像
差分サマリー
次Issue
修正方法
最小修正
修正前の成果物を保存する
result.json、report.md、スクショ、tasks.jsonを保存します。
推奨修正
同条件で再スキャンする
URL、ページ数、ログイン状態、viewport、wait条件を揃えます。
さらに改善
残課題を次スプリントへ送る
未解決所見を、原因クラスタと修正ガイド付きで次のIssueへ移します。
受け入れ条件
- 01PCとスマホの両方で目視確認し、主なCTAまたは操作対象が迷わず見つかる。
- 02キーボード操作、読み上げ補助、または自動検査で再発しやすい項目を確認する。
- 03修正後にui.designで再スキャンし、同じ所見が残る場合は原因を分解する。
- 04各タスクに、目的、対象、変更内容、非目標、受け入れ条件、確認コマンドまたは確認手順がある。
- 05修正後に、解消した所見、残った所見、新しく出た所見、確認不能な所見を分けて記録している。
- 06Before/Afterは同じURL、viewport、ログイン状態、待機条件で比較している。
- 07差分は、解消、残存、新規、比較不能に分かれ、次に直すタスクへ接続されている。
コーディングエージェント向け修正指示
目的: 修正前後のscan成果物を比較し、解消した所見、残った所見、新規に出た所見を分けてください。比較条件が違う場合は差分判断を保留してください。 追加確認: 再スキャン結果をスコアだけで判断せず、所見、証跡画像、report.md、tasks.jsonを突き合わせてください。
参考資料
よくある失敗
- 別ページや別viewportの結果を改善証拠として扱う。
- 見た目だけを整え、見出し、リンク、フォームラベルなどの意味構造を直さない。
- 1つの指摘だけを直し、同じ原因から出た別画面の再発を確認しない。
- 広すぎる一括依頼をAIへ渡し、関係ないリファクタリングやUI変更を混ぜる。
- 結果JSON、report.md、tasks.json、証跡画像のどれを正として見るか決めない。