アジャイル品質のための中核パターン:「アジャイル品質プロセス」と「障壁の解体」
QA to AQ 第1回
本連載では、アジャイル開発において効率的かつ効果的に品質保証を進めるために有用な実証済みのパターン集『Quality Assurance to Agile Quality』(以下、QA2AQ)の和訳を、関連するいくつかのまとまりに分けて提供することで、アジャイル開発における品質保証の実践をお手伝いします。初回となる今回は、全体像を解説するとともに、全パターンに共通する考え方やプロセスをまとめた2つの中核パターン「アジャイル品質プロセス(Integrate Quality)」と「障壁の解体(Break Down Barriers)」の和訳を提供します。
アジャイル品質保証と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担当者は、品質ストーリーの作成を支援し、特定のユーザーストーリーに対して品質の折り込みのための品質基準を識別できます。通常の機能テストや受け入れテストに加えて、スクラムチームは、システム品質の妥当性を確認するためのテストや、ダッシュボードを通して品質をモニタリングする方法も開発します。
この記事は参考になりましたか?
- QA to AQ:アジャイル品質パターンによる、伝統的な品質保証からアジャイル品質への変革連載記事一覧
- この記事の著者
-
鷲崎 弘宜(ワシザキ ヒロノリ)
早稲田大学 研究推進部 副部長・グローバルソフトウェアエンジニアリング研究所所長・教授。国立情報学研究所 客員教授。株式会社システム情報 取締役(監査等委員)。株式会社エクスモーション 社外取締役。ガイオ・テクノロジー株式会社 技術アドバイザ。ビジネスと社会のためのソフトウェアエンジニアリングの研究、実践、社会実装に従事。2014年からQA2AQの編纂に参画。2019年からは、DX時代のオープンイノベーションに役立つデザイン思考やビジネス・価値デザインからアジャイ...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
-
長谷川 裕一(ハセガワ ユウイチ)
合同会社Starlight&Storm 代表社員。日本Springユーザ会会長。株式会社フルネス社外取締役。 1986年、イリノイ州警察指紋システムのアセンブリ言語プログラマからスタートして、PL,PMと経験し、アーキテクト、コンサルタントへ。現在はオブジェクト指向やアジャイルを中心に、コンサルテ...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
-
濱井 和夫(ハマイ カズオ)
NTTコムウェア株式会社 技術企画部プロジェクトマネジメント部門、エンタープライズビジネス事業本部事業企画部PJ支援部門 兼務 担当部長、アセッサー。PMOとしてプロジェクトの適正運営支援、及びPM育成に従事。 IIBA日本支部 教育担当理事。BABOKガイド アジャイル拡張版v2翻訳メンバー。ビジネスアナリシス/BABOKの日本での普及活動に従事。Scrum Alliance認定Product Owner。SE4BS構築やQA2AQ翻訳チームのメンバー。
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
-
小林 浩(コバヤシ ヒロシ)
株式会社システム情報 フェロー CMMコンサルティング室 室長。CMMI高成熟度リードアプレイザー(開発,サービス,供給者管理)。AgileCxO認定APH(Agile Performance Holarchy)コーチ・アセッサー・インストラクター。Scrum Alliance認定ScrumMaster。PMI認定PMP。SE4BS構築やQA2AQ翻訳チームのメンバー。CMMIやAPHを活用して組織能力向上を支援するコンサルテ...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
-
長田 武徳(オサダ タケノリ)
株式会社エヌ・ティ・ティ・データ シニアITアーキテクト。ITサービス・ペイメント事業本部所属。2006年入社以来、決済領域における各種プロジェクトを担当後、2018年よりプロダクトオーナ・製品マネージャとしてアジャイル開発を用いたプロジェクトを推進。現在は、アジャイル開発におけるQAプロセスの確...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
-
田村 英雅(タムラ ヒデノリ)
合同会社 GuildHub 代表社員。日本 Spring ユーザー会スタッフ。大学で機械工学科を専攻。2001 年から多くのシステム開発プロジェクトに従事。現在では主に Java(特に Spring Framework を得意とする)を使用したシステムのアーキテクトとして活動している。英語を用いた...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
-
陳 凌峰(チン リョウホウ)
フリーランサー。2003年に上海交通大学(ソフトウエア専門)を卒業後、2006年から日本でシステム開発作業に従事。技術好奇心旺盛、目標は世界で戦えるフルスタックエンジニア。現在はマイクロサービスを中心にアジャイル 、DevOpsを展開中。
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア
