nav-portfolio-ppm

マネジメントは成功の梯子を上手く登ること。それに対し、リーダーシップは梯子を正しい位置に立手掛けること。
スティーブン・コヴィー

プログラムポートフォリオ管理の概要

プログラムポートフォリオ管理(PPM)は、SAFe内で最も上位の受託者意思決定責任を負う。ここで戦略と投資財源、プログラム管理、およびガバナンスに責任を持つのは、エンタープライズビジネス戦略と技術と財務上の制約を理解し、ポートフォリオプロダクト/ソリューション戦略を定義して実装する、ビジネス管理者および役員である。これらの人々は、通常、その責任を遂行する際にプロジェクトまたはプログラムマネジメントオフィス(PMO)の協力を得る。PMOはプログラムの遂行とガバナンスを導くという責任を共有する。ただし、企業の他の多くの職務と同様に、これらの責任を果たすにも、従来型のやり方ではリーン-アジャイルな開発をそのままサポートすることはできない。そのため、ここも変化の途中である。

詳細

プログラムポートフォリオ管理(PPM)は、図1に示すように、戦略と投資財源、プログラム管理、およびガバナンスの責任を主に担う人たちである。

Figure 1. Primary responsibilities of program portfolio management

図1. プログラムポートフォリオ管理の主な責任

SAFeにおいてこの責任を果たすために、PPMは、会社の投資と戦略の指針となる戦略テーマを制定して伝え、ポートフォリオビジョンの管理を担当する。このポートフォリオビジョンにおいて、関連する価値のストリームを決定し、アジャイルリリース列車予算を割り当て、横断的なポートフォリオバックログエピックを定義して優先順位を付け、行った投資とプログラムの進捗について会社に報告する。リーン-アジャイルへの移行中には、PPMはアジャイルと従来型のウォーターフォールとの両方のプログラムについてこのような責任を負うこともある。その様子を図2に示す。

図2. PPMは必要に応じてアジャイルとウォーターフォールの両方のプログラムの責任を負う

プログラムポートフォリオ管理チーム

この職務を担当する肩書きや役割は企業によって異なるだろうし、場合によっては正式な名前や部署がない場合もあるが、責任は明白である。SAFeではこの責任を分担する人たちをまとめてプログラムポートフォリオ管理と呼ぶ。

この作業の最終的な責任を負うのは役員であるが、通常彼らには、ビジネスケースを作成したりすべての実装作業を自ら指導し管理する時間やスキルがない。そのため、拡大解釈するとPPMには以下の人たちが含まれる。

  • プログラム/プロジェクトマネジメントオフィス(PMO) — 大規模なプログラムを開発から配置まで導き、状況および財務面について報告を行うことができる。この職務が、企業のソフトウェア開発ライフサイクル(SDLC)の定義までを担当する場合もある。
  • ビジネス分析者 — 取り組み(ビジネスエピック)を詳細化し、企業内外の価値のストリームに対する影響を判断できる。
  • エンタープライズおよびシステムアーキテクト — ビジネス戦略を支える技術ビジョンと実装シナリオを(アーキテクチャーエピックによって)定義できる。

リーン-アジャイルなプログラムポートフォリオ管理

ビジネスを成功させるには、この責任を効率的に果たすことが必須である。しかし、従来のウォーターフォールモデルに、非決定性のソフトウェア開発をトップダウンで制御して行うというある程度自然な傾向が組み合わさったことで、業界は、より効率的なリーンおよびアジャイルのパラダイムの採用を著しく妨げかねない振る舞いや発想をするようになっている。このような「小手先エンジニアリング」、「目いっぱい稼働」、「とにかくやれ」といった従来型の発想については、参考文献[1]および[2]で詳しく説明されている。

このような発想から抜け出せるよう、組織をリーン-アジャイルなプログラムポートフォリオ管理に移行するために使用できる7つの変換パターンを検討する(図3を参照)。

Figure 3. Seven transformational patterns for Lean-Agile Program Portfolio Management

図3. リーン-アジャイルなプログラムポートフォリオ管理のための7つの変換パターン

これらの変換パターンにより、戦略、投資財源、プログラム管理、ガバナンスという重要な責任を、効率的なリーン-アジャイルのやり方で果たす方法をよりよく理解することができる。詳細は以下で説明する。

戦略と投資財源

