Nexus - Amazon S3...Nexusは、役割・イベント・作成物と、約3～9 のスクラムチームの作業をまとめる技法で構成されたフレームワークである。複数のスクラムチームが、ゴールを達成する統合インクリメントを構築するため

Nexus™ ガイド

Nexus 完全ガイド:

大規模スクラム開発の外骨格

Developed and sustained by Ken Schwaber and Scrum.org

2015 年 8月

Copyright Scrum.org, 2015 All Rights Reserved Page 1 (Version 1.1)

目次

Nexusの概要 ............................................................................................................................ 2

Nexusガイドの目的 .................................................................................................................. 2

Nexusの目的........................................................................................................................... 2

Nexusの背景........................................................................................................................... 2

Nexusフレームワーク ............................................................................................................... 3

Nexusのプロセスの流れ .......................................................................................................... 4

ソフトウェアプラクティス............................................................................................................. 5

Nexus ......................................................................................................................................... 5

Nexusの役割........................................................................................................................... 5

Nexus 統合チーム................................................................................................................. 5

Nexusのイベント ...................................................................................................................... 6

Nexus スプリントプランニング ................................................................................................. 6

Nexus デイリースクラム .......................................................................................................... 7

Nexus スプリントレビュー ....................................................................................................... 7

Nexus スプリントレトロスペクティブ ......................................................................................... 8

リファインメント ...................................................................................................................... 8

Nexusの作成物 ....................................................................................................................... 9

プロダクトバックログ............................................................................................................... 9

Nexus ゴール ........................................................................................................................ 9

Nexus スプリントバックログ ..................................................................................................... 9

統合インクリメント ................................................................................................................ 10

作成物の透明性 .................................................................................................................... 10

「完成」の定義..................................................................................................................... 10

最後に ...................................................................................................................................... 10

謝辞.......................................................................................................................................... 10

翻訳.......................................................................................................................................... 11

TRANSLATED BY: Kado Masanori & Morita Kenji LinkedIn Twitter

mailto:[email protected]

https://jp.linkedin.com/in/kdmsnr

https://twitter.com/kdmsnr


Nexusの概要

Nexusガイドの目的

Nexusは、大規模なプロダクトやソフトウェアの開発を発展および維持するためのフレームワークで

ある。その構成要素としてスクラムを使用している。本ガイドでは、Nexusの定義を説明する。Nexus

の定義には、Nexusの役割・イベント・作成物と、それらをまとめるルールが含まれる。Nexusは、Ken

Schwaber と Scrum.orgが開発したものである。Nexusガイドはその開発者たちが執筆・提供する。

Nexusの目的

Nexus（名詞）：（Scaled Professional Scrum における）開発の単位

Nexusは、役割・イベント・作成物と、約 3～9のスクラムチームの作業をまとめる技法で構成されたフ

レームワークである。複数のスクラムチームが、ゴールを達成する統合インクリメントを構築するため

に、1 つのプロダクトバックログに取り組んでいる。

Nexusの背景

ソフトウェア開発は複雑であり、開発作業を統合して動作するソフトウェアを生み出すには、多くの作

成物やアクティビティが必要になる。「完成」された成果を生み出すには、これらをうまく調整しなけれ

ばいけない。作業をうまく整理して、並び替え、依存関係を解消して、成果の準備を整えなければい

けない。ソフトウェアには、物理的なものではないがゆえの難しさがある。

多くのソフトウェア開発者たちは、スクラムフレームワークを使用して、チームで協力しながら動作す

るソフトウェアのインクリメントを開発している。だが、複数のスクラムチームが 1つのプロダクトバック

ログや 1 つのコードベースで作業していると、困難が生じてしまう。たとえば、お互いに影響を及ぼ

すような作業をするときに、開発者たちが同じ場所にいない場合、どのようにしてコミュニケーション

をとればいいのだろうか？開発者が異なるチームに所属している場合、どのように作業を統合して、

どのように統合インクリメントをテストすればいいのだろうか？2つのチームを統合したときに、こうした

課題が発生する。チームが 3つ以上になると、さらに事態は複雑になる。

複数のチームが協力して、少なくともスプリントごとに完全で「完成」したインクリメントを作成しようとす

ると、それぞれの作業に多くの依存関係が生まれる。こうした依存関係は、以下に挙げたものと関係

