Nexusとは
Nexusはスクラムを開発したKen Schwaberが2015年に発表した大規模スクラム開発の手法である。言うまでもなく、スクラムはXPと並んで最も有名なアジャイル開発手法である（→Nexusの公式サイトへ）。
Nexusはスクラムを大規模開発向けに拡張しているので、Nexusを知るためにはスクラムを知る必要がある。スクラムは3〜10人程度のスクラムチームがイテレーション開発を運営するためのロール、成果物、イベント（やること）で構成されている。スクラムは単独のスクラムチームの運営を想定している。Nexusはスクラムを複数チームが連携しながらイテレーション開発を行えるように拡張している。
筆者がアジャイルコーチとして顧客を訪問するとよく聞かれることは、「アジャイル開発は１チームだけなのか。複数チームではどうするのか」ということである。スクラムでは1チームは多くても10人程度が目安である。同時に20人や30人といった規模のシステム開発にはアジャイル開発を適用できないのだろうか。基幹システムや業務システムのようなエンタープライズシステムでは、それくらいの規模の開発は珍しくない。筆者もNexusが登場するまでは手探りでスクラムを独自解釈で拡張していた。Nexusの登場によってガイドラインに沿った大規模アジャイル開発が行えるようになる。
なぜ、スクラム？
システム開発の成功の秘訣を突き詰めれば、小さい単位に分割して開発することと言えるだろう。小さな単位であれば人間が全体を見渡すこともできる。1000画面をまとめて開発するよりも、100画面に分割した方が仕様の整合性を確認できる。自ずと品質も上がる。
また殆どの場合、要求を最初に確定させることは不可能であり、仕様変更は受け入れざるを得ない。要件定義で仕様を細部に至るまでドキュメントに記述することは難しい。その上、仮に仕様の詳細までドキュメントに書けたとしても、読み手である顧客が正確に読み取ってくれるとは限らない。さらに、開発の途中にビジネスが変化して仕様が変更されることもある。要件定義で仕様を確定させられることを前提にすることが間違っている。
スクラムはプロジェクト運営の最適化とリスク軽減のためにイテレーション開発を採用している。小さい単位で開発を繰り返して、出来上がった成果物やシステムをステークホルダーに都度確認してもらう。フィードバックを得たら計画に反映する。
スクラムを支える3つの理念
スクラムを支える３つの理念は透明性、検査、適応である。
透明性とは全てのステークホルダーに情報を開示して、同じ認識を得ることである。プロジェクトの課題やリスクをスクラムチームだけで抱え込むのではなく、ステークホルダーに共有して、プロジェクト成功のために協力を仰ぐ。
検査は出来上がった成果物やシステムをテストやレビューするということである。品質を都度確認する。ウォーターフォールのように最後にまとめて確認するよりも品質を担保しやすい。
適応は、検査した結果などのフィードバックから自己改善して、次のイテレーションの計画に反映するということである。ウォーターフォールであれば最初に計画しておしまいだが、スクラムでは自己改善を継続しながら計画を状況に適応させていく。
スクラムへの誤解
アジャイル開発では高い品質が要求されるシステムは開発できないという誤解がある。ましてや、エンタープライズシステムをアジャイル開発で構築するなど以ての外という意見もある。アジャイル開発ではドキュメントを書かない、設計をしないといった間違ったイメージが先行しているからである。
実際にスクラムガイド（→こちら）を読めば分かるが、スクラムガイドには要求のまとめ方や、設計のやり方、品質の担保については書かれていない。それらは対象となるシステムのサービスレベルに応じてプロジェクトで選択すべきものだからである。
アジャイル開発はドキュメントを書かないといったイメージは2000年ごろにXPが日本に紹介されたときの古いものだろう。ただし、スクラムガイドにはそのようなことは書かれていない。アジャイル開発といってもXPとスクラムでは大きく異る。XPはペアプログラミングのような開発に関するプラクティスまで定めているが、スクラムでは開発の仕方は全く決めていない。アジャイルソフトウェア宣言はXPのKent BeckもスクラムのKen SchwaberやJeff Sutherlandも署名していることからごった煮の感がある。アジャイルを語るのであれば具体的にXPなのかスクラムなのか他の何かなのかを明確にしないと議論にならない。アジャイル開発の是非をブログなどで議論している人をよく見かけるが、得てして具体的な手法を明確にせずに議論している。アジャイル開発をよく調べずに議論しているものと思われる。
Nexusの特徴
Nexusの特徴は大規模開発で複数チームが連携するために、チーム間を取り持つNexus統合チームを編成することである。Nexus統合チームの役割は次のものである。
チーム全体を鑑み、チーム全体が最適に動ける環境や状態を作り上げる。
各スクラムチームから発生する共通の課題を解決することをけん引する。
チーム全体を最適に活動できるような仕組みを作る。
必要に応じて、他のスクラムチームと同様の活動を行う。
Nexus統合チームはプロダクトオーナー、スクラムマスター、メンバーで構成される。
プロダクトオーナー
唯一のプロダクトバックログに対し、最終決定権を持つ。各チームにより作り出されたプロダクトを確認し、「完成」を宣言する。状況によっては、各スクラムチームのプロダクトオーナーと兼務をする。
スクラムマスター
Nexusフレームワークをチーム全体で理解し、実施することに責任を持つ。状況によっては、各スクラムチームのスクラムマスターを兼務する。筆者の経験ではスクラムチームが5チーム以下なら兼務できるだろう。
メンバー
プロジェクト全体で利用する共通部品やツールを準備する。準備した共通部品やツールが、各スクラムチームで確実に理解され、正しく利用されるように活動する。共通のアーキテクチャを構築し、各チームで作成された作成物を統合や共通化する。
Nexusの流れ
Nexusはスクラムと同様の流れで進める。Nexus統合チームと複数のスクラムチームが連携するためのプラクティスは後程述べる。
※出典： NexusGuide-v1.1 「大規模スクラムの外骨格となるNexusTMフレームワーク」より
Nexusのプラクティス
以下、大規模開発向けに拡張されたNexusのプラクティスを説明する。
プロダクトバックログの作成と最適化、Nexusゴールの設定
Nexusにおいてプロダクトバックログは、Nexus統合チームが管理するものが唯一である。複数あるスクラムチームはプロダクトバックログを作成しない。Nexus統合チームがリファインして、各スクラムチームとの合議により最適化、優先度付けが行われる。このプロダクトバックログに載っている作業は、各スクラムチームに割り付けられる。
Nexus統合チームによってプロダクトバックログが十分に機能して、日々最適化がされていれば、それぞれのスクラムチームの衝突や無駄を生じさせることなく作業を進めていくことができるようになる。
Nexusスプリントプランニング
Nexus統合チームと各スクラムチームから代表者が集まり、プロダクトバックログの最新化を行い、各スクラムチームに作業の割り当てを行う。各スクラムチームが作業するバックログが割り当たったら、スクラムチーム毎にスプリントの計画を立て、スクラムチームのスプリントバックログを作成する。
Nexusスプリントバックログ
Nexusではスプリントバックログを、Nexusスプリントバックログと呼ぶ。異なるのはバックログで他のチームに依存する内容があったときに、依存内容を明記して、他のチームに共有することである。
ただし、筆者の経験からはこれは非常に複雑なオペレーションを生み出す。基本的にはバックログは依存しないようにすべきであり、どうしても依存する場合は同じチームに割り当てるべきである。それも難しいようならNexus統合チームが仲介すべきである。筆者はNexusスプリントバックログではなく、通常のスプリントバックログの使用を推奨する。
Nexusデイリースクラム
Nexus統合チームと各スクラムチームの代表者が集まり、日々の課題や調整事項について確認する。ここで確認された内容は、各スクラムチームのデイリースクラムによって、メンバーに共有する。
Nexusスプリントレビュー
各スクラムチームが開発したシステムを結合して、プロダクトオーナーがレビューする。Nexus統合チームと各スクラムチーム全員が集まる必要があるため、定期的に場所や時間を決めて集まれるようにすべきである。
Nexusスプリントレトロスペクティブ
各スクラムチームで行われたスプリントレトロスペクティブの結果から、全体に関わるものを各スクラムチームでまとめて、全体に共有する。問題の原因分析から解決方法の検討を行う。Nexusスプリントレトロスペクティブは、次の３つのパートで構成される。
- 1stパート 代表者が1つ以上のチームに影響する問題を特定し、全体の問題として共有する。
- 2ndパート 各チームが開催するスプリントレトロスペクティブにおいて、1stパートで上がった問題に対するアクションを検討する。
- 3rdパート 再びチームの代表者が集まり、2ndパートで検討されたアクションについて、どのように見える化して追跡するか、を合意する。
最後に
Nexusは複数のスクラムチームをオーケストレーションするために、指揮者たるNexus統合チームを編成するものである。しかし、Nexus統合チームの負担が過度になればボトルネックになり、プロジェクト全体が失敗することになる。基本方針は各スクラムチームが独立して活動出来るようにすることである。
Nexus統合チームはプロダクトバックログだけでなく、アーキテクチャや共通ライブラリの保守管理、データモデルの作成保守、外部連携仕様の整理などプロジェクト全体に関わる活動全般を行う必要がある。
言うまでもなく、Nexusの採用時には、十分に経験を持ったスクラムマスターと、参画しているメンバー全員のNexusに対する理解を深めておく必要がある。