Program-and-Value-Stream-Kanban

「改善は永遠にして無限である」と言われる。「カンバン」の活用も現状維持にとどまらず、創意と工夫をもってさらに発展させるのが、「カンバン」を動かす人たちの課題であろう。

– 小野 耐一

プログラムと価値のストリームカンバンの概要

SAFeでは、ポートフォリオ、価値のストリーム、プログラム、チームのすべてのレベルにおいてカンバンを導入することで、継続的に価値を納品するという目標をサポートしている。プログラムと価値のストリームのレベルでは、調査、洗練、優先順位付け、実装という一般的な作業フローのパターンに沿って、フィーチャーとシステム能力を作成する。カンバンシステムは「プル」の性質を持っているため、プログラムでWIP制限を基に処理能力を管理したり、システムの運用で大きな引き継ぎが発生するのを避けることができる。このような継続的なフローにより、協調と効果的な意思決定が促進される。プログラムエピックや価値のストリームエピックのような大きな取り組みは、プログラムカンバンや価値のストリームカンバンの特別な部分で管理され、結果として、ソリューションを先に進めるためのフィーチャーやシステム能力が生み出される。

プログラムおよび価値のストリームのカンバンシステムは、プログラムインクリメント(PI)のリズムに合わせて使われるため、利害関係者やチームは定められた信頼性の高い方法で価値を詳細化し計画し実装することができ、カンバンのどのステップも負荷が高すぎたり低すぎたりすることがなく、ソリューションはインクリメンタルに確実に構築される。

プログラムと価値のストリームのカンバンシステムは、ポートフォリオカンバンとともに、SAFe企業の内容ガバナンスモデルを構成する。このモデルは、高速で持続可能な価値のフローを実現するのに欠かせない経済意思決定フレームワークおよび制御の非中央集権化を具体化するものである。

詳細

ソリューション構築時には、プログラム価値のストリームのレベルにカンバンシステムを適用して価値のフローを円滑にする。このカンバンシステムは、チームにとって以下の点で役に立つ。

  • 新しい作業や作業のフローについての可視性が高まる。
  • 新しい価値の定義や受け入れ基準の継続的な洗練が確実に行われる。
  • 新しい作業について、分野、機能、レベルをまたがった役割間の協調が促進される。
  • 経済的意思決定が具体化される。
  • ポートフォリオレベル、価値のストリームレベル、プログラムレベルの間の関係が確立される。

価値のストリームカンバンとプログラムカンバンはポートフォリオカンバンと結び付いており、この3つのカンバンが一緒になって、何を構築するかについての重要な意思決定のほとんどに責任を持つ内容のガバナンスシステムが構成される。完全に展開された図1に示すように、準備が十分で実装の承認を得たポートフォリオエピック価値のストリームエピックとシステム能力に分割され、それが価値のストリームのカンバンに入れられる。システム能力と価値のストリームエピックは、価値のストリームカンバンを進んでいく過程でフィーチャーとプログラムエピックに分割され、それがプログラムカンバンに入れられる。

Figure 1. Enterprise Flow of Value.
図1. カンバンシステムを通る企業の価値のフロー

ポートフォリオにおけるソリューションの経済的利点と有効性を最適にするには、中央集権的に行われた意思決定(縦の矢印)とローカルコンテキスト(横の矢印)を統合する。このローカルコンテキストとは、価値のストリームやART顧客のコンテキストから直接発生したフィーチャーやシステム能力である。接続されたカンバンは、経済意思決定フレームワークの大部分を具体化したもので、行われた意思決定に対する継続的なフィードバックのメカニズムの基礎となる。

以下のセクションでは、プログラムと価値のストリームのカンバンについてさらに詳しく説明する。

プログラムカンバン

プログラムカンバンシステムは、フィーチャーおよびプログラムエピックのフローを円滑にするためのものである。すべてのカンバンシステムはそれぞれの目的に応じて専用に作成されるが、典型的な構造は図2のようになる。

Figure 2. Program Kanban
図2. プログラムカンバン

