品質作業の分散
- 品質作業の分散（原題Spread the Quality Workload, 原著 Joseph W. Yoder, Rebecca WirfsBrock, Hironori Washizaki）[6]
「グループの取り組みに対する個人のコミットメントが、チームを、会社を、社会を、文明を、機能させる。」 — Vince Lombardi（アメリカンフットボールのコーチ）
アジャイルチームは、ほとんどの時間を機能の仕様策定、実装、そして検証に費やします。そして、システムのリリース前には、システムが持つべき品質特性の組み込みとその検証も必要です。実施すべき品質関連のタスクはたくさんあります。こうしたタスクがタイムリーに対処されないと、QAがGTD（Getting Things Done）のボトルネックになりかねません。
アジャイルチームがすべてのタスクを適切なタイミングで対処するには、品質管理と機能提供のバランスをどのように取れば良いでしょうか？
＊＊＊
QA担当者は、部分的に実装された機能ではテストが役に立たないと考え、すべての機能が完成するまでシステムの品質特性の検証に消極的かもしれません。重要な品質特性を早めに検証しないと、重大な問題、遅延、手直しを引き起こす可能性があります。パフォーマンスやスケーラビリティの欠陥の改善には、システムのアーキテクチャに大幅な変更と修正が必要になることがあります。システムの品質特性に焦点を合わせる時期が早過ぎると、過剰設計と時期尚早の最適化につながる可能性があります。
システムの品質特性を検証する環境を構築するには、技術的なスキルと相応の労力が必要です。QA担当者がシステム品質の要件定義と検証タスクの全範囲の経験を欠いていると、反復的で非効率的な手動タスクを数多く実施することになるかもしれません。素早いフィードバックが得られるという利点はありますが、プロジェクトが大きくなるにつれて、増加するシステムの品質特性を検証する手動タスクが、チームの開発速度を低下させるでしょう。
文化的障壁の克服は困難を伴うかもしれません。たとえば、多くの開発者はコードの実装に専念することを好み、QAタスクやテスターの役目を引き受けたくないと考えています。開発者は、システムの品質特性の検証を、退屈なテスト作業だと思っているかもしれません。
QA担当者 は大抵、人員不足であり、過労状態であり、そして過小評価されています。これは士気低下の原因になり得ます。システムの品質特性に対処しようとした時には、十分なQAリソースや経験がないかもしれません。こうなると、QA担当者 は自発的ではなく受け身になり、役割が火事の防止ではなく火事の発見になります。
プロダクトオーナーは大抵、プロジェクトの初期段階では機能要件に集中します。機能を理解することは重要ですが、そのため品質関連のタスクが最後まで山積みになってしまうことがあります。
＊＊＊
QA担当以外の人も品質関連のタスクに巻き込み、品質管理の負担を調整するようにしましょう。プロジェクト全体に品質関連のタスクを差し込み、品質作業の負荷を長期にわたって分散させましょう。
我々のゴールは、システムの品質特性の定義、実装、検証といった、品質作業への取り組みを安定して行えるようにすることです。開発者は既にコードの品質に対して責任と所有権を持ち、それがシステムの機能や機能を含む中核となるビジネス要件を満たしているかどうかを確認する手助けをしています。加えて、開発者がシステムの品質特性の検証を支援することもできます。たとえば、開発者は、QAエキスパートによる指導と検証を受けながら、テストフィクスチャ（テストを何度も繰返し実行可能にするための前提や条件）を作成し、特定のシステム品質の検証に取り組むことがあります。あるいは、開発者がQA担当者とペアになって、重要なシステムの品質特性を検証・監視するためのインフラストラクチャを構築することもできます[Sav]。また、開発者がもし探索的テストの基本的なトレーニングを受けたなら、新しいシステム機能のまだ試されたことのないテスト観点を提供し、作業負荷を軽減してくれるかもしれません。
こうしたことは、プロジェクトの成功のため全員が協力し、言われた時だけでなく、必要な時に必要なだけ参加するということになります。開発者を含む全チームメンバーがQAのタスクを手伝うことができます。これが、品質への取り組みを「負荷分散」するということです。誰もが同じ専門知識を持っているわけではありませんが、品質関連のタスクをこなすことで学ぶことはできます。チームが成長して行く中で、チームメンバーがコンフォートゾーン[注2]から少し外れることもあるでしょうが、それは、成長においてはよくあることです。たとえば開発者は、コードをチェックインする前に、システム品質テストがすべてパスすることを保証する責任を持つようになるでしょう。QA担当者は依然としてシステム全体の品質を保証する責任がありますが、その責任やタスクの一部を共有することができます。
品質の作業負荷を長期に渡って分散させることは、チーム内に分散させることと同じくらい重要です。複雑なシステムの品質特性をプロジェクトの最後になって対処しようとすると、問題とやり直しが多く発生することでしょう。適切な時期に重要な項目が確実に対処されるようにするための方法の一つは、品質ロードマップと品質バックログを作成することです。
また、スプリントの終了前であっても、テストの実施に十分耐えうる実装になり次第、システム品質テストの作成と実施に取り掛かることは有効です。テスト結果は、まだ暫定的なものであっても、開発チームに重要なフィードバックを提供します。このテスト結果はまた、チームがいつ重要な品質特性に取り組み、改善すべきかを知るのに役立ちます。QA担当者は、実施したテストとその結果を継続的にフィードバックしなければなりません。いえ、これで十分ではありません。チームの全員が、品質の問題を見つけたら、気兼ねなく提起できるようにしましょう。
品質チェックリストとシステム品質ダッシュボードは、品質項目が忘れられたり、見落とされたりしないようにするのに役立ちます。経験は、品質エキスパートをシャドーイングし、QAリーダーとペアリングの実施で共有できます。品質作業の分散や、QAを含むOneチームとして働くことで、必ずや障壁の解体はできるでしょう。
[注2] コンフォートゾーン（Comfort zone）
不安を持たずに仕事ができる範囲をコンフォートゾーンと言います。コンフォートゾーンの外側はラーニングゾーンとなります。ラーニングゾーンで仕事をこなし、最終的にその仕事に不安がなくなると、ラーニングゾーンはコンフォートゾーンに変わります。つまり仕事のスキルをあげる、成長するとは、ラーニングゾーンに踏み込んでコンフォートゾーンを広げることなのです。ただ、コンフォートゾーンから外側に大きく踏み込みすぎて、仕事を上手くこなすことができないようであれば、気をつけてください。そこはラーニングゾーンの外側に広がるパニックもしくはデンジャーゾーンかも知れません。
おわりに
本稿では、アジャイル開発において効率的かつ効果的に品質保証を進めるために有用な実証済みのパターン集QA2AQから、アジャイルプロセスにおける品質保証のあり方や役割のパターンをまとめた、分類「品質のアジャイルなあり方」から3つのパターン「アジャイル品質スペシャリスト（Agile Quality Specialist）」「品質チェックリスト（Quality Checklists）」「品質作業の分散（Spread the Quality Workload）」の和訳を提供しました。本連載の以降では引き続き、他のパターンの和訳を提供する予定です。
参考文献
- [1] Joseph Yoder, Rebecca Wirfs-Brock, Ademar Aguilar, “QA to AQ: Patterns about transitioning from Quality Assurance to Agile Quality,” 3rd Asian onference on Patterns of Programming Languages (AsianPLoP 2014), Tokyo, Japan, 2014.
- [2] Joseph W. Yoder and Rebecca Wirfs-Brock, “QA to AQ Part Two: Shifting from Quality Assurance to Agile Quality,” 21st Conference on Pattern Languages of Programs (PLoP 2014), Monticello, Illinois, USA, 2014.
- [3] Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki, “QA to AQ Part Three – Shifting from Quality Assurance to Agile Quality – Tearing Down the Walls,” 10th Latin American Conference on Pattern Languages of Programs (SugarLoafPLoP 2014), Pousada Armação dos Ventos, Brazil, 2014.
- [4] Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki, “QA to AQ Part Four - Shifting from Quality Assurance to Agile Quality - Prioritizing Qualities and Making them Visible,”22nd Conference on Pattern Languages of Programs (PLoP 2015), Pittsbirgh, USA,
- [5] Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki, “QA to AQ Part Five,” 5th Asian Conference on Pattern Languages of Programs (AsianPLoP 2016), February 24-26, 2016, Taipei, Taiwan.
- [6] Joseph W. Yoder, Rebecca WirfsBrock, Hironori Washizaki, “QA to AQ – Part Six – Being Agile at Quality,” 23rd Conference on Pattern Languages of Programs (PLoP 2016), Monticello, Illinois, USA, OCTOBER 24-26, 2016.
- [Gaw] Gawande A., The Checklist Manifesto. Picador, 2009.（翻訳：吉田 竜、『アナタはなぜチェックリストを使わないのか？』晋遊舎 、2011.）
- [Sav]Savoia S., “Tearing Down the Walls: Embedding QA in a TDD/Pairing and Agile Environment,” Agile 2014 Conference, Orlando, Florida, USA.
