Nexus Framework: 3〜9チームで Scrum をスケールさせる方法

著者: Tara Minh · 更新日: 2026年10月10日

Nexus は、1つのプロダクトに取り組む約3〜9つの Scrum Teamのための、Scrum.org のフレームワークです。Scrum のルールを守ったまま、依存関係の管理に必要なものだけを追加します。具体的には、Nexus Integration Team、いくつかの追加イベント、そして各 Sprint ですべてのチームが貢献する1つの共有 Integrated Increment です。

スケールの悩みの多くは、コードを速く書くことではありません。2つのチームが同じモジュールを触り、3つ目のチームが両方を待っているのに、Sprint の終わりまで誰も気づかない、といったことです。Nexus はこの問題を中心に設計されています。会社の組織を作り替えることは求めません。依存関係を早い段階で見える化し、統合に対する責任を明確に誰かへ与えることを求めます。

重要な事実

• Nexus はKen Schwaber と Scrum.orgが開発したもので、Nexus Guideには2015年、2018年、2021年の各版があります。
• 現行のNexus Guide（2021年1月版）は、Nexus を、1人の Product Owner と1つの Product Backlog を持つ約3〜9つの Scrum Team と定義しています。
• Nexus Integration Team は、Product Owner、Scrum Master、そして1人以上の Nexus Integration Team Member で構成されます。
• このガイドは、Nexus のイベントに固定のタイムボックスを定めていません。所要時間は、対応する Scrum のイベントを目安にします。
• 2021年版では、Refinement がCross-Team Refinementに名称変更されました。
• LeSSは2〜8チームを対象としているため、両フレームワークはチーム数で大きく重なり、主な違いは組織変革をどこまで求めるかにあります。

Nexus framework とは

Nexus は、スケールしたプロダクトデリバリーを開発し、維持するためのフレームワークです。Scrumを最小限に拡張したものです。チームは引き続き Sprint を回し、1人の Product Owner と1つの Product Backlog を持ち、同じ Scrum の価値基準に従います。変わるのは、グループが緩やかに関連した複数の Increment ではなく、1つの Integrated Increment を生み出すことと、その統合を実現する責任を小さなグループが負うことです。

「nexus」は結節点を意味する言葉で、このフレームワークは主に結びつき、つまり Backlog 項目同士、チーム同士、そして各チームが Done と呼ぶものと実際にまとめて出荷されるものとの結びつきを扱います。

多くの部分を支えているのは、次の3つの考え方です。

• 1つのプロダクト、1つの Backlog。 すべてのチームが、1人の Product Owner が所有する同じ Product Backlog から作業を引き取ります。
• 依存関係はフローの敵である。 Sprint の前に依存関係を洗い出して取り除き、残ったものを追跡します。
• 統合は Sprint ごとに行う。 Nexus は、リリースフェーズの最後ではなく、少なくとも Sprint ごとに1回、動作する統合済みの Increment を生み出さなければなりません。

Nexus のロール: Nexus Integration Team

Nexus は新しいマネジメント層を追加しません。追加するのは1つのチームです。Nexus Guideによれば、Nexus Integration Team には次のメンバーが含まれます。

よくある誤解は、Integration Team が統合作業を行うというものです。そうではありません。統合作業は、引き続き各 Scrum Team が自分たちで行います。Integration Team は調整し、コーチングし、障害を取り除きます。そして、Integrated Increment が実際に存在し、Definition of Done を満たすことに責任を負います。また、Integrated Increment のための共有のDefinition of Doneも所有します。個々のチームはより厳しい基準を自分たちに課すことはできますが、より緩い基準にはできません。

メンバーは、仕事の変化に応じて入れ替えられます。ガイドによれば、Integration Team の責任が果たされているかぎり、Integration Team での立場がチームのメンバーとしての立場に優先します。つまり、両者が衝突したときはこちらのロールが先、という婉曲な言い方です。

Nexus のイベント

Nexus は標準の Scrum のイベントをそのまま残し、それらをチーム横断の版で包みます。Nexus Guideに基づいた各イベントの仕組みは次のとおりです。

実際の運用について、いくつか実践的な補足があります。

Cross-Team Refinement は、その価値が最も問われるイベントです。チームが Sprint Planning の場で、チーム B がチーム A によるスキーマ変更を必要としていると初めて知るようなら、リファインメントは失敗しています。これを継続的な作業として扱ってください。通常のBacklog リファインメントと密接に関連していますが、チーム横断の依存関係を見つけて小さくするという固有の役割があります。

Nexus Sprint Planning は、各チームの代表者が集まって作業の順序とチームの割り当てを確認する場です。その後、各チームが自分たちの担当分について通常のスプリントプランニングを行います。そこから生まれる Nexus Sprint Backlog は、進行中のすべてを共有して見るためのものです。

Nexus Daily Scrum は、全員ではなく代表者のためのものです。短く、統合に焦点を当て、その成果は Nexus Sprint Backlog と各チーム自身の計画の調整です。

