小さな確約を1つずつ実現していくと信頼が生まれる。

場は独自の意図をもって活性化する …

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

チームPI目標の概要

チームPI目標は、今後のPIにチームが達成しようとするビジネス上あるいは技術上のゴールをまとめた記述である。リリース計画策定中に、各チームはビジョンやインプットされた目標をレビューし、初期のユーザーストーリーを定義し、そして、容量がなくなるまで、各反復の計画にユーザーストーリーを追加していく。その後、チームはこれらの結果を用いて、計画に反映し、PIの具体的な技術上とビジネス上の目標を統合しまとめる。

各チームの目標を集約するとプログラムPI目標になる。この目標はまとめられ、公表される。こうすることで、すべての利害関係者は各チームとプログラムから何を期待できるかを理解することができ、すべての仕掛かり作業が可視化される。また、チームは、常に最新の、既知の、足並みが揃った、実施可能な、コミュニケーションが取られた最終目標を持ち、チームのためではなくチームによって作られた計画に基づいて実行する。PIの終了時には、各チームは結果を目標に照らして評価し、それをインプットとしてパフォーマンスを継続的に向上する。

詳細

SAFeは、意味のあるビジネス計画策定と成果を支援するために、チームとプログラムによる定期的な一連の短期確約を利用するという点で、確約が中心となっていると言える。この短期確約はチームとビジネス利害関係者の間に存在しなければならない信頼関係の重要な要素である。しかし、これを、固定された長期的なウォーターフォールのような成果物に確約することと決して混同してはいけない。後者はどのような結果を招くか、我々はすでに分かっている。しかし、ビジネス側で意味のある計画策定を行うには、IT/開発部門が若干の信頼できる、予測可能な予想をする必要がある。予想が少なすぎる場合、「開発者は役に立つものに何も確約できない」と言われ、一方、長すぎる場合は、「開発者はやると言ったことを決してしない」と言われる。どちらも最適ではない。なぜならば、両方がともにビジネス側とIT側の差異と不信を助長し、最終的にビジネスの成功を大きく妨害することになるからである。従って、ビジネス側とIT側の間に、何かが必要である。それがチームとプログラムPI目標の本来の意図である。また、プログラムPI目標で説明するように、システムにおける過度な仕掛かり作業を低減するには、ベクトル合わせの他に、実行可能な目標を設定するプロセスが欠かせない。 リリース計画策定時に、チームはPI目標を設定する。これによって以下の恩恵が得られる。

  • ビジネス側と技術側の間のコミュニケーションのために共通の言語を提供する
  • チーム間、およびチームと共通のプログラム使命とのベクトルを合わせる
  • チームが場を構築し、結集できるような短期的なビジョンを作成する
  • リリース予見性指標という重要なメトリックスを提供し、チームとプログラムがパフォーマンスを改善するために利用できるようにする
  • 上役とコミュニケーションをし、各チームがプログラムのビジネス価値への貢献度を明示する
  • プログラムを成功させるために対処しなければならないチーム間の依存関係を明らかにする

この後で説明するが、チームPI目標の設定は決して簡単なことではない。確かな見積もりと計画策定を行い、ベロシティーをよく理解し、今後のフィーチャーを分析し、バックログのストーリーを定義し、最終的には誰でも理解できるように簡潔なビジネス用語でまとめる必要がある。しかし、図1に示すように、最終結果は直接的で、分かりやすく表現される。

図1. 初期のチームPI目標

リリース策定計画時に、チームはビジョン、新しいフィーチャーを検討して、納品しなければならないストーリーを計画する。そうすることで、具体的なチームPI目標が識別される。その概要を図2に示す。

図2. PI目標設定の概要

 

チーム目標はインプットされたフィーチャーでしかないのか?

チームのPI目標はしばしば意図されたプログラムフィーチャーに直接関連する。実際、多くの場合、両者はしばしば同じである。しかしながら、複数のチームによって納品しなければならないフィーチャーや、コンポーネントチームの場合は、マッピングは直接的ではない。図3に示すように、一部のフィーチャーでは複数のチームが協力しなければならない。

図3. フィーチャーから目標へ。一部のフィーチャーは複数のチームの目標に現れる

 

一部のフィーチャー(フィーチャーA)は1つのチームで納品できるが、他のフィーチャー(フィーチャーB)は複数のチームの協力が必要である。フィーチャーやフィーチャーへのインプット以外に他のチームの目標も現れる。これらの目標には、将来のフィーチャーを実現するための技術的目標(図1に示す概念実証の例)や、開発インフラの強化などが含まれる。このプロセスの結果は、影響を受けたチームの目標に取り込まれる。

ストレッチ目標

ストレッチ目標は、確実に納品のタイムボックスを満たすための手段である([参考文献[2]、納品のリズムに同期するために、容量のマージンが必要である])。チームは非ストレッチ目標の達成に確約し、ストレッチ目標の達成については最善を尽くすことに合意する。ストレッチ目標はPIの容量に含まれるが、現実にはタイムボックス内で達成できる場合と達成できない場合がある。利害関係者は、それに応じて計画を立てることを知っている。ストレッチ目標はプログラムに以下の利益を提供する。

  • 経済性を向上する。ストレッチ目標がなければ、チームが1つの固定の時間枠(タイムボックス)に100%のスコープを確約する必要がある場合、システムにバッファを作らなければならない。バッファにより、不確実な「かもしれない」のスコープは、確実だけれども「かもしれない」よりも少ないスコープに変換されるが、結果的に全体の処理量が少なくなる。
  • 信頼性が向上する。ストレッチ目標を導入することで見積もり誤差が許容される。それによって主要な優先事項の納品に関する信頼性が向上する。納品に関する確約はチームと利害関係者間の信頼関係の構築にもっとも重要な要素である。
  • 変化に適応する。一定のリズムで確実に納品するため、ストレッチ目標は事実パターンが変化する場合に必要となる優先順位の調整に必要な容量を提供する。