している。

1. 要求：要求のスコープが重なる可能性がある。あるいは、実装方法が影響しあうこともある。プロ

ダクトバックログの並び替えや要求を選択するときに、このようなことを考慮する必要がある。

2. ドメイン知識：チームにいる人たちは、さまざまなビジネスやコンピュータシステムの知識を持っ

ている。こうした知識を適切にスクラムチームに配置して、スプリントでチームを中断させないよ

うにする必要がある。

3. ソフトウェアやテストの作成物：要求はソフトウェアコードやテストスイートで具現化されている／

されることになる。


要求、チームメンバーの知識、ソフトウェアコードやテストの作成物が、複数のスクラムチームに同じ

ようにそろっていれば、チーム間の依存関係は軽減できる。

スクラムを使っているソフトウェア開発が大規模になった場合、要求、ドメイン知識、ソフトウェアコード

やテストの作成物の依存関係は、チームの組織化を推進するものでなければいけない。それが可能

ならば、生産性は最適化されるだろう。

Nexusフレームワーク

Nexusは、複数のスクラムチームを組み合わせて統合インクリメントを作るときに、それらの上に成り

立つ外骨格（エクゾスケルトン）である。Nexusは、スクラムやその構成要素とうまく調和しており、す

でにスクラムプロジェクトを経験した人たちには馴染みのあるものとなるだろう。スクラムと Nexusの違

いは、スクラムチーム間の依存関係や相互作用に注意を払っており、ひとつの「完成」した統合イン

クリメントを少なくともスプリントごとにデリバリーするところにある。

図が示すように、Nexusは以下の要素で構成されている。

• 役割：新しい役割である Nexus統合チームは、最高の成果が生み出されるように、Nexusの適

用とスクラムの運用の調整・コーチ・監督を担当する。Nexus統合チームは、プロダクトオーナ

ー、スクラムマスター、Nexus統合チームメンバーで構成されている。

• 作成物：すべてのスクラムチームが、共通した 1つのプロダクトバックログを使用する。プロダク

トバックログアイテムがリファインメントされ、準備完了の状態になれば、スプリントのなかでどの

チームが担当するのかが、目で見てわかるようになる。新しい作成物である Nexusスプリントバ

ックログは、スプリントにおける透明性の確保を支援する。すべてのスクラムチームは、それぞ

れのスプリントバックログを保持している。

• イベント：通常のスクラムイベントを強化するために、新しいイベントを追加・補助・置換（スプリン

トレビューの場合）する。手を加えたことによって、Nexus全体とそれぞれのスクラムチームの両

方の取り組みに役立つ。


大規模スクラムの外骨格となる Nexus™フレームワーク

Nexusのプロセスの流れ

スクラムチームのすべてのメンバーが Nexusのクロスファンクショナルなメンバーとなり、 Nexusのす

べての作業を行う。依存関係があるため、チームが最も適切なメンバーを選択してから、特定の作業

を行うこともある。

• プロダクトバックログのリファインメント：プロダクトバックログは、依存関係がわかるように、そこか

ら排除あるいは最小化できるように、うまく分割する必要がある。プロダクトバックログアイテムは

、リファインメントによって薄くスライスされた機能となる。それらを担当するチームは、できるだ

け早く決定すべきである。

• Nexus スプリントプランニング：それぞれのスクラムチームの適切な代表者が集まり、リファインメ

ントしたプロダクトバックログの議論やレビューをする。代表者は自分たちのチームのプロダクト

バックログアイテムを選択する。それから、それぞれのスクラムチームで必要に応じて他のチー

ムと情報交換しながら、自分たちのスプリントの計画を立てる。成果物となるのは、包括的な

Nexusゴールにあわせた複数のスプリントゴール、それぞれのスクラムチームのスプリントバック

ログ、1 つの Nexus スプリントバックログである。Nexus スプリントバックログによって、スクラムチ

ームが選択したプロダクトバックログアイテムとそれらの依存関係が明らかになる。

• 開発作業：すべてのチームがソフトウェアを開発する。統合の完了をテストできるように、共通の

環境に頻繁に統合する。

• Nexus デイリースクラム：それぞれのスクラム開発チームの適切な代表者が毎日集まり、統合の

