ブログ

スクラムの依存関係を扱う3つの実績のある方法

開発チームは機能横断的(クロスファンクショナル)である。インクリメントを作成するスキルをチームとしてすべて備えている。- K. Schwaber and J. Sutherland、スクラムガイド、2013

※日本語版より抜粋し一部補完

彼らがそうでないときを除いて。

このトピックは、あなたの視点によっては皮肉かもしれませんしタイムリーかもしれません。前回の記事では、ストーリーを縦に切ることの重要性について説明しました。すべてのストーリーを動作するソフトウェアにするために持つべき最も重要な要素は、クロスファンクショナルチームです。とはいえ、そのとおりにやるのは難しいのが実情です。

スクラムのゲームのルールに従う上で、チーム間の依存関係は問題になります。

スクラムの開発チームは開発作業を担当しますが、それが大きなプロジェクトやプログラムのごく一部ということがあります。この場合、個々の開発チームは、企業にとって役立つものを作ることはできません。ビジネスに本当の価値をもたらすために、まずは他チームの作業と統合しないといけません。

スプリントごとに少なくとも1回、すべての作業を統合する必要があります。継続的統合に向かって進めていくべきですが、一方で他チームとの日常的な統合は最小限でないといけません。最初は、各チームの作業を継続的に統合することは困難だったり組織にその能力がなかったりする場合もあります。企業は、複数のチームの作業を統合するために、開発組織を変更する必要に迫られることもあります。プロダクトの開発やテストに使用する技術を変えなければならず、組織全体のエンジニアリングプラクティスを改善する必要もあります。

個々のチーム内あるいは開発者レベルで起こる変更もあります。ただ、ほとんどの企業では組織全体で多くの改善が必要です。どんなにシンプルな設計であったとしても、非常に複雑なプロダクトを作っています。最高の状況下でも毎スプリントで動作するソフトウェアを作ることは難しいですが、毎日の開発状況を知らなくては、それはもうほとんど不可能です。組織はこのような状況を見てスクラムではうまくいかないと文句を言いますが、問題に焦点を当てつつもソリューションにも焦点をあてる必要があります。今いきなりすべてのことはできませんが、適切なエンジニアリングプラクティス、いくつかの規律、そしてそこに向けてドライブをかけていくことで解決できるでしょう。

いくつかの一般的な外部依存シナリオを考えて、それらをスクラム内でどう扱うか見てみましょう。

フロントエンドの機能がインフラストラクチャの拡張機能に依存する場合

マイレポートチームは、プロダクトバックログアイテムを選択して、ユーザーが指定した期間のトランザクションすべてを1画面で表示できるようにしました。現状では、複数の画面からデータをエクスポートして、Excelでデータを集計しないと見れなかったのです。プロジェクトの作業には、画面、ワークフロー、およびデータベースの変更が含まれていました。

ワークフローとデータベースは、各部門のプロダクトの多くが使っているインフラストラクチャの一部となっていました。ユーザーの要求をサポートするには、データベースから頻繁にデータを取得したり、データベースにフィールドを追加したりする必要があります。これらの拡張が完了すれば、ユーザーインターフェイスに必要なすべてのデータが一度の要求で手に入ります。残念ながら、インフラストラクチャの変更は別のチームが担当します。そのためマイレポートチームは、（a）フロントエンドの機能拡張では、デモやテストのときにインフラストラクチャの変更に依存しないように進めるか、または（b）プロダクトバックログから別の項目を選択して、インフラストラクチャーチームが一緒に作業する準備が整うまで待つか、のいずれかになります。

幸いにも、アジャイルはこのような状況のためのガイダンスを提供しています：

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

• アジャイルマニフェスト、2001

チームが答えないといけないただ1つの質問は、オプション（a）が「価値のあるソフトウェア」をもたらすかどうかということです。答えが「Yes」の場合、それは2番目の疑問につながります。それは本当に依存関係があるのか、本当にインフラストラクチャの変更が望ましいのか？という疑問です。しかし今回の例では（a）に対する答えは「No」であるため、選択肢（b）のみが実行可能な選択肢でした。

チームは、他チームがスプリントプランニングに参加していない限り、外部の依存関係を持つストーリーを開始すべきではありません。ただしインフラストラクチャチームが複数のチームのために拡張に取り組むような場合、今回の作業を優先させられるのは誰になるでしょうか？1つのソリューションは、全体的なROIを担当するエンタープライズプロダクトオーナーです。個々のプロダクトバックログを単一のエンタープライズバックログにまとめます。エンタープライズプロダクトオーナーはインフラストラクチャのプロダクトバックログに優先順位を付けて、ROIを最大化し、リスクを最小限に抑えることができます。

作業がアーキテクチャのレイヤーで分割されている場合

