依存関係のマネジメント 〜 良い依存関係・悪い依存関係・酷い依存関係

チームと依存関係

• チームはアイテムを完成するのに苦労していますか？
• 他のチームや他の人を待っていることで、次のサイクルで大量に作業が溢れてしまった経験はありますか？
• 他のチームや人たちが作業を完了するまでの待ち時間の間に、アイテムがブロックされた状態になり、アイテムが古くなってしまうことはありますか？

ソフトウェア開発では、依存関係が蔓延しています。組織がアジャイルフレームワークを採用していたとしても、持続可能なチームを支援する構造にはなっていません。このように依存関係が蔓延する理由はたくさんあります。

アジャイルジャーニーを始めるときには、ベンダーや専門家に強く依存しているかもしれません。そしてまた、大規模なシステムを変更するには、いくつかのレベルの依存関係が求められます。現実として、依存関係がなくなることはありません。アジャイルの取り組みをスケールするならば、依存関係もスケールします。でも朗報があります。チームを依存関係の管理から依存関係の緩和に移行するために用いる戦略があります。

『スクラムガイド』による言及

『スクラムガイド』では、チームと依存関係について以下のように記載されています。

機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能力を持っている。スクラムにおけるチームのモデルは、柔軟性・創造性・生産性を最適化するように設計されている。

『スクラムガイド』 2017、K. Schwaber and J. Sutherland

訳注: 原記事では、Scrum Guide 2013 を引用していますが、該当箇所については Scrum Guide 2017 でも変更がないため、2017年10月への引用ならびにリンクとしています。

スクラムに慣れていないチームやアジャイルに慣れていない組織にとっては、ここに書かれていることがまだ現実的でないのはよくあることです。機能横断的チームは、アジャイルにとって礎ではありますが、組織がそこに至るには、とても長い時間を要するかもしれません。

もし、スクラムの恩恵を十分に実感したいのであれば、単に依存関係を管理するのではなく、依存関係を徹底的に緩和していきましょう。この方法を得るために読んでみてください。

よく耳にすること、よく言うこと

下記の各吹き出しにある […] には、

組織設計

私のチームは、主にバックエンドを担当しています。[…] については、別のチームに依存しています。

[…] には、ソフトウェアにおける任意のコンポーネントを当てはめてみてください。例えば、「フロントエンドの拡張」、「データベース層」、「統合」や「API」などです。

未熟なアジリティ

私のチームは、スクラムを採用していますが、一緒に仕事をしている他のチームの大半は、ウォーターフォールのようなより従来のアプローチを採用しています。

非機能横断

私のチームは、専門的なスキルとして […] を使っています。彼らは全く異なるタイムゾーンで働いています。

[…] には、専門的なスキルをもった人材を当てはめてみてください。例えば、「ベンダー」、「エキスパート」や「指導者」などです。

複合的なアーキテクチャ

私たちは、多くの異なる […] を取り扱っているので、真に機能横断的で疎結合にすることが不可能なのです。

[…] には、「システム」、「ツール」や「技術」などを当てはめてみてください。

その他の理由

他にもよく耳にする、よく言ってしまう「理由」があるはずです。それは何でしょうか？

良い依存関係、悪い依存関係、酷い依存関係

すべてのものと同様に、アジャイルには銀の弾丸や万能な解決策はありません。しかしながら、依存関係を緩和するためにできることはいくつかあります。それらには、すぐに解決できるものあれば、より長期的な入り組んだ解決策が必要な場合もあります。徹底的に依存関係を緩和するための解決策は、メンバーに任せて、フローを可能にすることです。

酷い依存関係もあるのでしょうか？良いものにするための話をしましょう。

短期的には、コミュニケーションと積極的なプランニングが鍵を握っています。長期的により強固な状態にするには、相互教育、権限の開放、組織設計の変化、さらには、採用やチーム形成の戦略を検討しましょう。広い範囲で成功するためには、誰もが労力を要します。

短期: スクラム オブ スクラム

