PI Planningとは?
PI Planningはどのように実施するのか?
続く5つのセクションでは、次の問いを詳しく解説します:
- PI Planningを成功させるとはどういうことか?
- 優れたバーチャル/分散/リモートPI Planningをどう実施するか?
- PI Planningの課題をどう克服するか?
- PI Planningの準備チェックリストとは?
- PI Planningのテンプレートはありますか?
最後に、PI Planningにそのまま使える、編集・ダウンロード可能なステップバイステップガイド をご紹介します。
PI Planning 101 PI Planningを成功させるとはどういうことか?
実際、SAFeの考え方に立てば、PI Planningはスケールドアジャイルフレームワークにおける唯一無二の要となる要素です。
SAFeの解釈を借りるなら、
PI Planningは、すべてのARTにとって不可欠な、ケイデンスに基づく同期ポイントです。
ここから何が読み取れるでしょうか。
PI Planningの成功が、Agile Release Train(ART)のチームにもたらすものは次のとおりです。
- 同期、
- (チーム間およびART間の)コラボレーション、
- アラインメント(ビジネスコンテキストのワークフロー、目標、ビジョンなど)、
- 人的ネットワーク、
- システムアーキテクチャの評価、
- 過剰な仕掛り作業(WIP)の排除、
- 意思決定の効率化、
- 予測可能性とアジリティを支える透明性。
成功したPI Planningイベントは、これらすべてを満たしたうえで、イテレーションの最後に「動くソフトウェア」を示すことができます。
端的に言えば、次の2つのアウトプットを生み出せていれば、PI Planningイベントは目標を達成したと言えます。
- コミットされたPI Objectives
- PI Objectivesとは、ARTを構成する各チームが作成したSMARTな目標の集合で、Business Ownersがビジネス価値を割り当てます。PI Objectivesへのコミットメントは、ARTにとって最も重要な到達点です。
- Program Board
- ARTの状況を最も正確に映し出すデータの集約で、新しいフィーチャーのデリバリー日、チーム間のフィーチャー依存関係、関連するマイルストーンを可視化します。ARTにとっての水晶玉とも言える存在です。
- チームブレイクアウトでユーザーストーリーをタスクに分解する
- イテレーション計画とチームのPI Objectivesを作成する
- リスクを特定し対処する
- Confidence Voteを行う
- ARTのアーキテクチャビジョンを提示する
- チーム間の依存関係とリスクの整理を支援する
- ARTの活動、システムデモ、Inspect and Adaptに向けたチームの準備を支援する
- 正規化された見積りの確立をチームに導く
- フィーチャーとケイパビリティの見積り方法の理解を助ける
- バックログの優先順位付けを行う
- ソリューションで提供予定のフィーチャーを示すビジョンを提示する
- 関連する今後のマイルストーンを共有する
- フィーチャーをユーザーストーリーに分解する
- プランニングのプロセスと期待される成果を提示する
- マネジメントレビュー、問題解決セッション、レトロスペクティブをファシリテートする。そのため、PI Planningセッションの実施はRTEの責任となる
この範囲を踏まえ、PI Planningは四半期ごとに実施され、一般的なスケジュールは次のとおりです。
- 第1四半期のPI Planning:12月
- 第2四半期のPI Planning:3月
- 第3四半期のPI Planning:6月
- 第4四半期のPI Planning:9月
これらは定期的かつ固定されたスケジュールに沿って、前もって計画されます。招待も早めに送付し、準備が滞りなく整うようにします。
分散型やリモートのPI Planningでもアジェンダは変わりませんが、イベントのスケジュールは多くの要因に左右されます。それらは次のセクションで解説します。
ボーナスTIP I
分散PI Planning 優れた分散/リモートPI Planningをどう実施するか?
- 情報を伝える最も効率的で効果的な方法は、開発チームの内部および開発チームへの対面での会話である。
一般的な認識とは異なり、PI Planningの本質的な強みは、チームが同じ場所に集まることにあるわけではありません。物理的な距離の有無が、スムーズで透明性の高いコミュニケーションの妨げにならないところまで、推進の仕組みを設計し強化することにこそ本質があります。
- 複数拠点・多文化のチームを対象とした運営ロジスティクスの負担、
- パンデミックを踏まえた地域ごとの渡航制限
- 慣れない環境で心理的安全性を確保することの難しさ
- イベントに十分な広さと適切さを備えた会場の確保、
- そして忘れてはならない、これら大がかりな手配にかかる費用と時間のコスト。
もちろん、バーチャルなPI Planningの実施も簡単ではありません。しかし、アジャイルチームが仕事の面でも人としても認められていると感じられる場を丁寧に設計できれば、リモートイベントのROIは対面を上回ることさえあります。
本ガイドの各セクションとボーナスTIPで紹介する経験知と実践的なノウハウを、ぜひ持ち帰ってください。
- プランニング拠点:必要な拠点数を見極め、分散する拠点をできるだけ少なくします。
- PI Planningアジェンダ:参加チームの複数のタイムゾーンに配慮した、包括的なアジェンダを作成します。
- 設備:プランニングを実施するのに適した物理スペースを用意します。
- ワーキングアグリーメント:参加者のニーズに応え、ARTの一人ひとりにとって最適な体験にします。
- ツール:幅広いプランニング活動を支える適切なテクノロジーを導入します。
- ファシリテーション:分散PI Planningを成功に導きます。
2つのタイムゾーンを対象に、こまめな休憩を挟みながら3つの半日に分けた、リモートPI Planningのスケジュール例です。
ボーナスTIP II
PI Planning:課題 PI Planningの課題をどう克服するか?
- ART全体の透明性とアラインメント、
- 効果的なコラボレーション、
- 効率的でインパクトのある意思決定、
- 意味のあるコミュニケーション、
- 目的意識のあるエンゲージメント。
実行面では、これらの課題は次のような形で現れます。
- データの統合不足、
- 時間がかかり誤りも生じやすい手作業での情報収集、
- ビジネス目標を見失うこと、
- 適切でない時間帯のセッション、
- 長時間で負担の大きいセッション、
- 技術的なトラブル、
- 準備不足のセッション運営。
Jiraを使うチームを抱えるRTEにとって、対面・リモートを問わずPI Planningを実施する際の最大の課題は、プランニングボードとJiraの間でスムーズかつ手間のかからないリアルタイム双方向連携を実現することです。
プランニングボードに可視化ツールを使う組織もあります。一見するとPI Planningを手軽に実施できる方法に見えますが、イベント中やイベント後に深刻な問題を招きかねません。
よくあるつまずきは次のとおりです。
- Jiraのパフォーマンス
PI Planning中に、多数のカードが連携した可視化ボードへ大勢が同時にアクセスすると、Jiraのパフォーマンスが著しく低下する事例がSAFeコミュニティで報告されています。
- 編集権限の制限
可視化ツールはもともとPI Planningのために設計されていないため、いくつかの制約があります。その1つが、ボードを編集できるユーザー数の上限です。
- データの手作業での移行
ALMツールとの間でデータをバックアップし、手作業で移す必要があり、時間と正確性の両面でコストが生じます。
アジャイルをスケールするうえで、これらの課題には大きな代償が伴います。失われる時間や金銭的コストは、その中で測定できる一部にすぎません。メンバーの落胆やモチベーション低下、ARTのチーム間で生じる信頼の欠如は見過ごされがちで、多くの場合は取り返しがつきません。幸い、Kendisを使えば、これらの課題は難なく解消できます。
ボーナスTIP III
PI Planning:準備チェックリスト PI Planningの準備チェックリストとは?
SAFeのガイダンスによれば、PI Planningの準備で検討すべき主要領域は3つあります。
- 組織面の準備:戦略のアラインメント、チームとトレインの編成
- コンテンツ面の準備:マネジメントと開発の準備状況
- ロジスティクス面の準備:イベントを成功させるための考慮事項
この3つのテーマをもとに、特に押さえておきたい確認事項をまとめました。
- プランニングのスコープとコンテキスト:プランニングの対象範囲(プロダクト、システム、技術領域)は特定できていますか。どのチームが一緒に計画すべきか把握できていますか。
- ビジネスのアラインメント:Business Ownersの間で、優先順位に関する共通理解はできていますか。
- アジャイルチーム:すべてのアジャイルチームに専任メンバーがいて、各チームのScrum MasterとProduct Ownerが決まっていますか。
- エグゼクティブブリーフィング:参加者全員に、現在のビジネスコンテキストを共有するブリーフィング
- プロダクトビジョンのブリーフィング:プロダクトマネジメントが、Program Backlog上位10件のフィーチャーについて説明しますか。
- アーキテクチャビジョンのブリーフィング:CTO/エンタープライズアーキテクト/システムアーキテクトが、新しいEnabler、フィーチャー、非機能要件(NFR)について説明しましたか。
- 拠点:プランニング拠点はいくつ必要ですか。
- テクノロジーとツール:ALMツールと連携したKendisが、リアルタイムのPI Program Board、PI Objectives、リスクのROAM、依存関係管理、そしてScrum of Scrums、Confidence Vote、Inspect and Adaptといった各種セレモニーをカバーします。分散プランニングやリモート参加者を支えるために、他にどんなツールが必要でしょうか。(ヒント:必要ありません。これで準備万端です。)
- コミュニケーションチャネル:質の高い体験を実現するための、音声・映像・プレゼンテーション・会話のメインおよび予備チャネル。
このチェックリストが、ARTの参加者全員の貢献に大きく依存していることにお気づきでしょう。前述のPI Planning参加者と役割のセクションにも、それが表れています。
ボーナスTIP IV
PI Planning:ステップバイステップガイド PI Planningのテンプレートはありますか?
PI Planningの準備をより万全にしていただくため、ボードのセットアップ、ユーザーの招待、そして当日までに必要な重要ステップの完了を確認できる、ステップバイステップガイドをご用意しました。
このガイドを読めば、あなたとチームがどこにいても、KendisがPI Planningをどのように支援するのかを一望できます。

