スクラムをスケーリングする Nexus フレームワークの概要

翻訳記事

この記事は、Simon Flossmann さんの「Overview of the Nexus Framework for scaling Scrum」を翻訳したものです。翻訳は Simon さんの許諾をいただいています。誤訳、誤字脱字がありましたら、ご指摘ください。

はじめに
Nexus フレームワークの説明
Nexus はスクラムを拡張し、競争力を維持する
もっと詳しく知りたい方へ
関連記事
本記事の翻訳者:
1. 1. 認定トレーナー
  2. 認定試験合格

はじめに

スクラムをスケーリングする際には、コストや労力と、恩恵と優位性のバランスをとることになります。コストと労力は、チームを追加することで発生します。恩恵と優位性は、同じ時間でより多くの価値を提供することで得られます。

スクラムの実践者たちは、スクラムのスケーリングが単なる数学的な問題ではないことを知っているます。常識的に考えて、チームがひとつの取り組みに共同で取り組む場合、どうしても統合上の衝突が発生します。このような衝突は、相互依存性から生じるものです。依存関係を透明性によって解消するには、規律と労力が必要であることは、誰もがわかっています。この労力は、各スプリントの終わりに統合されたインクリメントを提供することができれば見通しが立ちます。デリバリーのみが組織にとって価値をもたらすからです。

継続的に依存関係を解消し、すべての作業を統合することは、限界的練習* です。それが Nexus の核心なのです。Nexus フレームワークは、複数のチームがそれぞれの作業を継続的にひとつのプロダクトに統合できるようにすること中核としています。

訳註: 限界的練習（deliberate practice）とは、「練習は長い時間をかければいいというものではなく、コンフォートゾーンを少し上回るものであり、トップの人たちはそれを続けている」ということ。

スクラムの実践者たちは、Nexus フレームワークがスクラムを必要最小限に拡張するものであるため、これを使うことになるでしょう。スクラムを Nexus で拡張することを選択した組織は、ユーザーに継続的に価値を提供することを確約します。新しい役割のためにメンバーをトレーニングしたり、新しいプロセスや作業方法を導入したり、新しいインフラを設定したり、外部コンサルタントの支援を待ったりするためにスプリントを無駄に費やすことはありません。

この記事では、すでにスクラムに精通している実践者向けに、Nexus フレームワークの概要を解説しています。

訳註: この記事では、Nexus の知識を前提にしています。無料で日本語版を入手できる『Nexus™ ガイド – Nexus を使用した大規模スクラムの公式ガイド』を読んだ上でご覧いただくことをお勧めします。

Nexus フレームワークの説明

フレームワークの段階を説明し、要素によってチーム間の依存関係をどのように特定し、解消することができるかを説明します。読者がスクラムフレームワークをよく知っていることを前提としています。ここではスクラムに追加される要素だけを強調しています。

まずは、左側のプロダクトバックログから見ていきます。

注意: 上図のアイコンは、人を表すものではなく、責任を表すものです。それぞれの Nexus には、一人のプロダクトオーナーしかいません。

ひとつのプロダクトに取り組むには、ひとつのプロダクトバックログが必要です。これはスクラムチームが実施する作業の唯一の情報源です。この作業を透明にするために、リファインメントは、スクラムの有用なプラクティスです。しかしながら、拡張したしたスクラムでは、クロスチームリファインメントが必須となります。

① クロスチームリファインメントでプロダクトバックログを透明化する

クロスチームリファインメントでは、プロダクトバックログを分解していきます。この作業は、どのチームがどの作業を引き受けるのか、アイテム間に依存関係があるのかどうかが明確になるまで行われます。このレベルの透明性は、依存関係を事前に解消するために必要となります。次のスプリントで、どのチームがどのプロダクトバックログアイテム（PBI）に取り組む可能性が高いかを予測しておきます。クロスチームリファインメントは、次のスプリントのプランニングを簡素化することができます。

クロスチームリファインメントには、それぞれのスクラムチームの代表者が参加します。この代表者は、役割に基づいて選ばれるのではなく、洗練させるべき作業に基づいて状況に応じて選出します。クロスチームリファインメントのために代表者が集まる頻度は、プロダクトバックログ内における不確実性によって決まってきます。リファインメントは、継続的なプロセスであるため、タイムボックスは規定されていません。通常、スクラムチームたちは、Nexus スプリントプランニングイベントで PBI を選択できるようにするために、チーム内でリファインメントを続けることになります。

② Nexus スプリントプランニングでスプリントでの活動を調整する

Nexus スプリントプランニングが、スプリントの口火を切ります。このイベントでは、このスプリントに必要な作業とすべての活動が調整されることになります。Nexus スプリントプランニングには、Nexus の全メンバーが参加するのが理想的です。

このイベントは、スクラムチームの代表者とプロダクトオーナーが、洗練されたプロダクトバックログを検査し、スプリントゴールを設定することから始まります。

③ Nexus スプリントゴールでチーム全体の集中を高める

スプリントゴールは、そのスプリント内ですべてのチームに包括的なゴールを提供します。これは、Nexus の一貫性と焦点を生み出すのに役に立ちます。また、スクラムチームが別々の取り組みをするのではなく、共に作業することを促してくれます。

