本記事は、CodeZine連載「QA to AQ」の副読本として、現場で回る実装手順に寄せて再構成したもの。
本文は独自解説を主とし、引用は必要最小限に絞っています（図版は原則自作運用を想定）。
0. 今回のゴール
品質バックログを作っても、実行がQAに偏ると失速する。
今回は次の2点を運用設計する。
- 品質チェックリスト
- 品質作業の分散
ゴールは、品質タスクを「誰か1人の職能」じゃなく、
チームの標準作業にすること。
1. 品質チェックリストの役割
チェックリストは「思考停止の手順書」じゃない。
目的は3つ。
- 抜け漏れ防止
- 新メンバーの立ち上がり短縮
- 議論の共通言語化
2. チェックリストは3層で作る
層A: 全機能共通
- 例: ログ、監視、権限、エラーハンドリング
層B: ドメイン共通
- 例: 決済、在庫、認証などの業務固有
層C: ストーリー固有
- 例: 今回の変更点だけに効く観点
この3層に分けると、肥大化しにくい。
Scrum and XP from the Trenches の文脈で言うと、これは「Done定義の具体化」を日常運用へ落とす作業でもある。
つまり、チェック項目は単なる確認表ではなく、完了判定の共通言語。
3. すぐ使える品質チェックリスト（雛形）
## 共通チェック
- [ ] エラー時にユーザーへ意味のあるメッセージを返す
- [ ] 主要処理にトレースIDを記録
- [ ] タイムアウト/リトライ方針が定義済み
- [ ] 認可漏れがない（権限境界を確認）
## 非機能チェック
- [ ] p95応答時間が基準以内
- [ ] 監視アラートがしきい値と一致
- [ ] 主要パスの自動テストがCIで成功
## ストーリー固有
- [ ] （ここに固有観点を書く）
4. 品質作業の分散（具体）
「全員で品質を見る」は抽象すぎる。
だから、タスクを分割して割り当てる。
分散対象
- 受け入れ基準の品質追記
- 自動テスト
- 観測性（ログ/メトリクス）
- 負荷/信頼性検証
- リリース判定材料の作成
1スプリントの割り当て例
- 開発A: 回帰自動化
- 開発B: 観測性整備
- QA: 受け入れ基準と探索観点
- SRE: 閾値設計とアラート
5. 失敗パターン
失敗1: チェックリストが長すぎる
- 50項目超えで誰も読まない
- 対策: 常時15項目前後に絞る
失敗2: 更新されない
- 作って終わり
- 対策: ふりかえりで毎回1項目見直す
失敗3: QAだけが運用する
- 対策: チェック担当をローテーション
6. 2週間で導入する手順
Day 1-2
- 直近障害3件を選ぶ
- 再発防止観点を抽出
Day 3-4
- 3層チェックリスト初版を作成
- DoDに組み込む
Day 5-10
- 実際のストーリーで試行
- チェック結果をPRに残す
Day 11-14
- 無駄項目を削除
- 漏れた観点を追加
7. 計測ポイント
- チェックリスト実施率
- レビュー差し戻し率
- 同種不具合の再発率
数値より先に、再発の種類が減っているかを観察する。
8. まとめ
品質チェックリストは、品質作業を分散するための土台。
効く運用はこの3つ。
- 3層で作る
- 担当を分散する
- 毎スプリント更新する
次回予告
次は、品質を曖昧語から抜け出すために
**「測定可能なシステム品質 + 着陸ゾーン」**を扱う。
参考文献
- CodeZine連載一覧: QA to AQ
https://codezine.jp/article/corner/813 - パターンQA to AQによる Agile Quality
https://www.veriserve.co.jp/asset/approach/column/agile/agile02.html - Scrum and XP from the Trenches（英語原典）
http://infoq.com/minibooks/scrum-xp-from-the-trenches
シリーズ内リンク
- 前回: #2 品質バックログ
- 次回: #4 測定可能なシステム品質 + 着陸ゾーン