---

スクラムをどう拡張するか（分散した大規模プロジェクト）？きっと驚かれるはずです！

ここまで説明したスクラムは、一つの場所にいる、一つのチームで最も使いやすいものです。 しかし実際には、一つだけでは全体を実装できなかったり、メンバーが複数拠点に分かれたりします。

一つではプロダクトのニーズを満たせない場合、追加を検討できます。地理的に分かれているだけで、チームを増やす必要はありません。人数を増やすと、調整の費用が高まる場合もあります。 実際、多くのチームが、離れた場所や別の大陸に分散しています。

分散する理由には、さまざまなものがあります。

• 技術上の理由： ソフトウェアの特定の構成要素を作るノウハウが、本社周辺にない場合。
• 専門性の理由： 必要な開発活動の能力が、その場所にない場合。自動テスト、画面設計、他社ソフトとの連携などに、社外拠点の専門家が必要なことがあります。
• 規模の理由： 決めた期間に届けるため、一つのチームに収まるより多くの人が必要な場合。一つを無制限に大きくするのではなく、まとまりのある複数チームが必要かもしれません。
• 事業上の理由： 費用の低い場所の人材や、時差を生かして仕事を続けられる技術者の活用が、事業上の合理性を持つ場合。

意思疎通はスクラムの重要な一部なので、全員が、分散環境の課題を乗り越えるよう努める必要があります。 音声・映像会議、画面共有などを、全員が利用できるようにします。

よく使われる管理ツールも、健全で継続的な対話を支えます。プロダクトバックログ、スプリントバックログ、問題一覧、知識やニュースの共有などが含まれます。

プロジェクトの構成：複数チーム

大規模な環境へ広げる最もシンプルな方法は、同じ場所のチーム数を増やすことです。

複数が協力する必要があるなら、徐々に増やすのが良い方法です。

どういう意味でしょうか？

一つの場所にいる複数のチーム

多くの組織では、十チームを一斉に作るより、段階的な成長のほうが管理しやすくなります。一つから始め、数回成功した後に、一〜二チームを加えます。複数のチーム（詳細： 複数のスクラムチーム）がうまく協力できると確かめてから、さらに分散した組織へ追加していけます。

チーム数を増やす

新しく作る方法は、一般に二つあります。

• 既存のチームを分け、必要なときに新しいメンバーを加える。
• まだ参加していない、まったく別の技術者で新しいチームを作る。

既存のチームを分ける利点は、進行中のプロジェクトの知識と経験を持つ人を生かせることです。

通常、できた直後からある程度働けます。ただし、十分機能していたチームを二つに分けるため、意欲に問題が起こる可能性があります。 特に、経営層の事前の説明や理由がなく、心理面と技術面の準備ができていない場合です。

完全に新しいチームを加えるなら、既存の構成とスプリントは維持できます。それでも、調整、参加への準備、統合には注意が必要です。新しいチームの知識と勢いを育てるには、より長くかかります。

どちらの方法でも、次の原則を忘れないでください。

• 少数から始める。
• 徐々に増やす。
• 変化と成長の間も、仕事の継続と、ソフトウェアや事業価値の円滑な提供を守る。
• 生産性と継続を妨げる大きな問題があるなら、拡張より先に解決する。

プロジェクトの構成：分散チーム

複数の場所に分散すると、複雑さが特に大きくなります。対話の障壁、仕事の調整の難しさ、共通規範の誤解などは、その一部にすぎません。

複数の場所にいる複数のチーム

対処しなければ、重大な結果になります。

次の能力が不足すると、企業は数十億ドルものIT予算を無駄にします： 組織のリーダーシップ や スクラム拡張の専門性。

対応のための、重要な提案が四つあります。

• 新しいメンバーがフレームワークを学び、次の立場に必要な能力を身に付けられるようにします： スクラム拡張の専門家,
• プロジェクトを十分に紹介し、技術面だけでなく、事業価値の面でも、何のために働くのかを理解できるようにします。自分の貢献を高める判断ができるようにするためです。
• 規範を定めます。一つのチームに、対話、計画、実行の決まりがあるように、複数のチームにも上位の共通規範が必要です。共に伝え合い、計画し、働き、問題を解き、顧客と事業に価値を届けるためです。
• 新しい人が、少なくとも一時的には経験者と共に働くようにします。現地訪問や実地研修が必要でも、望ましいことです。知識を円滑に移し、異なる場所の人同士で、双方向の個人的な対話を築けます。

仮想チーム

一つのチームのメンバー自体が、複数の場所に分かれる選択肢もあります。「仮想チーム」と呼びます。

主な課題は、円滑な意思疎通です。同じ部屋にいなくても、必要なイベントをすべて行い、仕事を調整しなければなりません。

仮想チーム

役立つ場合、同じ場所の人は同じ部屋で働けます。ただし、遠隔の人も十分に参加できるようにします。協働・対話ツールへの依存は高まります。同じ会議室から映像会議で接続し、遠隔の仲間とイベントに参加できます。

スクラムプロダクトオーナーチーム

