品質の特定と品質の可視化ためのパターン：「着陸ゾーンの再調整」「着陸ゾーンの合意」「システム品質ダッシュボード」

QA to AQ　第7回

着陸ゾーンの合意

• パターン：着陸ゾーンの合意（原題Agree on Quality Targets , 原著 Joseph W. Yoder and Rebecca Wirfs-Brock）[2]

　「合意は押し付けの結果であってはならない」――Nestor Kirchner（アルゼンチンの元大統領）

　品質に関連した具体的な目標を定義する必要がある分野はいくつかあります。複数のユーザーストーリーまたは多数のフィーチャーに広く適用されるパフォーマンス、ユーザービリティ、国際性、信頼性、またはその他の非機能品質特性に対する目標があるかもしれません。または、重点的に改善したい特定のシステム品質があるかもしれません。どれだけの改善を目指すかは、議論の余地があるかもしれません。

　ただし、過去に似たようなことをしたことがある場合は、選択する品質基準とその許容値は明らかかもしれません。それ以外の場合は、合意に達するのが難しい場合もあります。

　品質の受け入れ基準を定義する際に、どのように合意に達することができるでしょうか？

＊＊＊

　多様な利害関係者は、異なる関心、背景、期待感を持っています。誰もが等しく情報を得ているとは限りません。矛盾した意見を持つ人もいるかもしれません。しかし、特定の品質関連の目標に向かって取り組むためには、誰もが共通の測定可能な目標に賛同し、それに向けて取り組む必要があります。

　技術的な制約により、何をどの程度の費用で提供できるかが制限されます。ビジネス上の懸念事項やマーケティングの傾向により、技術的な選択が行われる場合があります。技術的な決定には、コストや品質が影響することを考慮する必要があります。

　品質要件の優先順位は、多くの場合、それらを実装するための労力とベンチマークを実行するために必要な労力の大きさに左右されます。

＊＊＊

　したがって、品質関連の目標値に関する情報に基づいた合意に向けて努力しましょう。理想的には、知識のある個人の小規模グループが目標値に合意する必要があります。

　多様な意見を持つ多様な利害関係者がいる場合は、各利害関係者グループに、彼らが特に関連するいくつかの品質特性を特定させるようにすることができます。これらは、すでに設定した着陸ゾーンの基準に追加できます。

　初めて着陸ゾーンを設定する場合、プロダクトを知っている人を選び、最初に着陸ゾーンの基準の確立を行うことを推奨します[W2011b]。ビジネスアーキテクト、プロダクトオーナーまたはリードエンジニアは、品質基準の妥当な値を含む「提案された着陸ゾーン」を準備し、小グループで、質問や、説明の要求を受けてレビューします。着陸ゾーンについて、最低値、目標値、および優良値はグループによって合意される必要があります。技術的な考慮事項が品質目標にどのように影響するかを認識することが重要です。これらの値をどのように達成できるかについての前提に注意する必要があります。

　品質シナリオの特定の値を考え出すとき、同様のアプローチを使用することもできます。知識のある人の中には、達成すべき「提案された」値を大まかに決めてしまう人もいます。しかし、知識のある専門家のグループが初期値を改良する場合もあります。

　議論は、要点に沿って、協調的、非対立的でなければなりません。人によっては、過去の傾向と推定に基づいて一連の値を提案する場合があります。または、ソフトウェアアーキテクトが、プロトタイピングの結果またはベンチマークデータに基づいて値を提案する場合があります。または、合理的で可能な値を調査するために、チームが設計スパイクを宣言する場合があります。プロトタイピングまたは設計スパイクのエビデンスに説得力があるため、グループが最終的に数値の調整に合意する可能性もあります。品質値の目標を効果的に設定するために、グループは、相互尊重、信頼、透明性を持ち、隠されたアジェンダを持たないようにする必要があります。

　たとえば、あるプログラムで、チーフビジネスアーキテクトが着陸ゾーンで品質基準とその初期値の初期設定を行いました。その人は、自分の技術的な限界を知ったことのある元技術オタクでした。その人は、ビジネスに関する深い知識、製品ビジョン、着陸ゾーンの値に関して何を正確に、そして何に大きな柔軟性が必要かについての感覚を持っていました。その結果、いくつかの基準は非常に正確でした。多くのトランザクションを処理するビジネスに携わっているため、トランザクション量の予測される増加に基づいてどこを改善する必要があるかがわかっていました。1つのビジネスプロセスのトランザクション処理能力の目標は、新しいアーキテクチャとシステムのデプロイ機能を考慮して、既存の実装からの推定に基づいていました。許容可能な最低値は現在の実装よりも優れていました（それが新しいシステムを構築する理由であったため）が、目標値と優良値は現在の機能からの推定に基づいていました。保守性に関連する他の着陸ゾーンの基準は、一般に、パッチ、新しいシステムリリース、またはオンラインアップデートサポートのいずれかを必要とするものとして分類されていました。パッチ、リリース、またはオンラインアップデートの定義は、意味があいまいにならないように明確にされています。

　値を導き出すことが可能な方法として、情報に基づいた個人の推定値の平均化、ベースラインとして既存システムを使用、同様なシナリオからの値の推定、または作業コードのベンチマーク評価があります。場合によっては、推定値を取得するためにスパイクソリューションを作成する必要があります。

　特定の品質シナリオの目標について合意を得るには、ファシリテーターの役割を果たす誰かが必要になる場合があります。ファシリテーターは、建設的な議論ができるようにプログラムまたはプロダクトについて十分に知っている必要がありますが、「権限者」や「専門家」である必要はありません。ファシリテーターは、合意を得るのが得意であり、意見や異論を強く抱いている可能性のある個人から最善を引き出す必要があります。理想的には、ファシリテーターは、建設的な観察を実現するために製品について十分知っており、許容可能な基準と値を定義する上で、小グループをリードする能力を持っていることが望まれます。質の高い目標の定義を導くために、冷静で画一的な人よりも、情報に基づく判断を行えるファシリテーターの方が効果的な場合があります。

　アジャイルチームが品質目標に合意する必要がある場合が何度かあります。たとえば、アジャイルチームが重要な品質の発見をしたときに、品質シナリオまたは着陸ゾーンの基準に対する初期値を確立する必要があります。着陸ゾーンの再調整を行う場合には、属性を修正し、値の変更に関して、少数のグループで、十分に情報を共有した上で合意が行われる必要があります。