リリース前QAチェックリストを作る

まず確認する症状

• LPコピー修正でフォームや計測が壊れる。
• レポート表示変更でzipやtasks.jsonとの整合が崩れる。
• レビュー所見は理解できるが、開発者やコーディングエージェントが触る範囲と完了条件を判断できない。
• 修正、検証、再スキャン、残課題化の流れが分かれておらず、1つの大きな依頼になっている。

なぜ問題か

• 小さく速いリリースでも、壊れやすい契約を固定すると負債が溜まりにくくなります。
• チェックリストは人間とコーディングエージェントの両方が使える運用資産になります。
• AI実装では、曖昧な改善案よりも、対象、制約、受け入れ条件、検証コマンドが揃った小さなタスクが成功しやすくなります。
• 成果物をMarkdownやJSONで残すと、別の人や別のエージェントが途中から再開しやすくなります。

診断で見る指標

修正方法

受け入れ条件

1. 01PCとスマホの両方で目視確認し、主なCTAまたは操作対象が迷わず見つかる。
2. 02キーボード操作、読み上げ補助、または自動検査で再発しやすい項目を確認する。
3. 03修正後にui.designで再スキャンし、同じ所見が残る場合は原因を分解する。
4. 04各タスクに、目的、対象、変更内容、非目標、受け入れ条件、確認コマンドまたは確認手順がある。
5. 05修正後に、解消した所見、残った所見、新しく出た所見、確認不能な所見を分けて記録している。
6. 06リリース前チェックは、自動で見るもの、目視で見るもの、実ジョブで見るものに分かれている。
7. 07Scan、結果表示、Learnリンク、Review Pack、account、billingのような壊れやすい導線が対象に含まれている。

参考資料

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

よくある失敗

• 毎回全部を詳細レビューしようとして、運用が続かない。
• 見た目だけを整え、見出し、リンク、フォームラベルなどの意味構造を直さない。
• 1つの指摘だけを直し、同じ原因から出た別画面の再発を確認しない。
• 広すぎる一括依頼をAIへ渡し、関係ないリファクタリングやUI変更を混ぜる。
• 結果JSON、report.md、tasks.json、証跡画像のどれを正として見るか決めない。

関連ページ