敵を知り己を知れば、百戦危うからず

孫子

局所最適化より、全体最適はより多くの価値を創出する。

Don Reinertsen

プログラムPI目標の概要

プログラムPI目標は、アジャイルリリース列車の次のプログラムインクリメント(PI)についてビジネスと技術のゴールをまとめた記述である。リリース計画策定時に、各チームはビジョンや他のインプットされた目標をレビューし、初期のユーザーストーリーを定義する。そして、チームの容量がなくなるまで、各反復にユーザーストーリーを割り当て続ける。その後、チームはこれらの計画策定結果を用いて、PI向けの具体的なビジネスと技術の目標を統合しまとめる。これらがチームのPI目標である。

確約ができた後に、各チームのPI目標を集約し、プログラムPI目標としてまとめる。こうすることで、すべての利害関係者は何を期待できるかを理解でき、すべての仕掛かり作業が明確になる。また、プログラムは常に明確な、足並みを揃えた、決定的なプログラムレベルの目標を持って実施される。これはチームとプログラムの間、プログラムとビジネスの間の足並みを揃えることに役に立つ。PIの終了時点で、プログラムは目標に対する結果を評価し、そして、これをプログラムパフォーマンスの継続的な改善へのインプットとして利用する。

詳細

SAFeフレームワークの目的はソフトウェア開発に依存するビジネスの経済的な成果を向上させることである。そうすることにより日常の活動でそのソフトウェアに依存するユーザーの生活が向上する。好都合なことに、アジャイル手法でこれを行うと、ソフトウェア開発チームに権限が与えられ、仕事の活動がより実りのある、個人的にも充実したものになる。これらの利点はどれも、合意されたチームとプログラムのPI目標を反映した共通の達成可能なビジネス使命に、アジャイルチームが継続的に足並みを揃えなければ得られない。ただし、従来の開発とは違って、チームに対して目標が設定されるのではなく、チーム自身がこれらの目標を設定する。これは大変な差である

従って、短期間の意味がある目標を、作成する足並みを揃える確約するというプロセスは、開発とビジネスの信頼関係を構築するための重要な要素となる。これらの目標は、プログラムの結果を継続的に改善するための土台となる。

概要

リリース計画策定の不可欠な部分として、目標設定は定期的に行われる。時間枠内に何を完了できるかの確約はチームにしかできないので、最初はチームPI目標に注目する。目標設定の目的は以下のとおりである。

  • プログラムがビジネス使命に足並みを揃える
  • チームが、共通の使命及び近い将来の納品物に関する確約に足並みを揃える
  • 超過している仕掛かり作業を洗い出し、見直す
  • プログラムパフォーマンスの評価と改善を支援する
  • スプリントゴールが継続的にプログラム目標に足並みを揃えるため、チームの反復計画に情報を与える
  • ポートフォリオ管理に計画策定と進行状況についての情報を提供する

ビジョンは通常最新の優先順位が最も高い上位10位のフィーチャーで表す。リリース計画策定の主要なインプットはこのビジョンである。従って、フィーチャーがそのまま目標になるかもしれないが、それ以外にも目標に関して次のようにいくつか考慮しなければならない事項がある。

  • マイルストーン、リリース、展示会などの主要な顧客イベント/ビジネスイベント
  • アーキテクチャーフィーチャーを含むアーキテクチャー滑走路への貢献
  • サポートと維持管理、不具合の低減などの技術的負債
  • 新規および既存の非機能要求の順守
  • 調査活動の完了と報告
  • エンジニアリングプラクティスと開発インフラの進化、知識共有と相互トレーニング

上記のすべての側面は、プログラムバックログロードマップ、ビジョン、プログラムエピックの追加のコンテキストとなり、それらがすべて、リリース計画の目標設定プロセスへのインプットとして利用される。従って、図1に示すように、ほとんどの目標はプログラムバックログから取り出されたフィーチャーであるが、通常は追加のビジネス目標も見つかる。

Figure 1. Example Program PI Objectives

図1. PI目標の例

現実的な目標への確約は超過WIPの削減に役に立つ

チームPI目標をレビューすると、通常は、さまざまなビジネス利害関係者が思い描くすべてのものをPIの時間枠内で実現できそうにないことが明確になる。従って、合意を得るには、一部の現在開発中のプロジェクト(WIP)を再評価しなければならない。これはリリース計画策定プロセス全体を通して発生するが、最終的にはプログラムPI目標に対するすべての利害関係者の合意として具体化される。優先順位が低いプロジェクトはプログラムバックログに戻される(より低いコスト保有パターン、「今はやらない」とも呼ばれる)。超過WIPを減らすとオーバヘッドとスラッシングが減り、生産性とベロシティが高まる。最終結果として、すべてのビジネス利害関係者によって合意された実施可能な目標セットが設定され、効率が向上し、さらに納品が成功する可能性が高まる。それは、ほとんどの人が確約できるはずのものである。

より詳しく:チーム目標からプログラム目標を合成する

チームPI目標のページで説明したが、個々のチーム目標を確立することはリリース計画策定の最初の注力ポイントである。計画策定プロセスとチームの既知のベロシティーを用いて、次の期間内でチームが実施可能なこと、価値を納品する方法を決める。リリース計画策定の初期の結果は、SMARTで形式の整ったチームPI目標である。チームPI目標が決まって、承認された後、チーム目標は通常部屋の前方に集められる。計画策定の終盤に向けて、あるいは一般的にはその後すぐに、個々のチームPI目標がプログラムPI目標に集約される。その様子を図2に示す。

Figure 2. Synthesizing Program PI Objectives from Team PI Objectives

図2. チームPI目標から合成されたプログラムPI目標

結果として、次のPIの意図を伝えるためにまとめられた目標群ができあがる。これによってプログラム確約の土台が合成される。


さらに知りたい場合

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

[2] Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

Last update 24 July, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.