Nexus の成果物

Nexus は Scrum の成果物を使い、いくつかの共有版を追加します。

ガイドは、以前の版では「Nexus Goal」という用語を使っていましたが、Scrum の用語に合わせて2018年に Nexus Sprint Goal へ名称変更しました。古いブログ記事を読む際は、旧来の用語が使われている点に注意してください。

Nexus と SAFe、LeSS、Scrum of Scrums、Disciplined Agile の比較

Nexus は、スケーリングの選択肢の中では軽量な側に位置します。よく比較される選択肢との違いは次のとおりです。

2つの比較は、それぞれ一言添えておく価値があります。SAFe と比べると、Nexus はコミットメントが小さく済みます。全社の計画ケイデンスを採用するのではなく、すでに1つのプロダクトを共有しているチームに、調整役のチームを1つ加えるだけです。LeSS と比べると、違いはどこまで組織を再編する意思があるかです。LeSS はフィーチャーチームと、あらゆることに対して実質的な権限を持つ単一の Product Owner を求めますが、Nexus はそうした基本がすでにあり、統合の継ぎ目で支援が必要な状況を前提にしています。

Scrum of Scrums は、最も軽量な選択肢です。チームの代表者が依存関係を共有する定期的なミーティングであり、正式なものを導入する前にチームが行っている場合も多いでしょう。Nexus は、これをより構造化した版と見ることができ、定義されたイベントと成果物、そして責任を持つグループが備わっています。

Nexus の始め方

チームが通常どのように導入するかに沿った手順を紹介します。

1. 前提条件を確認する。 1つのプロダクトを開発する3つ以上のチーム、1人の Product Owner、そしてすでに単独でまともな Sprint を回せるチームが必要です。Nexus は、まだ Scrum を実践していないチームを直してはくれません。
2. Nexus Integration Team を編成する。 Product Owner を指名し、Scrum Master を選び、各チームから経験豊富な1〜2人を Integration Team Member に選びます。彼らに期待することを、短いワーキングアグリーメントで合意します。
3. 共有の Definition of Done を1つ作る。 チーム単位の完了だけでなく統合までを含め、「Done」が他のすべてと一緒に動作することを意味するようにします。
4. Cross-Team Refinement を始める。 毎週決まった枠を確保します。Backlog の上位を順に確認して依存関係に印を付け、ほとんどの項目が1つのチームで完了できるまで分割します。
5. Nexus Sprint Planning を実施する。 Nexus Sprint Goal を決め、項目をチームに割り当て、残っている依存関係を見える化した Nexus Sprint Backlog を作成します。
6. 依存関係ボードを管理する。 下のテンプレートを使い、Nexus Daily Scrum で確認します。
7. Nexus Sprint Review と Retrospective を1回ずつ開く。 5つのデモではなく1つの Integrated Increment を見せ、チーム同士の協働のしかたを改善します。
8. 検査と適応を行う。 統合の問題が遅い時期に出続けるなら、まずリファインメントを直し、次にチーム構成を見直します。

テンプレート: チーム横断の依存関係ボード

これをトラッカーにコピーして、毎日更新してください。Nexus を始めるときに、最も多く求められる成果物です。

列についての補足です。

• 提供元 / 提供先 は、依存関係の向きを明確にします。これがなければ、ボードは心配事のリストになってしまいます。
• 期限 は、「近いうちに」といった曖昧な表現ではなく、Sprint の何日目かで示します。これが Nexus Daily Scrum で確認される内容です。
• ステータス に必要な値は4つだけです。未着手、進行中、ブロック中、完了。
• 遅れた場合のリスク は、Integration Team が何から追いかけるべきかを素早く順位づけするための列です。

よい習慣は、Nexus Sprint Planning の時点と Cross-Team Refinement の後で、未解決の行数を数えることです。Sprint を重ねてもその数が減らないなら、リファインメントが依存関係を取り除けていないので、次に疑うべきはチーム構造です。

機能別の例

Nexus はソフトウェアから生まれましたが、その仕組みは、複数のチームが Sprint で作る、あらゆるプロダクトに当てはまります。

Do と Don't

Nexus が適さない場合

Nexus が適さないのは、チームが3つ未満の場合です。その場合は Scrum に軽い同期を加えれば十分です。1つではなく多数の無関係なプロダクトを調整している場合や、チームがまだ単独の Scrum を機能させられていない場合も適しません。ポートフォリオの予算配分、全社の計画、重いガバナンスが必要なら、SAFe のようなフレームワークのほうが広い範囲をカバーします。Nexus は3チームから9チームまでを支えます。会社全体のオペレーティングモデルであるかのようなふりはしません。

チームがすでに Scrum を実践していて、Sprint の終盤にお互いにつまずき続けているなら、Nexus は小さくリスクの低い変更です。Integration Team を指名し、依存関係を意識したリファインメントを始め、1つの Integrated Increment を一緒にレビューしてください。そこから始めて、必要だとボードが示したときにだけ構造を追加しましょう。