Making and meeting small commitments builds trust.

—Nonaka and Takeuchi, The Knowledge-Creating Company

PIオブジェクティブ

定義: PIオブジェクティブは、チームとトレインが次のPIで達成しようとするビジネスゴールとテクニカルゴールをまとめたもので、コミットされたかアンコミットのどちらかです。

PIプランニングの間に、チームは次のPIで達成するつもりのPIオブジェクティブを作成します。これらはいくつかのベネフィットを提供します。

ビジネスおよびテクノロジーのステークホルダーとのコミュニケーションに共通言語を提供する
短期的な焦点とビジョンを作り出す
ARTがART予測精度測定により、パフォーマンスとビジネスバリューをアセスすることを可能にする
各チームのビジネスバリューへの貢献を伝え、強調する
調整が必要な依存関係を表出する

詳細

SAFeは、ビジネス計画と成果を支援するために、ローリングウェーブ的に反復されるアジャイルチームとトレインからの短期的なコミットメントに依存しています。これにより、開発とビジネスステークホルダー間のベクトルを合わせと信頼関係が向上します。これらはPIオブジェクティブを通して伝達されます。

開発はその性質上、不確定要素がある一方で、ビジネスはある程度の信頼性と予測可能性に関して、チームに依存しています。予測可能性が不足していると会社は計画を立てることができません。過度に予測しようとする場合、組織は長期的な計画に取り組むことにコミットし、それ自体は、上手くいったとしても信頼性が低く、そしてアジリティを制限してしまいます。ビジネスおよびテクノロジーのステークホルダーは、その中間の状態を必要としており、それがPIオブジェクティブの主要な目的です。ベクトルを合わせることに加えて、現実的なオブジェクティブを設定することも、システム内の仕掛かり中の仕事(WIP)が過剰になるのを避けることができます。 PIオブジェクティブは、チームがPIプランニング中にそれらを特定するときに、主にボトムアップで作成されます。

チームのPIオブジェクティブを作成する

PIプランニング中において、チームは新しいフィーチャーを提示され、自分たちのローカルコンテキストからの仕事を表すストーリーと一緒にデリバリーする必要があるストーリーを計画します。これらの仕事全体は、特定のチームPIオブジェクティブのセットとして記述されます。その記述では、見積りとプランニング、チームのキャパシティの知識、今後のフィーチャーの分析、チームバックログのストーリーの定義、そして情報を誰もが理解できるシンプルなビジネス用語にまとめることが必要です。

チームが設定すべきオブジェクティブの数については、固定されたルールはありませんが、7～10のコミットされたオブジェクティブ（および2～3のアンコミットオブジェクティブ、以下参照）が最も効果的です。この範囲に入らない場合、他のチームやビジネスパートナーは詳細を理解し、プロセスを進めるのが難しくなります。オブジェクティブの数が多すぎると、中規模から大規模なARTでレビューするためには適さないでしょう。一方で少なすぎると、あまりに抽象化されすぎて、PIの終わりに客観的な測定ができません。

図1に、あるチームのPIオブジェクティブの例を示します。

図1 あるチームのPIオブジェクティブ

フィーチャーとPIオブジェクティブを区別する

チームのPIオブジェクティブは、多くの場合、意図されたフィーチャーに直接関連しています。多くは同じですが、図2が示すように、一部のフィーチャーは複数のチームのコラボレーションを必要とするため、直接的には同じ記述ではありません。

図2 フィーチャーからオブジェクティブへ、一部のフィーチャーは複数のチームのPIオブジェクティブに表示される

個々のチームが提供できるフィーチャー（たとえば、フィーチャーA）もあります。他のフィーチャー（フィーチャーB）では、いくつかのチームのコラボレーションが必要かもしれません。その場合、フィーチャーおよびフィーチャーへのインプットに加えて、他のチームのオブジェクティブも現われてくるでしょう。これらには、将来のフィーチャーを可能にする技術的なオブジェクティブ（例えば、図1の概念の検証等）、開発インフラストラクチャ強化、マイルストーンなどが含まれます。すべての計画プロセスの結果は、チームのオブジェクティブに記録されます。

フィーチャーと受け入れ基準は、行うべき仕事を理解し、捉え、協力するのに優れたツールです。それでも、「フィーチャーの完成」に夢中になりすぎて、隠れている全体的な目標を見逃しやすくなります。 PIオブジェクティブは、フィーチャーの開発から望ましいビジネスの成果を達成することに焦点を移すのに役立ちます。

ビジネスオーナーとの直接の会話により提供される意図をより深く理解することは、チームがシステムアーキテクトやプロダクトマネジメントに新たな視点を提供し、その専門知識を活用してより良いソリューションを迅速に作成する方法を見つけることにつながります。

(注、詳細ガイダンス記事PIオブジェクティブの役割では、チームのPIオブジェクティブとフィーチャーの違いをさらに説明し、その使用方法とバリューについての追加の洞察を提供します。)

