nav_ポートフォリオカンバン

受けた提案をすべて正確に理解してから行動するよう、ポートフォリオのサイズに関係なくすべての人に勧めています。

─スーズ・オーマン

ポートフォリオカンバンの概要

SAFeでは、内容の階層全体、つまりポートフォリオ、価値のストリーム、プログラム、チームの各レベルで、カンバンシステムを作成し実装することを提案している。これらのカンバンシステムは、よく似た働きをするし、互いにつながってはいるが、おおむね別のシステムであり、目的も違い、異なる抽象レベルで動作する。このページでは、それらのシステムのうちもっとも上位の、エピック用ポートフォリオカンバンシステムの実装方法をまとめて紹介する。このシステムは、ポートフォリオの経済面の多くを制御するものである。

ポートフォリオカンバンシステムの実装と管理は、プログラムポートフォリオ管理の管理下で行う。このようなシステムを実装するには、リーンおよびアジャイルの開発プラクティスをポートフォリオレベルのプラクティスとしてどう適用するべきかを、十分に理解しておく必要がある。また、新規開発や通常業務のサポート作業について、それぞれのアジャイルリリース列車の生産能力、ベロシティー、空き状況も理解しておく必要がある。企業は、これらを理解してはじめて、実際の実装コンテキストの十分な知識を持って、論理的かつ実利的な方法で、ポートフォリオレベルの取り組みの検討に着手することができる。

詳細

SAFeのポートフォリオ管理カンバンシステムは、主に、エピック(それを実現するための作業を行う価値のストリームおよびアジャイルリリース列車(ART)の行動方針に影響する大規模で横断的な取り組み)のフローに対処するために使われる。そのため、エピックの把握、分析、承認、実装への引き渡しは、ポートフォリオの重要な決定事項であり、その意思決定には、プログラムポートフォリオ管理(PPM)や影響を受ける価値のストリームおよびARTの代表者など、多くの主要利害関係者が参加する必要がある。

SAFeがこの状況にポートフォリオカンバンシステムを使用するのにはいくつかの理由がある。

  • 戦略的なビジネスの取り組みのバックログを完全に可視化する。
  • これらの取り組みを実装に移すための分析や意思決定を構造化し、可視化する。
  • WIP(仕掛かり作業)制限を設定する。これによって、分析を担当するチームが責任を持ってそれを引き受けること、処理能力や現実をはるかに超える実装やスケジュールの期待を生まないことを保証する。
  • ビジネスの主要利害関係者間の協調体制が進む。
  • もっとも重要なビジネスの決定事項に関して、経済性に基づいた意思決定ができるよう、定量的な透明性のある根拠を提供する。

エピック用のカンバンシステム

すべてのカンバンシステムは特定の目的に合わせて設計されている。このカンバンは、エピックを把握、分析、承認、管理するためのものである。このカンバンシステムを図に表すと図1のようになる。

図1.  ポートフォリオカンバンシステムと、協調する主な関係者

このポートフォリオカンバンシステムでは、エピックがシステムを通って実装(または拒否)へ進むときのいくつかの段階と、そこで必要とされる協調とが描写されている。

  1. じょうご─取り込むための状態。どのような新しい「大風呂敷」のアイデアも歓迎される。
  2. レビュー─この段階で、チャンス、工数、遅延コストの初期見積もりが確立される。
  3. 分析─実現性、測定可能なメリット、開発と配置の影響、リソースの空き状況の予定を明確にするため、より徹底した作業が行われる。軽量のビジネス企画が作成される。この段階の終わりに、エピックは承認または拒否される。
  4. ポートフォリオバックログ─ポートフォリオカンバンを通って「ゴー」の承認を得たエピックは、処理能力の空きができるまでポートフォリオバックログで待機する。
  5. 実装─処理能力に空きができると、エピックは関連するプログラムと価値のストリームのカンバンに移され、実装が始まる。エピックはその後、ポートフォリオレベルにおいて、メトリックスのページで説明するレポートを使って管理される。
  6. 完了─成功基準を満たしたエピックは完了する。

注:すべてのカンバンシステムが目的をもって構築されているため、カンバンシステムの設計および実装のプロセスは、それぞれのコンテキストの中で進化する。さらに、これらのシステムには他のメカニズムも含まれる。一部を挙げると、ビジネスエピックとイネイブラーの間の処理能力の割り当てや、遅延コストに基づいたさまざまな種類の作業のサービス等級、レーンの使用、フローを分析しボトルネックを発見するための手法、WIP制限の調整などである。これらについてこのページでは取り上げないが、指針のページの『Improving Flow with Kanban』(カンバンによるフローの改善)の記事が参考になるかもしれない。

システムの解説

1. じょうご

じょうごの待ち行列は「取り込む」ための待ち行列である。ここでは、どのような新しい「大風呂敷」のアイデアも歓迎される。どこから出てきたものでも構わない。ビジネス上の事柄も技術上の事柄も含まれる。典型的な要因には次のようなものがある。

  • ポートフォリオの戦略テーマ
  • 市場の予期しない変化、会社の買収、合併、新しい競合の参入など。
  • ソリューションの大幅なコスト削減や業務効率に関するニーズ。
  • ビジネス成績を悪化させるような既存ソリューションの問題。

この待ち行列では、エピックのビジネス企画や見積もりは必要ない。エピックは任意の形式で記述できる。通常は短いキーワードや短文で、「すべての自動車ローンのセルフサービス」のように記述する。ツールは重要ではない。ドキュメントやスプレッドシート、あるいは壁に貼った目に見えるシステムで通常は十分である。この待ち行列内の項目に対する作業の投資はわずかなので、この待ち行列にはWIP制限がかからない。すべてのアイデアを取り込んで検討する。じょうごのエピックは、プログラムポートフォリオ管理チームが決めた定期的なリズムで議論の対象となる。判断基準を満たしたエピックは、レビューの待ち行列に進む。

