はじめに
私自身EMとしてこれまでチームコラボレーションの課題にあたるケースをいくつも経験してきました。
スクラムをやったらいいんじゃないか、リアーキテクチャーを考えて、サービス分割したらいいんじゃないかとか、色々と模索が考えられている中で、本当にそれって根本解決になるのか？そもそもその手法は何を解決するのかしっくりこないと感じることがありました。
そういった課題にどのようなアプローチしたらいいか悩んでいたときに、『チームトポロジー』に出会い、これは一つの道標として使えると感じました。
自分達の課題は、開発手法でも、アーキテクチャーでもなく、組織構造に根本原因があるんじゃないか、そこから手を付けないといけなかったんじゃないかと考える機会となりました。
チームトポロジーとは何か
この本で書かれていることは、組織編成において、"どのようなチームがより効率的か"というのがフレームワークとして体系的に書かれています。
つまり、よくあるアジャイル・スクラム本などとは大きく違う点として、アジャイル・スクラム本は、まずチームがあって、そのチーム内でどのようにうまく開発していくかということが多いと感じていました。
この本でもアジャイル開発的な要素も出てきますが、その前段階となる組織編成についてまとめられた本なので、世の中的にも注目されたのではないだろうかと思います。
できる限り効果的なチームにするには、ただ偶発的もしくは行き当たりばったりでチームを編成するのではなく、継続的にチームを設計する必要がある。このように継続的な設計によるチーム構造のことをチームトポロジーと呼ぶ。これは、それぞれのチームの責任範囲を明確にしながら、組織内にチームを意図的に「配置」することを意味する。
チームファーストな境界を決める
本の中で一貫して言われていることとして、昨今のシステムは巨大で複雑性が極まるため、チームがなるべく独立してソフトウェアのデリバリーまで行えることが大切ということでした。
そして自立的なチームにするためには、適切な"境界を探す"ことと、"認知負荷を下げる"こと大切であるということが書かれています。
境界の節理面の見つけ方として、ビジネスドメイン、規制厳守、変更の頻度、チームの地理的配置、リスク、パフォーマンス、技術、ユーザーペルソナなどが上げられています。
技術面での分割としてフロントエンド、バックエンド、データ層といったチームの分け方において、
一般的でもある技術主導での分割は、往々にしてさらなる制約を生み出し、フローを改善するどころかフローを低下させる。技術主導で分割すると、全体的な視点ではそれぞれのチームの作業の透明性は低くなり、チーム内コミュニケーションと比べてチーム間のコミュニケーションは遅くなる。その上、プロダクトの依存関係が残り続けるため、チームの自律性が低くなるのだ。
と書かれています。言い換えると、理想的にはあるチームが一つのサービスの単位を一貫してデリバリーできるのがベターということだと理解しました。
また、モノリシックなソフトウェアを分割していく中で、注意点の１つとして、モノリシック思考というものがあり、
モノリシック思考（標準化）
モノリシック思考とはチームの「画一的」な考え方のことで、技術面やチーム間の実装アプローチにおける不要な制約を生み出す。ばらつきを最小限にするために何でも標準化すると、エンジニアリングチームの管理は楽になるが、これはとてもコストがかかる。優れたエンジニアは新しいテクニックや技術を学習できるし、学習したがっている。単一の技術スタックやツールを強制し、チームの選択の自由を奪うと、仕事で適切なツールを強制し、チームの選択の自由を奪うと、仕事で適切なツールを使う能力に大きな悪影響を及ぼし、モチベーションを阻害したり、ときにはモチベーションを消し去ったりしてしまう。『LeanとDevOpsの科学』の中で著者は、チームに標準化を強制することで学習や実験が減り、その結果貧弱なソリューションの選択につながるという研究結果に言及している。
このことから、チームの自律性を目指していく中で、プロセスマネジメントの自律性も考えていかなければならないと思います。
4つのチームと3つのインタラクションモード
どのような組織でも基本的なチームタイムは4つに分けれれ、それぞれのチームの関わり方（インタラクションモード）は3つに分類されます。
| チームタイプ | 説明 |
|---|---|
| ストリームアラインドチーム | ビジネスの主な変更フローに沿って配置されるチーム。職能横断型で、他のチームを持つことなく、利用可能な機能をデリバリーする能力を持つ |
| プラットフォームチーム | 下位のプラットフォームを扱うチームで、ストリームアラインドチームのデリバリーを助ける。プラットフォームは、直接使うと複雑な技術をシンプルにし、利用するチームの認知負荷をへらす |
| イネイブリングチーム | 転換期や学習期に、他のチームがソフトウェアを導入したり変更したりするのを助ける |
| コンプリケイテッド・サブシステムチーム | 普通のストリームアラインドチーム、プラットフォームチームが扱うには複雑すぎるサブシステムを扱うためのチーム。本当に必要な場合だけ編成される |
| インタラクションモード | 説明 |
|---|---|
| コラボレーションモード | 特に新しい技術やアプローチを探求している間、２つのチームがゴールを共有して一緒に働く。学習のペースを加速する上で、このオーバーヘッドには価値がある |
| X-as-a-Serviceモード | あるチームが、別のチームが提供する何かを利用する（API，ツール、ソフトウェア製品全体など）。コラボレーションは最小限になっている |
| ファシリテーションモード | あるチーム（通常はイネイブリングチーム）が、新しいアプローチの学習と適用を促すため、他のチームのファシリテーションをする |
これを実際の現在の組織に当てはめてみると、どこにコミュニケーションコストがかかり、デリバリーのボトルネックになるか見えてきました。
これから
現時点ではこれから次のステップとして、理想の組織構造を考え、どのようにマイグレーションしていくかを考えているところです。
ただし、略者による解説でも言われていますが、チームの編成は一気にやらないことと話してます。
目指すところはいかにチームの認知負荷を減らし、自律性を高めるというところにゆっくりとシフトしていきたいと考えています。
その他参考文献
参考にさせていただいたPodcastやブログをまとめさせていただきます。