ブログ

ryuzeeによるブログ記事。不定期更新

スクラムで依存関係を取り扱う方法

みなさんこんにちは。@ryuzeeです。

コーチングをしていてよく聞かれる質問の1つに、チーム間をまたがる依存関係の管理をどうするか、というものがあります。

これの回答となる素晴らしい記事がTHE QUIET AGILISTというサイトで公開されていました。 著者のRick Cusolitoさんに記事の翻訳と公開を快諾いただきましたので、以下で紹介いたします。 元記事はこちらです。http://www.quietagilist.com/blog/2014/10/16/handling-external-dependencies-in-scrum

スクラムの依存関係を扱う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つを使って多くの状況に対処できることは分かるでしょう。

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

それでは。

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック