アジャイル品質保証とQA2AQの背景
アジャイル開発における品質保証は、特定の段階で特定の人々のみが取り組むというよりも、専門家を交えつつロードマップ策定から日々のモニタリングに至るあらゆる段階でチーム全体となって取り組む活動となります。QA2AQは、アジャイル品質の考え方と推奨される実証された活動のエッセンスを、問題と解決をペアにしたパターンのカタログとしてまとめたものです。QA2AQとの名称には、「伝統的な品質保証からアジャイル品質へと変わっていこう」「昔ながらの品質保証の考え方から脱却し、アジャイル開発に適合する形でよりアジャイルな方法で品質保証を進めよう」といったメッセージが込められています。
QA2AQはもともと、アジャイル開発やオブジェクト指向、パターンの実績で著名なJoseph Yoder、Rebecca Wirfs-Brock、Ademar Aguilarの3氏により、2014年のアジア地域におけるパターン国際会議AsianPLoP’14において、6つのパターン（Pattern）と15のパトレット（Patlet、問題・解決の対のみを記述したパターンのモト、小さなパターンのようなもの）のまとまりとして発表されました[1]。その後、パターンとしては未完成であったパトレットについて順次完成させるとともに、新パターンの拡充および整理により、以降のPart 2[2]、Part 3[3]、Part 4[4]、Part 5[5]、Part 6[6]の発表へと至っています。本稿の筆者・鷲崎は[1]についてシェパード（投稿論文を改善させるための助言役）を務め、[3][4][5][6]について共著者としてパターンの執筆や洗練に加わっています。
日本におけるアジャイル開発の進展を受けて、QA2AQを紹介することで、日本のアジャイル開発における品質保証の実践をお手伝いしたいと思い、有志が集い翻訳するに至りました。以降では、QA2AQの全体像を解説するとともに、全パターンに共通する考え方やプロセスをまとめた2つの中核パターンアジャイル品質プロセス（Integrate Quality）と障壁の解体（Break Down Barriers）の和訳を提供します。
QA2AQの全体像
ウォータフォールプロセスとアジャイルプロセスとでは、そのプロセスモデルの違いに起因して、品質保証への取り組みも自ずと異なってきます。具体的には、アジャイルプロセスの主要な特徴としてインクリメンタルな出荷とチーム全体による取り組みがあります。その特徴からアジャイルプロセスにおいて、品質保証の取り組みを早期から随時実施することでその時に必要な機能と品質を達成すること、そして、品質保証の取り組みにチーム全体として関わることが重要です。
その円滑な実現に向けてQA2AQでは、本稿の執筆時点において23のパターンを、表1に示す4つの分類で整理してまとめています。また[4]においては、今後追加記述の可能性のある複数のパターン候補をパトレットとして挙げています。
| 分類 | 概要 | パターン名 |
|---|---|---|
| 中核 | 他のパターンを用いるうえでの基礎となるパターン |
|
| 品質のアジャイルなあり方 | アジャイルプロセスにおける品質保証のあり方や役割のパターン |
|
| 品質の特定 | 重要な品質を特定するためのパターン |
|
| 品質の可視化 | 重要な品質を可視化しチームメンバーに気付かせるパターン |
|
アジャイル品質プロセス
- パターン：アジャイル品質プロセス（原題 Integrate Quality, 原著 Joseph Yoder, Rebecca Wirfs-Brock, Ademar Aguilar）[1]
「品質は決して偶然に得られるものではない。それは常に、強い意志、誠実な努力、スマートな指示、および巧みな実行の結果である。品質は、様々な選択肢のうちで賢明な選択を表している」――William A. Foster
一般的に、QA（品質保証の活動）は、多くのスプリントの後まで、あるいは開発プロセスの後半まで行われることはありません。多くのスプリントが完了するまでQAテストを遅らせると、当初は十分と考えていた作業項目が、あとで多くの問題を引き起こしてしまう可能性や、プロセスの後半まで対処されなかった性能やセキュリティなどのシステム品質属性によって、アーキテクチャに混乱が引き起こされる可能性があります。もし重要なシステム品質を早期のスプリント中に認識し検討していれば、それらの品質は早い時期に組み込まれ、再作業が少なくなる可能性があるでしょう。
重要なシステム品質の検査をアジャイルプロセスにどのように組み込み、QA担当者はプロセスのどこへ入ればよいでしょうか？
＊＊＊
多くの場合、QA担当者は酷使されており、別のチームの一部になっています。QA担当者は多くの場合、上流側の実力者から非難され、常にそれに応答しなければならない状態にあります。QA担当者としてはもっと助けたいと思っていますが、時間も人も十分ではありません。
QA担当者は、製品をリリースするにあたっての障害物と見なされる可能性があり、多くの場合、QA担当者と開発チームの間に「我々と（我々とは異なる）あいつら」というメンタリティをもたらします。
アジャイルチームがフィーチャーと重要な機能に集中することは重要です。システム品質によっては、エンドユーザーにとって有益なものを示してすぐに満足させることができないため、重要ではないように思われる場合があります。
多くのチームメンバーは品質を重視しておらず、また多くの場合、さまざまなシステム品質を理解しておりません。開発者は、ユーザーストーリーの製品要求に基づいてシステムを実装することが得意です。対してQA担当者は、システムの品質を理解し検証することについて多くの専門知識を持っています。
＊＊＊
そこで、アジャイルプロセスの一環として、システムの品質を理解し、記述し、開発およびテストする方法を構築します。
これは、プロジェクトにとって重要なシステム品質を高いレベルで理解し、品質シナリオを使ってそれを記述する手段を提供することで実現できます。品質に関する作業は、プロダクトバックログタスクに含めることができ、最終的に、システム品質の識別、テスト、検証に役立つ品質ストーリーを作成できます。これには、重要な品質を特定し、スプリントに含めるためのバックログへ確実に含まれるように、プロダクトオーナー（PO）とQA担当者を引き込むことが含まれます。
アジャイルチームがこれを行うには、さまざまな方法があります。最も重要な考え方は、QA担当者をチームに組み入れてOneチームとしてあたり、品質の考え方をアジャイルマインドセットに統合することです。たとえば、スクラムを実践している際、こういったシステム品質へ注目する考え方が、計画やテストを含む通常のスプリントに組み込まれていることを確認します。図1に、品質に関する活動をスクラムプロセスに追加して重点的に取り組む方法の例を示します。
構想段階では、重要な品質属性を考慮して理解する必要があります。次に、プロダクトオーナーと協力して、スプリントの中で扱っていけるように、品質属性を優先順位付けしてバックログに含めます。スプリント中に、関連するすべての品質上のタスクが含まれ、QA担当者は、品質ストーリーの作成を支援し、特定のユーザーストーリーに対して品質の折り込みのための品質基準を識別できます。通常の機能テストや受け入れテストに加えて、スクラムチームは、システム品質の妥当性を確認するためのテストや、ダッシュボードを通して品質をモニタリングする方法も開発します。
