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

QA to AQ　第7回

　本連載では、アジャイル開発において効率的かつ効果的に品質保証を進めるために有用な実証済みのパターン集『Quality Assurance to Agile Quality』（以下、QA2AQ）の和訳を、関連するいくつかのまとまりに分けて提供することで、アジャイル開発における品質保証の実践をお手伝いします。7回目となる今回は、前回に引き続きアジャイルで重要な品質特性を特定するためのパターンをまとめた分類「品質の特定」、および「品質の可視化」の中から、3つのパターン「着陸ゾーンの再調整（Recalibrate the Landing Zone）」「着陸ゾーンの合意（Agree on Quality Targets）」「システム品質ダッシュボード（System Quality Dashboard）」の和訳を提供します。

表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] 品質ロードマップ [4] 品質バックログ [4]

着陸ゾーンの再調整

• パターン：着陸ゾーンの再調整（原題Recalibrate the Landing Zone 原著 Joseph W. Yoder and Rebecca Wirfs-Brock）[2]

　「素早くテストを行い、素早く失敗し、素早く調整する」――Tom Peters（アメリカの経営コンサルタント）

　最初に、数回の反復で達成すると予想される一連の着陸ゾーンの基準を定義しました。残りの着陸ゾーンは、意図的に大雑把な表現のままにしておきました。新しい機能を実装した後も、既存の基準の値を監視しながら、新しい着陸ゾーンの基準を追加し続けました。

　どのようにして着陸ゾーンを進化させ、最新の状態に保ち続けることができるでしょうか？

＊＊＊

　開発を続けると、基準を着陸ゾーンの目標値内に収めることが難しくなる可能性があります。新しく特定された着陸ゾーンの基準を達成するソリューションは、他の着陸ゾーンの値を維持することに影響を与える可能性があります。

　当初達成可能な目標と思われたものが、新しい情報または現在の実装状況を考慮して変更される可能性があります。

　目標を絶えず前後に移動しないことは重要です。ただし、アジャイルの精神では、新しい情報を学習すると、必要に応じて目標値を再検討して優先順位を付けることができます。

　プロダクトオーナーまたはクライアントは、これらの目標を重要と見なすものの、実行する必要がある他の事柄よりも優先順位が低いと見なし、システム全体への影響を理解できない可能性があります。

　予算と時間の制約により、重要な品質制約の達成に費やすことができる労力が制限される可能性があります。

＊＊＊

　したがって、単に敗北して投げ出すのではなく、着陸ゾーンの基準を再検討し、期待値をリセットしましょう。

　現在分かっていることを考慮すると、適切でない値があるかもしれません。

　システムを段階的に実装し、システムの機能と限界についてより多く学習してきているため、着陸ゾーンの基準とその値が時間とともに変化し、調整されるのは自然なことです。

　当初合理的な目標と思われたものは、新しい事実または市場の変化を考慮して変更されます。昨日のプロダクトを今日の市場に届けたいと思う人はいません。以前の実装の決定は、新たに特定された基準を達成する能力に影響を与えたり、能力を制限したりする可能性があります。たとえば、特定のパフォーマンス目標の達成に集中するよう決定すると、ユーザービリティや柔軟性の基準に影響を与える可能性があります。

　リリース基準のような着陸ゾーンは、変更することができ、変更されることもあります。実際、着陸基準の許容値を変更することは必ずしも悪いことではありません。特に現在の状況に対応し、思慮深い設計上のトレードオフを行う場合はそうです。これは、進行中の開発サイクルの一部です。品質目標の作業に優先順位を付け、品質特性と機能の提供のバランスを維持することが重要です。

　例えば、ある着陸ゾーンのパフォーマンス目標を達成するために返済する必要がある技術的負債を作り出した可能性があります。時間と予算の制約があるため、現在のリリースの設計のやり直しには投資しないこととします。機能を早く作ることよりも、機能を時間通りに提供することが重要です。したがって、着陸ゾーンを再調整することを選択します（受け入れ可能なパフォーマンス基準を低く設定する）。受け入れ可能なものを再定義するという意識的な決定をしたのです。

　また、新しい情報／システムの能力／技術に基づき、着陸ゾーンの基準を上方に再調整／再設定することもできます。たとえば、検証により、キャッシュとバッファのサイズを調整することで、重要なデータ変換（ETL）プロセスの処理能力を向上させることができます。時間制約が厳しいETLプロセスでは、キャッシュとバッファの調整を考慮し、単に「優良」な範囲に移動するのではなく、許容可能な最低値を上方に調整する必要があることに注意してください。チームが着陸ゾーンを再調整する場合には、チームは、着陸ゾーンの合意（品質目標の合意）が必要になることがよくあります。