PI Objectives

小さな確約を1つずつ実現していくと信頼が生まれる。場は独自の意図をもって活性化する …

- 野中、竹内、「知識創造企業」

PI目標概要

PI目標とは、次回のプログラムインクリメントでアジャイルチーム、ART、または価値のストリームが達成しようとしている、具体的なビジネス上/技術上の目標についてまとめた記述である。その主な目的は、理解したビジネス上/技術上の意図を検証すること、プロセスや戦略に関する事柄ではなく結果に対して連携すること、データを意味のある情報にまとめて連携を強化し全員に見えるようにすることである。

PI目標は、PI計画ミーティングと、場合によってはPI計画後ミーティングで策定される。PI計画ミーティングでは、各チームはビジョンなどの入力となる目標を見直し、初期のストーリーを定義し、そのストーリーを処理能力いっぱいまで反復の計画に割り当てる。その後、チームは反復計画をしっかりと検討し、自分のチームのそのPIにおける具体的な技術上/ビジネス上の目標をまとめる。各チームの目標を集約したものがプログラムのPI目標となり、それがビジネス責任者によって承認される。価値のストリームレベルのPI計画が必要な場合には、プログラムのPI目標をまとめて集約し、それを価値のストリームのPI目標とする。

こうすることで、各チーム、各ART、価値のストリーム全体から何を期待できるかを利害関係者全員が知ることができ、すべてのWIPが目に見えるようになる。各チームは、実現可能な合意済みの目標の、最新で既知の整合のとれた最終的なセットを実現できるよう、外から与えられたものではなく自分たちで作成した計画に基づいて作業を行う。

PIの終了時に、各チーム/各ART/価値のストリームは、結果を目標に照らして評価し、それを入力情報として継続的に能力を改善する。

(注:この重要な主題についての詳細は、関連するガイダンスのページを参照のこと。)

詳細

SAFeは、意味のあるビジネス計画とその成果を支援するというアジャイルチームアジャイルリリース列車(ART)、価値のストリームからの短期的な一連の確約に依存する点で、確約ベースであると言える。これは、開発者とビジネス利害関係者の間に存在しなければならない信頼の鍵となる要素である。これを、一連の固定された長期的なウォーターフォール風の納品物に対する確約と混同してはならない(これについてはソリューションの意図のページで説明する)。しかし、ビジネスの担当者が意味のある計画を立てるには、信頼できる予測可能な見通しをソリューション構築者にある程度立ててもらう必要がある。それが少なすぎると、「ARTが役に立つものをまったく確約できない」ことになる。多すぎると、「ARTがやると言ったことを実際にやったことがない」となる。どちらも最適ではない。どちらの場合もビジネスと開発の間の不信が高まるからである。そうなると、最終的なビジネスの成功が大幅に妨げられるし、仕事が楽しくなくなるのは言うまでもない。

我々にはその中間のものが必要で、それこそがチーム、プログラム、価値のストリームのPI目標の第一の目的である。連携の他に、実現可能な目標を設定するという過程は、システムの行程における余分な作業を減らすために欠かせない。

SAFeのPI目標と計画はボトムアップで作成される。これは、それぞれのアジャイルチームがソリューションの自分の担当部分を見積もって計画することで行われる。チームはチームのPI目標をPI計画ミーティングで作成し、そのプログラムインクリメントの終了までに何を準備のできた状態にするかを示す。チームが作成した目標はプログラムレベルで集約され、それがさらに価値のストリームレベルで集約される。その様子を図1に示す。

 

Figure 1. From Team to Program to Value Stream PI Objectives
図1. チームからプログラム、価値のストリームへのPI目標の集約

チームのPI目標を作成する

チームはPI計画ミーティングでチームのPI目標を設定する。それには次のような多くの利点がある。

  • ビジネスと技術との間で伝達をするための共通言語となる。
  • チームどうしを共通の使命に対して連携させる。
  • 近い将来のビジョンが作成され、それに向かってチームが結集しチームとして発展する。
  • プログラム予測性指標という重要なメトリックスが提供される。チームやアジャイルリリース列車はこれを使用して能力を向上することができる。
  • 管理者と意思疎通し、ビジネス価値に対する各チームの貢献を明らかにする。
  • システムを成功させるために対処しなければならないチーム間の依存関係を顕在化させる。

チームのPI目標を設定するのは簡単なことではない。確かな見積もりと計画を作成し、ベロシティーをしっかりと理解し、次回のフィーチャーを分析し、チームバックログ用にストーリーを定義し、最終的に誰もが理解できる単純なビジネス用語に統合する必要があるからである。しかし、その最終結果は、わかりやすく、そのまま示すことができる。例を図2に挙げる。

