品質ロードマップ
- パターン：品質ロードマップ（原題Qualify the Roadmap 原著 Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki）[4]
「必要なのは計画とロードマップと目的地に向かって進む勇気だけである」――Earl Nightingale（自己啓発作家・実業家）
多くのアジャイルチームは、計画の一部として製品ロードマップを作っています。このロードマップは通常、製品の機能を長期にわたって提供するための大まかなプランを示しています。
この大まかなプランは、そのプロジェクトに関与する複数のチーム間で共通の理解を共有し、利害関係者の期待やプロジェクト全体の計画や目標を組織全体に伝えるのに役立ちます。
ロードマップには、目標であるマイルストーンと、製品の主要な機能をいつ頃提供するかを示すタイムラインが示されています。
システムが持つべき品質特性は、製品の成功の鍵となる要素です。アジャイルチームはロードマップやタイムラインに、品質特性をどのように含めることができるのでしょう？
＊＊＊
エンドユーザーに提供される製品の機能は具体的で分かりやすく、エンドユーザーにとって明らかな価値があるので、ロードマップに簡単に示すことができます。
機能の提供にシステムの品質特性が関係する場合がありますが、それらがどのように関連しているか分からないと、機能を提供するために必要なシステムの品質特性とアーキテクチャがロードマップに示されません。
アジャイルチームは、エンドユーザー関連の機能に優先順位を付けて実装するため、ユーザーストーリーをバックログに含めるでしょう。しかし多くの場合、ユーザーストーリーにシステムの品質特性のことは書かれません。そのため、システムの品質特性を理解し、いつそれを考慮すべきか、判断することが困難な場合があります。
システム設計では、重要なビジネス要件を満たすのに十分な機能を実装することと、システムの品質特性に適切に対処することの間でのトレードオフを考えなければなりません。設計のトレードオフを行う際に、過剰な設計をしたり、技術的な品質の細部にこだわり過ぎたりすることがあります。一方で、基本的な機能が実装された後に重要なシステムの品質特性に対処しようとすると、大幅な修正作業が必要になることもあるでしょう。品質特性への適切な対処をすることで、混乱を少なくし、余裕を持って仕事ができるかもしれません。
＊＊＊
製品の機能を開発し、ロードマップを進化させながら、システムの品質特性とそれをサポートするアーキテクチャにいつ対処するかも計画しましょう。重要なシステムの品質特性をいつ実装する必要があるかを知るために、必ずPRM（Plan for Responsible Moment：責任ある瞬間の計画）を立てるようにしましょう。
製品ロードマップは、製品がいくつかのメジャーリリースでどのように成長する可能性があるかを示す高い視点から見た計画です。通常、製品ロードマップには、ユーザーストーリーによって実装される重要な機能が示されています。たとえば、注文処理や在庫管理などはデリバリが期待されている重要な機能であるため、ロードマップに示されているでしょう。注文処理を実装するには、1つ以上のサービスを開発し、Webサーバーをインストールし、トランザクションデータベースにアクセスすることが必要になる場合があります。これらは、ロードマップ上の技術的なロードマップアイテムとしてサポートする必要があるかもしれません。パフォーマンスやセキュリティも重要な場合は、これらを品質関連のロードマップアイテムとしてロードマップに追加することもできます。
品質関連のロードマップアイテムは、それに関係する機能とともに配置する必要があります。これは、よく知られているアジャイルの格言「正しく動くものを早く作れ」に反するように見えるかも知れません。しかし、アーキテクチャにリスクがある場合は、それに関係する機能を提供する前に、アーキテクチャの技術的な課題を解決する必要があるでしょう。このやり方は、スパイクソリューションを行って、そのソリューションを改良することに似ていると思いませんか？
計画中に、システム品質に関連する項目を製品バックログまたはToDoリストに追加する必要があります。バックログに品質関連の作業を追加すると、パフォーマンスやセキュリティがいつ必要とされるかがより明確になり、品質バックログを実施する際に役立つでしょう。
製品ロードマップには、主要な機能がいつ頃必要となるかを示すタイムラインがあります。そこに、必要なシステムの品質特性を達成するためのアーキテクチャを追加することができます。あるいは、アーキテクチャや共通で利用される技術が、いつ頃提供されるかを示す個別の技術ロードマップを作成することもできます。ここで重要なのは、個別の技術ロードマップがあるか、製品ロードマップ上でアーキテクチャを特定するかどうかではなく、いつ重要なシステムの品質特性を検討して作業するのかが可視化されていることです。品質バックログ、システム品質ダッシュボード、システム品質アンドンなどは、品質を可視化する方法です。
システムの品質特性の提供を明示的にしないと、必要と認識されない場合があります。特定のシステムの品質特性を実装するのに時間がかかりすぎると、アーキテクチャに大きな修正作業が入る可能性だってあります。システムのコアとなる部分が実装されるときなどに、関連する重要な品質特性がうまいタイミングで提供されれば、技術的なリスクを制限することが容易になり、プロジェクトをタイムリーに完了する可能性が高まります。こうして提供されたシステムの品質特性は、あなたのタスクを“DONE”とすることに直接貢献するでしょう。
製品ロードマップに必要なシステムの品質特性を検討して定義するためには、ISO/IEC 25010：2011[ISO]などのソフトウェアおよびシステム品質モデルの標準が参考になります。これらの標準は、典型的な品質特性を分類し、品質の懸念事項を体系的に検討するための広範なフレームワークを提供してくれるでしょう。アジャイルチームは、プロジェクトの初期段階で、信頼性やセキュリティなど、いくつかの重要な品質特性に焦点を当てて作業することがあります。使いやすさや保守性などの追加の品質特性を検討する場合、設計をやり直したり、当初考えられていた品質特性の期待値を再調整したりすることを余儀なくされる場合もあります。最初からすべての品質特性の要件を指定および定義することは必要でも望ましくもありませんが、重要な品質特性を定義し、製品ロードマップのどこでそれらが提供されることが期待されているかを明確にすることは重要なことです。
品質保証の懸念事項に適切に対処するために、IEEE 730-2014 [IEEE730]やIEEE 1012-2012 [IEEE1012]などの品質保証プロセスとアクティビティの標準では、アジャイルチームが製品ロードマップを調整または検討する際に役立つアクティビティを定義しています。たとえば、IEEE 730-2014では、目的、結果、およびタスクに関して16件のソフトウェア品質保証アクティビティを定義しています。これらのアクティビティを参照することにより、QAおよび他のチームメンバーは、プロジェクトの特定の要件や環境上の制約に合わせて、効果的で一貫したQAプロセスを開発することができるでしょう。
システムが進化すると、より多くの機能が提供されますが、システムの品質特性もそれに対応し続けることが重要になります。ある一時点で品質特性が適切に対処されていることを確認しても、それは品質特性がその後も安定していることを保証するものではないからです。一般的に、品質の最終的なチェックのタイミングを予測することは不可能です（ただし、いくつかの特定のケースでは可能かもしれません）。したがって、品質をチェックする計画は、単に「いつ」だけではなく、「どのコンポーネント」または「どの変更」にも対処する必要があります。「3回目のイテレーションの最後に、個人情報のプライバシーをチェックする」というだけでなく、「この変更が発生した場合は必ずチェックする」といったことも計画に含めるようにしましょう。