これまで説明したとおり、オーナーとチームの定期的な意思疎通は、成功する提供に不可欠です。

異なる場所でも、プロダクトの判断に効果的にアクセスできる必要があります。 一つのプロダクトには、一人のオーナー、一つのゴール、一つのバックログを共有します。補助的な仕事は委任できますが、説明責任は残ります。各チームへ別の責任者を置く必要はありません。

この版の「プロダクトオーナーチーム」と「チーフスクラムプロダクトオーナー」は、組織で協力する一つの形です。代理担当や専門家と働けますが、追加のスクラムの責任ではなく、一つのプロダクトの一人のオーナーを置き換えるものではありません。

この協力に支えられたオーナーは、次のことに集中します。

• 顧客の需要に応える、正しいプロダクトを作る。
• オーナーと代理担当が効果的に協力し、チームによる事業と技術の価値づくりを支える。

オーナーは、効果的なバックログ管理に責任を負い続けます。要件の補助的な仕事には、他の能力と関係者の意見も役立ちます。 事業計画の代表者、関係するステークホルダー、エンタープライズアーキテクト、技術アーキテクトなどです。

同じプロダクトでは、一つの順序付きバックログから、共有するゴールへ取り組みます。各チームはストーリーの一部を届けますが、複数チームの注意と成果が必要なものもあります。

コンポーネントチームとフィーチャーチーム

仕事を分配する際、特定の構成要素、または機能への責任を割り当てられます。 そこで「コンポーネントチーム」または「フィーチャーチーム」と呼びます。

コンポーネントチーム

システム全体の、特定の構成要素の実装だけに責任を持ちます。 ストーリーを完成させるため、構成要素内で実装できる小さな部分に分ける必要が生じます。要素間の依存関係により、継続的な統合が成功に不可欠になります。

スクラムプロダクトオーナーチーム

依存関係で、スプリント内の完全な機能の提供が難しくなる場合があります。協力と統合で対処する必要があります。同じプロダクトのチームには、共有する完成の定義を満たす、統合された利用可能なインクリメントが必要です。

未統合の作業のまとまりと、提供までの時間が増えます。 小さなまとまりと短い時間で、提供可能なインクリメントを届けるべきなので、望ましい状態とは言えません。

利点は、特定の構成要素の構造と設計の詳細へ集中し、専門性を築きやすいことです。 探索と革新が必要な要素には、大きな利点になります。

一方、システム全体の一部だけに専門化します。 全体を見渡す視点と、機能の事業上の必要性を見失う場合があります。

顧客が払うのは、構成要素ではなく、事業に使う機能の対価であることを忘れないでください。 機能へ集中し続けなければ、全体の最適化と統合に余分な時間がかかります。個別の要素を最適化する判断が、全体の成功と性能に、見えないボトルネックを作る場合があります。

コンポーネントチーム

フィーチャーチーム

バックログで定義したストーリーの実装に、全面的な責任を持ちます。 構成要素ごとに分ける必要はありません。各チームが、完全に動く機能と、それに伴う事業価値を届けます。

フィーチャーチーム

メンバーは職能横断的な能力を備え、素早い提供のため、可能な限り自律的に働きます。 システム全体の知識を保てるため、機能を他の部分と統合しやすいことが利点です。

ただし、構成要素の十分な知識を築くのは難しい場合があります。独立して素早く提供できるチームには、分野横断的な能力が必要なため、育成に時間がかかります。それでも、多くの組織で仕事を成し遂げるのは、こうした高い実力のチームです。皆さんの組織も、そうかもしれません。

コンポーネントチームとフィーチャーチームを、どう選びますか？

実際、多くの大きな組織は、専任のコンポーネントチームとフィーチャーチームを併用しています。

コンポーネントチームとフィーチャーチーム

図のチームCはコンポーネントチームです。機能を担う他のチームに、計画済み、または必要に応じた基盤サービスを提供します。 チームC自体は、最初から最後までのストーリーを直接実装しません。他のチームが約束したストーリーに必要なものを提供します。

そのため、各フィーチャーチームに必要な、その構成要素の専門家の人数を抑えられます。

分散したプロジェクト環境のスクラムマスター

分散環境では、マスターの役割がさらに重要になります。次のような事情があるからです。

• 価値観をそろえるために、追加の努力が必要になる。
• 複数のチームに関わる、個別と全体の規範を確立するのに時間がかかる。
• チームと成果物の依存関係が増え、障害も多くなる。

マスターは、相談しやすく、効果的に支援できる必要があります。同じ場所にいることは役立ちますが必須ではなく、遠隔でも支援できます。分散した構成でも、次のことを可能にするべきです。

• 進行を妨げる障害の除去を促す。
• 効果的な仕事の合意を作る支援をする。
• スクラムフレームワークの使い方の改善を助ける。

リード、すなわち主担当のマスターを置き、チーム横断のコーチングと調整を支える組織もあります。任意の構成であり、必須の階層や、各チームの責任の代替ではありません。

各チームには引き続きマスターの責任があり、自分たちのイベント、自己管理、改善に有効な支援が必要です。