Figure 1. An initial set of team PI Objectives
図2. バハライドチームの最初のPI目標の例

PI計画時に、チームはプログラムビジョンと新しいフィーチャーを見て、納品が必要なストーリーを計画に含める。その過程で、具体的なチームのPI目標も特定される。

フィーチャーと目標を区別する

チームのPI目標は、たいてい、対象のフィーチャーと直接的に関係しており、実際に多くの場合は同じである。しかし、この対応関係は常に単純であるとは限らない。図3に示すように、複数のチームの協調が必要なフィーチャーもあるためである。

Figure 3. From features to objectives; some features will appear on more than one team's objectives
図3. フィーチャーから目標へ:一部のフィーチャーは複数のチームの目標に登場する

一部のフィーチャー(フィーチャーAなど)は1つのチームだけで納品できるが、フィーチャーBのように協調が必要なものもある。フィーチャーやフィーチャーの入力の他に、他のチームの目標も登場する。この目標には、今後のフィーチャーを実現できるようにするための技術目標(たとえば図1の概念実証など)や、開発インフラの機能強化、マイルストーンなどが含まれる。このプロセスの結果はすべて、影響を受けるチームの目標に反映される。

PI目標があることで、チームはフィーチャーばかりを見るのではなく、望ましいビジネス結果へと目を向けることができる。フィーチャーや受け入れ基準は、ソリューションの反復を次のレベルに進めるために実施しなければならない作業を理解し、記録し、それに向かって協調するための優れたツールとなるが、「フィーチャーを終わらせる」ことに夢中になって、その中に隠された全体の目的を達成できないことになりがちである。核となる質問は、「我々の目的は、リストに挙げられたフィーチャーを完了することなのか、それともそのフィーチャーによって望ましい結果を提供することなのか。言い換えると、半分の作業で、すべてのフィーチャーを構築することなしに同じ価値を提供できるとしたら、それは受け入れ可能か」となる。

ビジネス責任者との直接の会話によって伝えられる意図をよりよく理解すると、多くの場合、チームはシステムアーキテクト/エンジニアリングプロダクト管理に新しい観点を提供でき、専門技術をより効果的に適用する方法をすばやく見つけられるようになる。

背伸び目標を使用する

背伸び目標によって、納品を時間枠の中で確実に行うことができる(納品のリズムに同期するには処理能力の余裕が必要である[2])。チームは背伸び以外の目標を納品すると確約する。さらに、チームは背伸び目標を納品するために最善を尽くすことにも同意し、背伸び目標はPIの処理能力に含められる。しかし背伸び目標は、現実には、タイミングやその他の不確定要素により、時間枠の中で達成されることもあればされないこともある。背伸び目標はPIの中で完了しない可能性があるため、利害関係者もそれに応じた計画を立てる。背伸び目標を使用することにより、次のような利点が得られる。

  • 経済面が改善する。背伸び目標がなければ、チームは固定された時間枠の100%の範囲を確約しなければならない場合に、品質を犠牲にするかシステム内に別の緩衝域を作り込むことを強いられる。緩衝域によって不確実な「実現できるかもしれない範囲」が確実だけれども「実現できるかもしれない最大値より少ない範囲」に変換され、その結果、全体としてのスループットが減る。
  • 信頼性が向上する。背伸び目標を設定することで、見積もりミスの許容範囲が生まれ、優先順位の高いものを納品できる確実性が増す。そして、確約したものを納品することは(背伸び目標は確約した目標ではない)、チームと利害関係者の間の信頼を構築する上で最も重要な要因である。
  • 変化に適応できる。リズムに乗って確実に納品する手段として、背伸び目標は、確約を果たしながらも事実パターンが変化したときに必要に応じて優先順位を変更するための、必要な処理能力となる。

通常、背伸び目標全体に割り当てられるのは、全処理能力の10%~15%である。また、背伸び目標は計画の範囲の中で何を変動部分として扱ってよいかを特定するために使うものであり、実行可能な範囲を超えて利害関係者がチームに負荷をかけるための手段ではないことを、常に気に留めておく必要がある。

SMART目標を記述する

チームのPI目標は、そのPIにおけるチームの計画の概要として役立つ。しかし、目標を高い抽象度で記述するということは、あいまいで検証不可能な「意図のかたまり」になりがちであることを意味している。この問題に対処するためにSMART目標を使用する。各目標は、以下に当てはまるように記述する。

  • Specific(具体的)。 意図する結果をできるだけ単純、簡潔、明白に述べる。(ヒント:動作動詞で記述するとよい。)
  • Measurable(測れる)。 目標を達成するためにはチームが何をする必要があるかを明確にしなければならない。測定基準は、文章での記述、Yes/Noで答えられる質問、定量的なもの、または範囲などで指定することができる。
  • Achievable(達成できる)。 チームの制御および影響の範囲内で目標を達成できなければならない。
  • Realistic(現実的)。 制御できない要因を認識する。(ヒント:「ハッピーパス」を前提としない。)
  • Time-bound(期限を定める)。 達成するための期間はPIの範囲内でなければならず、そのためそれに応じてすべての目標のスコープを決めなければならない。

