nav_PI計画策定

将来のプロダクト開発作業をあらかじめ規定することはできない。最終成果を理解しそれに反応できる人に、計画策定と制御を分散しなければならない。

─Michael Kennedy, Product Development for the Lean Enterprise

SAFeは魔法ではない……が、PI計画は例外かもしれない。

─著者

PI計画策定の概要

アジャイル宣言の原則では、「情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです」と述べている。SAFeではこれを次のレベルに進めて、PI計画策定を実施する。これは、影響の大きい、リズムベースの、アジャイルリリース列車(ART)全体の同期ポイントである。PI計画策定は、直接に会って行う定期的なイベントである。アジェンダは標準化されていて、まず、ビジネス背景とビジョンが示される。その後、チームの計画策定が行われるが、そこでは次のプログラムインクリメント(PI)の計画を作成する。主催するのは、通常、リリース列車エンジニア(RTE)であり、可能な限りARTのメンバー全員が参加する。期間は1.5~2日間で、IP反復内で行われる。つまり、PI内の他の反復の時間枠やスケジュールや処理能力には影響しない。計画策定の結果として、次のPIについて、合意のとれた一連のプログラムPI目標が確約される。地理的に分散したARTの場合、場所どうしの間で絶えずコミュニケーションを取ることによって、このイベントを同時に複数の場所で開催することがある。

複数のARTを含む価値のストリームの場合、PI計画前ミーティングを行って、ARTのPI計画策定セッションの背景と入力となる目標を設定する。PI計画後ミーティングは、価値のストリームに貢献するARTの成果を統合するのに使われる。

詳細

PI計画策定は、アジャイルリリース列車の「心臓の鼓動」となる、影響力の大きい、リズムに基づくイベントである。SAFeにとって、このイベントは重要で不可欠である(これを実施しなければ、SAFeを行っていないのと同じである)。規模が大きい場合、図1を見ると分かるように、これは非常に大きな意味を持つイベントとなり得る。

図1.  対面で行う大規模なPI計画策定。 米国のチームと同時に、インドやスロバキアのリモートチームも計画を作成している。

PI計画策定によって、ビジネス上の無数の利点が得られる。これには次のような作業が含まれる。

  • すべてのチームメンバーおよび利害関係者にまたがって幅広いコミュニケーションを行えるようにする。
  • ARTが頼れる人の輪を構築する。
  • ビジネスコンテキスト、ビジョンチームおよびプログラムのPI目標によって、開発とビジネスの足並みを揃える。
  • 依存関係を特定し、チーム間、ART間の連携を育成する。
  • 「ちょうど適当な量」のアーキテクチャーユーザーエクスペリエンスに関するガイダンスを実施する機会を提供する。
  • ニーズと処理能力を一致させ、WIPの超過を解消する。
  • 意思決定を素早く行う。

このイベントの入力情報は、ロードマップとビジョン、プログラムバックログ内のトップ10のフィーチャー、および、その他のビジネスコンテキストなどである。参加者は、ビジネス責任者を含むすべてのプログラム利害関係者とチームメンバーである。PI計画策定では、次の3つの主要成果物を作成する。

  1. チームが作成し、ビジネス責任者がビジネス価値を割り当てた、各チームの「SMART」チームPI目標と、集約され、まとめられた、プログラムのPI目標。
  2. 「プログラムボード」。新規フィーチャー、納品予定日、その他の関連マイルストーンを示す。チーム目標をもとにまとめたもの。
  3. プログラム全体によるこれらの目標についての自信の投票/確約。

さらに、規模の大きな価値のストリームでは、通常は複数のARTが同時に計画を立てる。その場合は通常、前後にPI計画前/後ミーティングを行い、共通のソリューションの目的に向けて、ARTのベクトル合わせおよび調整を行う。これらのミーティングについては、このページの後半で簡単に説明する。

準備

PI計画策定は、準備と連携とコミュニケーションが必要なイベントである。プロダクト管理アジャイルチームシステムおよびソリューションアーキテクト/エンジニアリングシステムチームや、その他の利害関係者など、イベントの参加者に通知し、しっかりと準備しなければならない。

イベントを成功させるには、主な3つの面で準備が必要である。

  • 組織の準備─戦略的な歩調統一とチームおよび列車の構成
  • 内容の準備─管理と開発の準備
  • 設備の準備─イベントのための実際の場所と手配

以下は、参考文献[1]の付録Cにある「リリース計画準備チェックリスト」の概要である。詳細は参考文献[1]の第16章を参照してほしい。

組織の準備

