【ISTQB /JSTQB ALTM 3.0解説】アジャイルチームにおける欠陥管理（Defect Management in Agile Teams）

アジャイル開発では「ドキュメントを最小限にし、価値ある成果物を最大限に生み出す」ことが重要な原則です。

しかし、**欠陥管理（Defect Management）**においてもドキュメントを減らして良いのか？という疑問を持つ人も多いでしょう。

本記事では、ISTQB Test Manager v3.0（Chapter 2.3.3）の内容をもとに、アジャイル開発における欠陥管理の特徴と、実務でのベストプラクティスをわかりやすく解説します。

✅ アジャイル開発における欠陥管理の基本的な考え方

アジャイル開発では、ウォーターフォールのように「正式な欠陥レポート」を逐一書くことはあまり行いません。

なぜなら、チーム内の密なコミュニケーションと短いスプリントサイクルによって、欠陥を即座に共有・修正できるからです。

たとえば、開発チームとテストチームが同じ部屋（コロケーション環境）にいる場合、

テスターが「この画面、表示が崩れてます」と声をかけ、開発者がすぐに修正する ― これで完結することが多いのです。

こうしたケースでは、欠陥チケットをわざわざ発行するよりも、リアルタイムで修正する方が効率的です。

ただし、アジャイルでも「すべて口頭」で済ませてしまうのは危険です。

管理や品質改善の観点から、一定の欠陥は正式に記録する必要があります。

以下のようなケースでは、軽量な欠陥レポートを残すのが推奨されます。

このような欠陥は、**「軽量なドキュメント」**として簡潔にまとめればOKです。

具体的には以下の項目を記録すれば十分です。

修正が間に合わなかった欠陥は、**プロダクトバックログ（Product Backlog）へ追加します。

バックログに登録することで、次回スプリントで他のストーリーやタスクと一緒に優先順位づけ（Prioritization）**が可能になります。

例：

「スプリント3」で発見したUIバグを「スプリント4」のバックログに登録し、開発チームが次回プランニング時に修正を組み込む。

アジャイルにおいて、欠陥管理の形式（どこまでドキュメント化するか）は状況により異なります。

以下の要素によって「軽量化」できる度合いが変わります。

要素	欠陥管理の影響
👥 チームの位置関係（コロケーションか分散か）	同じ場所なら口頭共有で十分、リモートならドキュメント必須
🌍 タイムゾーンの違い	時差がある場合、文書共有が不可欠
🧩 チーム数	1チームなら軽量でOK、複数チームなら追跡のために記録が必要
📚 チームの成熟度	新人が多いチームではドキュメントが教育・品質維持に役立つ
⚖️ 製品のリスクレベル	医療・金融など高リスク領域では形式的記録が求められる
🤝 契約・法的要件	規制遵守のために欠陥報告の証跡が必要

アジャイルでも、「欠陥をどのように扱うか」はチームで明確にルール化しておく必要があります。

これにより、チームメンバーが入れ替わっても、欠陥管理プロセスを一貫して運用できます。

アジャイル開発における欠陥管理は、**「形式ではなく効果」**を重視します。

ドキュメントを最小限にしながらも、品質を可視化する“ちょうどよいバランス”を見つけることが、テストマネージャーの重要な役割です。