Team Topologiesの難しさと課題
はじめに
僕はもともとアーキテクチャに興味がありコードの可読性や良い設計を保守運用経験を通じながら検証していたが、最近はチームの拡大とともに組織構造も設計論が影響すると考え始めて、アーキテクト兼マネージャーとして働いている。ケリー氏のこの指摘を見たときに、この方向性との一致を感じて嬉しくなった。
これまで以上に確信するようになったことがある。アーキテクトを名乗る人は技術的スキルと社会的スキルの両方が必要であり、人間を理解ししゃかいの枠組みのなかで仕事をする必要があるということだ。同時に、彼らには純粋な技術にとどまらない広範な権限が必要だ。組織構造や人事問題についても発言権を持つ、つまりマネージャーになる必要があるのだ。
Team Topologies p28
本記事はTeamTopologiesの難しさと課題について。
RSGT2025の一日目のKeynoteでは、The Art of Agile DevelopmentのJames Shoreさんの講演で、Team Topologiesについての課題とそれらをFaSTが解決する、というスライドがあった。（Team Topologiesは長いので以下TTで統一）
本記事ではこの指摘をきっかけに、TTの本質的な課題について僕なりの見解をまとめたもの。結論は意図的に最後に記載した。そこに至る経緯があった方が意図を正確に伝えられると思ったため。
僕自身は、RSGT2025ではTTを応用したチームのスケーリングに関するテーマで登壇した。現地では色々なスケーリングを試されている方と議論したり、ユーザーストーリーマッピングの著者であるJeff氏とスケーリングについて話したり、様々な発見がありとても楽しめた。（この考察の後、僕が実践していたチーム分割論について良い言語化ができたので別途記事にする）
拡大したスクラムチームの衝突、ご参加コメントいただきありがとうございました。資料共有いたします。
— Nibu (@SMycrow) January 8, 2025
詰め込んだ内容でしたが、ストーリーベースで理解して貰えるように頑張って推敲してきたので、Discordで分かりやすいとコメント頂けて大変嬉しかったです。https://t.co/Tqyxkt6gAI
#RSGT2025
Team Topologies vs FaST
1. Cross-Team Initiatives
複数チームでプランニングするのは難しいということ。確かにTTではストリームアラインドチームの認知負荷を下げるために、プラットフォームチームやイネイブリングチーム、コンプリケイテッド・サブシステムチームが３つにモードに分類されている。計画時に複数チームが協力する必要がある場合は想定されるが、TTはそれを各チームの役割の明確化（予測可能性）によって最小限に抑えようとする。そのため指摘されている通り連携が必要。
実際に僕達もプランニングの際に、プラットフォームチームに負荷が集中してボトルネックになったことがある。
ただし、これはチーム間の連携によって緩和することができた。具体的には、OSS的にストリームアラインドチームがプラットフォームチームのリポジトリにコントリビュートすることによって実現できた。
言いたいことは、TTは確かに複数チームの連携を前提としているのが、発生する問題は緩和できるということ。この考察から導出できるのは、TTを効果的に活用するには少なくともチーム間の連携をうまく処理する必要があるということ。TTは明確なチームの役割と予測可能性を与えており、チームファーストによる恩恵を受ける一方で、それによって発生する課題は連携によって解決しなければならない。Cross-Team Initiativesに関する指摘内容は正だが、それはある恩恵を得るために発生したコスト（課題）であって、その選択がもたらす良い面についても考慮すべきである。（チームファーストの恩恵についてはかなり分量も増えそうなのでここでは触れないが、スクラムとの親和性もあるためどこかで記事化したい）
2. Rigidity
ビジネス上のニーズが変化したとき、それに合わせてチームの割り当てを変更することは大変という指摘。TTはビジネス境界に依存している可能性もあるので、扱っているプロダクトに学習による変化が起きる場合、チーム構成を変更しなければならない。TTでは節理面という用語でチーム境界を定義しており、ユーザーペルソナ、コンテキスト境界、リスクなど様々なパターンが存在するとしている。境界によってはビジネスの変化に応じてチーム構成を変更する必要はもちろんあり、TTは以下に引用したようにチーム構成の進化も前提としている。
したがって、ソフトウェア・システムを構築し実行するためのモダンな組織を設計する際に最も重要なのは、組織自体の形態ではない。新しい課題が発生したときに組織を適応させ変化させていくための決定ルールと経験則だ。つまり、組織だけでなく、設計ルール自体も設計すべきなのだ。
さらに以下の指摘を加味すると、ある程度チームが固定化されていることは組織構造の進化のために有効であると言える。チームが固定化されている時、それをアンカーにチーム間の連携パターンや頻度を計測することができる。それがセンシングとして機能することで、再設計のための適切な情報を得ることができる。
しかし、組織がしかるべき自覚を持って、チーム構造を進化させるタイミングに気づくことは容易ではないことが多い。組織内のチームトポロジーを再設計するきっかけになる状況はいくつかある。これらを知って学べば、組織は自らの義務を理解し、適応と進化を続けられるようになるだろう。
Rigidityを進化のための学習コストと捉えて投資するかどうか、という観点が重要になるのだと思う。それを避けるならばFaSTによってチーム形成の柔軟性に解決を任せるのがいいのかもしれない。FaSTを実践している企業の方とDay３のOSTで話したとき、流動性がほとんどなくなるチームが出てくるかどうか、ということを聞いた。回答としては流動性のないチームは発生するし、それはそれで構わない、というものでとても腑に落ちた。つまり、FaSTはトポロジーという概念を適用せずに、自然解決的に安定的な構造を発見するという方法とも捉えられる。
この観点についての結論としては、Rigidityが課題というよりは、効果的な構造をトポロジーの導入で見つけるか自然発見的に見つけるか、どちらのアプローチをとるか、という選択であるということ。
3. Specialities
特定スキルの補助的関わり方が薄くなってしまうという指摘。TTではイネイブリングチームがストリームアラインドチームに不足している技術支援を行うため、技術獲得支援をしながら専門家が複数チームにまたがって活動する状況もあり得る。もちろん状況によっては一定期間特定のチームに専任することもある。そのためこの指摘については、そういった状況も想定されると言える。
FaSTは確かに特定期間は専任するためより腰を据えて活動できるのでその点では利点があるかもしれない。逆に言えば、同時に複数の専門的な課題に取りかかれる程度には専門家の数が必要になるとも言える。
したがってこの指摘については、チームの扱う複雑度や組織内のメンバーのスキルレベルによって、影響の大きさやその解決方法が異なる部分だと僕は捉えている。
4. Shared Code
複数のチームが同じコードを扱う場合、品質やオーナーシップの問題が発生するという指摘。それは同意しますが、TTの境界が適切であればこの問題は防げると捉えているので、TTに対する課題として挙げられていることには違和感がある。TTの書籍では以下の言及があり、これを進化的に解決していくのがマネージャーでありアーキテクトの仕事だと捉えている。
継続的にコラボレーションが必要になるなら、ドメインの境界やチームの責任が正しくないか、チーム内のスキルの組み合わせが正しくないことを示している。
この点に留意すればShared Codeの問題は適切に処理できるはず。加えて言えば、これらを経験的に発見して取り除く痛みを許容できないならTTの導入は難しいかもしれない。
僕は逆にFaSTの場合、この観点が問題にならないのかと疑問に思う。担当するストーリーによっては、同時に変更が必要なコードが発生するはず。その場合にどういう問題をどう解決しているのか、取り組んでいる方にぜひ聞いてみたい観点（もしよければご連絡いただけると嬉しい）。
結論
1. 見解
Keynoteで指摘されたTTの課題について、それらはある恩恵を得るために投資したコストのことであるか、TTの本質的理解に至らないまま適応したときに発生しうる問題のことである、ということを僕の考察と経験によって述べた。それらを緩和する方法もTTで説明されているため、困難な課題ではないのではないかと思う。ただし、これらに対応するにはソフトウェア設計の経験やドメイン駆動開発への投資が必要になる場面が多い。それを踏まえてTTの本質的な難しさと課題はなにか。
アーキテクトとしての経験と保守運用による継続的開発の実践経験を持ったエンジニアが、マネージャーとして組織構造を継続的に改善することに工数を投資して、それを上位の職務とメンバーの理解によって協力的に実現すること。
TTの難しさはメタっぽいがここに起因すると思う。これをプロダクトの成長過程の中で実現していかなければならない。
2. 留意点
スケーリングに関するフレームワーク全般に言えるが、既存の手法に当てはめようとするアプローチがよく取られており、個人的にはこれはあまり良い方法だとは思わない。あくまで今向かい合っている課題をどう解決するかについて、有効な知見や事実を利用していかないと組織レベルの課題解決は難しい。守破離とは言われるが組織構造については柔軟に考えるべきではないかと思う。
以下の記事のTTに対する指摘は個人的に的を得ていると感じた。今の組織をTTに当てはめようとするよりは、自分のもつ組織課題にアプローチするアイデアとして適用できないか考えればいい。特に単純な原理原則部分に基づくというのは、特定の方法への盲目的な追従を避け自分で考える方向に向かうので、とてもいい言葉だと思った。
Please read the book, stick it in your toolbox, and design your approach tailor-made and evolving for your specific organization. Avoid big design upfront approaches with Team Topologies, however tempting the simplicity might be. Go back to the basic proven physiological principles like Conway’s law and Dunbar's number or even tools like DDD or XP. Experiment in context and evolve, do Agile Transformations Agile.
3. 感想
RSGTには複数のチームで構成される組織体制の課題をどうにかしたいという悩みを抱えている人、それを突破しようと色々試している人などたくさんの人がいた。
この課題に関してスクラムをどうスケーリングするか、という方針の人が多かった（FaSTもあるが）。スクラムはなんかもっとソフトウェア以外側での応用やスケーリングの方に可能性を感じたりする。どちらにしても、ソフトウェアの継続的開発という領域では、組織構造に対してDevOps側の研究成果を活用すればもっと面白いことができるんじゃないか。
スクラムとTTの接点やシナジーについては、僕が重要視している関心事をもとに繋げられるトピックだと感じている。この観点について継続的に検査と適応を進めて得られた知見を今後も共有していきたい。
おまけ
RSGT2025のDay0にあったSpeaker's Dinnerで原田騎郎さんとスケーリングについて議論することができました。当時、TTは原著で読んでいたので翻訳者（原田さん）の名前を知らず、せっかくならもっとTTの話をすればよかったと後悔。。。後ほど翻訳版を購入して日英の両面から理解を深めました。とても読みやすい翻訳で助かりました。