Program Portfolio Management

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

– スティーブン・コヴィー

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

プログラムポートフォリオ管理 (PPM) は、SAFe内で最も上位の戦略と受託者意思決定責務を負う。大企業では、複数のSAFeポートフォリオがあるかもしれない。それぞれビジネス単位や部門レベルで、複数の取り組みを管理する役割を果たす。各SAFeポートフォリオはPPM機能を持つ。PPM機能、すなわち、戦略と投資財源、プログラム管理、およびガバナンスに責務を持つのは、エンタープライズビジネス戦略と技術と財務上の制約を理解し、企業の全体戦略に自分の担当分を定義して実装することに責務を持つ、ビジネス管理者および役員である。これらの人々は、通常、その責務を遂行する際にプロジェクトまたはプログラムマネジメントオフィス(PMO)の協力を得る。PMOはプログラムの遂行とガバナンスを導くという責務を共有する。この職務を担当する肩書きや役割は企業によって異なるだろうし、場合によっては正式な名前や部署がない場合もある。それでも、成功のためには、責務を効果的に達成することが欠かせない。

詳細

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

Figure 1. Primary responsibilities of Program Portfolio Management
図1. プログラムポートフォリオ管理の主な責務

この責務を果たすため、肩書きや役割は組織によって異なるだろうし、場合によって、PPMのための正式な部署がない場合もある。このグループや役割の名前はあまり重要ではない関心事で、成功のためには、責務を効果的に達成することが欠かせない。

プログラムポートフォリオ管理の責務

PPMは、会社の投資と戦略の指針となる戦略テーマを制定して伝え、関連する価値のストリームを決定し、予算を割り当て、横断的なポートフォリオバックログエピックを定義して優先順位を付け、KPIやポートフォリオコンテキストの他の側面を通じ、行った投資と進捗についてビジネス側に報告する(ポートフォリオコンテキストについて、企業をご参照))といった責任を持つ。

リーン-アジャイルへの移行中には、PPMはアジャイルと従来型のウォーターフォールとの両方のプログラムについてこのような責務を負うこともある。その様子を図2に示す。

Figure 2. PPM responsibilities can cover both Agile and waterfall programs
図2. PPMは必要に応じてアジャイルとウォーターフォールの両方のプログラムの責務を負う

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

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

Figure 3. Seven transformational patterns for Lean-Agile Program Portfolio Management
図3. リーン-アジャイルなプログラムポートフォリオ管理のための7つの変換パターン

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

戦略と投資財源

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

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

プログラム管理

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

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

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

ガバナンス

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

ポートフォリオコンテキスト

ポートフォリオコンテキストは以下を含む:

KPI。 KPIには、ROI、市場シェア、顧客ネットプロモーションスコア、革新会計などの定量的および財務的測定が含まれる。ポートフォリオ、価値のストリーム及びプログラムメトリックスについて、メトリックスをご参照。

定性的なデータ。定性的データには、強み、弱み、機会および脅威(SWOT)分析、そして最も重要なこととして、ポートフォリオの利害関係者のソリューション、市場およびビジネス知識の蓄積が含まれる。

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

PPMがSAFe原則 (すなわち 原則4 – 素早い統合された学習サイクルでインクリメンタルに構築する 及び 原則5 – 動くシステムの客観的な評価を基にマイルストーンを設定する)の手引きの作成やサポートにかかわっている場合には、その手引きでインクリメンタルな開発と顧客への早期のフィードバックを推奨しサポートしているはずである。

従来のマイルストーンの代わりに、アジャイルなマイルストーンとして(PI)とインクリメンタルなリリースを採用することを推奨したい。その様子を図4に示す。

Figure 4. Agile program milestones include PIs and frequently releasable solutions
図4. アジャイルなプログラムのマイルストーンは、PIと、頻繁に行われるソリューションのリリースである

 

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


さらに知りたい場合

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

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

Last update: 5 January 2015