結論から書きます。アジャイル開発におけるQAの仕事は「品質を保証しきること」ではなく、「品質について考え続けられる状態をチームに作ること」です。
アジャイル開発とQAは相性が悪いと思われがちです。スプリントが短く、仕様も変わり続ける中で「QAは何をすればいいのか分からない」「テストが追いつかない」「結局、最後にまとめて確認するだけになっている」と感じている方も多いかもしれません。
私自身、アジャイル開発の現場でQAとして関わってきましたが、最初は同じように戸惑いました。ただ、いくつかの前提を共有し、判断軸をはっきりさせることで、QAの立ち位置はかなり整理できます。
この記事では次の3点を扱います。
- アジャイル開発においてQAは何を担う存在なのか
- なぜ従来型のQAのやり方がうまくいかなくなりやすいのか
- 現場で無理が出にくかったQAの取り組み方
スポンサーリンク
判断軸：品質は「後工程」ではなく「チームの継続能力」
最初に、この記事全体で使う判断軸を明示します。
アジャイル開発における品質は、「バグが少ないかどうか」ではなく「チームが継続的に価値を届けられる状態かどうか」という前提に立ちます。
これは思いつきではありません。アジャイルソフトウェア開発宣言の背後にある12の原則には、「技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます」という項目があります。 品質を落として速く進むのではなく、品質を保つことが速さの条件だという立場です。
スクラムであれば、これは「完成の定義（Definition of Done）」として明文化されます。スクラムガイドでは、完成の定義はプロダクトバックログアイテムがプロダクトの品質基準を満たしたときの状態を表す正式な記述とされています。「どこまでやったら終わりか」がチームの合意として存在する点が重要です。
この前提に立つと、QAの役割も変わります。
| 従来のイメージ | アジャイルでの実態 |
|---|---|
| テスト工程を担当する人 | 品質が破綻しにくい進め方をチームと作る人 |
| バグを見つける専門職 | 品質リスクを見える化する人 |
| 最後に検査する人 | 完成の定義そのものに関わる人 |
アジャイルで従来型QAが苦しくなりやすい理由
個人の能力不足ではなく、前提のズレによるものがほとんどです。
「仕様が固まってからテストする」前提が崩れる
ウォーターフォール型では、要件定義 → 設計 → 実装 → テスト という流れが比較的明確でした。QAは「仕様が固まった後」に品質を確認すればよかった。詳しくはウォーターフォール開発におけるQAの重要性に書いています。
一方、アジャイルでは次のことが普通に起きます。
- 仕様がスプリント中に変わる
- 仮説検証のためにあえて荒く作る
- 次のスプリントで方向転換する
この中で「仕様が固まるのを待ってからテストしよう」とすると、QAは常に後手に回ります。
QA＝テスト担当、という期待が残り続ける
もう一つはチーム内の認識です。「QAがいるから品質は大丈夫」「バグはQAが見つけるもの」——こうした期待が残っていると、こうなります。
- 開発者のセルフチェックが弱くなる
- QAに確認が集中する
- スプリント終盤がテスト地獄になる
アジャイルの前提と、QAに向けられている期待が噛み合っていないケースは、思っている以上に多いと思います。
スポンサーリンク
アジャイルQAの本質的な役割は「品質リスクの見える化」
現場で一番しっくりきたQAの役割は、品質リスクを早く、分かりやすくすることでした。
すべてをテストしきらない前提に立つ
アジャイルでは「全部テストしてから出す」という考え方自体が現実的でないことが多いです。そのためQAは、次のリスクの整理を優先します。
- どこが壊れやすそうか
- どこがユーザー影響が大きいか
- 今回はどこまで保証できているか
私の場合、スプリント計画の段階から「ここは仕様が曖昧なので注意が必要そうです」「ここは前回も不具合が出やすかったです」と、早めに共有していました。
テスト結果より「判断材料」を渡す
QAが出すべきものは「OK / NG」だけでは足りません。
- どの観点は見られていて
- どの観点はまだ不安が残っているか
この情報があるだけで、リリース判断やスコープ調整がしやすくなります。品質を守るというより、品質について考える材料を揃える感覚です。
この考え方をE2Eテストに落とし込んだものがE2Eテストの品質基準です。
「何をどこまでやるか」の地図：アジャイルテストの4象限
QAの担当範囲を決めるとき、私は「アジャイルテストの4象限」を下敷きにしています。 Brian Marick が提唱し、Lisa Crispin と Janet Gregory が『実践アジャイルテスト』で体系化した枠組みです。
| 象限 | 軸 | 内容 | 自動化 |
|---|---|---|---|
| Q1 | 技術面 × チーム支援 | 単体テスト、コンポーネントテスト、APIテスト | ほぼ全部 |
| Q2 | ビジネス面 × チーム支援 | 機能テスト、受け入れ条件の検証 | できる範囲で |
| Q3 | ビジネス面 × 製品批評 | 探索的テスト、ユーザビリティ、UAT | 人がやる |
| Q4 | 技術面 × 製品批評 | 性能、負荷、セキュリティ | ツールで |
この図が役に立つのは、「QAは全部を見る人ではない」と説明できるからです。 Q1は開発者の領域で、QAが肩代わりするものではありません。QAの価値が最も出るのはQ3の探索的テストで、ここは自動化できません。
「QAに全部お願いします」と言われたときは、この4象限を見せて分担を話すのが早いです。感情論にならずに済みます。
スポンサーリンク
実務で効果があったQAの取り組み方
スプリント前半からQAが関与する
テスト工程を後ろに置くのではなく、次に早めに関わります。
- 要件の確認
- 受け入れ条件のすり合わせ
- 想定される異常系の洗い出し
これだけで、後半の手戻りはかなり減りました。「テストのため」ではなく「作る前に壊れにくくするため」の関与です。
とくに受け入れ条件のすり合わせは、テスト設計とほぼ同じ作業です。実装が始まる前に「これはどうなれば正しいのか」を詰めておくと、あとで揉めません。
テスト設計を“軽く”共有する
詳細なテストケースを完璧に作るより、次を簡単なメモや口頭で共有するほうがうまく回ることも多かったです。
- どんな観点で見るか
- 何を今回は捨てているか
「捨てているもの」を明示するのが効きます。 見ていない範囲が共有されていれば、開発者側も「どこに注意すればいいか」が分かります。
自動化は「守りたいところ」から
「全部自動化しよう」とすると失敗しやすいです。私は次を優先していました。
- 毎回触るところ
- 壊れると影響が大きいところ
自動化は目的ではなく、チームの継続性を守るための手段という位置づけが無難です。何をE2Eで自動化するかの判断軸はE2Eで「守るべきもの」はこう決めるにまとめました。
QAがいることでチームが楽になる状態を目指す
アジャイル開発におけるQAの価値は「バグを見つけた数」では測れません。 次のような変化が出ていれば、QAは機能している可能性が高いと思います。
- リリース判断がしやすくなった
- 品質の話が感情論になりにくくなった
- スプリント終盤の緊張感が減った
私自身、「QAがいると安心して進められる」と言われたときに、この役割の意味が腹落ちしました。
まとめ
- アジャイルQAの目的は「品質を保証しきる」ことではなく「品質について考え続けられる状態を作る」こと
- アジャイル宣言の原則には「技術的卓越性と優れた設計に対する不断の注意が機敏さを高める」とある
- スクラムなら完成の定義（Definition of Done）が品質基準の合意になる
- 従来型が苦しくなるのは「仕様が固まってからテスト」という前提が崩れるから
- QAの中心業務は品質リスクの見える化。OK/NGではなく判断材料を渡す
- 分担の説明にはアジャイルテストの4象限が使える。QAの本領はQ3の探索的テスト
- スプリント前半で受け入れ条件をすり合わせるだけで手戻りが減る
- テスト設計は「何を捨てたか」を共有するほうが効く
- 自動化は守りたい領域から。全部やろうとしない
全部を守ろうとすると、QAが苦しくなります。判断軸を共有し、リスクを言語化し、チームと一緒に考える立場に立てば、アジャイルとQAはそこまで相性が悪いものではありません。
「アジャイル開発でQAとして何をすればいいか分からない」と感じているなら、まずはテストの量より関わるタイミングと視点を変えてみるのが安全だと思います。
