本記事は、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 品質バックログ