組織全体でアジャイルをスケールするときには依存関係を緩和するためのよく知られているアプローチは、スクラム オブ スクラムです。スクラム オブ スクラムは、スケーリングのパターンです。スクラム オブ スクラムでは、それぞれのチームの代表者が集い、労力と依存関係を調整します。依存関係を可視化し、作業の価値や影響力に応じて率直に優先順付けをしていくことが価値のあるやり方です。依存関係のすべては、可視化し、他の要求に対して評価する必要があります（特別にお気に入りのプロジェクトや片手間の仕事は認めらられていません）。もう一つのよくあるやり方は、意思決定者の関与を確実にすることです。それにより、妨害要因の解決が早くなり、グループは、解決策に集中できるようになります。

依存関係の影響を受ける側のチームであれば、スクラム オブ スクラムは、複数のチームの会議に出席する必要性が緩和できる第一歩となるでしょう。ただし、それは依存関係を減らしていくための旅路の第一歩に過ぎません。できることはまだたくさんあります。

長期: フローを可能にして、メンバーに任せる

以下、役割ごとに解説していきます。

スクラムマスターまたは、テックマネージャー

全体的にみて、それぞれの依存関係について関心を持ち、鋭い質問をするようにしましょう。現状を受け入れてはいけません。なぜならば、依存関係の緩和は、明確な解決策のない複雑な問題だからです。スクラムチームやリーダーたち、さらには利害関係者たちとの対話を開催し、さまざまな立場から自分たちの仕事を検証してみましょう。

仕事を「完成 (Done)」させる

完成に達していない場合は、まず初めに、何が問題の原因なのかを分析します。「アイテムが大き過ぎていないか？」、「依存関係に気がついたのが作業前ではなく、作業中だったのではないか？」

アイテムが大き過ぎて、タイムボックス内に作業を完了し、すべてのテストをすることができないならば、バーティカルスライスした小さな作業アイテムにすることに重点を置いたコーチングとトレーニングが必要かもしれません。

実際に問題が他のチームやチーム外の専門家との依存関係にある場合もあります。その場合は、チーム、プロダクトオーナー、ビジネスリーダーと解決策を話し合いましょう。いくつかの解決策があるはずです。他のチームから独立して、アイテムをリリース可能な状態にするために必要となる振る舞いの変更に取り組めるようにしましょう。

チームを巻き込む

チームの作業のフローに詰まりがある場合もあります。おそらく、作業が溢れる度合いが高かったり、仕掛かり中の作業が始まったり止まったりしていたり、古くなってしまったアイテムがあったりがでてくるでしょう。ものごとをどう円滑に進めていけるかレトロスペクティブ（ふりかえり）で検討しましょう。

　問題解決にテクノロジーが必要となると、開発チームよりも可能性のある方法を知っている人たちはいません。また、開発チームは、作業に最も近い存在です。そして一部の人しか持ち合わせていない権限や制御、専門知識によって引き起こされるボトルネックについても開発チームはよく理解しています。

プロダクトオーナーまたは、ビジネスオーナー

コミュニケーションと準備が鍵を握っています。プロダクトオーナーやビジネスオーナーにできる最善策のひとつは、依存関係のプランニング、作業の優先順位付け、スコープの交渉を積極的に行うことです。アジャイルにおけるリーダーの役割は、チームの先頭に立ち、日々の難しい意思決定を下すことです。これはチームの成功に欠かすことができません。より詳しくは、「プロダクトオーナーとしてEQを高める5つのヒント」を読んでみてください。

先行した計画

開発者が早期に依存関係を識別できるように、少なくとも 2 〜 3 サイクル先の計画を立てましょう。これにより、他のチームとの協働が可能になります。また、他のチームのバックログを得ることで、依頼の価値を確実に伝えることができるようになります。アジャイルのさまざまなプランニングのサイクルを用いて、チームの3つの「タッチ」が、ビジョンやロードマップからリリース計画とリファインメントに至るまでの作業を分解できるように検討しましょう。