目標と一緒にビジネス価値を伝える

PI計画ミーティングで目標が最終的に決まると、ビジネス責任者はチームと直接会話をしながら、チームの個々の目標にビジネス価値を割り当てる。ビジネスからチームへ、そしてチームからビジネスへのこの会話の価値は、いくら強調してもしすぎることがない。意思決定の重みの背後にある戦略やコンテキストが伝わるためである。目標それぞれは、ビジネス責任者によって1~10の段階でランク付けされる。ビジネス価値を、その目標の必要工数や合計ストーリーポイントといった他の基準と混同してはならない。ビジネス価値は計算するものではなく、割り当てられて、実施するかどうかを検討する際の入力となる。チームの目標の多くは、ソリューションに対して直接すぐに価値をもたらす。イネイブラーなどその他のものは、インフラや開発環境や品質の取り組みの中で進められ、今後のビジネス価値をすばやく作成するために役立つ。これらの要因をすべて重みづけして最終的なバランスを取らなければならない。

チームのPI目標を最終決定する

目標がより「SMART」になり、背伸び目標が特定され、ビジネス価値が確立したときには、図1の目標はたとえば図4のように進化している。

Figure 4. Objective sheet with business value and stretch objectives
図4. ビジネス価値と背伸び目標を追加した目標シート

PI目標を確約する

PI計画の終盤になって、目標の合意が取れ、背伸び目標によってスコープの余裕ができ、リスクに対処したら、チームは自分たちが目標を達成できる自信があるかどうかを投票する。厳密に言うとこの投票は確約と同じものではないが、ほぼ同じものであると扱われる。そのため、この確約は妥当な要求でなければならない。確約は外からチームに与えられるのではなくチーム自身が行わなければならないというアジャイルの明白な事実の他に、SAFeの確約には次の2つの要素が含まれる。

  1. 確約した目標を達成するために力の限りを尽くすとチームは合意する。
  2. もしPIの途中で、いずれかの目標が達成可能でないと事実をもとに判断できた場合には、是正措置を取れるよう即座に報告するとチームは合意する。

こうすることで、すべての利害関係者は、a)プログラムの成果が計画通りに達成される、または、b)影響を軽減し是正措置を取ってビジネスの混乱を最低限に抑えられるよう通知を受け取れることが分かる。これは最善のものである。というのも、結局は研究開発であるからだ。

プログラムと価値のストリームの目標を作成する

PI計画プロセスの成果として、チームごとに1枚の、承認済みの目標シートが作られる。チームは目標のセットに対する自信のレベルを投票し、十分な自信があれば、その目標を集めたセットがARTの確約済み計画となる。(そうでなければ自信が持てるまで計画策定作業を続ける。)これがリリース列車エンジニアにとって必要な入力のすべてであり、リリース列車エンジニアはチームからのデータを使ってチームの目標をプログラムのPI目標にまとめ、管理者に伝えるのに適した形式にする。

これらの目標は、チームのPI目標と同じようにSMARTでなければならず、背伸び目標も含む。また、チームのPI目標の場合と同様に、これらには、ARTが取り組んでいるビジネスシステム能力や、イネイブラーや、その他のビジネス上/技術上の目的が含まれる。

PI計画後ミーティングですべてのARTの計画が策定された後で、価値ストリームエンジニアが目標をさらに価値のストリームのレベルで集約し、価値のストリームのPI目標がまとめられる。これがSAFeにおける最上位のPI目標であり、この目標によって、次のPIで価値のストリーム全体から何が納品されるかを利害関係者に伝えることができる。上の図1では、チームからプログラム、価値のストリームへとPI目標が集約される様子を示している。

ビジネス価値が指定されるのはチームのPI目標だけであることに注意してほしい。この価値は他のレベルにまとめられることがない。プログラムや価値のストリームの予測性指標を計算するときには、メトリックス自体がまとめられて上位レベルでの予測性を解明することになる。

余分なWIPを減らして現実的な目標を設定する

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

価値のストリームレベルでの計画策定も同様に行うことができる。各ARTの計画が互いに影響を及ぼし合い、一部の作業は価値のストリームのバックログに戻されて、後のPIで再評価されることになる。


さらに知りたい場合

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

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

Last update: 2 December 2015