スイス郵政はレガシーシステムのリプレイスのため、７つのチームでスケールド・スクラムを利用した。Ralph Jocham氏はアジャイルギリシャサミット2015に登壇し、10ヶ月、７チーム、18個のアプリケーション ＝@スイス郵政におけるスケールド・スクラムというタイトルでスケールド・スクラムの経験について語った。
InfoQはRalph Jocham氏にインタビューを行い、完了の定義を使ってどのようにスクラムをスケールしてレガシーな問題に対応したか、どうやって計画より３ヶ月前倒しでシステムを納品できるようにしたか、そしてプロジェクトで主に学んだことを伺った。
InfoQ: 複数のチームで取り組むのにどうスクラムをスケールしたのか教えていただけますか？
Jocham氏: スケールド・スクラムは核心のところでなおスクラムであり、経験主義と自己組織に基づいているべきものです。スケールとは依存関係の管理が全てで、正しい情報が正しい時に正しいところにあるということを確認するために行います。そのため、さまざまなチーム間で条件を追加してスクラムをスケールする必要があります。最低限、アーキテクチャ、横断的な機能、そして品質に関する懸念には対処しておかなければなりません。１番大事なのは、スプリント中いつどんなときでもインクリメントをリリース可能な状態にしておくということです ＝@そうして初めてやり残しなく"Done"となるのです。これを可能にするには継続的デリバリを目指して取り組む必要があります。継続的インテグレーションではうまくいかないのです。
Scrum.orgで私たちはNEXUSフレームワーク（プロフェッショナルなスケールド・スクラムとNEXUSを参照）を開発しました。 先述のポイントをしっかり押さえているものです。スケールに唯一の答えなどありません。多くのスケーリング・アプローチがそうであるように、方法の罠に陥ってはいけません。スケールにおいても経験主義であり、自己組織に基づいているべきです。正しいアプローチを生み出していきましょう。
InfoQ: スクラムはレガシープロダクトをリプレイスするために利用したとのことですが、チームにとって新たな課題は生じましたか？
Jocham氏: 既存のシステムは本当に老朽化していました。ソフトウェアはWindowsCEアプリケーションで、ハードウェアのサポートは終了していました。システムは機能していましたが、リプレイスしなければなりませんでした。
新たな課題が起こったか？そうですね、新しいプロダクトが要求された全ての機能性をカバーしていること、22000を超える現ユーザ基盤に適切に吸収されることを確実にしなければなりませんでした。何年も掛かって、奇抜さは特長になりました。だから私たちはユーザビリティに注意しなければなりませんでした。しかしながら、私たちはエンドユーザと関わり、かなり早い段階から彼らに意見を求めていたため、それ自体は課題ではありませんでした。彼らにはプロダクトバックログアイテムを最初に作るときから参加してもらいました。継続的にリファインメントを行い、アイテムをレディの状態にできました。これにはUIワイヤーフレームワークや明確な受け入れ条件を最低限のものとして含めていました。経験的なフィードバックループが隔週のスプリントレビューで完結していました。
個人的には、レガシーシステムのリプレイスを新しいプロダクトの開発と分けて扱ってはいませんでした。結局は価値（成果 対 結果）と、クライアントやエンドユーザの満足を最大化することが全てなのです。
InfoQ: レガシーな問題に対処するため、スクラムを合わせましたか？
Jocham氏: スクラムガイドではリファインメントプロセスは次のように説明されています。"プロダクトバックログアイテムに詳細、見積もり、並び順を追加することを、プロダクトバックログリファインメントと呼ぶ。これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスである。"
私たちが最後のエンドユーザ -- 郵便局員ですが -- をリファインメントに招待したとき、スクラムの変更を行いました。しかしこれはかなり詳細化されたレベルにありました。これを通してエンドユーザは経験的なフィードバックサイクルがあるスクラムのメリットを素早く理解し、受け入れてくれました。手短には、答えは"いや、スクラムを合わせてはいない"になるでしょう。リファインメントはスクラムの公式なイベントではありませんので。
しかしながら私たちはCDE ・Container Difference Exchanges（自己組織に影響を与えるもの。2001年、Glenda H. Eoyang著の『Facilitating Organization Change: Lessons from Complexity Science』で説明されている）に基づいたワークショップを開発チームに加え、スクラムをスケールしました。これはフィーチャ、アーキテクチャ、テストの依存性のため導入しました。スクラムはフレームワークであるため、プラクティスや要素の導入はとてもうまくいきましたし、そもそもそうなるようになっていました。
InfoQ: "Done"をどう定義していたかご説明いただけますか？
Jocham氏: "Done"の定義は主には品質、保守性、強化能力に関するものでした。ピーク時には100名を動員する大きなプロジェクトだったのです。プロジェクトの初期から、なるべく早く端末を展開してプロダクトを保守段階に入れ、後に続くチームが検証と妥当性確認の両観点からセルフテストシステムを引き継げるようにしていました。
全てのビジネスロジック機能で90%のカバレッジを保持し、各ビジネスシナリオに対してブラウザではSelenium、Android端末ではAppiumを使ったUIテストを適用していました。高いテストカバレッジが品質を保証するわけではないですが、高い品質は高いテストカバレッジによって得られることが多いです。これら全てがプロダクトが"Done"になったかどうかの決め手になっていたのです。
お話した品質の観点とは別に、コーディング基準に準拠しているかの日常的な点検と、実現する要求、テストケース、ソフトウェアアーキテクチャ、インターフェースの情報更新を行っていました。
最後に、プロダクトがドイツ語、フランス語、イタリア語の３ヶ国語に対応し、スイスのように国際化されていることを確認していました。
InfoQ: ３ヶ月早く納品できるようにしたそうですね。これを可能にした成功要因は何だったと思いますか？
Jocham氏: ３つあります。
1. 要求: 私たちは要求に関してアジャイルでした。１つのレガシープログラムを小さいアプリケーションに細分化することで１つのものに集中し、７つの開発チームが平行に作業できるようになり、フィーチャのリスクも軽減できました。アプリケーションの数は20から33に増え、再び18に減り、22で終わりました。このプロジェクトでフィーチャに変更を加えたことで、再利用可能なコンポーネントを多く生み出すことにつなげられました。
2. 品質: これは後から追加したのではなく、スタートの時点から最重要事項に挙げていたものです。品質は強力なビルドパイプラインに基づくテストの自動化、開発した全ての機能性の継続的インテグレーションを通して強化されていました。私が思うに、もしテストを開発の後かもっと後で行うなら、もはや品質ではなく安定性を重視していることになるのでしょう。
3. 透明性: これは駆け引きの（ほぼ）ない誠実で確かな仕事によって確保されるものでした。重要な局面全てにおいて継続的に状況を見極め、即効でリスクを軽減するよう取り組んでいました。調査したデータを基に２週間ごとにアクションを取っていたのです。成功の要となっていたのは信頼ですね。
InfoQ: このプロジェクトで主に何を学んだのか教えていただけますか？
Jocham氏: "Done"とは本当に完了することを意味し、UIからバックエンドシステムまで全面的に通ずるものです。物事が期待通りに行くと思っていてはいけません。全ての機能を初めの方に統合すること。最初のスプリントで"Done"にすること。完了を後に延ばすとろくなことになりません。
InfoQ: もしもう１回プロジェクトをやるとしたら、何か変えたいことはありますか？
Jocham氏: バックエンドシステムをどのように接続するか、それらがどのように動いて機能するかに関して、いくつか思い込みを持っていました。多くの場合、これらの思い込みは間違っていたので痛い目に遭いました。運良く自動テストを使っていたので助かった部分はあります。今後は "Done"というのはバックエンドシステムも含むように主張しようと思います。各開発チームにバックエンドの開発者を配置するようにします。