価値に集中

優先順位や期日でなく、価値についてコミュニケーションしましょう。チームは、複数の利害関係者の相反する要求についてバランスを取らねばならない場合があります。その場合は、期日ではなく、ビジネス価値に会話を集中させたいところです。自分たちのためにも、他の人たちのためにも以下について明確にしましょう：「この依存関係が解決しない場合、ビジネスにどのような影響があるでしょうか？」、「依存関係が全く解決しない場合はどうすればいいのでしょうか？」、「この依存関係は、何かの価値あるものを提供するために本当に重要ですか？それとも単に好ましいだけですか？」

依存関係のある作業の先送り

他のチームがプランニングミーティングに出席して確約するか、作業の開始前に依存関係が解決されない限りは、チームが外部との依存関係がある作業アイテムに取りかかるべきではありません。また、サードパーティからの依存関係を必要とする作業を順次こなしていくことに対して意欲的になることで、チームが学習やスキル向上を図り、依存度の高い作業をより多く支援し、他の人への依存を減らすことができます。

開発チーム

開発チームは、依存関係の緩和を行うときに、最初の防御ラインとなります。

T字型スキル

より多くのチームがより多くの仕事をこなせるように、いつでもどこでも相互教育に取り掛かりましょう。専門家が必要なときは、その人が数週間チームに加わり、知識や専門性を共有できるようにしましょう。その際、ペアを組むことを検討してください。

説明責任

リファインメント活動が、コードやデータベースでの実践的なものであることを確認しましょう。リファインメント中に、他の者に任せるのではなく、他の部分への依存している箇所を識別することに個人的な関心を持ちましょう。

アジャイルエンジニアリング

可能な限り頻繁にリリースするために、自動化やマイクロサービス、継続的インテグレーションのようなテクノロジーがどのように支援できるかを検討しましょう。チームが他のチームから独立して作業ができるようにコードをリファクタリングします。古くなった制約を受け入れるのではなく、権限と制御を少なくするように求めましょう。

アジャイルリーダー

フローを可能にし、メンバーに任せましょう。マネージャーやリーダーシップの役割は、機能横断的で自己組織化されたチームへの移行を支援するための組織構造と共に進化する必要があります。すべての目が開発に集中しているように見えますが、この要素の重要性は見落とされることがあります。しかし、リソースを解放し、制約を取り除くことができる仕組み全体の変更を行うことは、アジャイルリーダー以外には誰もできないのです。

フローを可能に

バリューストリームマッピング（VSM）のようなリーン分析を実施することで、ムダと遅れを識別しましょう。ゴールは、組織を合理的なバリューストリームと持続可能なチームへの進化させることです。また、バリューストリームの外部で依存関係を減らす計画を立てることです。

チームに任せる

エンパワーメントの文化を創造しましょう。「組織には単一障害点がありますか？」、「レビューには複数の段階がありますか？」、「一元化した意思決定文化なのか、それともボトルネックと依存関係を生み出す一元化されていない自律的な意思決定の文化なのか？」

イネーブルメントとエンパワーメントには違いがあります。イネーブルメントは、支援する活動に焦点を当てています。それに対して、エンパワーメントは、個人やグループに対してチカラを与えることです。

プロダクトオーナーやビジネスオーナーが「いいえ」と言えるようにすることで、仕掛かり中の作業を制限し、最も価値のある優先順位の高いアイテムの作業に集中させることができます。また、複雑で依存関係に溢れている作業を調整するムダを省くことができます。

スクラムマスターやチームマネージャーに権限を与え、レビューを減らすことで、情報やデータのフローが有効になります。チームが「はい」と言えるようにすることで、より多くのことが行えるようになることで、組織全体が統一された意欲的な仕事により効果性を発揮できるようになります。

チームは依存関係を終わらせる方法を見つけられていますか？

芸を磨き、真実を語り、感謝を示す

Julee Everett with Kim Andrikaitis