プロダクトモード組織におけるプログラムの管理方法

プログラムの成功のために、開始時に時間を投資する

プログラムの開始は、チームとプログラムを成功に導くための集中的なワークショップを実施するための自然な休憩点となります。プログラムキックオフの終了までに、ビジネス関係者とチームメンバーは、イニシアチブとその重要性、その役割、デリバリー方法、最初のリリースのハイレベルな範囲を認識している必要があります。このようにプロジェクトキックオフに前もって時間をかけることは、数ヶ月にわたる納期遅延に対する適切なリスク軽減策となります。以下のような成果をもたらすワークショップを実施するための時間を確保することをお勧めします。

• 何をすべきか、そしてなぜすべきなのか（現在の運用モデルへの変更を含む）について、すべての関係者を**連携**させる。
• 一貫した**働き方、セレモニー、ベストプラクティス**を定義する。
• 関係するすべてのチームに、ビジネス、技術、顧客の**コンテキスト**を周知させる。
• 個人の役割、責任、モチベーションを明確にすることで、チーム間の**信頼**を構築する。
• チーム内の共感と理解を築くための**基礎**を築く。
• デリバリーに存在するリスク、依存関係、仮定、複雑性を**明確にする**。

これらの成果を目指したキックオフの例として、次のようなスケジュールが考えられます。

プログラムに適切なリーダーシップスタイルを選択する

組織や製品部門の現在の文化によっては、プログラムのデリバリーに必要な緊急性とプロセスの標準化レベルを受け入れられない場合があります。そのため、ソリューションチャンピオンとして行動するプログラムリーダーは、イニシアチブの要求に合わせてリーダーシップスタイルを調整する必要がある場合があります。

例として、状況に応じたリーダーシップモデルは、さまざまなリーダーシップの状態における一般的なコミュニケーションスタイルの有用な説明を提供します（サイドバーを参照）。理想的な状態では、自己組織化された製品チームのリーダーは、チームに関与し、エンパワーメントします。しかし、プログラムでは、関係する製品チームの自己組織化の性質に挑戦する運用モデルの変更が必要になる場合があり、リーダーは自分のスタイルを調整し、通常よりも多くの時間を明確化と定義に費やす必要があるかもしれません。

コミュニケーションスタイルを変えることに加えて、プログラムリーダーは、新しい運用モデルをサポートするために必要な変更について、チームの説明責任を維持する必要があります。責任と説明責任を伝えるために一般的に使用されるツールは、責任委任マトリックス（サイドバーのRACIマトリックスを参照）です。このようなものを使用すると、プロセス標準の維持と重要なプログラム会議への参加に関して、チームメンバーが何を期待されているかを理解するのに役立ちます。

依存関係とリスクを綿密に管理する

チーム間の依存関係（バックログカップリングと呼ばれる）は、複数のチームがソリューションの異なる個別部分のデリバリーを担当するため、プログラムデリバリーでは一般的です。これらの依存関係を積極的に管理するための優れたプラクティスは、チームがより自律的にデリバリーできるように、個々のチームのバックログを分離することを目的としたアクティビティでプログラムデリバリーの前倒しを行うことです。

たとえば、例の製品チーム間のバックログカップリングを削減するために、プログラムチームは最初の数回のイテレーションでウォーキングスケルトンを構築することに集中することを決定する場合があります（下の図7を参照）。成熟した継続的デリバリー設定を想定すると、ウォーキングスケルトンはフィーチャフラグの背後で本番環境にデプロイでき、将来のプログラムの進捗状況の更新は、製品チームによってより多くの忠実度とスコープの深さが追加されるにつれて、ウォーキングスケルトンの進化に焦点を当てることができます。以下は、ウォーキングスケルトンチームが製品ロードマップにどのように適合するかを示すリリースプランの例です。

