品質のアジャイルなあり方（2）：「アジャイル品質スペシャリスト」「品質チェックリスト」「品質作業の分散」

QA to AQ　第3回

　本連載では、アジャイル開発において効率的かつ効果的に品質保証を進めるために有用な実証済みのパターン集『Quality Assurance to Agile Quality』（以下、QA2AQ）の和訳を、関連するいくつかのまとまりに分けて提供することで、アジャイル開発における品質保証の実践をお手伝いします。3回目となる今回は、アジャイルプロセスにおける品質保証のあり方や役割のパターンをまとめた、分類「品質のアジャイルなあり方」から3つのパターン、アジャイル品質スペシャリスト（Agile Quality Specialist）、品質チェックリスト（Quality Checklists）、品質作業の分散（Spread the Quality Workload）の和訳を提供します。

表1　QA2AQにおける分類とパターン

分類	概要	パターン名
中核	他のパターンを用いるうえでの基礎となるパターン	アジャイル品質プロセス [1]（第1回） 障壁の解体 [3]（第1回）
品質のアジャイルなあり方	アジャイルプロセスにおける品質保証のあり方や役割のパターン	QAを含むOneチーム [1]（第2回） 品質スプリント [1]（第2回） プロダクト品質チャンピオン [5]（第2回） アジャイル品質スペシャリスト [6]（第3回） 品質チェックリスト [5]（第3回） 品質作業の分散 [6]（第3回） 品質エキスパートをシャドーイング [5] QAリーダーとペアリング [3] できるだけ自動化 [6]
品質の特定	重要な品質を特定するためのパターン	重要な品質の発見 [2] 品質シナリオ [1] 品質ストーリー [1] 測定可能なシステム品質 [2] 品質の折り込み [1] 着陸ゾーン [2] 着陸ゾーンの再調整 [2] 着陸ゾーンの合意 [2]
品質の可視化	重要な品質を可視化しチームメンバーに気付かせるパターン	システム品質ダッシュボード [2] システム品質アンドン [4] 品質ロードマップ [4] 品質バックログ [4]

アジャイル品質スペシャリスト

• パターン：アジャイル品質スペシャリスト（原題Agile Quality Specialist, 原著 Joseph W. Yoder, Rebecca WirfsBrock, Hironori Washizaki）[6]

　「正しい質問をすることは、正しい答えをだすのと同じくらいのスキルを必要とする」――Robert Half（事業家）

　アジャイルプロジェクトの品質保証（QAチーム）は、機能の観点から要件を表現したユーザーストーリーに集中して評価と検証を行っています。アジャイルプロジェクトのQA担当者は機能テストが得意なのかもしれません。しかし、ソフトウェアが、エンドユーザーのニーズを満たすためには、拡張性、使いやすさ、安全性、信頼性といったシステムが持つべき品質特性も示す必要があります。目標を達成するためには、個々のユーザーストーリーだけでなく、システム全体の品質特性を検証する必要があります。

　アジャイルチームは、どのようにしてシステムが持つべき品質特性を特定し、それをテスト、検証するための最高の経験と実習を積んで、それを実現することができるでしょうか？

＊＊＊

　システムの品質特性の一部は、仕様、設計、実装、そして検証が適切に行われたかを確認するために、相当の専門知識を必要とします。主に機能面に焦点が置かれている場合、品質特性は重視されない可能性があります。多くの品質特性にはさまざまな専門知識が必要ですし、この専門知識をアジャイルチームが必ずしも有しているわけではありません。

　通常、ユーザーストーリーに具体的な品質特性の受け入れ基準が含まれることはありません。機能に焦点を当てることはメリットもありますが、エンドユーザーは機能が提供する価値を簡単に評価することができるため、機能が強調されすぎてしまうかも知れません。

　システムは、品質特性を含む要件全てが適切に対処されるまで完成したとは言えません。しかし、トレードオフは常に存在しますので、完璧を求めるのは間違っています。ビジネス機能とシステムの品質特性の両方にバランス良く対処する必要があります。特に相反する要件のバランスをとるために、品質特性についてのある程度の専門知識が要求されます。