PI Planning前
- 01 RTEがKendisでPIボードをセットアップし、PIの日程と期間を設定します
- 02 Jiraボードと接続します
- 03 色分けしたチームを作成します
- 04 Program Incrementのスプリントを定義します
- 05 JiraフィルターやJQLを使い、Jiraのパフォーマンスに影響を与えずに、フィーチャーをKendisボードへ取り込みます
- 06 フィーチャーにひも付いたJira上のチームストーリーは、自動的にボードへ取得されます
- 07 Kendisのチームを、それぞれのJiraボードにマッピングします
- 08 続いて、チームをKendisボードに招待します
- 09 ビジネス価値によってビジネスコンテキストを定義し、フィーチャーの優先順位付けを行って、プランニングの準備を始めます。
PI Planning当日
- 01 チームブレイクアウトでは、Scrum MasterがKendisの各チームエリアで、スプリントごとのチームキャパシティを設定します
- 02 Jiraボードで優先順位付けしたProgram Backlogから、Kendisボードのスプリントへフィーチャーを引き込みます
- 03 フィーチャーカードを展開し、タイトルとストーリーポイントの見積りを入力してストーリーを作成します。作成したストーリーは、該当フィーチャーにひも付き、スプリントに割り当てられた状態でJiraにも即座に表示されます
- 04 ドラッグ&ドロップで依存関係を色分けして可視化し、ステータス、リンク種別、説明を設定します。ボード上の表示の変化から、依存関係の解消状況を追跡できます
- 05 各目標のビジネス価値を活用し、それぞれをフィーチャーにひも付けます
- 06 PI内の各目標の進捗を測定します
- 07 プランレビューでは、Product OwnerがKendisボードを使って依存関係の状況を共有し、リスクを示しながらプランを説明します
- 08 チームごとのフィーチャー完了予定日を確認します
- 09 各チームのスプリントにおける、キャパシティと負荷の関係を評価します
- 10 Kendisボードのリスクレジスターで、リスクをROAMします
- 11 KendisボードのConfidence Vote機能を使い、PI単位、チーム単位、またはその両方で投票を行います
- 12 KendisボードのInspect & Adaptモジュールで、Inspect and Adaptセッションを実施します。プログラムのパフォーマンスを測定し、デリバリーを評価します
- 13 プランニングが完了したら、Kendisボードの状態をトラッキングに切り替えます
- 14 Kendisボードのデータを、Excelやcsvなど共有しやすい形式にエクスポートします。
PI Planning後
- 01 Kendisボードの強力なビジュアルマネジメント機能で、依存関係と目標の進捗を追跡します
- 02 スコープ変更トラッカーで、PIの進捗を自動的に追跡します
- 03 追加・編集されたフィーチャーや、スプリントが変更されたストーリーを把握してスコープの増加を予測し、当初のPI Planningと比べて実行段階でいつどのようにズレが生じたのかを理解します。

