開発とテストを統合する前提として
前回の記事（第1回：「スプリントが終わってもテストが終わらない」をなぜ繰り返すのか）では、スプリント内でテストが終わらない根本原因として、開発とテストのチーム体制の分断を取り上げました。
そして解決策として「開発とテストを一つの活動として統合する」という方向性を示しました。
しかし、この統合を進める前に、一つ重要な問いがあります。
自分たちのチームは、今どんなテスト活動を行っているのか。
そして、それで十分なのか。
全体像を把握せずに統合を進めると、「やっているテストはあるが、何かが足りない」という状態が続きます。
今回は、テスト活動の全体像を整理するフレームワーク——アジャイルテストの4象限を紹介します。
4象限とは何か
アジャイルテストの4象限は、Brian Marickが提唱し、Lisa CrispinとJanet Gregoryが著書『Agile Testing』で体系化したフレームワークです。テスト活動を「誰のためのテストか」と「何を目的とするテストか」の2軸で整理します。
縦軸は「ビジネス面のテスト（Business-facing）」と「技術面のテスト（Technology-facing）」。
横軸は「チームを支援するテスト（Team-facing）」と「製品を批評するテスト（Product-facing）」。
この2軸の組み合わせで、4つの象限が生まれます。
Q1——技術面・チームを支援するテスト
ユニットテスト、コンポーネントテスト、APIテストがここに入ります。
開発者が実装しながら行うテストで、コードが正しく動いているかを素早く確認します。
目的: 開発中のフィードバックを速くする。不具合を実装直後に検出し、修正コストを最小化する。
主な担い手: 開発者
特徴: 自動化が前提。CI/CDパイプラインに組み込まれ、コードの変更のたびに実行される。
Q1のテストが充実していると、開発者は「自分のコードが壊れていないか」を毎回確認しながら安心して実装を進められます。逆にQ1が薄いチームは、不具合の発見が後ろにずれ込み、修正コストが高くなります。
Q2——ビジネス面・チームを支援するテスト
機能テスト、ストーリーテスト、プロトタイプ検証がここに入ります。
「ビジネスの観点から見て、正しいものを作っているか」を確認するテストです。
目的: 受け入れ基準の充足確認。開発したものが、顧客・事業が期待することを満たしているかを検証する。
主な担い手: 開発者とテスト担当者が協力して設計。プロダクトオーナーや顧客も関与する。
特徴: スプリントプランニングやリファインメントの段階から設計を始めることで、開発の方向性のズレを早期に防ぐ。
Q2が機能するチームでは、「開発完了したが要件を満たしていなかった」という手戻りが減ります。受け入れ基準をテストとして明文化しておくことで、「何ができていれば完了か」がチーム全体で共有されます。
Q3——ビジネス面・製品を批評するテスト
探索的テスト、ユーザビリティテスト、ユーザー受け入れテスト（UAT）がここに入ります。
仕様書や受け入れ基準からは見えてこない、「実際に使ったときの問題」を発見するテストです。
目的: 製品の品質を批評的な目線で評価する。ユーザーの立場から見たときの使いにくさ、想定外の操作への対応、実際の使用場面での問題を発見する。
主な担い手: テスト担当者、UXデザイナー、顧客・エンドユーザー
特徴: 事前にテストケースを決め切るのではなく、テスト担当者の経験と判断を活かしながら探索的に行う。自動化になじみにくい領域。
Q3は「作ったとおりに動くか」ではなく「使えるか、価値があるか」を問うテストです。Q1・Q2が充実していても、Q3を省くと、ユーザーが実際に使う場面での問題が見つからないまま本番に出てしまいます。
Q4——技術面・製品を批評するテスト
パフォーマンステスト、負荷テスト、セキュリティテスト、信頼性テストがここに入ります。
機能の正しさではなく、システムの非機能的な品質を評価するテストです。
目的: 本番環境で製品が期待どおりに動き続けるかを確認する。速度・スケーラビリティ・安全性・耐障害性を検証する。
主な担い手: テスト担当者、インフラエンジニア、セキュリティ専門家
特徴: 専用ツールを使った自動化が有効。本番に近い環境で実施する必要があるため、CI/CDへの組み込みとは別途の仕組みが必要になることが多い。
Q4は後回しにされがちですが、本番リリース直前や大きな機能追加のタイミングで突如クリティカルな問題を引き起こします。「動く」と「使えるレベルで動き続ける」は別の問題です。
自社のテスト活動を4象限に当てはめてみる
4象限を理解するだけでなく、「自分たちのチームのテスト活動が今どこに集中しているか」を可視化することで、テスト戦略の偏りと空白地帯が見えてきます。
以下の問いに答えてみてください。
Q1の問い（技術面・チームを支援する）
- ユニットテストやコンポーネントテストを書いていますか？
- テストはCIで自動実行されていますか？
- テストカバレッジに意識的な基準がありますか？
Q2の問い（ビジネス面・チームを支援する）
- スプリントプランニングの段階で「何をどうテストするか」を議論していますか？
- 受け入れ基準はテストとして明文化されていますか？
- 「開発完了」の定義にテスト完了が含まれていますか？
Q3の問い（ビジネス面・製品を批評する）
- テスト担当者がユーザーの立場で探索的にテストする時間はありますか？
- 実際のユーザーや顧客が製品を試す機会はありますか？
- 仕様書にない問題を発見する仕組みがありますか？
Q4の問い（技術面・製品を批評する）
- パフォーマンスや負荷に関するテストを定期的に行っていますか？
- セキュリティの脆弱性を確認する仕組みはありますか？
- 本番環境に近い条件でのテストができていますか？
「Yes」が少ない象限が、自チームのテスト戦略の空白地帯です。すべての象限を均等に充実させる必要はありませんが、空白地帯を意識せずに放置することは、テスト戦略を持たないことと同義です。
4象限が示すこと——テストは「工程」ではなく「活動の集合体」
4象限を見て気づくことがあります。テストは決して「開発の後に行う一つの工程」ではありません。
Q1は開発中に行われる。Q2はスプリントの始めから設計される。Q3は開発が完了した後に探索的に行われる。Q4はリリース前後も含めて継続的に実施される。
テスト活動はスプリント全体に、そしてプロダクトのライフサイクル全体に広がっています。
開発とテストの統合を進めるとは、これらのテスト活動を「テストチームが後でやること」から、「チーム全体がスプリントを通じて担うこと」へと移行することです。
次回の記事では、この4象限を踏まえた上で、開発とテストの統合を実際のチームでどう進めるかを解説します。
まとめ
アジャイルテストの4象限は、テスト活動を2軸（チームを支援する／製品を批評する、技術面／ビジネス面）で整理するフレームワークです。
- Q1（技術面・チームを支援する）: ユニットテスト、自動化、開発者主体
- Q2（ビジネス面・チームを支援する）: 受け入れ基準の検証、開発とテストの協働
- Q3（ビジネス面・製品を批評する）: 探索的テスト、ユーザー視点での評価
- Q4（技術面・製品を批評する）: パフォーマンス、セキュリティ、非機能品質
自社のテスト活動を4象限に当てはめてみると、「やれていること」と「空白地帯」が可視化されます。
開発とテストの統合を進める出発点は、この全体像を把握することです。