GOTO Berlin 2015カンファレンスで，Stefan Roock氏が，設計図(blueprint)を使わないアジャイルのスケーリングという話題の講演を行った。InfoQでは，スクラムとXPの併用について氏にインタビューし，アジャイルフレームワークを組織設計の計画図として使用することが時期尚早な最適化であり，アジャイルスケーリングにおいてプラクティスよりも文化が原則が重要であるという，氏の意見について詳しく聞いた。インタビューの中で氏は，アジャイルスケーリングサイクル(Agile Scaling Cycle)について，その利用の方法を例をあげて説明するとともに，アジャイルのスケーリング手段として用いた場合のメリットと落とし穴について話してくれた。
InfoQ: 講演では，mobile.deでスクラムとXPを併用した経験を話されていましたが，XPを併用することによるメリットはどのようなものでしたか？
Roock: mobile.deでは当初，月１回のリリースを行っていました。スクラム導入前の作業方法ならばそれで十分だったのですが，10以上のスクラムチームが並列作業する状況では，リリースの頻度がボトルネックになったのです。この頃のリリースは，マージスロット — 開発成果をリリース候補にマージするためにチーム毎に事前定義された時間 — を編成することで管理されていました。
どのチームもできるだけ多くの機能を月次リリースにのせようとするため，最後の方のマージスロットは奪い合いになっていました。当然ながらマージでは予期していなかった問題も起きるので，マージ時間がスロットを超過することもありました。そのような場合にどうするべきか，私たちは何度も議論しました。
- 問題を引き起こしたチームをリリースから外して，以降のマージスロット計画が正しく進むようにするべきか。
- マージスロットの時間延長を容認するべきか。その場合，すべてのチームのマージが完了するまでリリースを延期するか，あるいは最後の方のマージスロットをリリースから外すのか。
このような問題の管理を担当するために，リリースマネージャが置かれていました。
スクラムを導入して間もなく，私たちは，継続的インテグレーションと自動テスト(ユニットテストとUIテスト)に注目することで，品質を向上し，オーバーヘッド削減を実現することができました。ブランチの数を減らすことによって，マージの労力を大きく低減することができたのです。マージ地獄が解消し，リリースマネージャの役割も不要になりました。
これと並行して，TDD，ATDD, ペアプログラミングなどの利用も開始しました。
現在mobile.deでは，必要ならば１日に複数回リリースすることも可能になっています。この間の経験については，開発者たちがebay開発ブログで文書にしています。
InfoQ: 講演では，アジャイルフレームワークを組織設計の計画図として使用することに対して，時期尚早な最適化策であると話されていましたが，これについて説明して頂けますか？
Roock: 私の経験では，設計図とフレームワークには，大きな意味でも小さな意味でも違いがあります。スクラムは設計図のようなものであり，そのように使うことも可能です。アジャイルとは何なのか，意味を知る上で最初のステップとなると同時に，ガイドラインの役割も果たします。
アジャイルの思想が習得できれば，次に考えるのは，自分たち独自のスケールアップアプローチでしょう。これはプラクティスの中で見つけ出したアイデアを検討し，組織構造として採用することの繰り返しになります。
この構造を事前に定義しようというのがスケーリングの設計図です。しかし何のために？成熟したアジャイルチームに設計図は必要ありません。不必要に制約されることになります。アジャイル初心者ならば，そもそもスケーリングに着手するべきではありません。走る前にまず，歩くことを学ぶべきです。
InfoQ: 背景となる原則を理解せずにプラクティスを実践している，という例を紹介して頂けますか？
Roock: 私の実施しているプロダクトオーナトレーニングの中に，数年のアジャイル経験を持っている，という参加者がいました。私たちがプロダクトバックログについて話しているとき，彼から利用するツールについて質問がありました。Excelを使用しているが，行数の制限を越えたので他の手段を考えなくてはならない，と言うのです。その会社が実際には非アジャイルなことを行っていて，それにスクラムと名付けているだけだということが，これで明らかになりました。彼は社内で”スクラム”を学んで，自分がスクラムを経験していると思っていたのです。
もうひとつ多い例がスプリントレビューです。トレーニング参加者の80%がスプリントレビューを承認会議，つまり計画が実施されたことの確認の場として使っています。スプリントの投資収益(ROI)を議論し，製品改善のフィードバックを収集する場としてスプリントレビューを使っている企業は，ごく少数に過ぎません。
私がスクラム実践の評価のために呼ばれていた時，そこでの日次スクラムはほとんど毎回，退屈な状況報告でした。エネルギの高いチームを構築し，計画することを目的としたイベントではなかったのです。
InfoQ: アジャイルをスケールアップする上で，なぜ文化や原則を考慮することがプラクティスよりも重要なのか，詳しく説明して頂けますか？
Roock: アジャイルアプローチはどれも，いくつかのルールや役割，ミーティングなどがあるだけで，極めてライトウェイトです。さまざまな状況に適応可能であることで，改善の余地も残していますが，誤りを犯す余地もあるのです。
アジャイルの文化や原則を採用せず，既存のフレームワークでプラクティスを解釈することは，この誤りにつながります。プロダクトバックログを要求仕様書の変形のように見たり，スプリントレビューを承認会議と考えたりするのはその例です。デイリースクラムは状況報告に，スクラムマスタはプロジェクトマネージャに，プロダクトオーナはステークホルダから要件を引き出す役人のような役割になります。
このような誤りを見つけるために，アジャイルの原則が役立つのです。
“プロダクトバックログ”をフィックスするという言い方は，“仕様変更は開発後半でも歓迎する”というアジャイルの原則とは相容れません。
“最高のアーキテクチャ，要件，設計は，自己組織型チームによって生み出される”という原則は，ステークホルダから要件を聞き出すだけ，というやり方が間違いであることを教えてくれます。
スケールアップには，アジャイル宣言(agile manifesto)をどのように適用すればよいのか，必ずしも明確でないような側面がいくつかあります。そのため，私を含む何人かのコーチは，スケーリングのための原則を設定しています(http://scaledprinciples.orgをご覧ください)。新たに作り出したのではなく，既存の原則をスケーリングの視点から集めたものです。
InfoQ: アジャイルのスケーリングサイクルのステップについて説明して頂けますか？これらのステップが，このような順番である目的は何でしょう？
Roock: アジャイルスケーリングサイクル(Agile Scaling Cycle)は，３つのステップからなる単純なサイクルモデルです。最初のステップでは，チーム間の依存関係の低減を行います。アジャイルでは自律的なチームが望ましいのです。その上で，残りの依存関係には十分な注意を払うことが必要です。 開発中には，チームのスクラムマスタには解決できないような(企業レベルの再編成が必要になるような)組織の機能不全が顕在化する場合もあるでしょう。その場合のスクラムマスタは，現在の状況下での回避策を見出さなくてはなりません。原因となった組織的機能不全については，ステップ３の組織開発で対処することになります。
このモデルは，私がPeter Beckと一緒に行ったアジャイルスケーリングのトレーニングがきっかけで生まれました。私たちは参加者に対して，知っているアジャイルスケーリングのプラクティスをポストイットに書くように言ったのです。彼らが書いているのを見ていると，たくさんの答が出されそうだったので，プラクティスを整理する構造が必要だと思いました。そこで３つの集合に分けることにしました — 依存性の削減，チームの調整，組織開発の３つです。これらの集合が便利そうだったので，プレゼンテーションでも使用しました。“アジャイルスケーリングサイクル”という名前を思い付いたのは，その少し後です。
すべてのモデルがそうであるように，アジャイルスケーリングモデルにも間違いがあります。一方で，便利な面もあります。スケーリングプラクティスのグループ分けには便利ですし，２つの重要な点に注目させてくれる点でも有用です。
- 自律したチームが重要であること。
- 検討と適用による組織改善が不可欠であること。
アジャイルスケーリングサイクルで間違っているのは，その順序です。実際は３つのステップが並行して行われるのです。ステップ２(チームの調整)に何ヶ月も費やした後で，その成果を捨てて，ステップ３で組織的な機能不全を伴う組織大改造を行うようなまねはしないでしょう。
InfoQ: 企業がこのアジャイルスケーリングサイクルを利用するにはどうすればよいのか，例をあげて頂けますか？
Roock: 私たちはよく，複数のチームへのアジャイル適用を“修復”するように求められます。ユーザが口にする問題のナンバーワンは，計画とチーム間の調整についてです。要するに彼らは，計画とコーディネーションのもっと強力なプラクティスが欲しいのです。
アジャイルスケーリングサイクルのステップ１である依存性の低減は，このような状況で開始されます。真にクロスファンクショナルなチームを作り上げることができれば，この問題はほぼすべてのケースで解決されることになります。
もうひとつは，アジャイルスケーリングサイクルのステップ３に関するものです。継続的改善のプロセスが必要なのはチームレベルに限った話ではない，ということを企業は認識しなくてはなりません。私たちはコーチングを通じて，これを理解してもらおうとしているのです。
InfoQ: アジャイルスケーリングサイクルのメリットと，陥りやすい失敗はどのようなものでしょう？
Roock: メリットのひとつは，最初から完璧な構造である必要のないことです。LeSS(Large Scale Scrum)はとてもよいと思いますが，最初から完全に導入するのは難しいかも知れません。アジャイルスケーリングサイクルでは，まず最初に依存性を徹底的に低減し，残った依存性の下で作業をする，としています。問題のある依存関係が目に見えるようになり，対処が可能になります。
落とし穴のひとつは，アジャイルスケーリングサイクルをシーケンシャルなプロセスであると誤解して，組織的な機能障害の除去を後回しにする可能性があることです。依存性削減とチーム調整を行うプラクティスを選択する上で，経験が必要だという点も落とし穴でしょう。そしてもちろん，可能ならばスケーリングプラクティスを使用したいと思っている人はたくさんいるでしょう — 間違いありません。そのために“Stefan式アジャイルスケーリング成熟度モデル”というものを作って，(もはや)必要のない調整プラクティスを挙げました。少ない方がよいですからね。