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

本章では、複数のプロダクトを同時に開発している組織において、限られたリソース（資金や開発チーム）をどのように配分し、どのプロダクトをどの順番で作るべきかを決定する「ポートフォリオプランニング」について解説します。

16.1 概要

ポートフォリオプランニングとは、ポートフォリオバックログのアイテム（新しいプロダクトのアイデアや大規模な取り組み）を、どの程度の期間で進めていくかを決定する作業です。

• タイミング: 一度きりではなく、継続的かつ定期的に行われる終わりのない作業です。
• 参加者: ビジネスの方向性を持つステークホルダー、各プロダクトを代表するプロダクトオーナー、そして実現可能性を判断するシニアアーキテクトや技術的なリーダーが参加します。
• プロセス: エンビジョニング（構想）された新プロダクトのデータ（コスト、想定利益、リスクなど）をインプットとします。それを評価し、開発リソースを割り当てる「承認された（アクティブな）プロダクト」と、今はやらない「保留されたプロダクト」に分類（アウトプット）します。

16.2 スケジューリングの戦略

承認された複数のプロダクトを、どのような順番（スケジュール）で開発チームに渡していくか（スケジューリング）は、組織の経済性に直結します。

ライフサイクル収益で最適化する

• スケジューリングの最大の目的は、個々のプロダクトの利益を個別に考えるのではなく、ポートフォリオ全体の「ライフサイクル収益」を最大化することです。
• そのためには、単なるROI（投資収益率）だけでなく、遅延コストの概念を導入する必要があります。

遅延コストを算出する

プロダクトのリリースが遅れることで「どれだけの経済的損失（失われる利益や増大するコスト）が発生するか」を月単位などで算出します。

• 例:
  • プロダクトA：ROI 20% / 遅延コスト 月5千ドル
  • プロダクトB：ROI 15% / 遅延コスト 月7万5千ドル
• ROIだけを見ればプロダクトAを優先したくなりますが、遅延コストを考慮すると、プロダクトBを後回しにした際の損失（月7万5千ドル）が甚大です。したがって、組織全体としてはプロダクトBを優先してスケジューリングするという経済的に合理的な判断が可能になります。

見積もる時は正確性であって、精度ではない

ポートフォリオレベルの巨大なアイテムを見積もる際、詳細な数値（精度）を求めることは不可能です。

• まだ詳細がわからない段階で「130万5千ドルかかる」といった精緻な数字を出しても意味がありません。
• 必要なのは「だいたい合っている（正確性）」ことです。そのため、ポートフォリオの見積もりには 「Tシャツのサイズ（XS, S, M, L, XL）」 のような、大まかな相対サイズの指標を用いるのが効果的です。
  • 例：Sサイズなら「2万5千ドルから5万ドル」、Lサイズなら「12万5千ドルから35万ドル」といった具合です。

16.3 インフローの戦略

ポートフォリオバックログに新しいプロダクトをいつ、どのように追加するか（インフロー）を管理する戦略です。組織のボトルネックを解消するために、以下の原則に従います。

経済的フィルターの適用

• エンビジョニング（構想）された新しいプロダクトのアイデアがすべてバックログに入るわけではありません。
• 組織の財政やリソースに合わせて「経済的フィルター」を適用し、十分な資金や見込みがないものは最初から弾く（バックログに入れない）必要があります。

追加と取り出しのバランスを取る

• バックログへの流入（インフロー）と流出（アウトフロー：開発着手）のバランスを保つことが重要です。
• レストランの予約と同じように、開発チームのキャパシティ（厨房の処理能力）を超えてアイテムを詰め込んでも、ただ渋滞（待ち時間）を生むだけで何のメリットもありません。

創発的なチャンスへのすばやい対応

• 市場の変化や法改正など、予期せぬ「創発的なチャンス」が起きたとき、1年に1度の年次計画に縛られていては対応が遅れます。
• スクラムでは、そうしたチャンスを既存の計画にすばやく割り込ませ、優先順位を組み替える柔軟性を持ちます。

小さなリリースを頻繁に行うための計画

• 巨大なプロダクトを一度にリリースしようとするのではなく、小さな単位に分割して頻繁にリリース（コンボイのような形式）するよう計画します。
• これにより、一部の機能だけでも早く市場に出し、ライフサイクル収益を劇的に向上させることができます。

16.4 アウトフローの戦略

ポートフォリオバックログからプロダクトをいつ取り出して、開発チームに渡すか（アウトフロー）の戦略です。

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

• 個々のメンバーの稼働率を100%にすること（ウェイターを常に忙しくさせること）を目的としてはなりません。
• 重要なのは、プロダクト（顧客）が待ち状態に陥らないように、作業の流れをスムーズにすることです。

WIPを制限する

• 組織が同時に開発するプロダクトの数（仕掛品：WIP）は、チームの能力（キャパシティ）に合わせて制限しなければなりません。
• キャパシティを超えて複数のプロダクトを並行開発させると、コンテキストスイッチによるムダが発生し、結局どのプロダクトの完成も遅れてしまいます。

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

• アーキテクトなど一部のメンバーの手が空いたからといって、見切り発車で開発を始めてはいけません。
• スクラムチーム全体（クロスファンクショナルなメンバー全員）の準備が整ってから一斉に開発をスタートさせることが重要です。

16.5 仕掛品の戦略

すでに開発が進行しているプロダクト（仕掛品）に対して、そのまま投資を続けるか、中止するかを定期的に判断します。

限界費用を使う

• 投資判断の際、過去に投じた開発費用（サンクコスト）に引きずられてはいけません。
• 「あといくらの追加投資（限界費用）で、どれだけの価値が得られるか」という未来の視点だけで、開発を継続するか、ピボット（方向転換）するか、打ち切るかを判断します。

16.6 終わりに

ポートフォリオプランニングとは、組織のリソースを「最も価値のあること」に集中させるための戦略的な活動です。次章（第17章）では、このポートフォリオに追加するための新しいプロダクトの構想を練る「エンビジョニング」について解説します。

---

エンジニアリングへの適用メモ

• 遅延コストの理解: 開発現場で「ビジネス側がなぜこのプロジェクトを急いでいるのか」が理解できない時、背後には「法改正対応」など固定期日型のペナルティ（莫大な遅延コスト）が関係していることが多々あります。この背景を知ることで納得感を持って開発に臨めます。
• WIP制限はチームを守る盾: 「これもやって、あれもやって」と降ってくる要求に対し、「チームのキャパシティ（WIP上限）を超えているため、どれかを保留にする必要があります」と論理的に交渉するための強力な武器になります。
• サンクコストの罠: 「せっかくここまで作ったから…」という理由で需要のない機能を作り続けるのは典型的なアンチパターンです。限界費用の考え方を持ち、潔く捨てる勇気を持つことがアジャイル開発では求められます。