　パフォーマンスやセキュリティ、信頼性といった要件を検証するテストを実装するよりも、システム機能を検証するテストを作成する方が簡単です。システム品質のテストは多くのユーザーストーリーに影響を与える可能性があり、これらの要件を適切に検証するには、多くの知識とスキルが要求されます。

　システム設計では、重要なビジネス要件を満たすのに十分な機能を実装する一方で、システムの品質要件に適切に対処することのトレードオフを行います。設計のトレードオフを行う時は、設計を過剰にしたり、システム品質の細部にこだわろうとしたりする傾向があります。その一方で、重要なシステム品質の目標を達成しようとして甘い見込みで実装を改良した結果、大変な事態になることもあります。

＊＊＊

　システム品質に関する特定のスキルがチームに不足しているなら、アジャイル品質スペシャリストをさまざまなタイミング（場合によってはフルタイム）で投入し、システムの品質特性の説明、検証、そしてテストを支援してもらいましょう。

　アジャイル品質スペシャリストは、特定のシステムの品質特性に関連する深い技術スキルを持つQAの役割です。アジャイルチームには、アーキテクトやアジャイル品質スペシャリストの深いスキルが必要になることがあります。たとえば、製品が安全でなければならないなら、セキュリティを最初から設計してシステムに組み込み、テストと検証を適切に実施する必要があります。セキュリティは魔法のように現れたりはしません。チームはQAのセキュリティ専門家だけでなく、セキュリティのアーキテクトか開発者の専門知識も必要とすることがあります。アジャイル品質スペシャリストは、チームが必要なスキルを習得するまでの一時的なメンバーですが、必要であればフルタイムのメンバーにもなります。アジャイル品質スペシャリストは、品質関連タスクを直接支援することでチームと協働します。単なるアドバイザーというよりは、実際に手を動かす人達です。

　スペシャリストという言葉には、特定の知識だけを持った頑固者という悪い意味もあります。一部のアジャイルチームでは、スペシャリストの採用を忌避することさえあります。しかし、チームで働いて良いのは「T字型^[注1]」 の人たちだけだというのは希望でしかありません。特定の品質関連のタスクを実行するために必要な深いスキルを、必ずしも誰もが簡単に習得できるわけではありません。スペシャリストが必要な場合がありますが、スペシャリストは必ずしもT字型ではありません。

　組織に品質のスペシャリストがいる場合、通常は品質保証グループに所属します。そうでない場合、組織の別の部署から品質のスペシャリストを連れてくるか、専門的な役割を支援するために外部のスペシャリストを連れてくることができます。このスペシャリストは、アジャイルの実践やプロセスに精通していない場合があります。その人をチームに効果的に組み込むには、一緒に働いて、アジャイルの価値と好ましい働き方をスペシャリストに理解してもらう必要があるかもしれません。スペシャリストの情報とアドバイスに基づいて、自分たちのプロセスを変えたくなることがあるかもしれません。多くの場合、品質のスペシャリストは、使いやすさ、パフォーマンス、セキュリティなど、異なる専門分野を持っています。何人もの品質のスペシャリストの助けを必要とすることもあるでしょう。

　アジャイル品質スペシャリストは、チーム全体にシステムの品質特性に対する意識を高めることでしょう。彼らは、システム品質関連のタスクを一人でも、または共同でもこなすことができます。たとえば、重要な品質の発見や、品質シナリオと品質ストーリーの作成やレビューの際に助けになってくれます。彼らは、品質の折り込み中に品質関連の受け入れ基準が適切に定義されているか確認してくれます。そして、有益なシステム品質アンドンとシステム品質ダッシュボードを作成してくれます。

　アジャイル品質スペシャリストが貢献したり、主導できたりするタスクはたくさんあります。彼らに負荷が集中し、品質関連の専門知識について唯一の情報源となってしまわないようにすることが大切です。アジャイル品質スペシャリストは、QAリーダーとペアリングすることや品質エキスパートをシャドーイングすることなどを通して、品質作業の分散を促進することができます。

[注1]　T字型

　T型の人材は、専門分野の深い知識を持つ縦棒のI型の人材（スペシャリスト）に広い知識の横棒「ー」をプラスした人材のこと。T字型の人々には、深くて幅広いスキルと知識がある[Brown]