計画の前に、参加者/利害関係者/ビジネス責任者の間でプログラムについて適度な戦略的整合が取れていること、チームが価値のストリームと同調していること、重要な役割が割り当てられていることを、確認しておく必要がある。そのために、準備状況を以下で確認する。

  • 計画の範囲と背景─計画策定プロセスの範囲(プロダクト、システム、技術分野)は理解されているか。計画を立てるためにどのチームが集まる必要があるかを把握しているか。
  • ビジネスの調整─ビジネス責任者間で優先順位について適度な合意が取れているか。
  • アジャイルチーム─アジャイルチームは存在するか。各チームに専用の開発者とテストリソースがあるか、また、スクラムマスターとプロダクトオーナーが特定されているか。

内容の準備

ビジョンと背景が明確になっていることや、適切な利害関係者が参加できることも、同じくらい重要である。そのため、PI計画策定では以下を行わなければならない。

設備の準備

多数の出席者をサポートするために必要な物理空間と技術インフラを確保することは簡単ではない。特にリモート参加者がいる場合は困難である。主に以下の点を考慮する。

  • 設備─出席者全員がゆったり入ることができなければならない。必要であれば別の小会議室も準備する。
  • 設備/技術サポート─サポート人員を事前に特定し、設定、テスト、およびイベント時に連絡がつくようにしておく必要がある。
  • 通信チャネル─分散した計画策定ミーティングの場合、プライマリとセカンダリのオーディオ、ビデオ、プレゼンテーションのチャネルが使用可能でなければならない。

イベントのアジェンダ

このミーティングは、通常、図2に示すような標準的なアジェンダで開催する。図の後でアジェンダの各項目について説明する。

図2.  標準的な2日間のPI計画策定のアジェンダ

1日目

ビジネス背景。上級役員/事業ラインの責任者が、ビジネスの現状を説明し、現在のソリューションが現在の顧客のニーズにどの程度対応できているかの観点を示す。

プログラムビジョン。プロダクト管理が現在のプログラムビジョン(通常はこれから実施する次のトップ10フィーチャーで表される)を説明し、前回のPI計画策定ミーティングからの変更と、今後のマイルストーンを明らかにする。

アーキテクチャービジョンと開発プラクティス。システムアーキテクト/エンジニアリングがアーキテクチャービジョンを説明する。さらに、シニア開発管理者が、テスト自動化や継続的インテグレーションなど、アジャイルをサポートするための開発プラクティスの変更のうち、次のPIで進めるものについて説明することもある。

計画策定の背景。リリース列車エンジニアが、計画策定のプロセスと、ミーティングの成果として何が期待されるかを説明する。

チームに分かれての検討1。チームごとに分かれて、各反復の自チームの処理能力(ベロシティー)を見積もり、フィーチャーを実現するために必要になりそうなバックログ項目を特定する。各チームが反復ごとの計画草案を作成し、全員に見せる。このプロセスの途中で、リスクと依存関係を洗い出し、チームPI目標の最初の案を作成する。また、フィーチャーをプログラムボードに追加する。

計画草案のレビュー。この計画草案のレビューは厳密に時間を限って行う。その時間の中で、チームは、目標の案、潜在的なリスク、依存関係などを含む主要な計画成果物を説明する。ビジネス責任者、プロダクト管理、その他のチームや利害関係者は、それをレビューし、情報を提供する。

管理層のレビューと問題解決。計画草案には、範囲、リソースの制限、依存関係などの課題が含まれている可能性がある。このレビューと問題解決のミーティングで、管理層は、さまざまに計画を調整して合意することで、範囲を取り決め、課題を解決する。RTEは、ファシリテーターを務め、達成可能な目標を設定するために必要な意思決定を行えるよう、主要な利害関係者を必要なだけ一緒に引きとめておく。複数のARTが含まれる価値のストリームでは、計画策定の1日目が終わった後で同様のミーティングを実施して、見つかったART横断的な問題を解決することがある。あるいは、影響を受ける列車のRTEどうしが話し合って問題を提起し、それを列車の管理層の問題解決ミーティングで解決する場合もある。

2日目

計画の調整。次の日のミーティングの最初に、管理者が、計画の範囲やリソースに対する変更があれば説明する。

チームに分かれての検討2。チームは前日の計画策定の続きを行い、適切な調整をする。チームはPI目標を完成させ、ビジネス責任者がそれにビジネス価値を割り当てる。

