アジャイルテストマニフェストを、開発チームの外側から読み解く
注意事項：
- この記事は自分の備忘録として記載しています。また生成AIを使って作成しています。
- 私が研修で学習したことをベースに書かせていますので、生成AIを単純に使った以上に私の理解力による問題がある可能性があります
はじめに
これからアジャイル開発に関わる人のために
近年、アジャイル開発を採用する組織やチームは増え続けています。 それに伴い、これまで開発プロセスの後半で関わることが多かった立場の人にも、
- スプリントの途中でレビューしてほしい
- 仕様が固まりきっていない段階で意見がほしい
- リリース前だけでなく、継続的に品質を一緒に考えてほしい
といった依頼が届く場面が増えています。
これは、アジャイル開発では 「品質は最後にまとめて確認するものではない」 という前提が置かれているためです。
一方で、従来の
- 要件を固めてから
- 開発し
- 最後にテスト・確認する
というウォーターフォール型の経験が長い場合、
- 何をどこまで関わればよいのか分からない
- 自分の責任範囲が曖昧に感じる
- 開発チームとの認識が噛み合わない
といった戸惑いが生じやすくなります。
そこで本記事では、 アジャイル開発におけるテストと品質の考え方を整理するための共通の軸として 「アジャイルテストマニフェスト」を取り上げます。
ここでの目的は、
- すぐにやり方を変えること
- これまでのテストや品質活動を否定すること
ではありません。
アジャイルな文脈で声をかけられたときに、 どう考え、どう判断するかの拠り所を持つことです。
アジャイルテストマニフェストとは何か
アジャイルテストマニフェストは、 2001年に公開された「アジャイルソフトウェア開発宣言（アジャイルマニフェスト）」の考え方を、 テストと品質の文脈に落とし込んだ価値観の整理です。
アジャイルマニフェストが 「ソフトウェア開発全体の価値観」を示したのに対し、 アジャイルテストマニフェストは、
- テストとは何か
- 品質は誰の責任か
- いつ、何のためにテストするのか
といった問いに対する判断の指針を示しています。
- 新しいテスト手法を定義するものではない
- 特定のプロセスや成果物を強制するものではない
- 従来型のテストを否定するものではない
という点です。
マニフェストが示しているのは、
左側の考え方にも価値があることを認めたうえで、 状況に応じて右側をより重視する
という価値判断の優先順位です。
これは、 正解が一つに定まらないアジャイル開発の現場で、 「何を基準に考えるか」を揃えるための共通言語として機能します。
コラム：よくある誤解①
「アジャイルではテスト計画書やテストケースは不要になる」
実際には「不要」になるわけではありません。 目的に対して最適な形に変わるだけです。
重要なのは文書の有無ではなく、
- チームが何を品質基準としているか
- どこまでできていれば安心して次に進めるのか
が共有されていることです。
コラム：よくある誤解②
「アジャイルではテスターや品質担当者は不要になる」
これも事実ではありません。
アジャイル開発ではむしろ、
- 品質観点やリスクを言語化する
- チーム外の視点を持ち込む
- 判断の軸を整理し、議論を助ける
といった役割の重要性が高まります。
これらの誤解は、 「やり方（How）」だけを見て、「なぜそう考えるのか（Why）」を共有できていないことから生まれやすいものです。
アジャイルテストマニフェストが示す5つの価値（要点）
アジャイルテストマニフェストでは、 次の5つの価値の対比が示されています。
| 従来よく重視されてきた考え方 | アジャイルでより重視する考え方 |
|---|---|
| バグの発見 | バグの防止 |
| 最後にテストする | ずっとテストし続ける |
| 機能をチェックする | チームが理解している価値をテストする |
| テスターの責任 | テストに対するチームの責任 |
| システムを壊す | 最高のシステムを構築する |
ここで大切なのは、 左が間違いで、右が正しいという意味ではないという点です。
ウォーターフォール型の開発では、 左側の考え方が合理的で、多くの成果を上げてきました。
一方で、
- 変化が前提
- 早く学び、早く修正したい
- 小さく作って価値を確かめたい
といったアジャイル開発の前提条件では、 右側の価値を意識したほうが、 結果として品質とスピードの両立につながりやすくなります。
開発チームの外側にいる人にとっての使いどころ
アジャイルテストマニフェストは、 そのまま現場に適用するルール集ではありません。
特に、開発チームの中に常駐していない立場の人にとっては、
- 判断に迷ったときの思考フレーム
- 開発チームとの会話を整理するための共通言語
として使うのが現実的です。
例えば、
- 今回の依頼は「発見」を求められているのか、「防止」を求められているのか
- 「最終確認」なのか、「途中での気づき」が欲しいのか
- 自分に期待されているのは実行なのか、視点なのか、助言なのか
こうした点を整理する際に、 5つの価値が状況を翻訳するための軸になります。
おわりに
- 何をやるべきかの正解集
ではなく、
- どう考えるかを揃えるための道具
です。
すべてを理解してから動く必要はありません。 まずは、
この場面では、5つの価値のうち どれを少し意識すると会話が前に進みそうか
を考えるところからで十分です。
アジャイル開発に関わる立場や距離に関わらず、 品質について建設的に関わるための共通言語として、 このマニフェストを活用してもらえればと思います。