「コミットされたオブジェクティブ」および「アンコミットオブジェクティブ」

短期的な一連のオブジェクティブにコミットし、それを提供することが信頼を構築するのに役立ちます。信頼は、すべてのステークホルダーが自信を持って前進し、「喫緊の項目は非常に実現可能性が高い」という考えを基に決定や計画を立てることを可能にします。一方で、研究と開発に固有の不確実性を前にして自信を持ってプランニングするのは簡単ではありません。物事は常に計画通りに進むわけではないため、システムに少量のバッファーを挿入することは賢明です。バッファーが大きすぎると、ARTは通常よりも達成できることが少なくなるかもしれません。バッファーが小さすぎると、多くのコミットメントが実現可能ではなくなるかもしれません。その結果、計画の信頼性が低下し自信も失われかねません。これに対処するために、SAFeはチームがプランニング中に「コミットされたオブジェクティブ」および「アンコミットオブジェクティブ」の両方を使用することを推奨します。アンコミットオブジェクティブは、チームのプランニングにおけるコミットメントに含まれない一方で、ART予測精度の測定では、チームに対してカウントされるため、ビジネスバリューを提供する予測精度を向上させるのに役立ちます。

アンコミットオブジェクティブは、PIのスコープ内で「変動」する可能性のある仕事を特定するのに使用されます。仕事は計画されていますが、結果は確定していません。チームは、オブジェクティブを達成する自信が低い場合にはいつでもアンコミットオブジェクティブを適用できます。この低い自信はさまざまな状況によるものです。

保証できない他のチームやサプライヤーとの依存関係。
このタイプの機能について、チームはほとんどまたは全く経験がない。この場合、チームは不確実性を減らすために、PIの早い段階でスパイクを計画することができる。
ビジネスが依存する重要なオブジェクティブが多数あり、チームはすでにほぼフルキャパシティの負荷がかかっている。

この場合、少数（2〜3つまで）のアンコミットオブジェクティブが賢明です。しかし、チームはアンコミットオブジェクティブをデリバリーするために最善を尽くし、それらはPIのキャパシティと計画に含まれています。しかし、これらのオブジェクティブがPIで完了しないかもしれないため、ステークホルダーはそれに応じて計画します。

アンコミットオブジェクティブは、いくつかのベネフィットを提供します。

経済性の向上 - アンコミットオブジェクティブがない場合、チームは固定されたタイムボックス内で100パーセントのスコープにコミットする。このため、チームは品質を犠牲にするか、システムに他のバッファーを挿入する必要がある。するとバッファーは蓄積され「不確定な早さを確定的な遅さに」変換されることになり、結果として全体のスループットが減少してしまう。
信頼性の向上 - アンコミットオブジェクティブは、スコープが変動することを表し、主要な優先事項をデリバリーすることに対する信頼性を向上させる。そのため、チームが述べたコミットメントをデリバリーすることは、チームとステークホルダー間の信頼を構築する上で最も重要な要素である。
変化への適応性 - 信頼性のあるケイデンスで提供するために、アンコミットオブジェクティブはコミットメントを満たすために必要なキャパシティマージンを提供し、状況が変わった時、必要に応じて優先順位を変更することができる。

SMARTなPIオブジェクティブを書く

チームのPIオブジェクティブは、そのPIに対するチームの計画をまとめます。それは非常に重要です。説明が非常に専門的で少し曖昧な場合もあるでしょう。その対策として、チームは自分たちのオブジェクティブを「SMART」に沿って記述します。

具体的 (Specific) - 目標とする成果をできるだけ簡潔に、明確に記述する。（ヒント、アクションを表す動詞から記述を始める。)
測定可能 (Measurable) - チームがオブジェクティブを達成するために何をする必要があるかを明確にする。測定方法は記述的、「はい」もしくは「いいえ」、定量的もしくは範囲を提示する。
達成可能 (Achievable) - オブジェクティブの達成は、チームがコントロールし影響を及ぼせる範囲内である。
現実的 (Realistic) – コントロールの効かない要因を認識する。（ヒント、「楽観的すぎる」想定は避ける。)
期限付き (Time-bound) – 達成の期限はPI内かそれより早くなければならないので、すべてのオブジェクティブは期限内に達成できるように調整されている。

注、SMART PIオブジェクティブは、それらが具体的で測定可能であるという点で、OKRフォーマットの主要な成果と似ています。しかし、OKRフォーマットをPIオブジェクティブに適用すると効果が低下することが実証されています。詳細はOKRをご覧ください。

PIオブジェクティブを用いたビジネスバリューの伝達