最終計画レビュー。最終計画レビューでは、すべてのチームがそれぞれ自分の計画をグループに発表する。各チームは与えられた時間の終盤に、リスクと妨害事項を述べる。ただし、この短い時間内では、それらを解決しようとはしない。計画が顧客にとって受け入れ可能であれば、チームはプログラムのPI目標シートとプログラムリスクシートを部屋の前方に掲示し、集約した目標が姿を表すのを全員がリアルタイムに見られるようにする。

プログラムリスク。計画策定中に、チームは自分の目標達成に影響を与える可能性のある、プログラムレベルの重大なリスクと妨害事項を識別している。これらについて、グループ全体として、より広い管理のコンテキストで対処する。リスクを1つずつ取り上げて以下のいずれかのグループに分類し、明確かつ正当で誰にも見えるような方法で対処する。

  • 解決済み(Resolved)─その問題に対する懸念がなくなったことにチームが合意する
  • 引き受け済み(Owned)─ミーティングでは解決できないので、誰かが責任を持つ
  • 受容済み(Accepted)─一部のリスクは事実であるか発生する可能性があるものなので、理解して受け入れるしかない
  • 軽減済み(Mitigated)─チームはリスクの影響を軽減するための計画を特定することができる

自信の投票。プログラムのリスクに対処した後、チームはプログラムのPI目標を達成する自信があるかを投票する。各チームは、「5本指の投票」を行う。平均が3~4本であれば、管理者は確約を受け入れるべきである。平均が3本よりも少なければ、計画作業を調整して計画を作り直す。2本以下の投票をした人には、懸念を表明する機会を与えるべきである。それによって、リスクリストに項目が追加されたり、再計画が必要になったり、情報が得られたりする。

計画のやり直し(必要であれば)。必要であれば、チームは自信が高いレベルに達するまで計画をやり直す。これは、ベクトル合わせと確約が時間枠の遵守より優先される場合の1つである。

計画策定作業の振り返り、次のステップ。最後に、RTEの主導で簡単にミーティングを振り返り、何がうまくいったか、何がうまくいかなかったか、次回は何を改善できるかを記録する。その後、アジャイルプロジェクト管理ツールへの目標とストーリーの取り込み、今後の主要な作業とイベントの日程など、次のステップについて話し合う。最後は部屋をきれいにする。

成功したイベントの成果物

イベントが成功すると、次の3つの主要成果物ができあがる。

1. チームが作成し、ビジネス責任者によってビジネス価値が割り当てられた、各チームの「SMART」目標。ここには、ゴールとして計画に組み込まれているけれども、チームが確約していない、背伸び目標が含まれる場合がある。背伸び目標は、ART実行時の信頼性および品質を向上するのに必要な、処理能力とスコープを柔軟に管理するためのオプションとなる(リズムに基づいて確実に納品するには処理能力の余裕が必要である)。図3はあるチームのPI目標の例である。

図3.  ビジネス価値と1つの背伸び目標が記載されたチームの目標シート

 

2. 「プログラムボード」。新しいフィーチャーの納品日、チーム間や他のARTとの依存関係、関連するマイルストーンが明示される(図4)。

図4.  プログラムボードの例

3. ART全体によるこれらの目標についての自信の投票/確約。

イベント後の作業

チームがイベントを終えて帰るときには、中身の入った次のPIのバックログができあがっている。これが、その後に行われる通常の反復計画策定の新しい入力情報になる。

ミーティングの後、RTEはチームのPI目標をプログラムのPI目標に組み入れ(詳細はPI目標のページを参照)、それを使って期待できる事柄を利害関係者に伝えたり、ゴールへ向けての進捗を管理したりする。これは通常、PI計画策定ミーティングの途中ではなく、それが終わった後に行う。その後でプログラムボードを保守するかどうかは任意である。PI計画が決まった後、ロードマップは通常、プロダクト管理が更新する。

そして最後に、プログラムは最も重要なPIの実行に進み、進捗を管理したり、新しい知識が現れて変更が発生すると必要に応じて調整を行ったりする。

複数のARTが含まれる価値のストリームにおけるPI計画策定

ここまでは、1つのARTの計画作業について説明してきた。しかし、規模の大きな価値のストリームでは、複数のARTが同様の計画セッションを実施するため、ARTをまたがった連携も必要になる。手配や居場所や範囲に応じて、これは同時に行うこともあれば、イノベーションと計画策定の反復の中で日時をずらして行うこともある。この場合、PI計画策定イベントの前後に、価値のストリームレベルのPI計画策定前/後イベントを実施する。


さらに知りたい場合

[1] Leffingwell, Dean.Agile Software Requirements:Lean Requirements Practices for Teams, Programs, and the Enterprise.Addison-Wesley, 2011, 第16章.(邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

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

Last update:12 August 2015