Nexusは，大規模なソフトウェア開発プロジェクトを展開，維持するためのフレームワークである。Nexus Guideは，スクラムをスケールアップする上でScrum Guideの次段階として，複数のソフトウェア開発チームを統合した活動のサポートとして使用することができる。
InfoQは今年初め，Scaled Professional ScrumとNexus Frameworkに関して，Gunther Verheyen氏にQ&A形式のインタビューを行っている。そのGunther Verheyen氏がAgile Greece Summit 2015で，Scaled Professional Scrumフレームワークについて講演する。カンファレンスの様子はInfoQでもお伝えする予定だ。
InfoQはNexus Guideの著者で，アジャイル宣言(Agile Manifesto)の原作者で署名者のひとりでもあるKen Schwaber氏にインタビューし，Nexusフレームワークとガイドについて，Nexusがスクラムに与えるもの，Nexus統合チームについて，スクラムのスクラム(Scrum of Scrums)とNexusのデイリースクラムについて，チームのレトロスペクティブと改善活動を整合させるには，Nexusと他のスケールアップアプローチとの関係，といった内容で話を聞いた。
InfoQ: Nexus Guideについて簡単に説明して頂けますか？ このガイドを公開しようと考えた理由は何だったのでしょう？
Schwaber: Nexus Guideはすべての面において，Scrum Guideと同種のものです。オンラインで誰でも無償で利用できる，クリップオン形式のスケーリングフレームワークで，３ないし９のスクラムチーム(通常)をひとつのソフトウェア開発活動に統合するためのものです。
InfoQ: プラクティスや戦術の適用が目的ではなく，基本的なルールを提供するものであるという意味から，スクラムはフレームワークである，と言われています。ですがNexusは，40以上のプラクティスを 提供すると発表しています。それもまだ，スクラムと同じ意味でのフレームワークなのでしょうか？
Schwaber: Nexusのプラクティスやそれを自動化するためのツールは，大規模なスクラム開発プロジェクトを運用する上で何が必要なのかを表したものです。確かにNexusのワークショップでは，大規模ソフトウェア開発を特徴付けるものとして，プラクティスやツールを使用しています。もっとも，スケールアップの過程で使用するプラクティスやツールは，これらだけに限りません。例えば，プロダクトバックログに属性を追加するプラクティスといったものもあります。要件定義に自動化ツールを導入しているような組織であれば，すでにこのようなニーズには答を用意していて，他の手段を採用していると思います。
InfoQ: スクラムと比較した場合，Nexusには他に，どのような役割やイベントが追加されているのでしょう？
Schwaber: Nexus統合チーム，プロダクトバックログの洗練，Nexusスプリント計画，Nexusスプリント目標，Nexusデイリースクラム，Nexusスプリントレビュー，Nexusスプリントレトロスペクティブ。これらはすべて，同じような名前のスクラムの機構を覆ってカプセル化したものです。
InfoQ: このような追加をしたというのは，スクラムだけでは不十分ということではないのでしょうか？
Schwaber: スクラムが不十分というのは，何に対してなのでしょう？自動運転車の開発でしょうか，次期スペースシャトルの開発ですか？(皮肉)
スクラムはひとつのイテレーション，ひとつのインクリメント，ひとつのソフトウェア開発活動を表現した，極めてシンプルなフレームワークです。使い方がそれぞれ違うことは分かっていますので，ここでは敢えて，それ以上の説明はしません。もっと複雑な利用方法については，ユーザにお任せします。事実，本当に多くの企業や組織が，自分自身のプロセスや標準，フレームワークといったものを作り上げています。それらを使って，さまざまな開発上の課題にスクラムを適用しているのです。
そうだったのですが，SAFeやDaDのような企業の方法論が現れたことで，Nexusを開発しよう思い立ちました。従来型の大企業では，こういった方法論を大枚はたいて購入して実践しています。これらが万能策(銀の弾丸)であり，お金を払うことでソリューションの有効性が保証されると思っているのです。残念なことにこれらの方法論は，ユーザに対して唯一つのスクラム開発プロセスを押し付けます。このような大企業に，自分たちのリリーストレイン(であれ何であれ)で，ソフトウェア開発を行うにはどうすればよいかを知ってもらうために，私たちはNexusを開発しました。
InfoQ: Nexus Guideには，“中心的な責任が満足できれば，Nexus統合チームのメンバは開発チームのメンバとして，ひとつないし複数のスクラムチームで作業してもよい”とあります。アジャイルチームのメンバは，ひとつのチームだけでフルタイムで作業するのが普通ですが，Nexusがこれと違うのはなぜでしょう？
Schwaber: フルタイムのチームでフルタイムに作業した方が，より生産的であることは分かっています。ですが，私たちはここで常識を適用します。改善や統合といったスケールアップ要件に関して，スクラムチームのスキルが非常に高ければ，Nexus統合チームのメンバが周りで忙しそうにする必要は何もありません。彼らが生産性を発揮すればよいだけのことです。
InfoQ: 複数チームの参加する製品プロジェクトでは，活動の方向性や進捗を合わせるために“スクラムのスクラム”を用いる場合がありますが，Nexus Guideでは言及されていません。これは意図したものですか？
Schwaber: スクラムのスクラムについては，これまで著書の中で何度か取り上げたことがありますが，Scrum Guideではスクラムの仕組みとして認めていません。スクラムのスクラムはNexus GuideのNexusデイリースクラムで初めて，公式に取り上げられています。
InfoQ: Nexusでは，チーム間のレトロスペクティブや改善活動の整合をどのようにサポートしているのか，詳しい説明をお願いできますか？
Schwaber: サンドイッチするのです。 最初にスクラムチームが集まって簡単なレトロスペクティブを行い，自分たちが作業の統合と拡大を行った時に生じた問題点を確認します。その次には，スクラムチームのメンバとNexus統合チームで本格的なレトロスペクティブを実行します。ここでの目標は，スケールアップに向けた活動をより生産的かつ効果的にする上で，次のスプリントの目標がどのように変わるのかを明確にすることです。そして第３には，スクラムチームのメンバが自身のチームのレトロスペクティブに戻ってこの情報を伝え，レトロスペクティブを完成させるのです。
InfoQ: 既にNexusを適用した組織はあるのでしょうか？事例などがあれば教えてください。
Schwaber: はい，世界中にあります。情報を収集し編集していますので，用意ができ次第，事例とケーススタディとして私たちのWebサイトやwww.scrum.orgで公開する予定です。玉石混交の事例集になると思います。
InfoQ: 過去数年間にローンチされた他のスケーリングアプローチ(SAFe, DAD, LeSS)とNexusの関連について，説明して頂けますか？
Schwaber: スコープ，アプローチ，コスト，どの面でも違います。
Nexusはプロダクトバックログから始まって，予算や目標，スコープなど，ソフトウェア開発のスケールアップに特化しています。
同時にNexusは，ソフトウェア開発に対して，組織がユニークなアプローチを運用するためのフレームワークに過ぎません。定式ではありませんし，成功を保証するものでもないのです。ソフトウェア開発に携わる人たちは，望める限り最高の方法で成功を収めるべく，自身の活動を行っています。大切なのはプロセスやツールより，個人であり，相互関係なのです。
それから，Nexusはフリーで，Nexus Guideとしてオンラインで参照できます。
InfoQ: Nexusについてもっと詳しく知りたい読者は，どこへ行けばいいのでしょう？
Schwaber: www.scrum.orgですね。フロントバナーにあります。