Roadmap

予測することは非常に難しい。特に未来は。

– Neils Bohr

ロードマップの概要

ロードマップは、価値のストリームとアジャイルリリース列車(ART)の納品物を短期的なスケジュール上に示して伝えるためのものである。通常は約6か月間のプログラムインクリメント(PI)マイルストーンを表していて、自信を持って確約されたものが記載され、次のPIでの納品物と、このあと1~2PIの中程度に自信のある予定納品物が可視化される。ロードマップは、ソリューション管理とプロダクト管理によって作成され、ビジョンや納品戦略が進化するのに合わせて更新される。

もちろん、将来を予測するのは危険なことなので、リーン-アジャイルな企業は現実のパターンやビジネス状況が変化したときにそれに対応できる必要があり、そのため、すぐ先のことであっても柔軟性は保証されている。しかし、現実社会では、ときおりそれ以上のことが要求される。そのため、企業はさらに長期的な予測が必要になる可能性がある。取り組みの中には開発に数年かかるものもあり、顧客やサプライヤーやパートナーに対してある程度の確約をしなければならないからである。そのために、SAFeでは、アジャイル開発の物理学とプログラム実施の予測性に基づいた、長期的な予測に関する指針を提供している。

予測対象の期間は慎重に検討する必要がある。短すぎる場合、企業は適切なレベルの連携ができなかったり、将来のシステム能力やフィーチャーについて伝えられないリスクを負う。一方、長すぎる場合、企業は将来の予測を試みることになる。さらに悪いことには、新たな要求が生じても、その要求が長い確約された待ち行列を通過するために時間がかかり、変化する顧客のニーズに素早く対処できなくなる。

詳細

計画に従うことよりも変化への対応」は、アジャイル宣言の4つの価値の1つである。その価値に従って行動しようとすると、実際には計画を持つことが非常に重要であることが明らかになるはずである。計画がなければすべてが変化になり、バックログは、「いつも機嫌のいい犬の尻尾」のように、簡単に予想できたはずの変化に振り回されてしまう。その結果として、スラッシングや、余計な再作業やWIPが生じる。これでは誰もが意欲を喪失する。計画は役に立つ。

ロードマップはまさにそのような計画となる。ロードマップのコンテキストにおいて、チームは自分たちが現在確約していることは何か、意図として何が計画されているかを知ることができる。そこで計画されたタスクを日常的に実施することで、個人的な満足感が得られ、現実の変化に対応するために必要な精神的身体的能力の余裕が生まれる(これらの変化には予想できなかったものも含まれる)。

SAFeのロードマップは、一連の計画されたプログラムインクリメント(PI)と、言い渡されたさまざまなマイルストーンから構成される。その例を図1に示す。

Figure 1. An example PI Roadmap for a gaming company
図1. あるゲーム会社のPIロードマップの例

ロードマップ上の各要素はマイルストーンである。これにはチームが定義した学習マイルストーンと、外部イベントなどによって決まる日付マイルストーンがある。

PIロードマップの作成

図1のロードマップには3つのPI(約30週間)が表示されている。多くの企業では、これくらいの期間がだいたい適切である。仕事を実施できるだけの詳細が明らかになっていて、しかも、期間が短いため、長期的な確約に縛られてビジネスの優先順位の変化に柔軟に対応できなくなることもない。このロードマップは、1つの「確約PI」と、2つの「予測PI」から構成される。それぞれについて後のセクションで説明する。

確約PI

During PI計画, teams commit to meeting the program 時に、チームは次のPIのプログラムPI目標を達成すると確約する。そのため、近い将来の計画は十分に自信の持てる計画でなければならないし、企業は次の新しい機能の影響を自信を持って計画できなければならない。SAFeを使用するのが初めてでまだPI計画に十分な自信が持てていないアジャイルリリース列車(ART)の場合は、システムデモ検査と適応のワークショップを行うことで、今後はPIごとにもっと自信が持てるようになる。いずれの場合でも、次のPIで予測したとおりに納品することが、どのARTにとっても重要な能力である。

予測PI

次の2つのPIの予測はもう少し興味深い。価値のストリームやARTでは、通常、一度に1つのPIだけの計画を立てる。多くの場合、ビジネスや技術を取り巻く状況はめまぐるしく変化するため、あまり先のことまで詳細に計画するのは無謀でしかないためである(ただし一部のアーキテクチャー滑走路は例外かもしれない)。

