PIプランニング

Future product development tasks can’t be predetermined. Distribute planning and control to those who can understand and react to the end results.

—Michael Kennedy, Product Development for the Lean Enterprise¹

定義: PIプランニングは、共通のミッションとビジョンに向けてチームとステークホルダーがベクトルを合わせる、ART全体のケイデンスベースのイベントです。

PIプランニングとは何か？

PIプランニングは、ART内のすべてのアジャイルチームとリーダーシップが、共通のミッションとビジョン、およびコミットされたプランに対してベクトルを合わせるケイデンスイベントです。 PIプランニングはSAFeにとって不可欠なイベントです。

PIプランニングは、以下のような多くのビジネスベネフィットを提供します。

• すべてのアジャイルチームメンバーとステークホルダー間の対面コミュニケーションを確立できる
• ビジネスコンテキスト、ビジョン、チームやARTの PIオブジェクティブに合わせて、開発とビジネスゴールのベクトルを揃える
• 依存関係を特定し、チーム間、ART間のコラボレーションを促進する
• 過不足のないアーキテクチャと、リーンユーザーエクスペリエンス (UX) をガイドする機会をもたらす
• デマンドとキャパシティの釣り合いを取り、余分なWIP (仕掛かり中の仕事)を排除する
• 迅速な意思決定を促進する
• バリューがどこでいつ提供されるかの全体的で透明性のある視野を作成する

可能であれば、全員が対面で参加することが望ましいですが、 すべてのアジャイルリリーストレイン (ART) を同じ場所に集めることが常に実用的ではあるとは限りません。 もちろん物理的な対面でのプランニングにはベネフィットがありますが、重要なのは仕事を行う人が一緒に計画するということです。 物理的な存在が不可能でも、リアルタイムでバーチャルなプランニングは、ARTの全メンバーが参加している限り、効果的であることが証明されています。

どのようにPIプランニングの準備をするか？

PIプランニングは、準備、調整、コミュニケーションを要する需要なイベントで、 RTEがファシリテートします。 イベントの参加者には、ビジネスオーナー、プロダクトマネジメント、すべてのアジャイルチーム、システムアーキテクトとソリューションアーキテクト、その他のステークホルダーが含まれます。 RTEは、PIプランニングイベントを十分に前もってスケジュールし、参加を確実にします。 このイベントにおけるビジネスオーナーの積極的な参加は、予算支出に対する重要なガードレールを提供します。

PIプランニングへのインプットは以下が含まれます。

• ビジネスコンテキスト
• ロードマップとビジョン
• 最優先のフィーチャーとARTバックログ

成功したPIプランニングイベントは、主に2つのアウトプットを提供します。

• コミットされたPIオブジェクティブ - 各チームは、ビジネスオーナーによって割り当てられたビジネスバリューを持つPIオブジェクティブを作成する
• ARTプランニングボード - 新しいフィーチャーのデリバリーの日程、チーム間のフィーチャーの依存関係、および関連するマイルストーンを特定する

イベントが成功するためには、以下の3つの主要な領域での準備が必要です。

• 組織の準備
• コンテンツの準備
• ロジスティクスの準備

以下のセクションでは、これら3つの領域について説明します。

組織の準備

PIプランニングの前に、参加者、ステークホルダー、そしてビジネスオーナーの間で戦略のベクトルを合わせる必要があります。 重要な役割が割り当てられます。 これを事前に対処するためには、イベントの主催者は次のことを考慮しなければなりません。

• プランニングのスコープとコンテキスト - プランニングプロセスのスコープ（プロダクト、システム、技術分野）は理解されていますか？ どのチームが一緒にプランを立てる必要があるのか知っていますか？
• ベクトルを合わせる - ビジネスオーナーの間で優先事項について合理的な合意はありますか？
• アジャイルチーム - 私達の組織にはアジャイルチームがいますか？ 各チームには専任のメンバーと特定されたスクラムマスター/チームコーチおよびプロダクトオーナーがいますか？

コンテンツの準備

明確なビジョンとコンテキストを持つことは、適切なステークホルダーが参加できるようにするために同じくらい重要です。 したがって、PIプランニングには以下の要素が含まれていなければなりません。

• エグゼクティブブリーフィング - 現在のビジネスコンテキストを定義するブリーフィング
• プロダクトビジョンブリーフィング - プロダクトマネジメントが準備したブリーフィングで、ARTバックログのトップ10のフィーチャー
• アーキテクチャビジョンブリーフィング - 新しいイネーブラー、フィーチャー、現在および将来の状態のアーキテクチャ、そして次のPIに関連する非機能要件（NFR）を伝えるためのプレゼンテーション

ロジスティクスの準備

大勢の参加者をサポートするイベントを準備することは些細なことではありません。 この準備には、物理的に共有されたプランニングのためのスペースを確保すること、そしてリモート参加者や完全に分散されたPIプランニングの場合は、それに必要な技術インフラストラクチャへの投資も含まれます。 考慮事項には以下のものがあります。