プログラムカンバンは大きく2つの構造的要素から構成される。プログラムエピックのセクションとフィーチャーのセクションである。それぞれについて以下で説明する。

プログラムエピックセクション

プログラムカンバンのプログラムエピックセクションの目的は、プログラムエピックを分析して承認し、フィーチャーに分割することである。このフィーチャーがプログラムカンバンの「下流」のフィーチャーセクションにおいてさらに調査/実装されることになる(図2を参照)。プログラムエピックセクションはプログラムカンバンの中に常に存在するわけではなく、プログラムのローカルコンテキストの中でどれだけ頻繁にプログラムエピックが発生するかによって変わる。

プログラムカンバンシステムのこの部分では、プログラムエピックを調査し承認するために、より高いレベル(通常は価値のストリームレベルやポートフォリオレベル)の利害関係者に関与してもらう必要がある。ここでのフローは、概して、ポートフォリオカンバンの一連のステップとよく似ている。

  • プログラムエピックのじょうごでは、すべての大きな取り組みが歓迎される。このステップにWIP制限はない。
  • プログラムエピックのレビューステップでは、割り当てられた分析者がエピックについての初期調査を行い、WSJFを使って大ざっぱな評価をして、どのエピックを次のステップに進めて詳しく調査するかを判断する。
  • プログラムエピック分析者の役割には、エピックをさらに調査すること、このステップ内の他のエピックと比較してサイズとWJSFを微調整すること、ソリューションの代替案を検討すること、インクリメンタルな実装戦略の考え得る経路を洗い出すこと、必要なコスト/技術やアーキテクチャーの向上/インフラについて判断することなどがある。この情報は軽量ビジネス企画に記録される。内容と予算について十分な権限を持つ利害関係者は、それに基づいてエピックを承認するかどうかを検討する。承認されたエピックはフィーチャーに分割され、フィーチャーカンバンに移される。

ポートフォリオエピックの場合と同様に、プログラムエピックにも、エピックの定義、調査、実装を手助けするエピックオーナーが必要になることがある。

フィーチャーセクション

プログラムカンバンシステムのこのセクションの目的は、フィーチャーの準備、優先順位付け、実装を円滑に進めることである。フィーチャーの中には、ローカルで発生するもの(プログラムエピックを分割して作成されたもの、または親のプログラムエピックを持たない個別のフィーチャーとして作成されたもの)も、上流のカンバンから来るものもある。どちらの場合もフィーチャーはフィーチャーのじょうごに入れられる。

プログラムカンバンのフィーチャーセクションは、ローカルの内容に関して権限を持つプロダクト管理およびシステムアーキテクトの管理下に完全に置かれる。以下のステップは、アジャイルリリース列車(ART)カンバンのフィーチャーセクションを具体的に説明したものである。

  • フィーチャーのじょうごでは、すべての新しいフィーチャーが歓迎される。これには、新しい機能や既存システム機能の機能強化が含まれる。システム品質を向上したりアーキテクチャーまたはインフラを強化するバックログ項目もここで新しく発生する。
  • ビジョンと整合し戦略テーマをサポートするフィーチャーは、フィーチャーの洗練に移されてさらに調査が行われる。このステップでは、ビジネス上の利点、受け入れ基準、WSJFといったフィーチャーの主要属性を洗練する必要がある。フィーチャーの全体的なサイズ調整も、標準化されたストーリーポイントを使ってフィーチャーの見積もりをする時にこのステップで行われる。この見積もりの目的は、経済的見積もりと、スコープに基づいた長期的な価値納品の予測を行うためである。分析対象のフィーチャーの一部では、プロトタイプを作成するなどアジャイルチームを巻き込んだ調査が必要になることがある。通常、このような調査作業は、PI計画に含められる。分析のステップのWIP制限は、プロダクト管理や分野の専門家がどれだけ参加できるかと、チームが調査作業にどれだけの処理能力を充てられるかで決まる。
  • 十分に詳細化され、プロダクト管理によって承認されたうち、もっとも優先順位の高いフィーチャーが、次のステップであるプログラムバックログに進み、そこでバックログの他の項目に対して相対的にWSJFで優先順位が付けられる。
  • PIの境界それぞれで、ARTはプログラムバックログから上位のフィーチャーをプルし、実装ステップへと進める。この移行はPI計画プロセスの結果として行われる。PI計画では、選択されたフィーチャーがストーリーに分割され、その後、そのPIの期間内にチームによって実装される。