問題が発生していないかを確認する。問題があれば、スクラムチームのデイリースクラムにその

情報が伝えられる。スクラムチームはデイリースクラムにおいて、Nexusデイリースクラムで発生

した統合の問題を解決できるように、その日の計画を立てる。

• Nexus スプリントレビュー：すべてのチームがプロダクトオーナーのもとに集まり、統合されたイ

ンクリメントをレビューする。このときにプロダクトバックログの調整が行われることもある。


• Nexus スプリントレトロスペクティブ：それぞれのスクラムチームの適切な代表者が集まり、共通

の課題を特定する。その後、スクラムチームが個別のスプリントレトロスペクティブは開催する。

チームの適切な代表者が再び集まり、共通の課題の必要なアクションについて議論することで

、ボトムアップの情報を提供する。

ソフトウェアプラクティス

多くのソフトウェア開発プラクティスは、スクラムチームの作業をまとめて、統合インクリメントを作成す

るために必要である。こうしたプラクティスには自動化が必要である。自動化することによって、作業

や作成物のボリュームや複雑さが管理しやすくなる。大規模な環境では特にそうだ。

Nexus

Nexusの役割・イベント・作成物は、スクラムガイドに書かれているスクラムの役割・イベント・作成物

の目的や意図をそれぞれ継承している。

Nexusの役割

Nexusは、Nexus統合チームと約 3～9のスクラムチームで構成される。

Nexus統合チーム

Nexus統合チームには、（Nexusの共同作業による）統合インクリメントを作成する最終的な責任があ

る。統合インクリメントは少なくともスプリントごとに作成されなければいけない。スクラムチームには、

リリース判断可能なソフトウェアのインクリメントを開発する実行責任がある。スクラムチームのメンバ

ーの役割は、スクラムガイドで規定されている。

Nexus統合チームは、以下の構成のスクラムチームである。

• プロダクトオーナー

• スクラムマスター

• 1 人以上の Nexus統合チームメンバー

Nexus統合チームのメンバーは、それが適切で必要なときには、Nexusに含まれるスクラムチームで

作業することがある。ただし、その場合も Nexus統合チームの作業を優先しなければいけない。

Nexus統合チームのメンバーであることは、通常のスクラムチームのメンバーであることよりも優先さ

れる。これにより、多くのチームに影響する問題を解決する作業が優先されるようになる。

Nexus統合チームの構成は、Nexusのニーズに応じて、時間とともに変化する可能性がある。Nexus

統合チームの共通のアクティビティには、依存関係やチーム間の問題に対する認識を高めることや

、コーチング、コンサルティングが含まれる。また、プロダクトバックログの作業を行うこともある。

Nexus統合チームは、あらゆる統合の問題に対して、当事者としての認識を持つ。また、Nexusのス

クラムチームのすべての作業の統合を成功させる最終的な責任がある。統合には、チーム間の技術

的／非技術的な制約を解消することも含まれる。こうした制約は、統合インクリメントを絶えずデリバリ


ーするという Nexusの能力を妨害する可能性がある。Nexus統合チームは、制約を解消するために

Nexusにあるボトムアップの情報を使うべきである。

Nexus 統合チームのプロダクトオーナー

Nexusは、1 つのプロダクトバックログで作業する。スクラムフレームワークで説明しているように、1

つのプロダクトバックログには、その内容の最終決定権を持つ 1人のプロダクトオーナーが割り当て

られる。プロダクトオーナーには、複数のスクラムチームで統合されたプロダクトや作業の価値を最

大化する実行責任がある。プロダクトオーナーは、Nexus統合チームに所属する。

プロダクトオーナーは、Nexusで作成する統合インクリメントの価値を最大化するために、プロダクト

バックログの順番とリファインメントに最終的な責任を持つ。そのやり方は、組織・Nexus・スクラムチー

ム・個人によって大きく異なる。

Nexus 統合チームのスクラムマスター

Nexus統合チームのスクラムマスターは、Nexus フレームワークが理解され、実施されることに対する

実行責任を持つ。Nexus統合チームのスクラムマスターは、同じ Nexusに含まれる 1つ以上のスク

ラムチームのスクラムマスターになることもある。

Nexus 統合チームのメンバー

