Technical Information

パターンQA to AQによる Agile Quality（アジャイル品質）への変革と事例

2014年、Joseph Yodar氏やRebecca Wirfs-Brock氏が中心となり、アジャイル品質の考え方と推奨される活動を「QA to AQ」というパターン集として発表しました。QAはQuality Assurance、AQはAgile Qualityで、伝統的な品質保証からアジャイル品質の考え方・行動へ変革していこうというメッセージが込められています。私自身もこの活動に参画し、パターンの編纂や拡充のほか、日本語への翻訳展開も進めています^※。本公演ではこのQA to AQの概要に加え、実際の事例についても解説します。

※「QA to AQ：アジャイル品質パターンによる、伝統的な品質保証からアジャイル品質への変革」
https://codezine.jp/article/corner/813

早稲田大学
グローバルソフトウェアエンジニアリング研究所
所長
鷲崎弘宜氏

※この記事は、『ベリサーブアカデミックイニシアティブ 2020』の講演内容を基にした内容です。

アジャイル品質パターン QA to AQ

１．パターンとは何か？

最初に、そもそも「パターン」とは何かをご説明しましょう。これはChristopher Alexanderという建築家が提唱した「パターン・ランゲージ」に端を発しています。
図1の①の写真、左側はパリを代表するカフェ、右は神戸のカフェです。世界中にはたくさんのカフェがあり、心地良いカフェというのは地域によって少しずつ異なります。しかし、よくよく見ると共通の部分があって、地域や場所に限定されない良さというものも存在します。それをドキュメント化し、別の場所で具体化して再利用することはできないでしょうか。この二つのカフェの良い共通点を整理したのが、②の部分です。
ここには「名前」「問題」「解決」として、地域や場所に依存しない普遍的な内容が記述されています。つまり、こういう問題はこうして解決すると良い、という考え方が一つの「パターン」としてまとめられています。

ここで注目すべきは、原典の表題がパターン・ランゲージ、つまり「言語」であるという点です。個々のパターンを語彙=ボキャブラリーとみなし、その組み合わせによってコミュニケーションや新たな計画に役立てることができます。③がその一例で、ここで強調されているいくつかの単語、実はその一つ一つがパターンであり、これらの組み合せによって一つの都市計画がまとめられています。これが元々の建築理論におけるパターンが目指していたものです。

この考え方は、アジャイル開発やオブジェクト指向の設計パターンなど、ソフトウェア開発にも実際に応用されていて、さまざまな広がりを見せています。

https://en.wikipedia.org/wiki/Coffeehouse#/media/File:Caf%C3%A9_de_Flore.jps
https://ja.wikipedia.org/wiki/%E3%82%AB%E3%83%95%E3%82%A7#/media/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Former_Foreign_Settlement_of_Kobe_Hyogo_Japan_A55_03s3.jpg

図1：建築におけるパターン・ランゲージの例

２．なぜパターンなのか？

アジャイル品質の考え方や活動をパターンとして整理すべき理由は二つあります。一つ目は、品質とは特定の行動ではなく、日常的に繰り返される事柄の中で成立するのだということです。ちなみに、哲学者のAristotle（アリストテレス）が残した言葉に次のようなものがあります。

「Quality is not an act, it is a habit.」

彼は、質とは一度の行為ではなく習慣、日々の反復であると述べています。品質というものを捉える上で、このマインドは非常に大事です。

二つ目は、アジャイルの源流にはさまざまな説がありますが、私見では先ほどのパターン・ランゲージが一つ、もう一つはEdwards DemingらのPDCAによる品質管理です。実際に、初期のアジャイル開発であるEVO（EVOlutionary Development）は、反復的なPDCAサイクルをソフトウェア開発に応用したものです。これらを原点としていることから、アジャイル品質をパターン集として整理することは理にかなっていると言えます。

３．QA to AQの概要

これらを踏まえ、アジャイル開発における品質への取り組みとそのヒントを23のパターン集としてまとめたものが「QA to AQ」で、大きく4つのカテゴリに整理されています（図2）。

図2：中核パターンのカテゴリ