戦略と投資財源の目的は、会社の付加価値の高いプロダクトやサービスを開発し保守するプログラムを通じて、ビジネス戦略の実現を促進することである。価値のストリームは、特定され、育てられ、監視され、継続的に改善される。投資財源は、ビジネス戦略と現在の戦略テーマに応じて、進行中のプログラムや新しい取り組みに割り当てられる。さらに以下のリーンなプラクティスを導入すると、企業が経済面の目標を達成するのに役立つ。

  • リーン-アジャイルな予算編成。予算の項でも説明するが、アジャイルリリース列車ごとに独自の予算枠があり、この予算枠は1年に2度見直される。予算に関する権限を(ビジネス責任者の指揮下であっても)列車の意思決定者に引き渡すことで、新しい取り組み(フィーチャー)ごとに憲章を制定する必要がなくなる。これによりオーバーヘッドが減り、ストップとスタートを繰り返してプロジェクトが途切れ途切れになることを避けられる。また、列車に割り当てられた予算の制約の中で、必要に応じてすばやく意思決定ができるようになる。それでもやはり、プログラムエピックの場合は範囲が広いため、ある程度のPPMの承認が必要となる。
  • 要望の管理と継続的な価値のフロー。どのようなシステムでも負荷をかけすぎると処理能力が落ちる。ポートフォリオで要望を管理できないと、チームや個人が複数の取り組みの間でスラッシングを起こし、「過剰なWIP」という目に見えない敵によって速度や品質が制限されてしまう。既存プログラムの作業を可視化し、アジャイルなプログラムの速度を理解することで、WIPを管理し、効率的なプロダクト開発フローを保つことができる。この管理とサポートは、アーキテクチャーおよびポートフォリオカンバンシステムを実装し、ポートフォリオバックログを保守し可視化することで行う。
  • エピックと軽量ビジネス企画。今後生じる横断的作業を可視化し経済的根拠を示すために、ビジネスエピックアーキテクチャーエピックを定義して分析する。その際、それぞれのエピックの裏付けとして軽量ビジネス企画を使用する。軽量ビジネス企画は、エピックオーナーによって作成されるもので、理由付けや分析や優先順位付けに使用できるが、過度の詳細化はしないで済む。

プログラム管理

プログラム管理は、プログラムの実行を成功させるための支援と指導を行う。この責任は主にアジャイルリリース列車とリリース列車エンジニア(RTE)が担うが、ポートフォリオ全体にわたる成功したプログラム実行パターンの作成と収集、適用をPPMが手伝うこともある。多くの組織では、RTEはPMOに加わっていて、そこでベストプラクティスや共通のプログラム測定基準やレポートを共有することができる。あるいは、開発組織の直属の場合もある。

ただしどちらの場合でも、従来型の組織と比較すると、アジャイルプログラム管理は、従来型の職務の多くをプログラムに委任する。例を以下に示す。

  • アジャイルリリース列車の自己管理。従来型のプロジェクトやプログラムの憲章や管理作業は、価値のストリームをベースとした自己管理および自己組織化するアジャイルリリース列車に置き換わる。アジャイルリリース列車のそれぞれが、利害関係者に対して継続的な価値のフローを提供する。
  • 非中央集権的ローリングウェーブ計画。中央集権的な計画は、非中央集権的なプログラムとチームをベースとしたローリングウェーブ計画に置き換わる。この計画は、日常的なリズムをベースとしたリリース計画策定作業で作成される。
  • アジャイルな見積もりと計画。非常に詳細なビジネス企画を作成し、非常に早い段階で要求を具体化し、非常に細かいWBS(work breakdown structure)を作成するという従来のやり方は、アジャイルな見積もりと計画に置き換わる。アジャイルな見積もりと計画では、ストーリーポイントという単位を使用し、それをチーム、プログラム、ポートフォリオを通じて一貫して適用する。

ガバナンス

ガバナンスという機能はアジャイルでも存在する。そうでなければ、費やした投資についてのポートフォリオレベルでのフィードバックも得られなければ、プログラムの報告もなく、セキュリティや、規制、標準、品質、リリースなどに関する重要な要求を確実に伝えて妥当性を確認する手段もなくなる。ガバナンスについては、測定基準およびライフサイクルマイルストーンという面から検討することができる。これについて以下で説明する。

測定基準

SAFeでは、ポートフォリオ全体の状況を評価するのに使用できる、さまざまなメトリックスについての手引きを提供している。その中には、ポートフォリオレベルの測定基準(ポートフォリオメトリックスを参照)とプログラムレベルの測定基準(ARTメトリックスを参照)が含まれている。

ライフサイクルガバナンス

さらに、PMOまたはPPMがソフトウェア開発ライフサイクルの手引きの作成やサポートにかかわっている場合には、その手引きでインクリメンタルな開発と顧客への早期のフィードバックを推奨しサポートしているはずである。従来のマイルストーンの代わりに、アジャイルなマイルストーンとしてプログラムインクリメント(PI)とリリースを採用することを推奨したい。その様子を図4に示す。

Figure-4-Agile-Program-Milestones-1024x410

図4. アジャイルなプログラムのマイルストーンは、PIと、頻繁に行われるソリューションのリリースである

リリース列車の憲章が承認された後、もっとも重要な内部マイルストーンは、リリースとリズムベースのPIである。これらは定量的なメトリックス、顧客からのフィードバック、検査と適応の振り返りサイクルによって、継続的に改善される。


さらに知りたい場合

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

[2] Thomas and Baker, DTE Energy. Establishing an Agile Portfolio to Align IT Investments with Business Needs. 2008.

Last update 24, July, 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.