今回のテーマは「経営層で立案した戦略を開発現場へどのようにブレイクダウンしていくか」。SAFeの中核イベントであるPI(Program Increment)プランニングについてご紹介します。

今回解決する課題

今回解決する課題は次の5つです。

  • A-3:経営層/ビジネス層が戦略を変更しても、現場まですぐに浸透させられず、組織内に混乱が生じる
  • A-4:開発規模の小さなITシステムの開発方針を柔軟に変更できていたが、システムの規模が大きくなると、アジリティが低下してしまう
  • C-3:顧客/親会社の関係者とIT/開発のメンバーがフラットな立場で開発を進められていない
  • C-4:親会社の方針変更に追随して、自社の組織方針を軌道修正することができていない
  • C-5:親会社を含めた企業グループ全体として戦略/ビジョンに基づいたビジネスが行えていない

これまでの「業務の効率化を主眼としたIT戦略」であれば、年単位で戦略を見直せば十分でした。しかし、デジタルビジネスにおいては市場の変化(ニーズ、新技術)やユーザーの変化に応じて柔軟に戦略を変えていく必要があります。よって、年単位での見直しでは、市場の変化に追随していくことが難しくなります。

そのため、戦略を数カ月単位で見直すようなアプローチが必要なのですが、ウォータフォール開発でそうした見直しを実施すると、要件定義や設計の手戻りが発生します。特に、中~大規模のビジネスでは多様なパートナー企業との連携もあり、連携先との意識疎通も含め現場は大混乱することでしょう。スケジュールが遅延するのはもちろん、残業の常態化や変更の背景が正しく/即座に伝わらないことによる経営層への不満が募り、モチベーションの低下につながります(課題A-3、A-4)。

また、開発部門が分社化されていた場合には、戦略/方針の変更に合わせてビジネス部門やステークスホルダーと足並みを合わせ、同じ方向を向いて軌道修正していくことは非常に困難です(課題C-3、C-4、C-5)。

SAFeのPIプランニングでは戦略を現場まで落としこみ、向こう2ヵ月~3ヵ月の開発計画を詳細化します。その中で、足並みを揃えていくための戦略立案or見直し、予算編成、体制構築、開発という一連の流れを整理し、戦略が開発現場まで浸透する効果を高めることができます。

PIプランニング

本連載の第7回で概要を説明しましたが、PIプランニングは8~12週間のPI期間の最初に実施されるイベントです。ARTごとに関係者全てが参加し、通常2日間実施されます。標準的な会議アジェンダは、以下の通りです。

アジェンダ

標準的なPIプランニングのアジェンダ/出典:https://www.scaledagileframework.com/pi-planning/

1日目

1日目のアジェンダは以下の通りです。

  • ビジネスオーナーは、参加者全員に「ビジネスの状況」を共有する
  • プロダクトマネジメントは、参加者全員に「プロダクトのビジョン」を共有する
  • システムアーキテクトは、参加者全員に「アーキテクチャビジョン」と「開発プラクティス」を共有する
  • ランチ休憩を含むかたちで、リリーストレインエンジニアは、参加者全員に今回のPIで期待している要望を説明する
  • 「チームブレイクアウト#1」として、ART内のAgileチームごとに分かれてPIドラフト計画を検討する
  • チームブレイクアウト#1で作成したPIドラフト計画の草案を、PIプランニング参加者がレビューする

多くの参加者はここまでですが、主要メンバーは、2日目に向けて見直しを実施します。特に1日目の進行で気づいた事や、ビジョンやスコープ、チーム体制などに調整が必要かどうか確認します。

1日目の特徴的なアジェンダは、チームブレイクアウト#1です。AgileチームごとにPIドラフト計画の草案を作成します。具体的な成果物としては「PIプランニングシート」「PI目標シート」「リスクシート」そして「プログラムボード」です。

PIプランニングシートには、該当するPIで扱うチームバックログを、PI目標シートには該当するPIでの努力目標を、リスクシートにはアジャイルチーム内で解決できないと思われる問題などをそれぞれ記載します。特にユニークなのが、プログラムボードです。プログラムボードではAgileチームを縦に並べ、各チームのイテレーションを横軸で表した上で、チーム同士のフィーチャーの依存関係を表現します。複数Agileチームで進める場合の一番課題となり得るチーム間の調整事項をPIプランニングで大まかに整理することになります。

