ポートフォリオプランニング

ポートフォリオバックログのアイテム : プロダクトあるいはそのインクリメント (1 回分のリリース)、あるいはプロジェクト (ここではこれらすべてを 「プロダクト」 と呼ぶ)

概要

タイミング : 終わることのない作業 (プロダクトの開発や保守が続く限り)」

プロダクトプランニングの前に行うとは限らない

エンビジョニング (プロダクトプランニング) のアウトプットがポートフォリオプランニングの重要なインプットになる

エンビジョニングのデータを使って、どのプロダクトにどの程度投資するかを判断する

参加者 : 内部のステークホルダーや各プロダクトのプロダクトオーナー

必須ではないが、シニアアーキテクトや技術的なリーダーも参加することが多い

プロセス

インプットは、新しくエンビジョニングしたプロダクトと、仕掛中のプロダクト

アウトプットは 2 つ

アクティブなプロダクト群 : 承認されていてすぐに開発に入るものや、仕掛中で今後の継続開発も承認されているもの

アクティビティは 4 つ

スケジューリング

インフローの管理

アウトフローの管理

仕掛中のプロダクトの管理

スケジューリングの戦略 (適切な優先順位付けに有益)

3 つの戦略

ポートフォリオ全体のライフサイクル収益の総計を最大化する (個別最適ではない)

ライフサイクル収益に最も影響する 2 つの変動要因 : 遅延コストと存続期間 (作業量やプロダクト規模の代替)

Leffingwell による、遅延コスト算出のためのモデル

ユーザー的な価値、時間的な価値、リスクの削減 / 機会の確保の 3 つについて、それぞれ遅延コストを 1 (最低) から 10 (最高) までの数字で設定し、3 つの合計がそのプロダクトの遅延コスト

インフローの戦略 (ポートフォリオバックログにアイテムを追加するタイミングを決める際の指針)

経済的フィルターの運用

エンビジョニングのアウトプットをもとに、新しいプロダクトの開発を進めるか中止するかを決める

その組織の資金需要を満たすかどうかを確かめるアクティビティ

組織にとって適切な経済的フィルターを選ぶ

よい経済的フィルター

コストをはるかに上回る価値を生み出せる機会を素早く承認できるもの

それ以外の機会は (例外的なものを除き) 却下すべき

多くの組織では年次戦略的計画を立案している (第 3 四半期ごろ) → 次年度中に作業する予定のプロダクトの完全なリストができて、それらを一斉にポートフォリオバックログに追加することになる (手に負えない)

年次戦略は必要だろうが、その戦略で達成することの詳細をプロダクトレベルでまで決める必要はない

重大な決断を不確実な情報をもとにくだしてしまうことになるので、避けるべき

月に 1 度とか、四半期ごとに 1 度ぐらいの頻度にすべき

創発的な機会へのすばやい対応

創発的な機会 : 事前に想定できなかったことや、まず起こりえないと思われていたこと

発生する前に資金を投入する価値はないので、発生したあとに迅速に対応できるようにする (ポートフォリオバックログにアイテムを追加する頻度を高くするなど)

小さなリリースを頻繁に行うための戦略

経済面を考えると小さな単位で頻繁にリリースすることが不可欠

大きなプロダクトが資源を使うことで、ほかのプロダクトがキューに溜まってしまう (それらのプロダクトに遅延コストが発生する) → 大きなプロダクトがライフサイクル収益に大きな損失をもたらしうる

アウトフローの戦略 (ポートフォリオバックログのアイテムを取り出すタイミングを知る指針)

作業者の手待ちではなく、作業の手待ちに注目せよ

誰も手を付けてない作業の方が、何も作業がない要因よりずっとムダである

間違ったやり方 : ポートフォリオバックログの先頭のアイテムを取り出し、作業用の要因を割り当てる → 全員の稼働率が 100 % になるまで繰り返す

これだと全員が大忙しの状態になる

より良いやり方 : 新しいプロダクトの作業が円滑に流れること、かつ、それが仕掛中プロダクトの作業の流れを止めないこと

WIP を制限する

スクラムチームの数とそれぞれのチームがどの種類のプロダクトの作業をできるのか、という情報があれば、同時に何件のプロダクトに取り掛かれるかがわかりやすい (チームごとではなく人数などで考えると難しい)

チーム全員の準備が整うのを待つ

仕掛中のプロダクトの戦略 (現在進行中のプロダクトの開発を続行するか、ピボットするか、デリバリーするか、開発を打ち切るかを判断)

定期的に行う必要がある。 また、予想外のできごとに対して臨時に行うこともある

あるプロダクトに対して、意思決定の時点までに進められたあらゆる作業は 「埋没費用」

注目するのは、次の段階に進むための限界費用

これまでにいくら使ったかを一切無視して、次に進むための出費に見合うだけの見返りが得られるかどうか

選択肢は 4 つ (上から順に判断基準に照らしていく)

資金の追加投入に資するか？ → 維持 (プロダクトの開発をそのまま続ける)

必要最小限の機能が実装されているか？ → デリバリ (作業を止めて、そのプロダクトを出荷する)

別の道はあるか？ → ピボット (これまでに学んだことに基づいて、方向転換する)

ここまでなければ → 打ち切り