大規模開発では、個々のスクラムチームではあまり使われないツールやプラクティスが必要になる。

Nexus統合チームは、これらのプラクティスやツール、一般的なシステムエンジニアリングの利用に

精通したソフトウェアのプロフェッショナルたちで構成される。Nexus統合チームのメンバーは、依存

関係を検出するために、これらのプラクティスやツールが確実に実施・理解・使用されるようにする。

また、「完成」の定義に向けてすべての作成物を頻繁に統合する。

Nexus統合チームのメンバーには、Nexusのスクラムチームがこれらのプラクティスやツールを獲得・

実施・学習できるように、コーチングや指導を行う実行責任がある。また、品質の高い統合インクリメ

ントを開発するために、組織で求められる開発・インフラ・アーキテクチャ標準のコーチングを行う。

主要な実行責任が満たされたなら、Nexus統合チームのメンバーは、1つ以上のスクラムチームの

開発チームメンバーとして作業することができる。

Nexusのイベント

Nexusのイベントの期間は、スクラムガイドにある対応するイベントの長さによって決まる。Nexusのイ

ベントは、対応するスクラムイベントに追加されるタイムボックスである。

Nexusスプリントプランニング

Nexus スプリントプランニングの目的は、Nexusのスクラムチームが 1つのスプリントで行うすべての

活動を調整することである。プロダクトオーナーは、ドメイン知識を提供し、選択や優先順位の付け

方を指導する。


Nexus スプリントプランニングを始めるにあたり、リファインメントのイベントで作られた作業の順番をそ

れぞれのスクラムチームの適切な代表者が確認・調整する。コミュニケーションの問題を最小化する

ために、スクラムチームのすべてのメンバーが参加すべきである。

Nexus スプリントゴールは、Nexus スプリントプランニングで策定する。それは、そのスプリントのなか

でスクラムチームが達成する目的の説明である。Nexusのすべての作業が理解できたら、スクラムチ

ームはそれぞれのスプリントプランニングを実施する。共通のスペースでミーティングを実施すれば、

チームは新しく発見した依存関係を共有することができる。Nexus スプリントプランニングは、それぞ

れのスクラムチームがスプリントプランニングを終了したときに完了する。

Nexus スプリントプランニングでは、新しい依存関係が明らかになることがある。それらは見える化し

て、最小化すべきである。また、複数のチームをまたがる作業の順番を調整することもある。プロダク

トバックログを十分にリファインメントしておけば、スプリントプランニングで新しく依存関係が見つかる

ことは少ないだろう。スプリントで選択されたすべてのプロダクトバックログアイテムとそれらの依存関

係は、Nexus スプリントバックログで見える化するべきである。

スプリントプランニングが始まるまでに、プロダクトバックログを十分にリファインメントして、依存関係

を特定し、排除または最小化すべきである。

Nexusデイリースクラム

Nexusデイリースクラムは、それぞれのスクラム開発チームの適切な代表者が集まり、統合インクリメ

ントの現在の状態を検査し、統合の問題を特定し、チーム同士の依存関係を新たに発見するための

イベントである。

Nexusデイリースクラムでは、参加者は統合インクリメントの衝突に焦点をしぼり、以下のことを議論

すべきである。

• 昨日の作業はうまく統合されたか？うまく統合されていなければ、それはなぜか？

• 新たに特定された依存関係は何か？

• Nexusのチーム間で共有が必要な情報は何か？

Nexusデイリースクラムでは、現在の依存関係を見える化し、管理するためにNexus スプリントバック

ログを使用する。

Nexusデイリースクラムで特定された作業はスクラムチームが引き取り、それぞれのデイリースクラム

で計画する。

Nexusスプリントレビュー

Nexus スプリントレビューは、スプリントの最後に開かれ、そのスプリントで Nexusが構築した統合イン

クリメントに対するフィードバックを提供するものである。

Nexus スプリントレビューは、スクラムチームのスプリントレビューを置き換えるものである。なぜなら、

ステークホルダーから統合インクリメント全体に対するフィードバックを得ることが焦点になるからだ。

完了した作業のすべてを詳細に見せることは不可能かもしれない。ステークホルダーからのフィード

バックを最大化するには、それなりのテクニックが必要である。


Nexusスプリントレトロスペクティブ

