Vision

働く人はコンテキストを渇望し、自分の作業が全体にどう貢献するかを知りたがる。

– Daniel Pink

ビジョンの概要

ビジョンとはこれから開発するソリューションの今後のビューを記述したもので、そこには顧客や利害関係者のニーズと、そのニーズに対処するためのフィーチャーやシステム能力の案が示される。サービス対象の市場、顧客層、ユーザーのニーズも記載される。開発するソリューションの大局的なコンテキストの概要や目的も示される。ビジョンによって境界が設定され、それを基に新しいフィーチャーや非機能要求やその他の内容に関する意思決定が行われる。

ビジョンには、願望的な性質と戦術的な性質の両方がある。主に具体的な契約上の義務が理由の場合もあれば、システム構築者が見た市場のチャンスに反応する場合もある。

ビジョンのアイコンは、SAFeの「全域パレット」上にある。これが示すのは、通常はプログラムレベルおよび価値のストリームレベルのソリューションに重点が置かれるが、ポートフォリオビジョンも明らかに関係があり、もちろんアジャイルチームは担当するシステム部分の長期的なビューを持つことができるという事実である。

詳細

リーン-アジャイルな方法で短期的な成果物に集中的に取り組むことの利点を疑う人はほとんどいない。責任を負うことができる最後の瞬間まで意思決定を遅らせること、仕掛かり作業を制限すること(早すぎる段階での先行した詳細な要求仕様書、今後ずっと使い続けられるアーキテクチャー、詳細な長期計画など)、その代わりに迅速な価値の納品を重視することは、リーン-アジャイル開発の特徴である。これほどまでに行動を重視し行動に偏っているものは他にない。「構築したらわかる」。

しかし大規模なソリューションのコンテキストでは、すべての担当者それぞれが、ソリューションが今何をするべきかについての意思決定を日々行っており、その際に、今後何が容易に(または容易でなく)なりそうかについても判断している。このように、最終的には、現在のソリューションの有効性と、今後のソリューションの開発の経済性の両方を判断することになる。この目的を達成するには、すべてのチームメンバーにソリューションのビジョンを知らせ続ける以外の方法はない。というのも、それこそが、今行っていることをなぜ行うかを示しているからである。長期的、短期的なビジョンを継続して作成、維持、伝達することは、プログラムの目的と目標を理解して共有するために欠かせない。これは特に、市場のニーズやビジネス要因が変化し続けるのに合わせてこれらの考えも進化するからである。

SAFeでは、ビジョンは全域パレット上にある。これは、コンテキストに応じてさまざまな場所にビジョンを適用できるということである。ソリューションビジョンは、3レベルのSAFeのプログラムレベルまたは4レベルのSAFeの価値のストリームレベルに現れ、アジャイルリリース列車アジャイルチームにソリューションを構築している理由を知らせる。ポートフォリオでもビジョンを作成し、複数の価値のストリームがどのように協力してより大きい企業の目標を達成するかを示すべきである。もちろん、チームにもビジョンという構成要素を適用することができる。これはより短期的、または長期的なビューにチームを集中させるのに役立つ。

ポートフォリオビジョン

ポートフォリオビジョンでは、短期的な意思決定に対して、実践的(局所的な意思決定は長期的なコンテキストに照らして行われる)でありかつ精神的(「これは本当にやる価値のあることなんだ」)でもある方法で、長期的なコンテキストを設定する。リーン-アジャイルなリーダーは、主に、会社の戦略的方向性を設定することと、その戦略を実装するチームの使命を規定することに責任を持つ。『スイッチ!』[1]では、この長期的なビューを「目的地の絵ハガキ」と呼んでいる。これを図1に示す。

Figure 1. The Portfolio Vision is an enterprise-level “postcard from the future”
図1. ポートフォリオビジョンは企業レベルの「未来からの絵ハガキ」である

ポートフォリオビジョンには次のような特性がある。

  • 願望的だが現実的であり、達成可能である。 ビジョンは、人の心をひきつけ、いくらか未来的でありながら、何らかの有意義な時間枠の中で達成できる程度に現実的でなければならない。
  • 人を旅に参加させるだけの動機となる。ビジョンは、戦略テーマや個々のチームの目的と整合していなければならない。

この長期的ビジョン(とそのもととなったビジネスコンテキスト)は、通常、定期的なPI計画イベントでチームに知らされる。これを知らせるのはビジネス責任者の場合もあれば、ビジョンを伝えたりその達成に貢献したいという気を起こさせるのがうまい経営幹部の場合もある。ビジョンを与えられると、チームは自分たち独自の強みをどう適用するかを考え始める。本当の意味での関与は目的地を念頭に置いて始まる。この目的地は、チームが自分たちの目的を達成するために役立つ。

ソリューションビジョン

長期的なビューが決まったら、プロダクトおよびソリューション管理は、ポートフォリオビジョンをソリューションビジョンに変換して、そのソリューションの背後にある理由と方向性を示す責任を持つ。それには、次のような項目を検討し、答えを出す必要がある。

  • この新しいソリューションは何を行うか。
  • どのような問題が解決されるか。
  • どのようなフィーチャーや利点がもたらされるか。
  • それは誰のために提供されるか。
  • どの程度の性能(非機能要求)がもたらされるか。

ソリューションビジョンへの入力情報

SAFeでは、この責任は主に(SAFeが3レベルと4レベルのどちらであるかに応じて)プロダクト管理とソリューション管理が負う。彼らはビジネス責任者やその他の利害関係者と直接協力して、すべての入力情報を合成し、1つの総合的な凝集性の高いビジョンにまとめる。図2に示すように、入力情報が尽きることはない。

Figure 2. Solution vision input sources
図2. ソリューションビジョンの入力情報源

入力情報源には次のようなものがある。

ソリューションの意図へのビジョンの記載

リズムベースの顔を合わせたPI計画というSAFeのプラクティスを実施していると、ビジョン文書(ビジョン文書のさまざまな形式が参考文献[2]、[3]、[4]で紹介されている)は、ローリングウェーブビジョン概要説明が書き加えられたり、ときにはそれに置き換えられる。このローリングウェーブビジョン概要説明は、短期的、長期的なビジョンをチームに日常的、定期的に示すものである。PI計画時に、ソリューション管理などの価値のストリームレベルの利害関係者は現在の全体的な価値のストリームビジョンを説明し、プロダクト管理は特定のARTのコンテキストとビジョンを示す。

ビジョンの関連要素と、システムの現在の具体的な振る舞いの詳細は、ソリューションの意図に記載される。

プログラムビジョン

4レベルのSAFeでは、ソリューションビジョンの他に、各ARTが独自のビジョンを作成し、自分たちが作成する特定のシステム能力やサブシステムの方向性を詳細に記述する。このビジョンは、それがサポートするソリューションビジョンと緊密に結合しているべきである。

ロードマップビュー

計画し関与するには方向感覚が欠かせない。しかし、チームがビジョンを達成する方法について何らかの現実的な計画がなければ、メンバーは何をしなければならないかを実際に知ることができない。この目的を満たすのがロードマップである。図3にその例を示す。

Figure 3. The Roadmap is part of the vision.
図3. ロードマップはビジョンの一部である

PI計画のビジョン – トップ10フィーチャー

ロードマップは本当に役に立つ。しかし、行動し実行するには、目の前のステップが明確でなければならない。そのために、プロダクトおよびソリューション管理は次の数ステップを提示する責任がある。SAFeのコンテキストにおいて、これは一度に1PIずつ、一度に1フィーチャーずつ、着実に歩を進めることに該当する。その様子を図4に示す。

Figure 4. Vision is achieved one PI at a time, via the "Top Ten features for the next PI"
図4. 「次のPIのトップ10フィーチャー」を使って一度に1PIずつビジョンを達成する

これを成し遂げるために、プロダクト管理は WSJFを使って常にフィーチャーの優先順位を更新し続ける。そしてPI計画時に「トップ10」をチームに提示する。チームは、これまでにもビジョンがだんだんと進化するのを見てきているし、新しいフィーチャーがこちらに向かってきているのにも気付いているので、リストが新しくなっていても驚かない。さらに、プログラムカンバンを有効に利用してフィーチャーや利点や受け入れ基準が作成されているため、この境界に達したフィーチャーは十分にまとまっていて入念な調査がなされている。アーキテクト/エンジニアによるレビューも済んでいて、さまざまなイネイブラーは実装済みである。

ただし、このトップ10は計画策定プロセスの出力ではなく入力であって、次のPIで何を達成できるかは、処理能力の制限や、依存関係、計画中に明らかになる知識などに左右されることを、誰もが理解している。プログラムインクリメントごとにPI目標にまとめられる行動方針を計画して確約できるのはチームだけである。

しかし、これらのフィーチャーは実装のための準備が済んでいる。そしてプログラムはフィーチャーを1つずつ実装してビジョンの達成へと進んでいく。

ソリューション管理は同様のトップ10システム能力をPI計画前ミーティングで提示する。

 


Learn More

[1] Heath, Chip and Dan Heath. Switch: How to Change Things When Change Is Hard. Broadway Books, 2010.(邦訳:スイッチ! 〔新版〕― 「変われない」を変える方法、早川書房、2013)

[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.(邦訳:アジャイルソフトウェア要求、翔泳社、2014)

[3] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.(邦訳:アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス、翔泳社、2010)

[4] Leffingwell, Dean and Don Widrig. Managing Software Requirements. Addison-Wesley, 2001.

Last update: 27 December 2015