品質の可視化のためのパターン「システム品質アンドン」「品質ロードマップ」「品質バックログ」

QA to AQ　第8回

　本連載では、アジャイル開発において効率的かつ効果的に品質保証を進めるために有用な実証済みのパターン集『Quality Assurance to Agile Quality』（以下、QA2AQ）の和訳を、関連するいくつかのまとまりに分けて提供することで、アジャイル開発における品質保証の実践をお手伝いしてきました。最終回となる第8回は、重要な品質を可視化しチームメンバーに気付かせるパターンをまとめた、分類「品質の可視化」の中から3つのパターン「システム品質アンドン（System Quality Radiator）」「品質ロードマップ（Qualify the Roadmap）」「品質バックログ（Qualify the Backlog）」の和訳を提供します。

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

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

システム品質アンドン

• パターン：システム品質アンドン（原題System Quality Radiator 原著 Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki）[4]

　「豪華なプレゼンテーションは自分にとって魅力的であるとともに、他の人を納得させるものでなければならない」――Freddie Mercury（クイーンのボーカリスト）

　通常、アジャイルソフトウェア開発では、アーキテクチャやクリティカルな品質など、システムの他の重要な側面に注意を払うより前に、見栄えや機能性に注目します。アジャイルプロジェクトでは、「動くものを作ってから、最適化する」といった声を耳にすることがあります。ほとんどのアジャイルプラクティスでは、プロダクトオーナーによって優先度付けされたバックログに従い、重要な機能要件を開発するように促されるでしょう。

　システムが発展するにつれて、システムが持つべき品質特性の何が重要で、どのようにそれらを測定するか理解しはじめます。そして、これらの品質特性の測定値を追跡することと、システムの現在の品質を知ることは、ますます重要になっていきます。品質特性の中には製品の成功の鍵となる必要不可欠なものもあるからです。

　アジャイルチームは、システムの重要な品質特性とその現在のステータスを、アクセスしやすく、確認しやすくする手段を、どうすれば提供できるでしょう？

＊＊＊

　アジャイル開発者は、ユーザーストーリーに基づいてシステムを開発することは得意でしょう。重要な品質特性が何かを理解することも、重要な機能が何かを理解することに加えて重要なのです。重要な品質特性を可視化することは、プロジェクトの成功の鍵となるものをチームが知る上で役に立つでしょう。

　いくつかの品質特性は、可視化された有意義な指標を作成し維持することが困難です。何らかの動きがあるか、品質特性の値がそれなりの頻度で変化しない限り、人はそれらを気にしなくなるでしょう。リマインダーも有意義ですが、無視されてしまう可能性があります。

　品質状況を可視化するための多くのツールとディスプレイを作ることは、システムが出荷に必要な条件を十分に満たしているかを確認することと比べると、無意味な贅沢のように思えるかも知れません。ディスプレイの作成には時間がかかり、QAツールの構築に割けるリソースと人員は限られています。多くの場合、設計が重要な品質に与える影響を慎重に検討する時間はありません。

　同様に、何を測定し監視するかを慎重に検討する時間もありません。どの品質のモニタリングが重要であるかを知ることは困難です。より多くのシステムが構築され、品質特性が実装されるにつれて、特定の品質特性をモニタリングすることが重要になってきます。性能などの品質特性は、新しい機能を追加すると劣化することがあります。一方、一度検証され、テスト可能になったものには、時間とともに変化する可能性が低いものもあります。

　性能および信頼性といった特定の品質特性が定期的に追跡されていないと、開発プロセスの後半で改善することが非常に困難になる可能性があります。当初のシステムは品質の制約を満たしていた可能性があるものの、システムが発展するにつれて、品質特性が見えなくなり、その結果、時間とともに維持されなくなります。

＊＊＊

　誰もが質問する必要なく、仕事中または休憩中に人々が見ることができるように特定のシステム品質特性とその現在のステータスに関する情報を知らせるディスプレイを設けましょう。

　システム品質アンドンには、ポスターやディスプレイから、かんばんボード上の色付きの付箋、色付きのバックログアイテムまで、さまざまな形式があります。重要なことは、品質アンドンが目の届くところにあって理解しやすいことです。また、品質アンドンを最新の状態に保つことも重要です。Alistair Cockburnは次のように述べています[Coc]：

　「アンドンは、仕事をしている人や通りすがりの人が目にできる場所に掲示されているディスプレイである。それは、皆が関心のある情報を、誰にも質問する必要がない形で表示するものである。これは、割り込みをより少なくし、より多くのコミュニケーションを可能にすることを意味する」

　ディスプレイには、チームが積極的に取り組んでいる、現在の着陸ゾーンの値、現在のスプリントの品質ストーリー、品質に関する活動についてのリマインダー、または品質の測定値が表示される場合もあります。その日のあるシステム品質関連テストの結果を表示するだけのこともあるでしょう。サードパーティのツールを使用して、主要なシステム品質特性と現在の値を表示することもあります。

　また、測定可能なシステムを監視して可視化する特定のツール（場合によっては開発環境へのプラグインとして）を作成する必要がある場合もあります。チームがシステムのリアルタイム監視を開始すると、ツールがシステム品質ダッシュボードに発展する可能性もあります。一部の品質特性は直接測定できませんが、注意することが必要です。これらの品質特性はアンドンとして掲げて、チームで忘れないようにしましょう。

　システム品質アンドンにはシステム品質ダッシュボードを含めることができますが、アンドンとダッシュボードの主な違いは、アンドンが意図的に品質の状態と情報を一目で伝えることを目的としていることです。一方、ダッシュボードには、ちょっと立ち寄っただけの観察者には簡単に理解できない、非常に詳細な情報を含んでいる場合があります。システム品質ダッシュボードは必ずしもシステム品質アンドンではありませんが、システム品質アンドンの一部として含めることはできます。

　また、システムの重要な品質特性のチャートやリストをその目標値とともに作成し、それをチームに見えるようにしてください。このチャートには、特定の品質についての測定値ではなく、あるスプリントで、または複数のスプリントで関心のあった特定の品質項目に関するリマインダーが含まれている場合があります。

　品質関連のよくあるリマインダーの例を次に示します。

• すべてのサービス呼び出しのパフォーマンスを調整する…
• 監査ログが生成されていることを確認する…
• セキュリティホールの特定に関心を持つ…
• キャッシングによる高速化に取り組み続ける…

　システム品質アンドンは、実際の測定値、目標、短期的な目標、および長期的な品質目標を組み合わせたものにすることもできます。品質に関する情報の表示は1つだけとする必要はありません。重要なことはシステム品質アンドンを新しい情報で頻繁に更新することです。そうしないと見て貰えなくなるでしょう。出される情報が多すぎると、何が本当に緊急で重要な品質なのかを解釈することが難しくなり、値の変化を見失ったり無視したりする可能性もあります。