• 場所 - プランニングが行われる各場所を、事前に準備する
• テクノロジーとツール - 分散型プランニングまたはリモート参加者をサポートするための情報と、ツールへのリアルタイムアクセスを可能にする
• コミュニケーション チャンネル - 主要および副次的なオーディオ、ビデオ、およびプレゼンテーションチャンネルを利用可能にする

この記事は、単一のARTのプランニング活動に焦点を当てています。 しかし、大規模なバリューストリームには、複数のARTとサプライヤーが含まれている場合があり、 複数のPIプランニングイベントの調整が必要になるかもしれません。 この大規模に調整する方法の詳細は、プランニング前の準備、および調整しデリバーするガイドの記事に記載されています。

どのようにPIプランニングイベントを実行するのか？

PIプランニングの標準的なアジェンダは、ビジネスコンテキストとビジョンのプレゼンテーションから始まります。 次に、チームブレイクアウトが続き、チームが次のPIのためにコミットされたオブジェクティブを基に、おおまかなイテレーションプランを作成します。 このイベントは、リリーストレインエンジニア (RTE)によってファシリテートされ、ARTの全メンバーが参加し、イノベーションとプランニング (IP) イテレーション中に行われます。

PIプランニングは、IPイテレーションと呼ばれる特別なイテレーションタイムボックス内で行われます。 これにより、アジャイルチームが他のイテレーションで行っているデリバリーのキャパシティに影響を与えることなく、計画を立てることができます。 PIプランニングは2日間にわたって行われますが、ARTが複数のタイムゾーンにわたるプランニングを行う場合は、このタイムボックスを延長することができます。

イベントは、図１のようなアジェンダに従って進行します。 以下のセクションでは、各項目の説明について説明します。

1日目のアジェンダ

• ビジネスコンテキスト - ビジネスオーナーまたはシニアエグゼクティブが、現在のビジネスの状況を説明し、ポートフォリオビジョンを共有し、既存のソリューションが顧客のニーズにどれほど効果的に対応しているかの見解を提示します。
• プロダクト / ソリューションビジョン - プロダクトマネジメントは、現在のビジョン（通常は今後のトップ10のフィーチャー）を提示します。 彼らは前回のPIプランニングイベントからの変更点と、関連するマイルストーンを強調します。
• アーキテクチャビジョンと開発プラクティス - システムアーキテクトがアーキテクチャビジョンを提示します。 また、シニア開発マネージャーが、テスト自動化、DevOps、継続的な統合、および継続的なデプロイメントなど、チームが次のPIで採用するアジャイルを支援する開発プラクティスの変更点を紹介することもあります。
• プランニングの背景説明とランチ - RTE (リリーストレインエンジニア)は、プランニングのプロセスと予想される成果を提示します。
• チームブレイクアウト #1– ブレイクアウトでは、チームごとに各イテレーションのキャパシティを見積り、フィーチャーを実現するために必要なバックログ項目を特定します。 各チームは、イテレーションごとドラフトプランを作成し、全体に見えるようにします。

このプロセス中で、各チームはリスクと依存関係を特定し、初期のチームPIオブジェクティブをドラフトします。 PIオブジェクティブには通常、「アンコミットオブジェクティブ」が含まれます。これらはプラン（例えば、これらのオブジェクティブのために定義され、含まれているストーリー）に組み込まれた目標ですが、未知数やリスクが多いために、チームによってコミットされていません。 アンコミットオブジェクティブは、時間があるときに行う追加の仕事ではありません。 むしろ、プランの信頼性を高め、ARTが達成できない可能性のあるオブジェクティブに対して、マネジメントに早期警告を提供します。 チームはまた、図３のようなフィーチャーと関連する依存関係をARTプランニングボードに追加します。

• ドラフトプランレビュー - 厳密にタイムボックスされたドラフトプランレビューの間に、チームはキャパシティと負荷、ドラフトPIオブジェクティブ、潜在的なリスク、依存関係を含む主要なプランニングアウトプットを提示します。 ビジネスオーナー、プロダクトマネジメント、その他のチームやステークホルダーがレビューし、意見を提供します。
• マネジメントレビューと問題解決 - ドラフトプランは、スコープ、人材、リソースの制約、および依存関係のような課題を提示する可能性があります。 問題解決の会議中に、マネジメントはスコープの変更交渉や、様々なプランニングの調整に合意することで他の問題を解決することができます。 RTE (リリーストレインエンジニア)は、達成可能なオブジェクティブに到達するために必要な決定を下すまで、必要に応じて主要なステークホルダーをまとめ、ファシリテートします。

注: ソリューショントレインでは、初日のプランニングの後に、追加のマネジメントレビューと問題解決ワークショップを行い、ART間の問題を対処することもあります。 又は、関係するトレインのRTE (リリーストレインエンジニア)同士が話し合い、ARTごとのマネジメントレビューと問題解決会議の問題を議論することもあります。 ソリューショントレインエンジニア (STE) がファシリテーターとなって、ART間の課題の解消をサポートします。

2日目のアジェンダ