４．中核パターン

「中核パターン」は、基盤となる考え方や進め方で、二つのパターンで構成されています（図3）。

図3：中核パターン

５．アジャイル品質プロセス

図4はアジャイル開発で一般的なScrumをベースに、アジャイル品質プロセスを説明したものです。Scrumのプロセスでは、初めにプロダクトバックログを作成しますが、その準備段階となる製品ビジョン/ロードマップの作成時点から、重要な品質シナリオを特定します。プラットフォームや主要機能だけでなく、この段階から品質を考慮しておくわけです。次のバックログ管理にも品質の項目を含めます。また、スプリントの中はもちろん、フィードバックの前にも品質テストを実行します。こうしたサイクルの繰り返しが、推奨される品質プロセスとなります。

図4：アジャイル品質プロセス

６．障壁の解体

アジャイル開発では、常に変化に適応しながら短いサイクルで開発と評価、改善が繰り返されていきます。そのため、品質の確保は専門家が担うという従来の考え方から脱却し、チーム全体で取り組むことが必要となります。ここで重要になるのが、障壁の解体です。早い段階からQA担当者をチームに加え、全てのスタッフと利害関係者がコミュニケーションを妨げる障壁を取り壊しながら品質に携わっていく。そして、結果として得られた品質には、チーム全体が評価されるような体制作りも必要です（図5）。

鷲崎、長谷川、濱井、小林、長田、田村、陳、QA to AQ：アジャイル品質パターンによる、伝統的な品質保証からアジャイル品質への変革、Codezine、
https://codezine.jp/article/corner/813

図5：障壁の解体

７．品質のアジャイルなあり方

中核パターンで提示した考え方を、具体的な体制や手法としてまとめたのが「品質のアジャイルなあり方」です。ここでは、推奨する進め方やロールを9つのパターンで示しています（図6）。

これらのパターンのうち、特に重要となるパターンについて具体的に説明しましょう。パターン「QAを含むOneチーム」は、中核パターン「障壁の解体」についてチーム構成の面で具体化したものといえます。
図7のように、プロダクトオーナー、開発メンバーのみならず最初からQA担当を含んだOneチームでは、中央にあるようなトライアングルが構成されます。QA担当は「プロダクト品質チャンピオン」や「アジャイル品質スペシャリスト」として活動します。開発チームのメンバーは「品質エキスパートをシャドーイング」もしくは「QAリーダーとペアリング」などの活動を通じて、必要に応じて品質作業の分散を行います。これは、負担を調整するとともに、品質に関する知識や作業手順をチーム内で共有し、知見として浸透させていくことにもつながります。

図6：品質のアジャイルなあり方

Joseph Yoder、"品質面でアジャイルであるために"、第2回enPIT-Proスマートエスイーセミナー：アジャイル品質保証と組織変革、2018
鷲崎、長谷川、濱井、小林、長田、田村、陳、QA to AQ：アジャイル品質パターンによる、伝統的な品質保証からアジャイル品質への変革、Codezine、
https://codezine.jp/article/corner/813"

図7：QAを含むOneチーム

品質への取り組みを高速、かつ変化に適応可能な状態で進めるために、プロダクトの価値に直結する部分は、できるだけ自動化するべきです（図8）。それも、可能な限り早く自動化することが大切です。ただし、何もかも自動化するのではなく、きちんと計画を立てて進める必要があります。いち早く自動化すべきなのは、ビルド・結合・テストなどの繰り返し行う作業です。また、ミスが起こりやすい作業や品質のメトリクス、コードの臭い^※1 の検出なども自動化することをお勧めします。一方で、発生頻度が少ないもの、その都度考える必要のあるものは自動化には不向きと言えるでしょう。
また、ストリームとして流れていくアジャイル開発にも立ち止まる時間は必ず設けられていて、そこで少し振り返って次の改善につなげるといったことを繰り返していきます。そのタイミングで、システム上で一貫して満たすべき品質特性については、品質チェックリストを用いて確認を行います。ただし、リストがあまり過大なものになると、チェックそのものが目的になり形骸化する恐れがあるため、本当に重要なところに絞り、極力具体的な期待値を含めた形にすることをお勧めします。
図9はその実例で、あるWeb系の開発に使用したチェックリストです。パフォーマンスの項目には、「500ms未満」というように具体的な期待値が含まれています。さらに、誰もが同じようにチェックを行える状態になっています。

