本記事は、CodeZine連載「QA to AQ」の副読本として、現場で回る実装手順に寄せて再構成したもの。
本文は独自解説を主とし、引用は必要最小限に絞っています（図版は原則自作運用を想定）。
0. 今回のゴール
前回は「QAを含むOneチームと品質スプリントの“儀式化”を防止する」を扱った。
今回はその続きで、品質活動を継続するための中核になる品質バックログを作る。
狙いは1つ。
- 品質課題を「気づいた人の善意」から「チームの計画対象」に変える
1. なぜ品質バックログが必要か
ありがちな失敗はこれ。
- 品質課題がSlackで流れて終わる
- リファクタやテスト改善が毎回後回し
- リリース前だけ品質タスクが急増
機能バックログだけで回していると、短期価値に寄る。
だから、品質課題を明示的に積む場所が必要。
2. 品質バックログの最小定義
品質バックログは、次を満たせばスタートできる。
- 目的: 品質劣化の予防と回復
- 単位: 1〜3日で完了できる粒度
- 優先軸: リスク × 影響度 × 回収容易性
品質バックログ項目テンプレ
[Quality] APIタイムアウト時の再試行戦略を統一
- 背景: タイムアウト時のエラー率上昇
- リスク: 中
- 影響: 決済失敗増
- 完了条件:
- [ ] 再試行ポリシー定義
- [ ] 統合テスト追加
- [ ] 監視アラート閾値更新
3. 機能バックログとの関係
別管理にするか、同一ボードに混ぜるかは議論になりやすい。
現場で壊れにくいのは次。
- 管理は同じボード
- 種別で
Feature/Qualityを明示 - スプリント計画で品質比率を固定（例: 20%）
これで「品質だけ別世界」を防ぎつつ、
「品質が無限後回し」も防げる。
補足として、Scrum and XP from the Trenches でも「プロダクトオーナが見積済みバックログを所有する」ことが強調される。
品質バックログも同じで、優先順位と説明責任の置き場を曖昧にしないのが肝。
4. 優先順位の付け方（実践手順）
数式より、最初はこの3軸で十分。
- Risk（再発・流出リスク）
- Impact（ユーザー/事業影響）
- Cost（実装コスト）
優先度スコア例:
$$
Priority = Risk \times Impact \div Cost
$$
5段階評価でも回る。
重要なのは「誰の主観か」を減らすこと。
5. 2週間スプリントへの埋め込み
ルール
- 各スプリントの品質枠を最初に予約
- 品質枠を機能都合で使い切らない
- 品質項目にもDoDを適用
例（2週間）
- 1〜2件: 予防（テスト自動化、監視）
- 1件: 是正（既知欠陥の根本対応）
- 1件: 負債返済（設計/依存更新）
6. 失敗パターンと回避
失敗1: 品質バックログが“ゴミ箱”化
- 症状: 粒度バラバラ、完了条件なし
- 対策: 完了条件を必須化
失敗2: 毎回、機能優先で品質0件
- 症状: 3スプリント連続で品質消化0
- 対策: 品質比率のガードレールを固定
失敗3: QAしか更新しない
- 症状: 開発メンバーが品質課題を起票しない
- 対策: ふりかえり時に全員1件起票ルール
7. 30分でできる初期導入
- 直近インシデントを5件集める
- 根本原因を分類（要件/設計/実装/運用）
- 改善タスクを品質バックログ化
- 次スプリントに2件だけ入れる
最初から完璧を狙わない。
「積む→消化→学ぶ」を回す。
8. KPI（この回の重点）
- 品質バックログ消化率
- 品質起因インシデント再発率
- 品質タスクのリードタイム
「件数」より「再発率」を重視すると、改善が前に進む。
9. まとめ
品質バックログは、品質活動を“善意”から“計画”に変える装置。
運用のコアは次の3点。
- 種別を明示する
- 品質比率を固定する
- 完了条件を必須にする
次回予告
次回は、品質バックログを回す時に効く
**「品質チェックリストと品質作業の分散で『QA依存』から脱却する」**を扱う。
参考文献
- 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