上記の例では、ウォーキングスケルトンはMVPユーザージャーニー全体で構成されますが、ユーザーインターフェースの忠実度にはほとんど時間が費やされていません。さらに、すべてのAPI統合は、モックおよびハードコーディングされたデータを使用してスタブ化されます。ウォーキングスケルトンを顧客が使用するためのものではなく、製品チームがお互いに結合する作業を、チームが独自のバックログのデリバリーを進める前にほとんど解決するためのものであることに注意してください。さらに、ウォーキングスケルトンが構築されると、すべてのチームがコードを継続的に統合できるようになり、統合が遅れるリスクを軽減します。

プログラムのデリバリーには他にも多くのリスクがあるため、通常のイテレーションサイクルの一部としてリスクを積極的に管理することは、成功に不可欠です。アクティブなリスク管理は、標準的な製品デリバリーサイクルの一部ではないことが多いため（上記の例で示されているように）、デリバリー全体を通じて勢いを維持するには、リーダーシップチームの側にある程度の規律が必要です。

強力なコミュニケーション戦略を開発する

プログラム管理における調整努力の大部分は、コミュニケーションに費やされ、次のことを行います。

• すべての関連する関係者に情報が伝えられ、問題を提起し、質問をする機会が与えられるようにする。
• チーム間のコミュニケーションを促進し、デリバリーにおけるボトルネックを軽減する。
• プログラムリーダーシップチームにブロッカーを提示し、リーダーシップチームがそれらを軽減するのに役立つようにする。

プログラムにおけるこの必要なコミュニケーションのオーバーヘッドのために、プログラムリーダーシップは、各関係者グループのニーズを満たすタッチポイントを持つ強力なコミュニケーション戦略を作成する必要があります。コミュニケーション戦略の例を以下に示します。

情報伝達を支援する視覚的な成果物に投資する

物理的なプログラムウォール（下の図9を参照）などの視覚的な成果物は、主要な関係者だけでなく、会社全体にとってもプログラムの優れた情報ラジエーターとして機能します。

プログラムウォールは、当初は孤立したイニシアチブとして見られますが、最新の状態に保ち、その周りの会話を強制することにより、新しい組織習慣と規律を作成することもできます。物理的なウォールの興味深い追加の副次的利点は、チーム間の協力と説明責任を促進できることです。さらに、プログラムウォールは、誰かと時間をスケジュールする必要なく、情報をすばやく消費できるようにすることで、会社内の他の人々からの質問を促すのに役立ちます。

理想的なプログラムウォールには、状況を簡単に更新するために必要な情報のみが含まれています。上記の例から、スウォームチームが作業を完了して解散し、デリバリーチームが現在、成果物を処理しており、そのうちの1つのチームが将来のブロッカーを削除するために何らかの支援を必要としていることがわかります。

プログラム管理のための明確な役割を持つことを恐れない

プログラム管理の規律は、複数のチームのオーケストレーションと調整を伴うイニシアチブが成功するために不可欠であると考えています。しかし、実際の役割の定義と責任は、組織のコンテキストとプログラムの複雑さに依存するため、この役割をプログラムマネージャーではなく「ソリューションチャンピオン」と呼ぶことを好んでいます。しかし、基本的に、イニシアチブ全体の健全性について責任を負い、次の戦略要素に重点を置いた努力を行う人が必要です。

• チーム間の連携を継続的に確保する。
• チームと外部関係者間のコミュニケーションが円滑に流れるようにする。
• 関連性があり重要な情報を最新の状態に保つ。
• プログラムの依存関係とリスクを管理する。

役割の責任を明確にして、関係者全員に周知させることが重要です。特に、プログラムのキックオフ時に実施することが望ましいです。製品モード組織でソリューションチャンピオンを導入する際に観察されたリスクとして、製品チームメンバーとソリューションチャンピオンの責任が重複し、両方の役割の効果が低下することがあります。前述のように、ソリューションチャンピオンはプログラムの戦略的側面に集中し、関係チームの戦術的な製品デリバリータスクには関与すべきではありません。以下のRACIマトリックスは、役割間の責任分担を示しています。

ソリューションチャンピオンと製品デリバリーのリーダーシップおよびチーム間の説明責任の分離に注意してください。