受け入れ条件で修正完了を判定する

まず確認する症状

• 修正したが、どの状態なら完了かチームで判断が分かれる。
• 再スキャンで所見が残ったとき、仕様の問題か誤検出か分からない。
• レビュー所見は理解できるが、開発者やコーディングエージェントが触る範囲と完了条件を判断できない。
• 修正、検証、再スキャン、残課題化の流れが分かれておらず、1つの大きな依頼になっている。

なぜ問題か

• 完了条件が曖昧だと、自動開発でも人間レビューでも手戻りが増えます。
• 証跡画像、所見、テスト、計測を同じ基準で見るとPDCAが回ります。
• AI実装では、曖昧な改善案よりも、対象、制約、受け入れ条件、検証コマンドが揃った小さなタスクが成功しやすくなります。
• 成果物をMarkdownやJSONで残すと、別の人や別のエージェントが途中から再開しやすくなります。

診断で見る指標

修正方法

受け入れ条件

1. 01PCとスマホの両方で目視確認し、主なCTAまたは操作対象が迷わず見つかる。
2. 02キーボード操作、読み上げ補助、または自動検査で再発しやすい項目を確認する。
3. 03修正後にui.designで再スキャンし、同じ所見が残る場合は原因を分解する。
4. 04各タスクに、目的、対象、変更内容、非目標、受け入れ条件、確認コマンドまたは確認手順がある。
5. 05修正後に、解消した所見、残った所見、新しく出た所見、確認不能な所見を分けて記録している。
6. 06各受け入れ条件は、誰が見ても合否を判断できる具体的な状態になっている。
7. 07自動テスト、目視、再スキャン、計測のうち、どれで確認するかが条件ごとに決まっている。

参考資料

• llms.txt proposal
• Chrome Lighthouse: llms.txt
• W3C WCAG 2.2 Techniques

よくある失敗

• テストが通ることだけを完了条件にし、実際の画面確認を省く。
• 見た目だけを整え、見出し、リンク、フォームラベルなどの意味構造を直さない。
• 1つの指摘だけを直し、同じ原因から出た別画面の再発を確認しない。
• 広すぎる一括依頼をAIへ渡し、関係ないリファクタリングやUI変更を混ぜる。
• 結果JSON、report.md、tasks.json、証跡画像のどれを正として見るか決めない。

関連ページ