Nexus スプリントレトロスペクティブは、Nexusが検査と適応に焦点をしぼる公式な機会である。それ

は、以下の 3 つのパートで構成される。

1. 最初のパートは、Nexusの適切な代表者たちが、1つ以上のチームに影響がある問題を特定

する機会である。この目的は、共通の問題をすべてのスクラムチームに明らかにすることである

。

2. 2 番目のパートは、スクラムチームが開催するそれぞれのスプリントレトロスペクティブである。こ

れはスクラムフレームワークで説明されているものである。議論のインプットとして、Nexus スプリ

ントレトロスペクティブの最初のパートで挙がった問題を利用できる。スクラムチームのスプリント

レトロスペクティブでは、これらの問題に取り組むアクションを生み出すべきである。

3. 最後の 3 番目のパートは、スクラムチームの適切な代表者が再び集まり、特定されたアクション

をどのように見える化して、追跡するかに合意する機会である。これにより、Nexus全体が状況

にあわせて適応できるようになる。

スケールには機能障害が伴うため、すべてのレトロスペクティブでは以下の議題を扱うべきである。

• 完成していないものはあるか？Nexusは技術負債を作り出していないか？

• 作成物（特にコード）は、頻繁に（できれば毎日）統合されているか？

• 未解決の依存関係が蓄積されない程度に、頻繁にソフトウェアがビルド・テスト・デプロイされて

いるか？

上記の問いに対して、必要ならば以下のことを議論する。

• なぜこのようなことが起きたのか？

• どのように技術負債を解消するのか？

• どのように再発防止するのか？

リファインメント

大規模の Nexusには、さまざまなレベルのリファインメントが存在する。プロダクトバックログアイテム

が十分に独立していれば、Nexusのスクラムチーム同士で必要以上のコンフリクトを生じさせることな

く、選択や作業が可能となる。

リファインメントのミーティングの回数・頻度・時間・出席者は、プロダクトバックログの本質的な依存関

係によって決まる。依存関係や複雑さが大きければ、依存関係を取り除くためにより多くのリファイン

メントが必要になる。プロダクトバックログアイテムは、非常に大きく曖昧な要求を分解するところから

、スクラムチームが 1 つのスプリントでデリバリーできる実行可能な作業になるところまで、さまざまな

レベルを通過する。

大規模のプロダクトバックログリファインメントには、2つの目的がある。ひとつは、どのスクラムチーム

がどのプロダクトバックログアイテムをデリバリーするかを予測することだ。もうひとつは、チーム間の


依存関係を特定することである。見える化することによって、チームは依存関係の監視と最小化が可

能になる。

チームをまたがるリファインメントの最初のパートでは、プロダクトバックログアイテムが十分に詳細に

なるまで時間をかけて分解すべきである。これは、どのチームがデリバリーするのか、今後のスプリン

トがどのような順番になるのかを理解するためだ。

リファインメントの 2番目のパートでは、依存関係に焦点をしぼるべきである。チームやスプリントを横

断して、依存関係を特定して、見える化すべきである。作業の順番や割り当てを見直し、チーム間の

依存関係を最小化するために、これらの情報が必要となる。

プロダクトバックログアイテムが準備完了となり、スプリントプランニングにおいて最小限の依存関係

でアイテムを選択できたとすれば、それはスプリントで十分なリファインメントのミーティングが行われ

ていたということである。

Nexusの作成物

作成物は、透明性や検査と適応に必要な機会を提供する作業および価値を示したものである。透

明性および検査と適応については、スクラムガイドに記述されている。

プロダクトバックログ

Nexus とそこに含まれるすべてのスクラムチームに対して、スプリントバックログはただ 1つだけ存在

する。プロダクトオーナーには、プロダクトバックログの内容・可用性・順番の最終的な責任がある。

大規模の場合、依存関係が検出され、最小化できるレベルまで、プロダクトバックログを理解しなけ

ればいけない。そのために、プロダクトバックログアイテムは「薄くスライスされた（thinly sliced）」機能

と呼ばれる粒度まで分解されることが多い。スクラムチームによって選択可能になったときに、プロダ

クトバックログアイテムは Nexus スプリントプランニングに向けて「準備完了（Ready）」になったと見な

される。このとき、他のスクラムチームに対する依存関係は排除または最小化され、そのスクラムチー