通常、ストレッチ目標の許容誤差の合計は容量全体の10%~15%である。ストレッチ目標は計画のスコープ内で何が変動してもかまわないかを識別するために利用されることを忘れてはならない。ストレッチ目標は、利害関係者がチームにできること以上に負荷をかける方法ではない。

SMART目標

チームPI目標はPIに関するチームの計画を簡潔にまとめたものである。目標の抽象度が高いという事実は、ぼやけた、証明できていない「意図のかたまり」となる傾向があることを意味する。これに対処するため、スマートなチームは「SMART」目標を利用する。各目標は以下のように書かれる。

  • 具体的(Specific)。単純に、簡潔に、そしてできるだけ明確に意図する成果を述べる。(ヒント:動作動詞を使用する)
  • 測定可能(Measurable)。目標を達成するためにチームがしなければならないことを明確にする。測定基準は、記述式、Yes/No式で指定するか、具体的な量あるいは範囲で指定することができる。
  • 達成可能(Achievable)。チームの制御と影響の範囲内で目標を達成できなければならない。
  • 現実的(Realistic)。制御できない要素を識別する。(ヒント:「すべてがうまくいった場合」を想定しない)
  • 時間限定(Time-bound)。達成するための期間はPI内でなければならない。従ってすべての目標はそれに応じてスコープを決定しなければならない。

ビジネス価値

リリース計画策定中に、目標が確定していくにつれて、 ビジネス責任者はチーム毎にフェース・ツー・フェースの会話を行い、各チームの個々の目標にビジネス価値を割り当てる。この特別な会話は、ビジネスからチームへ、またチームからビジネスへと、評価判断の裏にある戦略とコンテキストを伝えるものなので、その価値は、いくら誇張してもしすぎることは全くない。ビジネス責任者は個々の目標に対し1~10のランク付けを行う。ビジネス価値は、必要な労力、1つの目標に関連するストーリーポイントの合計などの、他の測定指標と混同してはいけない。ビジネス価値は計算されるものではなく、ビジネス責任者によって割り当てられ、実施時に考慮する1つのインプットとして役に立つ。

ビジネス価値は目的を達成する潜在的なビジネス効果を伝えることを意図している。ビジネス効果という概念はビジネス効果マッピングのようなテクニックで開発されてきた(参考文献[2]と[3])。ビジネス効果は、ビジネスの観点から意味があり、ビジネスの重要な優先事項に関連がある具体的な結果である。ビジネス価値を割り当てる際に、ビジネス責任者は、目標に関連したビジネス結果を検討し、相対的なビジネス価値を決定する。多くのチーム目標はエンドユーザーや顧客に直接的な価値を即時に提供する。一方、アーキテクチャーフィーチャー、インフラや開発環境における先行作業、品質への取組は、将来のビジネス価値をより速く提供するためのものである。これらすべての要素を評価して、最終的なバランスを決定しなければならない。

結果

目標がより「スマート」に作成され、ストレッチ目標も識別され、ビジネス価値が確立されると、図1の目標が図4のように進化する。

図4

チームPI目標への確約

リリース計画の終わりに、目標が合意され、ストレッチ目標によってスコープのマージンが提供され、リスクが検討されると、目標を達成するチームの能力についての信頼度投票が求められる。厳密にいうと、信頼度投票は確約と同じものではないが、大体同じものとして取り扱う。従って、この確約は依頼するのが妥当なことでなければならない。また、「確約はチームに与えるのものではなく、チームからもたらされるものでなければならない」というアジャイルな根拠があるので、SAFeにおけるチームの確約は以下の2段階で行う。

  1. 確約した目標を達成するためにできる限りのことを行うことにチームが合意する
  2. 明らかになった事実から目標が達成できないことが分かった場合に, 是正措置を取れるようにチームはすぐに申告することに合意する

このようなやり方で、すべての利害関係者は以下のどちらかを知ることができる。

a) プログラムの結果が計画通りに達成されるという予定。

b) リスクを軽減し、是正措置を講じることで、ビジネス上の障害を最小にできるだけの十分な予告。

これは調査と発展のための最高な方法である。

チーム目標からプログラム目標へ

リリース計画策定プロセスの結果として、1チームにつき1枚の承認された目標シートが作成される。チームは1セットの目標に対する自信のレベルを投票する。十分に自信がある場合、目標のセット全体は確約されたプログラム計画となる(そうではない場合、自信を持てるまで計画策定を継続する)。場合によって、これはリリース列車エンジニアに必要なすべてのインプットである。リリース列車エンジニアはチームのそのデータを利用し、管理コミュニケーションに適した形式でチーム目標をプログラムPI目標にまとめる

まとめ

集中的なトップダウン計画策定モデルから、チームが計画策定や確約に責任を持つモデルへ移行することは、リーンなアジャイル企業への変革にとって影響力の大きい1つのプロセスである。これを行うことによって、チームは権限を与えられて活性化し、仕事への満足度と達成感が向上し、パフォーマンスのレベルが上がる。また、これはビジネスとITの間の信頼関係を深めるためには、小さいけれども重要なステップである。そして、予見性と全体のビジネスパフォーマンスが改善され、より高いレベルの従業員満足度が得られる。これは本当に好循環である。


さらに知りたい場合

[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 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.