プロダクトオーナーは、スプリントの目的を定義するために、Nexus スプリントゴールを用います。スクラムチームは、一緒に完成すれば Nexus スプリントゴールを実現できる、優先順位の高い PBI を選択するようにします。継続的なリファインメントのプロセスによって、選択した PBI の依存関係が特定でき、ほぼ解消されているはずです。

PBI の最初の選択後、それぞれのスクラムチームはそれぞれのスプリントプランニングを進めていきます。

Nexus スプリントプランニングは、それぞれのスクラムチームのスプリントプランニングのための入れ物の役割を果たしています。このプランニングは、Nexus スプリントゴールを達成するための大まかな計画と、スプリントの初期の数日間の詳細な計画が作成された時点で完了とします。この包括的な計画は、Nexus スプリントバックログに集められます。

④ Nexus スプリントバックログで依存関係をリアルタイムに映し出す

Nexus スプリントバックログは、開発者が Nexus スプリントゴールを達成するために必要だと考えている PBI で構成されています。この新しい作成物は、すべてのチームの予測作業とチーム間のすべての依存関係を可視化してくれています。

Nexus スプリントバックログは、チームの境界線を超えて作業を調整するのに役に立ちます。例えば、スクラムチーム(A)がある PBI を完成させるためにスクラムチーム(B)に依存していたとして、スクラムチーム(A)がその PBI を完成させる上で進捗できない場合、このことが Nexus スプリントバックログに可視化されるのです。

Nexus スプリントバックログにより、チームはスプリント中にチームを超えた協働を行うことができます。スクラムチームのスプリントバックログを集約したものを見ることができるのです。これにより、Nexus が、スプリント中の依存関係の説明責任を果たすのに役に立ちます。Nexus スプリントバックログは、スプリント中のワークフローをリアルタイムに映し出していて、毎日更新する必要があります。この更新は、Nexus デイリースクラムで行われるべきです。

⑤ Nexus デイリースクラムで統合上の問題を可視化する

それぞれのチームの開発者と Nexus 統合チームは、（それぞれのチームの）デイリースクラムの前に集まり、Nexus スプリントゴールに対する進捗状況を確認します。彼らは、統合したインクリメント（これまでに Nexus で一緒に完成させた作業）の現状について、浮上した統合上の問題や新たな依存関係を明らかにすることによって、確認していきます。

代表者たちは、この情報をそれぞれのチームのデイリースクラムのインプットとして用います。この中での Nexus 統合チームの役割は、それぞれのチームが統合や依存関係の問題と、チームレベルでの行動の必要性を特定できるようにすることです。

もちろん、クロスチームのコミュニケーションが行われるのはこのときだけではありません。Nexus デイリースクラムは、Nexus スプリントバックログを更新するための最小限な機会であり、そのための時間を共有するものです。

⑥ 統合インクリメントで経験主義に求められる透明性を生み出す

PBI は、プロダクトとして完全に統合された場合にのみ完成の定義を満たします。その場合にのみ、プロダクトの新しいインクリメントが生み出されるわけです。プロダクトを統合することで、経験主義を後押しする必要な透明性が生まれます。遅くともスプリントの終わりまでには、使用可能なインクリメントを作成しなければなりません。理想的には、統合とデリバリーがより頻繁に行わるようにします。

作業の統合は、行うべき他の作業よりも優先されるべきです。統合の問題がある場合は、他の PBI を実装してプロダクトに統合する前に、まずはその問題を解決しなければなりません。

⑦ Nexus スプリントレビューで統合インクリメントを検査する

Nexus スプリントレビューは、スクラムチームのスプリントレビューに代わって、スプリントのアウトカム（成果）を全体的に把握するためのものです。その目的は、インクリメントに対するステークホルダーからのフィードバックを得ることと、プロダクトの改善点を特定することです。

これは大きな規模のイベントとなる可能性があるため、ハイレベルな結果に焦点を当てる必要があります。詳細なアウトプットを検査する必要がある場合、プロダクトオーナーとステークホルダーは、スプリント中にいつでもプロダクトの特定の部分をレビューすることができるのです。スクラムと同様に Nexus スプリントレビューの結果は、プロダクトバックログを適応させるためのインプットとなります。

Nexus スプリントレビューは、スプリントの終盤に行われます。その後、スクラムチームは、スプリントレトロスペクティブを行うための十分な情報を得ているはずです。

⑧ Nexus スプリントレトロスペクティブで Nexus 全体の改善を可能にする

Nexus スプリントレトロスペクティブを実施する方法は数多くあります。ここでは一つの一般的な方法を示します。

スクラムチームのレトロスペクティブへのインプットとして、代表者は複数のチームに影響する問題を特定します。フォローアップとして、それぞれのチームは、それぞれのチー自身のためのスプリントレトロスペクティブを実施します。

クロスチームの問題は、Nezus スプリントレトロスペクティブの基礎となります。チームのレトロスペクティブの後、改善を可視化kするためにそれぞれのチームの代表者たちが再び集まります。これにより、チームがスプリント中にその実施に対する責任を持ち続けることができます。

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 コースで取り上げれている数多くの興味深いトピックの一つです。Scaled Professional Scrum コースに参加したい方は、私のクラススケジュールページで詳細を確認してください。