ムだけでプロダクトバックログアイテムを完成できなければいけない。

Nexusゴール

Nexus スプリントプランニングでは、スプリント全体に対するゴールを策定する。これを Nexusゴール

と呼ぶ。これは、Nexusに含まれるスクラムチームのすべての作業とスプリントゴールの総和である。

Nexus スプリントレビューでは、Nexusゴールを達成するために開発した機能のデモを行う。

Nexusスプリントバックログ

Nexus スプリントバックログは、スクラムチームのスプリントバックログにあるすべてのプロダクトバックロ

グアイテムをまとめたものである。これは、スプリントにおける依存関係や作業の流れを強調するため

に使用する。Nexus スプリントバックログは、少なくとも毎日（多くの場合、Nexusデイリースクラムで）

更新する。


統合インクリメント

統合インクリメントとは、Nexusにおいて完了した「統合された作業」すべての総和である。統合インク

リメントは、利用可能でリリース判断可能なものでなければいけない。つまり、「完成」の定義を満たし

ていなければいけない。統合インクリメントは、Nexus スプリントレビューで検査する。

作成物の透明性

構成要素であるスクラムと同様に、Nexusは透明性にもとづいている。Nexus統合チームはスクラム

チームや組織と一緒に、すべての作成物において透明性が確保され、インクリメントの統合状態が

幅広く理解されるように作業する。

Nexusの作成物の状態にもとづいた意思決定は、作成物の透明性のレベルによってその効果が決

まる。不完全あるいは部分的な情報では、意思決定も不正確で間違ったものになる。こうした意思決

定の影響は、Nexusの規模に応じて大きくなっていく。透明性が確保されていなければ、リスクが最

小化され、価値が最大化されるように、Nexusを効果的に導くことは不可能である。

ソフトウェアを開発するときには、技術的負債が許容不可能になる前に、依存関係を検出および解

消しなければいけない。許容不可能な技術的負債かどうかは、結合するときにはじめてわかる。ただ

し、すべての依存関係が解消されたかどうかは不明のままだ。このような場合、未解決の依存関係

はコードやテストベースに隠れており、ソフトウェア全体の価値を低下させていくのである。

「完成」の定義

Nexus統合チームは、「完成」の定義に実行責任を持つ。「完成」の定義は、スプリントで開発される

統合インクリメントに適用されるものである。Nexusのすべてのスクラムチームは、「完成」の定義を忠

実に守らなければいけない。インクリメントは、利用可能であり、プロダクトオーナーによってリリース

判断可能となったときに「完成」と見なされる。

プロダクトバックログアイテムは、その機能がプロダクトに追加され、インクリメントとうまく統合されたと

きに「完成」と見なされる。すべてのスクラムチームは、そのことを満たすようなインクリメントの開発と

統合の作業に対して、実行責任を持つ。

スクラムチームは、チームにおいて独自の「完成」の定義を適用することも可能だが、インクリメントの

「完成」の定義よりも緩い基準を適用してはいけない。

最後に

Nexusは無料であり、本ガイドで提供されるものである。スクラムフレームワークと同様に、Nexusの

役割・作成物・イベント・ルールは不変である。Nexusの一部だけを導入することも可能だが、それは

Nexusではない。

謝辞

Nexusおよび Scaled Professional Scrumは、Ken Schwaber、David Dame、Richard Hundhausen、

Patricia Kong、Rob Maher、Steve Porter、Christina Schwaber、Gunther Verheyenが共同で開発し

たものである。


翻訳

本ガイドは、上記の謝辞にある開発者たちによって提供された英語バージョンを日本語に翻訳した

ものである。日本語訳は、角征典（@kdmsnr、ワイクル株式会社）と守田憲司（@wsfjp）が担当した。

Documents

Nexus - Amazon S3...Nexusは、役割・イベント・作成物と、約3～9 のスクラムチームの作業をまとめる技法で構成されたフ レームワークである。複数のスクラムチームが、ゴールを達成する統合インクリメントを構築するため

Nexus - Amazon S3...Nexusは、役割・イベント・作成物と、約3～9 のスクラムチームの作業をまとめる技法で構成されたフレームワークである。複数のスクラムチームが、ゴールを達成する統合インクリメントを構築するため