• プランニングの調整 - 翌日、イベントはマネジメントがプランニングのスコープ、人材、そしてリソースへの変更を発表することから始まります。
• チームブレイクアウト #2 - チームはプランニングを続け、適切な調整を行います。 彼らは、図4に示すように、ビジネスオーナーがビジネスバリューを割り当てるPIのためのオブジェクティブを最終化します。

• ファイナルプランレビューとランチ - このセッションでは、全てのチームが、自分たちのプランをグループに発表します。 各チームの時間枠の終わりに、チームはリスクと阻害要因を述べ、それらのリスクを後のROAM分類エクササイズで使用するためにRTE (リリーストレインエンジニア)に提供します。 その後、チームはビジネスオーナーにプランが受け入れ可能かどうかを尋ねます。 プランが受け入れられた場合、チームは自分たちのチームPIオブジェクティブシートを部屋の前に持ってきて、全員がリアルタイムで集約されたオブジェクティブを確認できるようにします。 ビジネスオーナーが懸念を抱いている場合、チームは特定の問題に対処するためにプランを調整することができます。 その後、チームは修正されたプランを提示します。
• ART PIリスク - プランニング中、チームは自分たちのオブジェクティブを達成する能力に影響を与える可能性のあるリスクと阻害要因を特定しました。 これらは、全体のトレインの前で、より広範なマネジメントコンテキストで解決されます。 １つずつ、リスクが誠実さと透明性を持って議論され、対処され、次のカテゴリーのいずれかに分類されます。
  • Resolved (解決済み) - チームはリスクがもはや懸念事項ではないことに同意する
  • Owned (オーナーあり) - PIプランニング中に解決できないため、トレインの誰かがリスクの責任を引き受ける
  • Accepted (甘受する) - リスクの中には、理解し受け入れなければならない事実や潜在的な問題がある
  • Mitigated (軽減策あり) - チームはリスクの影響を軽減するプランを特定する

• 二部構成の自信投票 – ファイナルプランレビューの準備状況を評価するために、各チームは『フィストオブファイブ』と呼ばれる投票メカニズムを、物理的またはデジタルツールで実施します。 この最初の投票は、通常チームブレイクアウト #2中に行われます。 さらに、ARTのPIリスクが解決された後、ART全体でも『フィストオブファイブ』を物理的またはデジタルツールで実施します。 平均が3本の指以上であれば、マネジメントはコミットメントを受け入れる必要があります。 平均が3本未満の場合、チームはそのプランを見直します。 2本以下の指で投票した人は、懸念を表明できるようにする必要があります。 この懸念は、リスク一覧に追加されたり、リプランが必要になったり、有益な情報が得られたりする可能性があります。

• プランの再検討 - 必要に応じて、チームはARTが高い信頼レベルに達するまでオブジェクティブを再検討します。 この追加のプランニングは、タイムボックスを守ることよりも、ベクトルを合わせることと、コミットメントが重視される場面の一つです。
• レトロスペクティブのプランニングと次のステップ - 最後に、RTEは、PIプランニングイベントの簡単なレトロスペクティブを行い、うまくいった点、改善が必要な点などのフィードバックを収集することで、今後のPIプランニングイベントを改善できるようにします。

PIプランニング終了後のステップ

次のステップ - 通常、次のステップについてのディスカッションが続き、チームへの最終指示が含まれます。これには以下のようなものがあります。

• 必要であれば、プランニングに使用された部屋の清掃をする
• アジャイルライフサイクル管理（ALM）ツールにチームのPIオブジェクティブとストーリーを入力する
• レビューチームとARTイベントカレンダーの確認する
• イテレーションプランニングとチームシンクの場所とタイミングを決める

プランニングイベントの後、RTE（リリーストレインエンジニア）と他のARTステークホルダーは、個々のチームのPIオブジェクティブを一連のART PIオブジェクティブ（図6）にまとめ、これを使用して対外的なコミュニケーションを取り、目標に向けた進捗状況をトラックします。

プロダクトマネジメントは、ART PIオブジェクティブを使用してロードマップを洗練し、次のPIの予測を改善します。

チームは、次のPIのために入力済みのバックログを持ってPIプランニングイベントを後にします。 そして、PIオブジェクティブ、計画、およびリスクを通常の作業エリアに持ち帰るか、デジタルツールを更新して計画を正確に反映させます。 ARTのリスクはRTEが保持し、リスクを所持または軽減する責任者が情報を把握し、リスクを積極的に管理していることを確認します。 ARTプランニングボードは、依存関係とマイルストーンのマネジメントを可能にするために、PI全体を通して、物理的またはデジタルで維持されます。

最も重要なことは、ARTがPIを実行し、新たな知識が出現するにつれて必要に応じて進捗状況をトラックし、調整することです。 PIの実行は、すべてのチームが最初のイテレーションのためのプランニングを行い、その出発点としてPIプランを使用することから始まります。 それは、後続のイテレーションプランニングプロセスに新鮮なインプットを提供します。 PIプランニング中に作成されたプランは、詳細なストーリーレベルの受け入れ基準を考慮していなかったため、チームは最初とその後のイテレーションプランを調整する可能性が高いです。

---

参考資料

[1] Kennedy, Michael. Product Development for the Lean Enterprise. Oaklea Press, 2003.