Portfolio Backlog

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

– W. Edwards Deming

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

ポートフォリオバックログは、SAFeの最上位のバックログである。戦略テーマに取り組み、ビジネスの成功に欠かせない競合との差別化や業務の効率を生み出す一連の総合的ポートフォリオソリューションを作成するために必要となる、この後のビジネスエピックやイネイブラーエピックを保持するメカニズムである。

ポートフォリオバックログに到達するエピックは、カンバンシステムを通過する際に、レビューされ、分析され、実装を承認されている。分析ステップで、エピックの見積もりを行う。見積もることによって、ポートフォリオレベルで必要な予測性が得られ、そして、企業に効果的な計画策定と実行をサポートするためにどのくらいがあれば十分かというを与える。

詳細

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

Figure 1. The Portfolio-Backlog holds Epics ready for implementation
図1. ポートフォリオバックログによって、実装に準備できたエピックを保持する

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

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

ポートフォリオバックログのインプット

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

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

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

Figure 2. Business and enabler epics in the Portfolio Backlog
図2. ポートフォリオバックログ内のビジネスエピック及びイネイブラーエピック

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

予測

企業が変化する市場機会に迅速に対応できるよう、SAFeは企業の適応性を高める。また、期日を固定し、スコープを変動させることは、アジャイル納品に最も効果的に思える。これにより、頻繁なインクリメントの納品がサポートされ、スコープ、時間及びリソースといったすべての側面が固定される場合と比べ、必然的な品質のトレードオフが避けられる。また、企業では、アジャイルかどうかにかかわらず、将来に対する感覚が必要である。

  • 企業、及び企業のパートナーや顧客が今後のリリースに計画しなければならない
  • ビジョンは進化する企業戦略を定義し、追跡しなければならない
  • ロードマップは予測された納品物に戦略的意図を反映する

したがって、効果的なアジャイル予測を行う能力は、主要な経済的要因であり、リーン・アジャイルな企業の重要な能力である。

予測には見積もりが欠かせない

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 3 December 2015