図8：できるだけ自動化

図9：品質チェックリスト

※1：プログラミングにおいて、システム上で深刻な問題を引き起こす可能性のあるソースコードの兆候を比喩で表現したもの。

８．品質の特定

どの品質が重要なのかを見極め、それをきちんと書き下して共有するのが「品質の特定」で、8つのパターンで構成されています（図10）。

重要な品質の発見

顧客の代表なども含む利害関係者とともに、何が重要なのかをきちんと定義します。

品質シナリオ

重要な品質について、特に性能、負荷、セキュリティなどの非機能要件を誰もが理解できる平易な表現で記述しておきます。図11は、品質シナリオの例です。開発プロセスの早い段階で大まかな基準の品質シナリオを作成しておくことが必要となります。

品質ストーリー

やや抽象度の高い記述である品質シナリオをより具体的にしたもので、品質にフォーカスしたユーザーストーリーと言っていいでしょう。これをプロダクトバックログなどに追加して、スプリントで回していきます。

測定可能なシステム品質

ISOやJISにもうたわれていますが、品質は「測定可能」でなければなりません。セキュリティが高い、パフォーマンスが高い、といった曖昧な表現ではなく、それがどの程度なのかを明確にする必要があります。

品質の折り込み

品質の受け入れ基準を具体的に設定します。先出の品質シナリオや品質ストーリーに記述する、あるいは機能面に着目したユーザーストーリーに、この機能の実現に当たり、品質の基準はこうなります、という形で記載してもよいでしょう。

着陸ゾーン

品質の受け入れ基準には、「着陸ゾーン」という考え方がお勧めです。変化に適応できることが特徴のアジャイル開発では、受け入れ基準をピンポイントで設定するのは困難な場合もあります。そこで、最低値・目標値・優良値といったように、着地点に一定程度、幅を持たせるという考え方です。これは処理能力など、さまざまな品質属性について記述することが可能です（図11）。

着陸ゾーンの再調整

着陸ゾーンは、ニーズやベンチマークの変化に応じて適宜再調整を行います。

着陸ゾーンの合意

当然ですが、着陸ゾーンは利害関係者と事前に合意しておくことが必要です。

図10：品質の特定

図11：性能、負荷、セキュリティなど重要な非機能要件については、
早い段階で大まかな基準の品質シナリオを作成しておくことが必須

９．品質の可視化

重要な品質特性は、開発プロセスのあらゆる段階で「見える化」し、メンバー全員が常時気を配って取り組むことが大切です。これを4つに整理したのが「品質の可視化」です（図12）。

図12：品質の可視化

１０．ロードマップ

製品ロードマップに品質特性を組み込み、いつどのように対処するかを明記します。図13はその例で、負荷分散・セキュリティ・安定性・応答性などを、それぞれの要件や重要性に応じて計画に組み入れています。これらは状況の変化に合わせて随時見直しを行う必要があります。

Joseph Yoder、"品質面でアジャイルであるために"、第2回enPIT-Proスマートエスイーセミナー：アジャイル品質保証と組織変革、2018

図13：品質ロードマップ

１１．品質バックログ

品質項目をプロダクトバックログに追加します。機能だけではなく、品質に関する事柄もタスク管理に組み入れて、優先順位を付けながらスプリントで回していきます。

１２．システム品質ダッシュボード

品質の様子をグラフや表などで可視化して、推移やアラート情報などをチームで常時確認・共有できるようにします。

１３．システム品質アンドン

ダッシュボードよりも簡易的に、例えばランプの点滅のようなレベルで誰もが直感的にステータス確認ができるディスプレイがあれば、なお良いでしょう。

QA to AQの事例

QA to AQの取り組みには、実際に日本国内でも活用事例がいくつか出てきています。