しかし、価値のストリームやプログラムのバックログにはカンバンシステムを通り抜けてきたシステム能力やフィーチャー(今後のマイルストーンを構成するもの)が含まれている。これらは、論理的に検討され、チームにもおなじみであり、受け入れ基準が設定中で、ストーリーポイントの単位で規模の予備的見積もりが行われている。ARTのベロシティー、PIの予測性測定値、相対的優先順位、そしてこれまで保守などの通常業務に費やされてきた作業の量が分かれば、ARTはそれほど苦労せずに今後のフィーチャーをロードマップ上にだいたい配置することができる。その結果、ほとんどの列車は、3つ程度のPI期間に関してそれなりの自信のあるロードマップを持つことになる。

長期的予測

ここまでの説明では、企業がポートフォリオ内のすべてのARTに関して、妥当で短期的な意図の計画を作成できることを強調してきた。ただし、多くの企業、特にサプライヤーが参加し、ハードウェアのリードタイムが長く、サブシステムが大きく、納品日を守ることが必須で、外部顧客に確約しているような、複雑な大規模システムを構築する企業では、それだけの期間のロードマップでは不十分である。人工衛星や穀物用コンバインや新しい自動車などを構築するには、PIロードマップよりもずっと長い期間が必要であり、企業はもっと先の将来まで現実的に計画を立てる必要がある。

さらに、外部イベントが理由で長期的な予測が必要になる場合以外でも、企業は今後の期間に対する投資を計画する必要がある。長期的なビジネスの要望を支えるために役立ちそうなものや開発のボトルネックになり得るもの、特定の価値のストリームに対する投資の増減を理解しなければならない。

つまり、結論は明らかである。大部分の場合、PI計画の範囲を超えた先まで予測する必要があり、これは今後の作業の計画がほとんど作成されていない場合でも同じである。

長期的な取り組みの見積もり

幸いなことに、アジャイル作業の物理学では、長期的な作業を予測する手段が用意されている。もちろん、作業を予測するには見積もりが必要である。見積もりを行うには、チームは正規化された見積もりに基づいてアジャイルのストーリーポイントを使用し、エピックレベルの大きい取り組みを見積もることができる。その様子を図2に示す。

Figure 2. Epics are estimated in story points rolled up from feature estimates
図2. エピックはフィーチャーの見積もりを合計したストーリーポイントで見積もる

 

これらの見積もりと、ARTのベロシティーの知識と、新しい取り組みに割り当てることができる処理能力の判断とを基に、ビジネス担当者は「what-if」分析を行うことができる。その例を図3に示す。

Figure 3. Epic estimates, capacity allocations and ART velocities are used for longer term forecasting
図3. エピックの見積もり、処理能力の割り当て、ARTのベロシティーを使って長期的予測を行う

このようにして、企業は必要なだけ長い期間を含むロードマップを作成することができる。しかし、企業がこのような予測をするときには注意が必要である。多くの人は長期的な予測ができることを目的としがちだが、リーン-アジャイルなリーダーは、長期的な確約をするたびに企業のアジャイルさが損なわれることを理解している。要求を事前にかなり明確に決定できる場合でも、革新は予測が困難で変動が大きいこと、既知の作業についてのみ見積もりが行われる傾向があること、今後の処理能力を予測するのは困難であること、出来事を予見できないことなどのさまざまな要因が一緒になって、現実を過小評価する傾向が生まれる。固定された長期的な計画を作成して確約すると気分はすっきりするだろうし、状況によってはそのような計画や確約が必要な場合もあるだろうが、その結果、経済的により大きな恩恵が得られそうな新しい成果に向けて方向転換するアジャイルさは確実に制限される。両方を手にすることはできない。

結果として、リーン-アジャイルな企業では、適切な量の可視性、連携、確約を確保しつつ、適切な量の柔軟性を保てるよう努力することになる。積極的に、長期的な確約を予測に切り替え、PIの境界それぞれで必要に応じて優先順位とビジネス価値を継続的に再評価することで、適切なバランスが得られる。

地獄の待ち行列の回避

リーン-アジャイルなリーダーは、待ち行列理論を理解し、待ち行列の長さが納品時間に与える影響をはっきりと意識している。単純に言うと、確約した待ち行列が長くなるほど、新しい取り組みの待ち時間が長くなる。たとえば先に挙げた図1では、ロードマップ上の2番目のPIの負荷にはまだ余裕がありそうである。そこから計算すると、計画にない新しいフィーチャーの待ち時間は10~20週間となる。現在のPIには含められないが、次のPIに含めることは可能である。

下の図4のロードマップはまったく別の話である。

Figure 4.
図4. 完全に確約されたロードマップは地獄の待ち行列である

たとえばもし、このロードマップ上のすべての項目が完全に確約されていて、チームがほとんど処理能力いっぱいで走り続けていると、新しいシステム能力の待ち時間は60週間を超えることになる。企業がいくらアジャイルなつもりでいても、それは思い違いである。管理者の夢はリトルの法則によって毎回打ち負かされる。


さらに知りたい場合

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.(邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

Last updated: 25 October 2015