2. レビュー

レビュー待ち行列に進んだエピックは、さらに時間を投資して検討されることになる。この待ち行列では、エピックの大ざっぱな規模が割り出され、ある程度の価値の見積もりが行われる。時間の投資は、議論レベルと、必要であればごく予備的な調査に限られる。エピックは、エピック価値の記述テンプレートを用いて詳細化される(エピックのページを参照)。投資額が増えるため、この待ち行列にはWIP制限がかけられ、検討中の項目の数が抑制される。ビジネス上の利点がどこにあるかが特定され、WSJFを使って各項目に優先順位が付けられる。待ち行列の一番上に上がってきたエピックは、空きができ次第、分析の待ち行列にプルされる。

3. 分析

この待ち行列に到達したエピックは、より厳密な分析を行う価値があるものなので、さらなる投資が必要になる。進行中の作業の責任はエピックオーナーが負う。エンタープライズアーキテクトシステムアーキテクトアジャイルチームプロダクトおよびソリューション管理、影響を受ける可能性のあるアジャイルリリース列車の主要利害関係者の間で、積極的な協調作業が始まる。ソリューション、設計、実装の代替案を調査する。社内開発するか、アウトソーシングするかを検討する。軽量のビジネス企画を作成して、ゴーストップかの提言をする。

この待ち行列の項目には希少な要員をつぎ込むことになるし、さらに重要なことに、今後多大な投資が必要になる。そのため、ビジネス分析者、開発チーム、エンタープライズアーキテクトの処理能力や、この待ち行列内のすべての項目をどれだけのスループットで処理したいかに応じて、WIPを考慮し、制限がかけられる。分析からポートフォリオバックログ待ち行列へ進めるかどうかは企業にとって重要な経済的意思決定なので、作成されたビジネス企画に基づいて、適切な権限を持った人が判断しなければならない。ゴーの基準を満たしたエピックは、ポートフォリオバックログ待ち行列に進む。

4. ポートフォリオバックログ

ポートフォリオバックログの状態に到達した項目は、適切な権限を持つ人からゴーの判断を得ている。通常は、プログラムポートフォリオ管理の誰かがこの判断を行う。これらのエピックは定期的にレビューされる(下記参照)。また、この待ち行列は次の実装作業向けの低コストの待機状態を表す。1つ以上の価値のストリームまたはアジャイルリリース列車に十分な処理能力がある場合、この待ち行列のエピックは実装待ち行列に進む。

5. 実装

処理能力に空きができると、エピックは、該当する価値のストリームやプログラムのカンバンにプルされ、通常はそこでさらなる分析が行われる。エピックはシステム能力やフィーチャーに分割され、受け入れ基準が決められる。準備ができると、新しいシステム能力やフィーチャーは、該当するPI計画策定の境界(大規模な価値のストリームの場合には計画前イベントのこともある)で提示される。その後、開発チームによる実際の実装が始まる。規則正しいプログラムインクリメント(PI)でソリューションを進化させることで、客観的に進捗を評価できる優れた観察ポイントが得られる。エピックは適切なメトリックスを使って完成まで追跡することができる。

実装の責任は開発チームにあるが、エピックオーナーは「プル」ベースで残り、チームが作業を十分に理解できるまで責任を共有する。

6. 完了

成功基準をすべて満たしたエピックは完了と見なされる。しかし、エピックは範囲が広いため、「最初の意図を満たした完了」が必ずしも望ましいとは限らず、識別されたシステム能力やフィーチャーが後で破棄されることもあり得る。いずれにしても、エピックは完了の状態に到達し、累積フロー図をこのレベルで適用している場合には、これが退出のタイミングとなる。

PIのリズムでポートフォリオの作業フローを進める

多くのPPMチームは、エピックの「レビューと仕様のワークショップ」を実施して、システム内で左から右へとエピックを進める。このワークショップには、通常、ポートフォリオの利害関係者と、価値のストリームまたはARTレベルから内容および技術の権限を持つ人が参加する。そして、協力して、ソリューション戦略の意味合いを検討し、エピックを下位レベルのエピック/システム能力/フィーチャーに分割する方法を特定し、エピックを次の状態に進めるか、今のまま保持するか、拒否してシステムから取り除くかするために必要な意思決定を行う。この過程で、エピックは戦略テーマに照らして検証され、WSJFやその他のデータに基づいてじょうごからレビュー、レビューから分析へと進められる。軽量のビジネス企画が作成され、レビューされる。最後にゴー/ストップの判断が下される。承認されたエピックはポートフォリオバックログに移動し、そこで実装の処理能力に空きができるのを待つ。

このワークショップをリズムに合わせて行うかどうかは任意である(リズムに合わせて行う方が好ましいが)。ただし、実装のタイミングは関連する価値のストリームやARTのリズムに影響を受けるため、PI計画策定プロセスより前にそれぞれの価値のストリームやARTに情報を提供できる頻度で実施しなければならない。


さらに知りたい場合

[1] SAFe ガイダンスページImproving Flow with Kanban.

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

[3] Anderson, David.Kanban:Successful Evolutionary Change for Your Technology Business.Blue Hole Press, 2010.(邦訳:カンバン: ソフトウェア開発の変革、 リックテレコム、2014)

 

Last update:20 October 2015