イノベーションは顧客からではなく、製作者から生み出す。

W. Edwards Deming

ポートフォリオバックログの概要

ポートフォリオバックログは、SAFeの最上位のバックログである。ビジネスの成功に欠かせない競合との差別化や業務の効率を生み出す一連の総合的ポートフォリオソリューションを作成するために必要となる、この後のビジネスエピックやアーキテクチャーエピックを保持するメカニズムである。ポートフォリオバックログに到達するエピックは、カンバンシステムを通過する際に、レビューされ、分析され、実装を承認されている。

詳細

ポートフォリオバックログには、実装するよう承認されたエピックが、優先順位を付けられて保持される。これらのエピックは、図1に示すように、ビジネスエピックまたはアーキテクチャーエピックのカンバンシステムにおいて、「ゴー」と承認されている。

 

Figure 1. Overview of Portfolio Backlog as part of the Portfolio Vision 2

図1. ポートフォリオビジョンのポートフォリオバックログ部分の概要

 

これらのエピックは、ビジネスチャンス、合併・買収、技術の変化や衰退といった重要な事柄がきっかけとなって生じ、共通インフラを共有したり(「JBossアプリケーションサーバーに移行する」など)共通のビジネス動作を実装する(「スイート内の全プロダクトにまたがるシングルサインオンを実装する」など)といったことを行うための、さまざまなアジャイルリリース列車を連結するのに一般的に使われる承認済みの取り組みを表す。その目的は、複数のアジャイルリリース列車や価値のストリームの顧客向けに、より高い価値をもたらす調和したソリューションを作成することである。

プログラムポートフォリオ管理の下で、ポートフォリオバックログは、アイデアと実装の間の最後の関門となる。低コストの保管領域であり(保守はあまり必要ない)、ここに置くことで、承認済みで実装の処理能力が空くのを待っているビジネスエピックおよびアーキテクチャーエピックが見えやすくなる。ポートフォリオバックログ内のエピックは、定期的に見直され、該当するアジャイルリリース列車の処理能力の空きに応じて実装スケジュールに組み込まれる。

ポートフォリオバックログの入力

エピックは、範囲が広く、多くは横断的な性格を持つため、通常は多額の投資が必要であり、開発プログラムとビジネスの成果の両方に相当な影響を及ぼす。そのため、エピックをポートフォリオバックログに入れる前に、まずビジネスまたはアーキテクチャーのカンバンシステムにおいて、実現可能性やROIの見込みを分析しなければならない。この境界に達したエピックは、カンバンシステムの責任者から「ゴーの推薦」を得るのに必要な特定、詳細化、分析が済んでいるという点で、成熟した状態にあると言える。

ポートフォリオバックログの管理

ただし、図2に示すように、各エピックはバックログ内に唯一存在するエピックではないため、実装スケジュールに組み込むにはさらなる理由付けが必要である。そのため、エピック間で相対的な順序付けをするロジックを検討する必要があるが、一般には最後にWSJFによる優先順位付けを行う。この場合、ビジネスエピックとアーキテクチャーエピックは、通常、それぞれの種類に割り当てられた処理能力の範囲内で、互いとのみ比較される。その中で最上位に上がってきたものは、実装準備ができた状態になり、列車の処理能力に空きができればポートフォリオバックログからプルされる。

 

Figure 2. Exploded View of Portfolio Backlog

図2. ポートフォリオバックログ内のビジネスエピックおよびアーキテクチャーエピック

[注: ポートフォリオバックログの前段階の軽量ビジネスケースには、より強固な優先順位付けプロセスが適用される。これは単に最終的な検討であり、エピックはここで、同様にそのプロセスをくぐり抜けてきた他のエピックと比較される。ただし、作業規模の他に、プログラムの処理能力の空き状況も検討しなければならない。実装に使用できるリソースのレベルに作業期間(WSJFの分母)が大きく依存するためである。]

ポートフォリオ予測

SAFeの他の部分で説明したように、アジャイルチームでは、ストーリーポイントと相対見積もりを用いて、ユーザーストーリーの規模と期間を手早く見積もる。プログラムレベルでは、プロダクト管理者システムアーキテクトが(適宜プロダクトオーナーやチームと協力して)、過去のデータを利用して、フィーチャーの規模をストーリーポイントでかなりすばやく見積もることもできる。また、見積もりにさらに投資することが経済的に妥当であれば、規模の大きなフィーチャーをストーリーに分解して、より細かく検討することができる。

さらに、上の図2に示したように、フィーチャーの見積もりは、ポートフォリオバックログ内でエピックの見積もりにまとめられるため、実装が始まる前にエピックの経済面を理解することができる。

最後に、これは最も重要なことだが、プログラムの速度が分かっていると、ポートフォリオ管理者などの計画担当者は、処理能力を割り当てることで、さまざまなシナリオにおいてポートフォリオエピックにどれだけの時間がかかるかを見積もることができる。その結果、下の図3に示すように、長期間の計画や予測の妥当なモデルを作成できる。

Figure 3. Portfolio Forecasting with epics size estimates, capacity allocation, and program velocities

図3. エピックサイズの見積もり、処理能力の割り当て、プログラムの速度によるポートフォリオ予測

アジャイルであろうとなかろうと、大規模ソフトウェアプログラムの見積もりを高精度で行うための魔法の杖は存在しない。SAFeでは、ウォーターフォール開発手法でこれまで適用されてきた見積もり/計画メカニズムよりも信頼性が高いと証明されたメカニズムを提供している。

実装への移行

該当するプログラムでリソースに空きができると、優先順位の高いエピックがポートフォリオバックログから実装へと移される。エピックオーナーは、このプロセスを先に進め、プログラムのプロダクト管理者と協力してエピックをプログラムエピックフィーチャーに分解したり、それぞれのプログラムバックログ内でそのフィーチャーの優先順位を付ける。これを行うと、エピックはプログラムバックログ内のフィーチャーに変換されるためプログラムバックログ内には存在しなくなるが、それでもエピックの進捗についてのレポートを作成することは有用である。これについてはポートフォリオメトリックスで説明する。


さらに知りたい場合

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

Last update 25 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.