本記事は、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

シリーズ内リンク