どうも、とがみんです。
システムをクラウドへ刷新していこうという流れの中で、「どのようにすれば安全かつ効率的にシステム開発を行いデリバリーできるのか」というテーマが職場でホットトピックとなり、そのテーマに対して最近考えるようになりました。
アジャイルやスクラムといった実際にシステムを開発する手法だけでなく、そもそものチームのあり方を問うている「チームトポロジー」という本を読んだので、理解したこと考えたことの整理をし、さらに理解を深めていこうかと思います。
Contents
どうすれば価値あるソフトウェアをすばやく提供できるのか
チームやチーム同士のコミュニケーションのあり方を設計する上で、安定で高速なデリバリーを実現し続けるために重要なことをいくつか整理していきます。
1チームでデリバリーフローをまわせる
デリバリー速度を高めていく上では、一つのチームでデリバリーの一連のフローを対応できることが重要になります。
そのため、外部チームへの依存関係をゼロにしていくことがデリバリー速度を高めていくために重要です。
新機能がすでにできているのに、チーム外の何かをまたないと、次に進められないというような状態が生まれると、デリバリー速度が遅くなってしまい、またその依存関係が多いほど、チームが自律して動ける範囲が狭まり、自律性を阻害してしまいます。
そのため、チームは職能横断でデリバリーフローをスムーズに回せるようにしていく必要があります。
チームの認知負荷をしっかり考慮したチーム設計にする
チームの認知負荷を適切に保つような責任範囲の設定や取り組みが重要になります。
チームの認知負荷を考慮せず、チームの責任範囲が広がりすぎると、自分の仕事に熟達するだけの余裕がなくなり、担当業務のコンテキストスイッチに悩まされパフォーマンスが落ちてしまいます。
責任を持ちすぎているがゆえに、複数のチームから発生する要求が多く、その優先順位の調整を絶えず行う必要が生まれてしまったりし、認知限界を大きく超えてしまうと、デリバリーの遅延や品質問題が発生してしまい、チームのモチベーションが低下してしまいます。
また、認知負荷を考慮する場合は、責任範囲だけでなく、時間軸による認知負荷の増減も考慮する必要があります。
新規サービス開始時は、チームの時間は全て使え、認知負荷が何もないかのように計画されてしまうことが多いですが、時間の変化とともに、コンポーネントの数が増えたり、保守対応や既存システムの拡張も求められると、徐々に認知負荷が増大してしまいデリバリーのボトルネックになってしまいます。
オーナーシップを持てるように設計する
チームがシステムに対して責任を持ち、オーナーシップをもてるようにします。
複数のチームに同一のシステムの変更を許すと、その変更がもたらす混乱について、誰もオーナーシップを発揮しなくなってしまい、ソースコードの負債化や、無駄なコミュニケーションが発生し、安全で高速なデリバリーが行えなくなっていきます。
そのため、システムは単一チームが管理し、コンポーネントやライブラリ、コードの共有は許すべきではありません。どのチームが管理すべきかを明確化し、また複数のチームが同一のコードを管理しないように気をつける必要があります。
デリバリーを速くしていくためのチームトポロジー
安全で高速なデリバリーを実現するにあたって、チームがオーナーシップを持ってシステムを管理し、適切な認知負荷で、デリバリーフローが回せるような体制を目指す必要があります。
そのために、チームトポロジーでは、安定して高速なデリバリーを実現するための「チームパターン」と「インタラクションモード」というものを紹介してくれています。
組織やプロダクト開発のフェーズ等、あらゆる観点から「チームパターン」や「インタラクションモード」を選択し、実践することで効果を発揮する型のようなものです。
4つの「チームパターン」と「インタラクションモード」を簡単に紹介していきます。
4つのチームパターン
ストリームアラインドチーム
ストリームアラインドチームは、このチームだけで安全に顧客やユーザーに価値を届けられるようにするための根幹のチームです。
このストリームアラインドチーム以外のチームは、このチームの負荷を減らすために存在しています。
価値のデリバリーをより安定的に高速で行えるようにそのフローを整備したり、ユーザーからのフィードバックを受けすぐに軌道修正を行えるようにします。
イネイブリングチーム
「イネイブリングチーム」は、特定のスペシャリストから構成され、能力ギャップを埋めることを助ける動きを行い、複数のストリームアラインドチームを横断的に支援します。
適切なツールや、プラクティス、フレームワークの調査や探索を行い、ストリームアラインドチームが多大な労力をかけずに能力を獲得し、進化できるようにします。
このチームは積極的にストリームアラインドチームがのニーズを探索しておき、ストリームアラインドチームが必要となる前に、新しいアプローチ、ツール、プラックティスについて先んじておきます。
コンプリケイティッド・サブシステムチーム
「コンプリケイティッド・サブシステムチーム」は、専門知識が必要とされるパーツを開発、保守する責任を持つチームです。動画処理、数理モデル、顔認識エンジン等が該当します。
特別な専門知識が必要な場合にのみ作られます。
プラットフォームチーム
「プラットフォームチーム」は、インフラやツール、共通サービスなどの内部サービス(プラットフォーム)を提供するチームです。
3つのインタラクションモード
安全で速いソフトウェアデリバリーを行う上で、4つのチームの組み合わせだけではなく、それぞれのチームがどのようなインタラクションを行うのか、どのタイミングでチーム同士のインタラクションを変えるのかといったことも重要になります。
3つのインタラクションモードが提案されているので、紹介していきます。
コラボレーション
「コラボレーション」は、他のチームと密接に協力して作業するインタラクションモードです。
2チームが一定期間密接に作業することで、新しい技術、パターンや手法を調査・発見するときなどに適しています。
2チームの責任は共有され曖昧にはなりますが、問題を素早く解決することができ、組織は素早く学習することができます。
一方で、協力作業で認知負荷が増大に繋がったり、コラボレーション以前よりも生産量が減るという可能性がデメリットとしてあげられます。
X-as-a-Service
「X-as-a-Service」は、最小限のコラボレーションで何かを利用、または提供するインタラクションモードです。責任は明確に定義されており、境界が効果的であれば、利用する側のチームは素早いデリバリーが可能になります。
サービス提供側は、サービスをできるだけ利用しやすくすることを目指します。
ファシリテーション
「ファシリテーション」は、障害を取り除くために、他のチームを支援したり、支援を受けたりするようなインタラクションモードです。
別のチームから積極的に作業の一部をファシリテーションまたはコーチしてもらいます。
主にチーム間でで発生する問題を検出して対応したり、一方のチームが別のチームが新しいアプローチを学習したり習得したりするのを一定期間支援し、できるだけ早く独り立ちさせることを目標とします。
チーム連携イメージ
基本的にはストリームアラインドチームがメインチームのため、このチームの認知負荷を下げるようにチームをつくっていきます。
ストリームアラインドチームがデリバリーの一連のフローを実現する上で技術的能力のギャップがあれば、イネイブリングチームがそのギャップを補うような動きを「コラボレーション」というインタラクションモードで行っていったり、
複雑なサブシステムがある場合はそれを管理する「コンプリケイティッド・サブシステムチーム」を立ち上げ、複雑なシステムをストリームアラインドチームに「X-as-a-Service」というインタラクションモードで提供するといった感じです。
対象ドメインの性質や、チームの成熟度に応じて、インタラクションモードも柔軟に変更し進化させていく必要があります。
まとめ
価値あるソフトウェアをすばやく提供し続けるためには、認知負荷や、チーム間コミュニケーションを考慮した組織設計が必要になります。
組織は進化し続けるため、チーム状態、や適切なタイミングで、チームのあり方やチーム間コミュニケーションを変化させていく必要がありそうです。
一通り本を読んで理解を深めたので、今後仕事でも実践し、知見をため、より安全で高速なデリバリーを実現できるようなチーム作りを模索していきたいです。
