残された人生の持ち時間はいつかゼロになる。

- チャック・パラニューク、ファイト・クラブ、1996

ロードマップの概要

ロードマップは、チームおよびプログラムとビジネス目標との「位置合わせ」を確立し、伝達する。また、近い将来のスケジュールで何を納品するかを可視化する。通常、ロードマップでは3~6ヶ月のPIとリリースマイルストーンを表すが、そこには、自信を持って見通せる次のプログラムインクリメント(PI)の成果物、中程度に自信のあるその後のPIのもの、あまり自信のない長期のものが含まれる。ロードマップはビジョンとリリース戦略が発展するのに合わせて、プロダクト管理によって作成および更新される。

期待された時間基準は注意深く調整しなければならない。短すぎる場合、企業は正しいレベルの「位置合わせ」ができなかったり、将来のフィーチャーを伝えられないリスクを負う。一方、長すぎる場合、将来の予測に基づいて進むことになり、さらには、新たな要求が生じても長い確約された待ち行列を通過するために時間がかかり、変化する顧客のニーズに対処できなくなる。

詳細

ロードマップはビジネス目標を簡潔に表す一連の計画されたプログラムインクリメントリリース日付からなる。図1に、3つのプログラムインクリメントの例を示す。

sasddas

図1. あるゲーム開発会社のロードマップ。PIとリリースを示した

リズムを用いて開発し、需要に応じてリリースする」で説明したように、リリースはプログラム計画策定のリズムに一致しない場合もある。図1のロードマップの場合、リリースにどの目標が含まれるかを表すため、ロードマップ注釈を利用する。図2はよりシンプルなロードマップである。この場合、PIの日付がリリースの日付と同じである。

いずれの場合も、ロードマップは以下の観点から解釈しなければならない

次のPI。リリース計画策定時に、チームは次のPIのプログラムPI目標を達成すると確約する。そのため、近い将来の計画は十分に自信の持てる計画でなければならないし、企業はこれからの新しい機能の影響を自信を持って計画できなければならない。新しいプログラムでは、今後のPIで自信を持って納品するために検査と適応が役に立つ。

次のPI+1。一度に複数のプログラムインクリメントの計画を立てるプログラムはほとんどない。これは、プログラムのベロシティーが成熟した状態になっていなかったり、チームが今までのPIから十分な予見性を獲得できなかったことなどが理由である。ビジネス背景は迅速に変化しているので、遠い将来のために詳細に計画することは愚かでしかない(アーキテクチャー滑走路は例外かもしれない)という理由も考えられる。いずれの場合も、ビジョンやPI計画策定プロセスにより次のPIの目標はある程度見えてきてはいるが、計画は作成されないため、次のPI+1には自信を持って確約できない。

次のPI+2。本質的に次のPIと同じであるが、さらに遠いところにある。ビジネス、顧客や市場の移り変わりや次のPIや次のPI+1にある納品の変更などが原因で、計画された目標が変更される可能性は高くなる。

その結果、計画サイクルはより長いほど、知らないことがもっとさらされる。未知のものを理解しようといくら頑張っても、考慮に入れることができないものが常にあるだろう。簡単に言えば、何が知らないかを知らないだ。ここは計画のためよりアジャイル的な1つのアプローチはあなたを支援できる。以下のような積極的あるいは消極的な知られていないイベントの結果として、アジャイルは方向の変化にさらされるリスクを最小限に抑える

従って、企業はこのような「予測」に気を付けなければならない。多くの人は長期的に予測できることをゴールと捉えがちだが、リーン-アジャイルリーダーは長期的な確約が企業の俊敏性を損なうことを理解している。場合によって、固定された長期的な計画と確約が適切だと感じられ、ときには要求されることがあるかもしれない。しかし、ビジネスは変化するので、このようなことは企業が新しい、より経済性のある有益な成果へと舵を切るための俊敏性を制限する。両方を得ることはできない

結果として、アジャイル企業は、ちょうどよいレベルの可視化や「位置合わせ」、確約を確立しながら、ちょうどよい量の柔軟性を持とうと努力している。幸いにも、各リリースの境界でニーズを明確にするとともに、継続的に優先順位とビジネス価値を再評価するという意欲や確約を介して、正しいバランスが取得できる。

ロードマップと俊敏性に関するコメント

アジャイル純粋主義派はロードマップの利用がアジャイルの原則やプラクティスと矛盾していると考えている。確約された計画に縛られていて、どうやってアジャイルになれるだろうか(ウォーターフォールではないか?)。我々はそのような状況を理解している。

一部の管理者はチームが将来を厳密に予測できなければならないと信じている(エジソンさん、クリスマスまでにこの豆電球が必要なのです。仕様はこれね!)。このような結論を導かされたのは利害関係者の存在かもしれない。これらの利害関係者が最終的にすべてを支払うのだから、正確にいつ何を得られるのかを知りたいと求めているのだ。我々はそのような状況も理解している。

しかし、このような極端なやり方はどちらも有効ではない。

代わりに、SAFeのロードマップでは、アンチアジャイルパターンに陥らずに、ちょうどよいレベルの「位置合わせ」と可視化(3~6ヶ月)を提供する。スマートなリーン-アジャイル企業は、中間的な見方をし、確約できるものに確約し、長期に関しては柔軟性を持つ。


さらに知りたい場合

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

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.