プログラムボード

プログラムボードでフィーチャーの依存性を表現する/出典:https://www.scaledagileframework.com/pi-planning/

なお、チームブレイクアウト中に疑問点があれば、会議に参加しているビジネスオーナーやプロダクトマネジメントに質問をすることが可能です。PIプランニングでは、こうした”壁を生まないコミュニケーション”によって、ビジネスに対する全員の深い理解や早い意思決定を促進することができます。

2日目

続く2日目のアジェンダは以下の通りです。

  • 1日目の最後に見直した計画を参加者に共有する
  • チームブレイクアウト#1として、1日目同様にAgileチームごとに分かれて最終的なPIドラフト計画を検討する
  • 各アジャイルチームの最終的なPIプランニングを発表し、参加者は内容をレビューしてランチ休憩に入る
  • アジャイルチームのチームリスクシートをまとめて、期間中に発生し得るリスクを分析する
  • PI目標シート上の各PI目標に対して達成する自信について、チーム全員で指投票(後述)する
  • 投票結果が平均以上になるまでPIプランニングを修正し、平均以上になったところで全員で合意できたものとして完了する
  • 参加者全員で振り返りを行い、次の日から活動が開始できるような情報共有を行い、2日間のイベントを終了する

2日目にPIドラフト計画を完了させますが、その直後にリスク分析を行います。その際も経営層がPIプランニングに参加しているので、リスク情報が開発チームだけに閉じることなく、内容によっては経営層やビジネス部門への課題として引き継がれます。

指投票

指投票とは、文字通り参加者が指を使ってPI目標を達成する自信について投票するものです。挙げる指の本数で確信度を示します。

  • 1本:確信がない。アジャイルチームがPI目標を全て達成すると思えない
  • 2本:あまり確信がない。アジャイルチームがPI目標を全て達成しない可能性がある
  • 3本:ある程度確信している、アジャイルチームがPI目標を達成できるだろう
  • 4本:成功すると確信している。アジャイルチームがPI目標を達成できるはず
  • 5本:絶対に成功すると確信している。アジャイルチームがPI目標を達成する自信がある
会議を通じて、「達成度が低い」という投票をした参加者の懸念を聞くことで、リスクの追加や再計画の必要性を確認します。この活動はタイムボックスに固執せず、全員がコミットメントできるようになることを目指します。

Pre PIプランニングとPost PIプランニング

PIプランニングはARTの単位で実施されますが、複数のARTで構成されるラージソリューションレベルの場合には、ART間の整合性と情報共有が必要になります。そのためのイベントが「Pre PIプランニング」「Post PIプランニング」です。

Pre PIプランニングは、PIプランニングのためにビジネス状況やプロダクトビジョンを調整する場です。一方、Post PIプランニングはPIプランニングでの決定事項が全体として機能しているかどうか、場合によっては再計画の必要があるかどうかを判断するために実施されます。親会社を含めた企業グループ全体で進めていくようなビジネス領域の場合には、組織間をまたぐ整合性、情報共有をこのイベントを通じて解決します。

PrePI PostPI

Pre PIプランニングのアジェンダの例/出典:https://www.scaledagileframework.com/pre-and-post-pi-planning/

Post PIプランニングのアジェンダの例/出典:https://www.scaledagileframework.com/pre-and-post-pi-planning/

* * *

今回は、SAFeのなかでも特徴的なイベントであるPIプランニングについて説明しました。2日間のイベントのなかで、ビジネス上の戦略を現場まで落としこみを行う一体感のある活動であることが理解いただけたのではないでしょうか。経営層、ビジネス部門、ステークホルダー、そして開発現場が直接会話することで、迅速にビジネス上の意思決定や意思疎通を実現できる仕組みになっています。

なお、昨今では、新型コロナウイルス感染症の影響もあり、PIプランニングもリモート会議での実施が主になっていますが、SAFeではリモート会議で意思決定や意思疎通を円滑に行うためのプラクティスも提供されています。興味のある方は、SAFe公式サイトの「Distributed PI Planning with SAFe」をご確認ください。