PIプランニング中にオブジェクティブが最終化されると、ビジネスオーナーは対面で各チームのオブジェクティブに「ビジネスバリュー」を共同で割り当てます。このチームとの会話により、これらの重み付け決定の背後にある戦略とコンテキストを伝えるため、その重要性をいくら強調してもしすぎることはありません。ビジネスオーナーは、各オブジェクティブを評価するために1（最低）から10（最高）までの範囲を使用します。ビジネスバリューを割り当てる一つのアプローチは、各チームが最優先のオブジェクティブに対して10をつけるものを一つ以上持つようにすることで、チーム間の不健全な比較を避けるのに役立ちます。代替的なアプローチは、チーム全体でビジネスバリューを「正規化」することで、すべてのチームが10（あるいは9や8）を持たないようにすることもできます。これは、チームがART全体で最も高いバリューのオブジェクティブに集中し、必要に応じて集結して、PIで最も高いバリューが提供されることを確認するのに役立ちます。

割り当てられたビジネスバリューは、まだ合計を計算されず、実行の考慮事項としてのインプットとして機能します。チームの多くのオブジェクティブは、ソリューションに対し直接的ですぐわかるバリューを提示します。他の要素、例えばイネーブラー（インフラストラクチャ、開発環境、品質イニシアティブの進歩など）は、将来のビジネスバリューをより迅速に創出することを可能にします。これらすべての要素は最終的にはバランスをもって考慮されなければなりません。

チームPIオブジェクティブを最終化する

オブジェクティブが、より「SMART」に作成され、アンコミットオブジェクティブが特定され、ビジネスバリューが確立されたとき、図1のオブジェクティブは図3のように進化するかもしれません。

図3 ビジネスバリューを割り当てられた最終的なチームのPIオブジェクティブ

PIオブジェクティブにコミットする

PIプランニングの終盤にて、チームはPIオブジェクティブにコミットする自信投票が行われます。（アンコミットオブジェクティブは、このコミットメントに含まれていません。）仕事をする人々に対し、この投票を行ってもらうことは合理的な一面をもちます。このSAFeのコミットメントには2つの部分があります。

チームは、コミットされたオブジェクティブを達成するために、合理的に可能な限りのことをすることに合意します
PIの間に、一部のオブジェクティブが達成不可能であることがわかった場合、チームはすぐにエスカレーションすることに同意し、ステークホルダーに通知され、是正措置が取られるようにします。

このように、すべてのステークホルダーは、ARTの結果が計画通りに達成されるか、または問題が起きた際に軽減し、是正措置を講じるため等の十分な情報を提供され、ビジネスの混乱を最小限に抑えられるかを知ることができます。結局のところ、これは「研究と開発」であるため、それ以上は望めません。

ARTとソリューショントレインのPIオブジェクティブの作成

PIプランニングプロセスのアウトプットは、各チームの承認されたPIオブジェクティブの集まりになります。チームは、一連のオブジェクティブに対し自信投票を行い、自信度が十分に高い場合、オブジェクティブの集合体はコミットされたARTの計画になります。リリーストレインエンジニアは、チームのオブジェクティブをマネジメントコミュニケーションに適した形式でART PIオブジェクティブにまとめます。

まとめられたオブジェクティブは、チームのPIオブジェクティブと同様に「SMART」であるべきで、アンコミットオブジェクティブを持つべきです。また、チームのPIオブジェクティブと同様に、ART PIオブジェクティブは、ARTが取り組んでいるビジネスフィーチャー、イネーブラー、または他のビジネスまたは技術的な目標を説明するかもしれません。

ARTがソリューショントレインの一部である場合、オブジェクティブはソリューショントレインエンジニアによってさらにまとめられ、ソリューショントレインPIオブジェクティブへ合成され、要約されます。これはSAFeにおけるPIオブジェクティブの最上位レベルであり、それらはステークホルダーに対してソリューショントレインが次のPIで何を提供するかを伝えます。以下の図4は、チームからARTへ、そしてARTからソリューショントレインPIオブジェクティブへまとめる要約の方法を示しています。

ビジネスバリューは、チームのPIオブジェクティブにのみに割り当てる必要があります。その予測精度メトリクスがまとめられ、より高いレベルでの予測精度を決定します。

図4 チーム、ART、およびソリューショントレインPIオブジェクティブのロールアップ

現実的なPIオブジェクティブでWIPを減らす

チームのPIオブジェクティブレビューにおいて、さまざまなビジネスステークホルダーが想定したものすべてがPIタイムボックスで達成される可能性は低いとわかるかもしれません。したがって、計画された仕事の一部は、PIオブジェクティブに合意を得るためにビジネスオーナーと再評価する必要があります。

その際、優先度の低い作業項目は、ARTバックログに戻されます。過剰なWIPを減らすことで、オーバーヘッドとドタバタ状態を減らし、生産性とベロシティを向上させます。その結果、すべてのビジネスステークホルダーとチームメンバーが合意した実現可能なPIオブジェクティブのセット、効率の向上、そしてデリバリー成功の可能性が高まります。

大規模ソリューションレベルでのプランニングも上記とよく似ています。ARTのプランニングは互いに影響を及ぼし、一部の仕事をソリューショントレインバックログへと、後のPIで再評価するために、戻すこともあります。

詳しく学ぶ

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

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

最終更新: 2022年12月13日