プログラムカンバンの管理は、ビジネスフィーチャーの内容に関して権限を持つプロダクト管理と、イネイブラーをサポートするシステムアーキテクトによって行われる。彼らは、受託者責任と意思決定能力を持つ外部利害関係者に定期的に関与してもらって、規模の大きな取り組みを承認する。

価値のストリームのカンバン

価値のストリームのカンバンは、プログラムのカンバンシステムと構造やフローはほとんど同じなので、ここでは詳しく説明しない。ただし、扱う対象は、システム能力と価値のストリームエピックである。価値のストリームカンバンの管理はソリューション管理チームが、サポートはソリューションアーキテクトが行う。価値のストリームエピックを承認するには、ポートフォリオの利害関係者に参加してもらう必要がある。

関連イベント

プログラムと価値のストリームのどちらのレベルのカンバンシステムにも、価値のフローを支援するためのいくらかのイベントが必要である。その中には、広い目的で実施されるものも、カンバンシステムに特有のものもある。価値のストリームレベルとプログラムレベルでは同期の取れたPIのリズムで作業が進むため、カンバンシステムの作業をそのリズムと同期させることが非常に重要となる。以下に示すのは、プログラムと価値のストリームのカンバンシステムのコンテキストで行うよう提案しているイベントである。リリース列車エンジニアと価値ストリームエンジニアは、通常、それぞれのレベルのこれらのイベントでファシリテーターを務める。

エピック仕様ワークショップ

ポートフォリオレベルの仕様ワークショップと同様の構造だが、エピック仕様ワークショップには、プログラムエピックや価値のストリームエピックに対する権限を持つ分析者や利害関係者が参加する。ワークショップの間に、一部のエピックをじょうごからレビューに、あるいはレビューから分析にプルすることができる。さらに他のものに関しては、進めるか止めるかの判断をし、その後で、進めるフィーチャーおよびシステム能力をカンバンの「下流」部分に移行する。

プログラム/価値のストリームのバックログの洗練

該当するレベルの内容と技術について権限を持つ人が通常は参加するこのワークショップの目的は、フィーチャーまたはシステム能力のバックログを構築することである。ビジネス上の利点や受け入れ基準のサイズ調整および詳細化は、この時点で行う。WJSFを使ってフィーチャーやシステム能力に大ざっぱに優先順位を付け、バックログにプルできるようにする。

PI計画

一般的に、PI計画は価値のストリームレベルのPI計画前セッションから始まる。ここでは価値のストリームのカンバンに含まれるシステム能力をフィーチャーに分割し、価値のストリーム内の列車ごとに用意されたプログラムカンバンシステムに入れる。このセッションの入力は、価値のストリームのバックログの上位システム能力である。このセッションにはソリューション管理とプロダクト管理の両方が参加する。各プロダクト管理者はここで作成されたフィーチャーを持ち帰って自分のプログラムのカンバンシステムに追加し、さらに詳細化が必要な場合には「フィーチャーのじょうご」ステップに入れる。フィーチャーはカンバンシステムの中を順に移動し、洗練のステップを通り抜けたものは列車によってプルされ、列車の2日間のPI計画セッションの対象となる。これらのセッションの結果を集約したものは価値のストリームレベルに戻され(PI計画後セッション)、どのシステム能力を実装に移すかを理解するための材料となる。

ソリューション/システムデモ

フローシステムの目的は、バックログ項目を完成まで持っていくことである。ソリューションデモシステムデモによって、利害関係者はどれだけの作業が完了しどれだけの価値が納品されたかを評価することができる。


 

Last update: 30 November 2015