PI Planning前
- 01 RTEがKendisでPIボードをセットアップし、PIの日程と期間を設定します
- 02 該当するURLとAPIトークンを入力して、Azure DevOpsまたはTFSと接続します
- 03 色分けしたチームを作成します
- 04 Program Incrementのスプリントを定義します
- 05 既存のクエリを使うか新しいWiqlを記述して、フィーチャーをKendisボードへ取り込みます
- 06 ストーリーとフィーチャーの関連付け方を決めます
- 07 クエリで取得したフィーチャーの子アイテムであるストーリーは、すべて自動的にKendisボードへ取得されます
- 08 Kendisのチームを、Azure DevOpsにマッピングします
- 09 続いて、チームをKendisボードに招待します
- 10 ビジネス価値によってビジネスコンテキストを定義し、フィーチャーの優先順位付けを行って、プランニングの準備を始めます
PI Planning当日
- 01 チームブレイクアウトでは、Scrum MasterがKendisの各チームエリアで、スプリントごとのチームキャパシティを設定します
- 02 Azure DevOpsで優先順位付けしたProgram Backlogから、Kendisボードのスプリントへフィーチャーを引き込みます
- 03 フィーチャーカードを展開し、タイトルとストーリーポイントの見積りを入力してストーリーを作成します。作成したストーリーは、該当フィーチャーにひも付き、スプリントに割り当てられた状態でAzure DevOpsにも即座に表示されます
- 04 ドラッグ&ドロップで依存関係を色分けして可視化し、ステータス、リンク種別、説明を設定します。ボード上の表示の変化から、依存関係の解消状況を追跡できます
- 05 各目標のビジネス価値を活用し、それぞれをフィーチャーにひも付けます
- 06 PI内の各目標の進捗を測定します
- 07 プランレビューでは、Product OwnerがKendisボードを使って依存関係の状況を共有し、リスクを示しながらプランを説明します
- 08 チームごとのフィーチャー完了予定日を確認します
- 09 各チームのスプリントにおける、キャパシティと負荷の関係を評価します
- 10 Kendisボードのリスクレジスターで、リスクをROAMします
- 11 KendisボードのConfidence Vote機能を使い、PI単位、チーム単位、またはその両方で投票を行います
- 12 KendisボードのInspect & Adaptモジュールで、Inspect and Adaptセッションを実施します。プログラムのパフォーマンスを測定し、デリバリーを評価します
- 13 プランニングが完了したら、Kendisボードの状態をトラッキングに切り替えます
- 14 Kendisボードのデータを、Excelやcsvなど共有しやすい形式にエクスポートします
PI Planning後
- 01 Kendisボードの強力なビジュアルマネジメント機能で、依存関係と目標の進捗を追跡します
- 02 スコープ変更トラッカーで、PIの進捗を自動的に追跡します
- 03 追加・編集されたフィーチャーや、スプリントが変更されたストーリーを把握してスコープの増加を予測し、当初のPI Planningと比べて実行段階でいつどのようにズレが生じたのかを理解します
ご質問はありますか?
プログラムレポートとアナリティクス
依存関係管理
リスクレジスターのトラッキング
フィーチャートラッキング
スコープ変更のトラッキング
始める準備はできましたか?
Kendisは、最も効率的なビジネス変革を実現する、最もスマートなスケーリングソリューションです。