着陸ゾーン
- パターン：着陸ゾーン（原題Agile Landing Zone 原著 Joseph W. Yoder and Rebecca Wirfs-Brock）[2]
「パックがある場所ではなく、パックが向かっている場所で滑る」 ――Wayne Gretzsky（カナダ出身のアイスホッケー選手）
複雑なプロジェクトまたはプロダクトでは、プロジェクトの成功に寄与するシステムの品質特性を認識する必要があります。これらの重要な成功基準が、他の無数の要件に負けるようなことがあってはなりません。
また、システムを実装するときに設計のトレードオフを行う必要があります。ほとんどの場合、これらのトレードオフはアーキテクチャに影響を与えるため、成功の定義はある程度柔軟にする必要があります。別の設計目標を達成するために、ある設計目標で妥協することが必要かもしれません。
考え抜いた設計のトレードオフへの対応を可能にするためのシステムが持つべき品質特性を、どのように理解して監視できるでしょうか？
＊＊＊
優先順位を付け、完成の定義に寄与できるように、重要な品質特性を早期に特定することが重要です。また、何が「これで十分」であるかを定義する際には、ある程度の柔軟性も必要です。つまり、システムが持つべきすべての品質特性について、厳格で迅速な（柔軟ではない）受け入れ基準を求めてはいけません。
システムの品質特性の中には、目標とする特定の数値はありませんが、最低限許容できる数値については分かっているものがあります。またある品質特性については、特定の目標を設定しているかもしれませんが、他のシステム品質目標を達成するために、その目標に妥協してもかまわない場合もあります。いくつかの品質要件と全体的な説明責任を果たすためには柔軟性が必要です。
＊＊＊
したがって、着陸ゾーンを定義して使用します。
着陸ゾーン[Gilb]は、プロダクトの「リリース可能性」を監視および特徴付けるために使用される一連の基準です。着陸ゾーン[W2011a]は、すべての基準と許容値が固定されていない、もしくは当初は不明であるゾーンです。着陸ゾーンの基準と値は、プロジェクトの存続期間中に形になっていきます。着陸ゾーンの基準は、許容値に許容範囲を提供することを除き、リリースの基準に似ています。目指している数字は1つではありません。対象のシステム品質属性ごとに値の範囲があります。これにより、「十分」であるものを定義する柔軟性が得られ、着陸ゾーンの合意の範囲内でトレードオフを行うことができます。
着陸ゾーンの基準には、最低、目標、および優良の3つの値があります。最低値は、より高い値を求めているかもしれないが我慢して受け入れられると思っているものです。目標値は、合理的なコストと労力で達成できると思うものです。優良値とは、大きな努力なしでは達成できないと思われるものです。最低値と目標値が同一である場合があります。これは、許容できる品質を達成する上で柔軟性が制限されていることを示します。
あるいは、要件の柔軟性が最も低い場合、満たす必要のある特定の値を使用して受け入れ基準を定義することもできます。成果にある程度の柔軟性がある品質属性に対してのみ、着陸ゾーンを使用します。
表2は、ローン処理システムの着陸ゾーンの例です（簡単にするために、すべての値は架空の値で、実際のプロジェクトの着陸ゾーンとは関係ありません）。それぞれの行は、ローン処理システムを使用して実行する必要があるタスクを表します。
値は、システムを使用してビジネスタスクを完了するのにかかる実際の時間を表します。タスクは、ユーザーによって開始される場合とされない場合があります。一部は、データ受信またはローンの状態の変化（ローンの金利の調整またはローン処理者の割り当て）によって起動されます。その他には、構成データの追加、追加コードの作成、および本番環境への変更の導入が含まれます。
たとえば、品質属性「新しいローン契約の追加」の最低許容時間は2週間です。目標は、ユーザーが新しいローン契約のすべての情報を入力し、24時間以内にシステムに設定できるようにすることです。「新しいローン商品の追加」は、新しい種類のローンの処理をサポートするために必要ないくつかのアクティビティとアクションを完了するため、2週間を目標としています。
| 品質属性 | 最低 | 目標 | 優良 |
|---|---|---|---|
| 新しいローン契約の追加 | 2週間 | 24時間 | 12時間 |
| 新しいローン商品の追加 | 3週間 | 2週間 | 1週間 |
| ローンの調整 | 4日間 | 2日間 | 1日 |
| ローンリスクのアクセス | 1日 | 6時間 | 10分間 |
| ローン処理者の割り当て | 1ヶ月 | 1週間 | 1日 |
着陸ゾーンの各行は、測定可能な要件（測定可能なシステム品質を参照）を表します。この要件には、最低、目標、および優良のラベルが付いた許容値の範囲があります。目的は、開発の最後に各要件をこの範囲内に収めることです。範囲内には、目標というラベルの付いた希望された値があります。最低、目標、および優良という値は、予算と与えられた期間に関連しています。
いくつかの属性がある場合は、パフォーマンス、データ品質、信頼性、使いやすさといったシステム品質カテゴリとその優先度に従って着陸ゾーンを整理すると便利です。表3は、測定対象のシステム品質カテゴリに従って編成された着陸ゾーンの一部を示します。
| カテゴリ | 品質属性 | 最低 | 目標 | 優良 |
|---|---|---|---|---|
| パフォーマンス |
処理能力 （1日あたりのトランザクション数） |
50,000 | 70,000 | 90,000 |
| 平均トランザクション処理時間 | 2秒 | 1秒 | 1秒未満 | |
| … | ||||
| データ品質 |
システム間のデータ一貫性 （重要なデータ属性の一貫性の割合） |
95％ | 97％ | 98％ |
| データ精度 | 97％ | 99％ | >99％ | |
| … |
着陸ゾーンは、監視対象をいくつかの重要なものに集中（数百とかではなく）するのに役立ちます。目的は、プロジェクトの成功に不可欠な基準のみを含めることです。そうすることにより、より大きな視野で理解しやすくなります。1つの属性がその最低値を下回っている場合、他の属性はどうなるか？ それらも最低値を下回っているか？ もしそうであれば、全体的なプロダクトの目的を達成する上で大きな問題を抱えていることになります。そうでなく、すべての要件が正確に目標に合っていなくても、プロダクト／システムの出荷を成功させることができる着陸ゾーンがあります。
着陸ゾーンの基準が変化し、時間とともに調整されることを予期してください。最初に、今後数か月間に達成する予定の着陸ゾーン部分を定義し、着陸ゾーンの残りの部分を意図的に粗削りのままにしておくこともできます。当初達成可能または合理的な目標と思われたものは、新しい事実または市場の変化を考慮して変更される可能性があります。昨日の製品を今日の市場に届けたいと思う者はいません。リリース基準のような着陸ゾーンは、変更することができ、実際変更されます。
たとえば、早期に達成された着陸ゾーンの目標を達成するために懸命に働いたが、早期の決定が将来の作業にマイナスの結果をもたらしたことがわかる場合もあります。次の目的を達成するために、どちらかを返済する必要がある技術的負債を作り出した可能性もあります。時間または予算の制約がある場合、着陸ゾーンの再調整を実施する（さらに、期待値を低く設定する）ことを決定できます。
ロードマップを検証し（品質ロードマップ）、これらのシステム品質属性を着陸ゾーンに含めると、いつ考慮すべきかが把握できるようになります。着陸ゾーンの目標は、品質チャートやシステム品質アンドンに配置するといったさまざまな手段を使って、チームに対してより可視化を行うことができます。
おわりに
連載の第6回では、アジャイル開発において効率的かつ効果的に品質保証を進めるために有用な実証済みのパターン集QA2AQから、アジャイルで重要な品質を特定するためのパターンをまとめた、分類「品質特性の特定」から3つのパターン「測定可能なシステム品質（Specify Measurable Values or System Qualities）」「品質の折り込み（Fold-out Qualities）」「着陸ゾーン（Agile Landing Zone）」の和訳を提供しました。次回の連載では引き続き、分類「品質の特定」と「品質の可視化」から3つのパターンの和訳を提供する予定です。
参考文献
- [1] Joseph Yoder, Rebecca Wirfs-Brock, Ademar Aguilar, “QA to AQ: Patterns about transitioning from Quality Assurance to Agile Quality,” 3rd Asian onference on Patterns of Programming Languages (AsianPLoP 2014), Tokyo, Japan, 2014.
- [2] Joseph W. Yoder and Rebecca Wirfs-Brock, “QA to AQ Part Two: Shifting from Quality Assurance to Agile Quality,” 21st Conference on Pattern Languages of Programs (PLoP 2014), Monticello, Illinois, USA, 2014.
- [3] Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki, “QA to AQ Part Three – Shifting from Quality Assurance to Agile Quality – Tearing Down the Walls,” 10th Latin American Conference on Pattern Languages of Programs (SugarLoafPLoP 2014), Pousada Armação dos Ventos, Brazil, 2014.
- [4] Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki, “QA to AQ Part Four - Shifting from Quality Assurance to Agile Quality - Prioritizing Qualities and Making them Visible,”22nd Conference on Pattern Languages of Programs (PLoP 2015), Pittsbirgh, USA, 2015.
- [5] Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki, “QA to AQ Part Five,” 5th Asian Conference on Pattern Languages of Programs (AsianPLoP 2016), February 24-26, 2016, Taipei, Taiwan.
- [6] Joseph W. Yoder, Rebecca WirfsBrock, Hironori Washizaki, “QA to AQ – Part Six – Being Agile at Quality,” 23rd Conference on Pattern Languages of Programs (PLoP 2016), Monticello, Illinois, USA, OCTOBER 24-26, 2016.
- [BCK] Bass, Len, Clements, Paul and Kazman, Rick, Software Architecture in Practice (2nd Edition), Addison-Wesley, 2003.
- [BBC] Bransford T., Brown A., and Cocking, R., How People Learn: Brain, Mind, Experience and School. National Academy Press, 2000.
- [Brown] Brown T., The hunt is on for the Renaissance Man of computing, in The Independent, September 17, 1991.
- [CH] Coplien J. and Harrison, N., Organizational patterns of agile software development. Wiley, 2004.
- [Duv] Duval, Paul. Continuous Integration: Patterns and Anti-Patterns. DZone, 2010.
- [GILB] Gilb, Tom. 2005. Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Butterworth-Heinemann.
- [Knuth] Knuth, D., “Structured Programming With Go To Statements,” Computing Surveys, Vol 6, No 4, December 1974, pp. 261-301.
- [MR] Manns, M. L., and Rising, L. Fearless Change: Patterns for Introducing New Ideas. Addison-Wesley Professional, 2004.
- [MYGA] Merson P., Yoder J., Guerra E., and Aguilar A., “Continuous Inspection: A Pattern for Keeping your Code Healthy and Aligned to the Architecture,” 3rd Asian Conference on Patterns of Programming Languages (AsianPLoP), Tokyo, Japan, 2014.
- [W2011a] Wirfs-Brock R., (July 28, 2011). Agile Landing Zones,