１．「できるだけ自動化」

繰り返し実行するテストの自動化と継続的な自動化を実現するために、継続的インテグレーションからテストの管理、テストの実行までを自動化します。また、全体テストをスプリントに、部分的なテストを日々の活動にそれぞれ組み込んでいます（図14）。

長田武徳、アジャイル品質パターンの利用事例、スマートエスイーセミナー：アジャイル開発と品質、2020年8月20日
https://smartse.connpass.com/event/178629/　https://en.wikipedia.org/wiki/Jenkins_(software)　https://logodix.com/
https://www.gurock.com/testrail/　https://aws.amazon.com/jp/s3/　https://gatling.io/　https://www.selenium.dev/　https://appium.io/

図14：「できるだけ自動化」の利用事例

２．「品質シナリオ」

アーキテクチャの開発にC4モデル^※2 を用い、そこで求められる品質要求に具体的な数値を含めた品質シナリオを併記することで定義しています(図15)。

※2：Ionut Balosin氏が提唱しているソフトウェアアーキテクチャの表記法。コンテキスト（context）、コンテナ（containers）、コンポ―ネント
（components）、コードというレベルの異なる4つの図を使い、必要箇所に絞って表現する事により、アーキテクチャを簡潔に表現することができる。

長田武徳、アジャイル品質パターンの利用事例、スマートエスイーセミナー：アジャイル開発と品質、2020年8月20日
https://smartse.connpass.com/event/178629/

図15：「品質シナリオ」の利用事例

３．「着陸ゾーンの再調整」

品質基準の見直しには何らかの根拠が必要になりますが、必要なデータがある程度取得できる場合は、機械学習などを交えて調整するのがお勧めで、図16はその一例です。保守性に関する品質要求を捉える際に、従来は実行行数や関数の数を指標としていました。しかし、別のレビューデータと突合した機械学習の結果、関数の数は無視して、実行行数にもっと厳しい基準を適用すべきという見直しが図られました。

N.tsuda、H.Washizaki、Y.Fukazawa、Y.Yasuda、S.Sugimura、"Machine Learning to Evoluate
Evolvability Defects：Code Metrics Thresholds for a Given Context,"18th IEEE International
Conference on Software Quality, Reliability & Security（QRS 2018）"
https://smartse.connpass.com/event/178629/　

図16：「着陸ゾーンの再調整」の利用事例

４．組織とプロセス変革への取り組み

アジャイル品質の取り組みを推進する上で最も重要なのは、やはりOneチームの構築と、品質作業の分散だと思います。これについても、参考になる事例をご紹介しましょう。一つ目はQAコミュニティで、これはQA担当者をチームに送り込むのではなく、逆にチームメンバーの中からQAエンジニアを選出し、その人たちとQA部門がチームを超えて交流する環境を作るというものです。これによって、 QAの知見を広く共有し、Oneチームへの布石にしようという試みです（図17）。

長田武徳、アジャイル品質パターンの利用事例、スマートエスイーセミナー：アジャイル開発と品質、
2020年8月20日

図17：QAコミュニティを活用しQA部門がチームを超えて交流するための環境づくり

もう一つはテイラーアップと呼ばれるもので、組織標準のプロセスを強制せず、最低限の標準を守った上でチームに適したプロセスを独自に構築するという手法です。そこにアジャイル品質のパターンやプラクティスを適宜組み入れて、各プロジェクトやチームで活用する仕組みを作っています（図18）。

小林浩、アジャイル品質パターンによる伝統的な品質保証（Quality Assurance）からアジャイル品質
（Agile Quality）への変革（適用事例）
Https://smartse.connpass.com/event/178629/

図18：テイラーアップを用いた仕組み作り

おわりに

このQA to AQの取り組みは、現在も編纂・拡充を続けています。ぜひ皆さんからも良い事例や知見をご提供いただき、私たちと一緒に皆さんにもこの活動の推進にご協力を願えればと考えています。本講演が、そのきっかけとなれば幸いです。

この記事をシェアする

パターンQA to AQによる Agile Quality（アジャイル品質）への変革と事例

目次