本記事は、CodeZine連載「QA to AQ：アジャイル品質パターンによる、伝統的な品質保証からアジャイル品質への変革」を補助する副読本として、実例と運用手順を加筆した実践ガイドです。
本文は独自解説を主とし、引用は必要最小限に絞っています（図版は原則自作運用を想定）。
0. この記事の狙い
アジャイル開発をしていても、品質活動だけは最後に寄りがち。
結果として、スプリント終盤にテストと手戻りが集中し、チーム全体の速度と信頼が同時に落ちる。
この問題に対して、今回は次の2パターンをセットで扱う。
- QAを含むOneチーム
- 品質スプリント
ポイントはシンプル。
- QAを「後工程の受け皿」から「設計段階の参加者」に変える
- 品質作業を「別働隊のイベント」から「通常スプリントと接続した運用」に変える
1. 前提（誰向けか）
この回は、以下のメンバーが同じ会話をするための記事。
- PO
- EM
- 開発メンバー
- QA
- SRE/運用
「QAチームだけ頑張る」前提ではない。
開発チーム全体で品質を設計する前提で読むと刺さる。
2. まず押さえる原典の要点（最小引用）
QA to AQの説明として、以下の趣旨は超重要。
「品質の確保は専門家が担うという従来の考え方から脱却し、チーム全体で取り組むことが必要となる」
出典: パターンQA to AQによる Agile Quality（アジャイル品質）への変革と事例
https://www.veriserve.co.jp/asset/approach/column/agile/agile02.html
これを実装レベルに落とすと、次の2つになる。
- チーム編成にQAを最初から織り込む（Oneチーム）
- 品質作業をスプリント運用に統合する（品質スプリント）
補足: Scrum and XP from the Trenches から見た実務の勘所
古典だけど、ここは今でも効く。
- 内部品質（保守性、テスト、可読性）は交渉対象にしない
- チームはバーンダウンを持ち、速度を把握する
- スプリント中の外乱を抑え、タイムボックスを守る
つまり、QA to AQで言う「チーム全体で品質を担う」は、
運用の根っこで Scrum and XP from the Trenches と繋がってる。
3. 失敗しやすいアンチパターン
アンチパターンA: QAがスプリントの外にいる
- 計画会議で品質観点が入らない
- 実装後に品質要件が判明する
- テストが「後追い検査」になる
アンチパターンB: 品質スプリントが“後始末フェーズ”化する
- 本スプリントで作って、次スプリントで品質対応
- 不具合と負債の先送りが常態化
- ベロシティが見かけだけ上がる
アンチパターンC: KPIが“件数”しかない
- バグ件数だけ追う
- 早期検出・流出防止・自動化率が見えない
- 改善の打ち手が決まらない
4. Oneチームの実装方法（役割分担）
「全員が品質に責任を持つ」は正しい。
でも、それだけだと責任が拡散する。だから責務を明示する。
推奨RACI（最小セット）
| 活動 | PO | 開発 | QA | SRE |
|---|---|---|---|---|
| 品質目標の優先順位付け | A | C | C | C |
| 受け入れ基準の品質観点追記 | A | R | R | C |
| 自動テスト実装 | C | R | R | C |
| 非機能検証（性能/信頼性） | C | R | R | R |
| リリース判定 | A | C | R | R |
- R: 実行責任
- A: 最終責任
- C: 相談先
QAを「承認者だけ」にしないのがコツ。
QAは設計と実装に入る。
5. 品質スプリントを通常スプリントに接続する
品質スプリントを別建てで回すと、だいたい分断する。
なので、次の形を推奨。
5-1. 2レーン運用
各スプリントを2レーンで管理する。
- Featureレーン: 機能実装
- Qualityレーン: 品質改善・検証強化・自動化
5-2. 品質レーンのWIP制限
品質レーンのWIPを固定する（例: 2〜3）。
これで「品質タスクが無限に積まれる」を防ぐ。
5-3. DoD（Definition of Done）に品質項目を埋め込む
DoD例（最小セット）
- 主要受け入れ基準に品質観点を記述済み
- 単体・結合の自動テストがCIで成功
- 重大欠陥（Severity1/2）が0
- 監視/ログ確認ポイントを更新済み
さらに実務では、Done判定を曖昧にしないために、
「誰が了承したらDoneか」まで明示すると強い。
- 例: 「当該ストーリーは、担当テスタが受け入れ基準の充足を確認した時点でDone」
6. 30日導入プラン（そのまま使える）
Week 1: 見える化
- 直近3スプリントの品質課題を棚卸し
- 欠陥の流出箇所を分類（要件/設計/実装/テスト/運用）
- 現行DoDの品質項目を確認
成果物:
- 品質課題リスト（10〜20件）
- 流出マップ
Week 2: Oneチーム化
- 計画会議にQAを必須参加
- 各ストーリーに品質受け入れ基準を追記
- RACIを決定して公開
成果物:
- 更新済みテンプレート（ストーリー/DoD）
- RACI表
Week 3: 品質レーン開始
- 品質レーンを作成
- WIPを設定（2〜3）
- 品質タスクを毎日レビュー
成果物:
- スプリントボード（2レーン）
- 品質タスク運用ルール
Week 4: 計測と調整
- KPIを観測
- ボトルネックを1つだけ潰す
- 次スプリントへ改善を引き継ぐ
加えて、スプリント長の見直し議論は毎回やりすぎないのがコツ。
まずは固定（例: 2〜3週間）で数スプリント回して、
チームの「鼓動」を作ってから調整する。
成果物:
- KPIダッシュボード（簡易でOK）
- 次スプリント改善計画
7. KPI（まずはこの3つ）
KPI-1: リリース後欠陥密度
- 定義: リリース後欠陥数 / リリース機能量
- 目的: 流出の実態を把握
KPI-2: 欠陥検出リードタイム
- 定義: 欠陥混入時点〜検出時点までの時間
- 目的: 早期検出能力の確認
KPI-3: 自動テスト実行率
- 定義: 自動実行されたテストケース数 / 全対象ケース数
- 目的: 品質活動の再現性を確保
※ バグ件数単体では改善判断が弱い。
「流出」「早期検出」「再現性」の3軸で見ると打ち手が決まりやすい。
8. ミニケース（よくある現場）
Before
- QAはスプリント終盤から参加
- ストーリーに品質受け入れ基準がない
- リリース前に手動テストが詰まる
After（4スプリント後）
- QAが計画会議から参加
- 主要ストーリーに品質基準を追加
- CIで品質ゲートを運用
- リリース前の手動検証工数が減少
ここで効いたのは、派手な仕組みじゃなくて、
- 役割の固定（RACI）
- 品質レーン
- DoDの更新
この3点。
9. すぐ使えるテンプレ
9-1. ストーリー追記テンプレ
### 品質受け入れ基準
- [ ] 応答時間: p95 <= 300ms
- [ ] 主要画面でアクセシビリティ違反（重大）0件
- [ ] 失敗時のログにトレースIDを出力
9-2. 品質タスクテンプレ
[Quality] Checkout API の負荷テストをCIに統合
- 目的: p95遅延の早期検出
- 完了条件:
- [ ] 負荷シナリオ追加
- [ ] しきい値超過時にCI失敗
- [ ] ダッシュボード表示
10. まとめ
Oneチームと品質スプリントは、スローガンじゃなく運用設計の話。
特に効くのはこの順番。
- QAを計画段階に入れる
- 品質レーンを常設する
- DoDとKPIを更新する
これで、品質は「最後に検査するもの」から「日々設計するもの」に変わる。
次回予告
次回は、今回の運用をさらに安定化するための
**「品質バックログ」**を扱う。
「機能バックログに飲み込まれない品質課題の管理方法」を実務テンプレ付きで整理する。
参考文献
- 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 - Qiita ヘルプ: 著作物を引用する際の注意点
https://help.qiita.com/ja/articles/about-copyright - Scrum and XP from the Trenches（英語原典）
http://infoq.com/minibooks/scrum-xp-from-the-trenches
シリーズ内リンク
- 次回: #2 品質バックログ