📚
【読書記録】チームトポロジー - 技術主導の分割を避け、価値を届ける組織設計
チームトポロジー
書籍名: チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
著者: マシュー・スケルトン、マニュエル・パイス
この本を手に取った理由
- 組織拡大に伴い、チーム間のコミュニケーションコストが増大し、デリバリー速度が低下している課題があった
- アジャイルやスクラムの本は多く読んできたが、その前段階となる「組織編成」についての体系的な知識が欲しかった
- 「チーム指向の組織設計」を読んで、さらに組織設計の具体的なフレームワークを学びたいと思った
本の概要
高速なデリバリーを実現することを目的とした、組織設計とチームインタラクションのための実践的な適応モデルを紹介する本。4つの基本的なチームタイプ（ストリームアラインドチーム、プラットフォームチーム、イネイブリングチーム、コンプリケイテッド・サブシステムチーム）と3つのインタラクションモード（コラボレーション、X-as-a-Service、ファシリテーション）を定義し、チームの相互作用を明確化する。コンウェイの法則を活用しながら、チームを継続的に設計し「配置」することで、バリューストリームを最適化する方法を示している。
印象に残ったポイント
1. チームトポロジーとは「継続的な設計によるチーム構造」
- 効果的なチームにするには、偶発的や行き当たりばったりではなく、継続的にチームを設計する必要がある
- それぞれのチームの責任範囲を明確にしながら、組織内にチームを意図的に「配置」することを意味する
- アジャイル本の多くは「チームがあること」を前提に書かれているが、この本はその前段階の組織編成を扱っている点が新鮮だった
- 組織設計は一度決めたら終わりではなく、ビジネスや技術の変化に応じて継続的に見直すべきものだと理解できた
2. チームファーストな境界を決める - 技術主導の分割は避ける
- 昨今のシステムは巨大で複雑なため、チームがなるべく独立してソフトウェアのデリバリーまで行えることが重要
- 境界の見つけ方として、ビジネスドメイン、規制、変更頻度、地理的配置、リスク、パフォーマンス、技術、ユーザーペルソナなどがある
- フロントエンド・バックエンド・データ層といった技術主導の分割は、フローを低下させ、チーム間コミュニケーションを増やし、自律性を損なう
- 理想的には、あるチームが一つのサービスの単位を一貫してデリバリーできる体制がベストと理解した
- 過去の組織で技術スタック別にチーム分けをしていた経験があり、まさにコミュニケーションコストで苦しんでいたことが言語化された
3. モノリシック思考（過度な標準化）の危険性
- チームの「画一的」な考え方は、技術面やチーム間の実装アプローチにおける不要な制約を生み出す
- 単一の技術スタックやツールを強制し、チームの選択の自由を奪うと、モチベーションを阻害する
- 標準化を強制することで学習や実験が減り、貧弱なソリューション選択につながる（『LeanとDevOpsの科学』より）
- 管理の楽さを求めて標準化を進めがちだが、チームの自律性とプロセスマネジメントの自由度も同時に考える必要がある
- 認知負荷を下げながらも、チームに適切な技術選択の自由を与えるバランスが重要だと気づいた
こんな人におすすめ
- 組織拡大に伴うコミュニケーションコストやデリバリー速度の低下に悩んでいるマネージャー
- アジャイル・スクラムは実践しているが、組織編成レベルでの最適化を考えたいリーダー
- 複数のチームを跨ぐプロジェクトのボトルネックを解消したいと考えている人
- コンウェイの法則を理解し、組織構造とシステム構造の関係を活用したいエンジニア
- チーム設計の共通言語やフレームワークを組織に導入したい人
まとめ
4つのチームタイプと3つのインタラクションモードというシンプルなフレームワークで、複雑な組織設計を体系的に捉えられる点が素晴らしい。特に「技術主導の分割」や「過度な標準化」といった、一見正しそうに見えるが実はアンチパターンとなる考え方が明確に指摘されていて、目から鱗だった。
現在の組織をこのフレームワークに当てはめてみると、デリバリーのボトルネックがどこにあるのかが可視化され、具体的な改善アクションが見えてきた。組織設計は一度決めたら終わりではなく、継続的に見直すべきものだという視点も重要。
「チーム指向の組織設計」と併せて読むことで、アンチパターンの理解とチームトポロジーによる具体的な設計手法の両方が身につき、組織改善の強力な武器になる。エンジニア組織のマネージャーには必読の一冊。
書籍情報リンク
Discussion