時には、アーキテクチャのレイヤーを越えたクロスファンクショナルチームを作れないこともあります。このような状況では、スクラムの3つの柱（透明性、検査、適応）を見失わないようにしてください。検査し、適応するために、チームは常にプロダクトバックログのどこにいるかを知る必要があります。チームはできるだけ頻繁に動作するソフトウェアをリリースする能力も必要です。

Amlarは、疑わしい銀行活動を特定するために金融取引を監視しようと考えていました。これらの機能を届けるには5つのレイヤーが必要です。第1は、銀行と他のエンティティとの間のすべての取引を収集して格納するレイヤー。第2は顧客口座情報を保持するレイヤー。第3は、金融取引の規制ガイドラインを保持するレイヤー。第4は、トランザクションと規制内容とを比較しメッセージトラフィックを作成するレイヤー。第5は、さらなる調査のためにメッセージをアラートとして表示するレイヤー。それぞれのレイヤーは、地理的に異なる場所（1つはジョージア州、1つはニューハンプシャー州、3つはマサチューセッツ州）にある別々の組織によって開発されました。それぞれのレイヤーにはそれぞれ別のプロダクトオーナーと開発チームがいました。Amlarの役員たちは進捗に満足していました。いったいどうやったのでしょうか？チームは、どのようにして、古くなった仕様で作り続けずに変化に適応しているかを確認したのでしょうか？どのようにしてインクリメントが価値あるプロダクトに統合されるか、それぞれのチームはどのように知ることがでたのでしょうか？

まず、統合レイヤーを作成します。第6のレイヤーです！統合レイヤーチームには、他の各レイヤーの代表者がいました。統合レイヤーは毎日各レイヤーからビルドを取り出し、それらを単一のビルドに統合しようとしました。次に、統合テストを開発し、最終プロダクトがリリースされたときの機能をテストしました。障害を引き起こしたレイヤーには障害を報告しました。そのチームは、それ以上の開発を進める前に、まずは問題の対応を優先しなければなりませんでした。最後に、各スプリントの終わりまでにすべてのレイヤーをインクリメントに統合しないといけないという規範が確立されました。そうでない場合は、何も完成と呼べず、何もデモできませんでした。

スクラムチームがウォーターフォールチームに依存する場合

HipaaCareは健康保険を販売しており、従来のシステムをアフォーダブルケア法やその他の規制変更に対応するために新しいシステムに置き換える必要がありました。1つのチームが、4つの顧客層のレガシーメインフレームコンポーネントを置き換えるCRMシステムの構築を担当しました。関連する申請と請求データをCRMに取り込み、顧客データを他のシステムで利用できるような共有Webサービスは別の専任チームによって開発されていました。

Webサービスチームは、SOA設計仕様からなる独自のマイルストーン駆動プロセスを使用していました。マイルストーンは、設計ドキュメント、各サービスのプロトタイプ、そして完成したプロダクトでした。このプロトタイプは、最終的なプロダクトの簡単な模造品でしたが、CRMチームのテスト環境として提供され、スプリントのあらゆる機能の検証に使用できました。しかし、サービスチームへの納入までは3ヶ月かかりました。

CRMチームはスクラムを使用し、最初の3ヶ月で3つのスプリントを完了しました。そこでは、Webサービスの仕様に基づくモックサービスを使って機能を構築しました。実際のサービスが提供された後、開発したものを実際のCRMでテストしました。

変更やコミュニケーションミスはプロダクトの複雑さと直接関係しています。スクラムがスプリントで最低一回統合を必要としているのはそのためです。そうすればスプリントレビューでデモができます。他のチームがスクラムを使用しない場合、スクラムチームは他のコンポーネントの代わりとなるものを使いながら可能な限り統合する必要があります。これらの代替品は、後での変更を最小限に抑えるために工夫して使用しないといけません。

CRMチームは、プロトタイプの準備が整うまで、新しいサービスの構造を理解して代替となるものを作っておかなければなりませんでした。彼らは、最初のスプリントでいくつかの拡張機能といくつかの新機能を選択しました。予想される変更を考慮できるように設計をリファクタリングしました。そうすることで以前に開発した機能が引き続き機能するようにしました。

このソリューションでは、完成したWebサービスを使ってCRMチームが再テストする必要がありました。設計が変更されるたびに、再テストのために代替品を変更しなければなりませんでした。しかし再作業はその機能に限定され、変更が発生した時点で設計は完了になりました。ウォーターフォールで作られた実際のサービスで、スクラムチームのシミュレーションレイヤを置き換えたということです。

結論

チームがクロスファンクショナルではなく、自己完結型ではない理由はたくさんあります。多くの大企業がスクラムを採用していますが、まだそのような構造になっていないことが多いのです。なんらかのレベルの依存関係が必要となるようなエンタープライズ全体のシステム変更もあります。しかし原因が何であれ、すべての問題を解決するようなソリューションはありません。ただ、上記の3つの例のうちの1つを使って多くの状況に対処できることは分かるでしょう。

依存関係についてどんな問題が発生しましたか？みんなが喜ぶ解決策を見つけられましたか？