もともと発売当初に購入して流し読みだけしていたけど最後まで読み切れていなかった。 あらためて内容を詳細に把握しておきたいということで読み切った。
概要
チームトポロジー本については訳者の紹介記事やfukabori.fm が詳しい。 自分はfukabori.fmで強く興味を持って購入した(気がする)。
副題にある通り、ソフトウェアの素早いデリバリを実現するためにチームをどのように設計すべきか、について書かれている。
よかったところ
この書籍の内容は、逆コンウェイ戦略や4つのチームタイプと3つのインタラクションモードのような組織設計が主眼ではなく、
認知負荷にどのように対処すべきかが主なトピックであると理解した。
認知負荷に対処するために不要なコミュニケーションを制限するアプローチとして、これらの組織設計を活用するという話が単に紹介記事を読むだけでは理解できていなかった。
このあたりの誤解を解くためにも実際に本書を読んでよかった。
この書籍でも何度も参照・引用しているが、「LeanとDevOpsの科学」に触れて逆コンウェイ戦略の必要性などを語っている。 LeanとDevOpsの科学を読んだ当時は、自分も逆コンウェイ戦略を活用して組織をどうするべきか会社で話をした記憶はあるが、認知負荷にここまで焦点を当ててはいなかった気がする。 そういう意味で、LeanとDevOpsの科学から次の具体的なアクションに進める上で認知負荷への対処が重要なファクターであるということを言語化・再確認できた。これを認識する上で読んでよかったと感じた。
チームタイプのような組織設計みたいな話になると「ユニコーン企業のひみつ」で紹介されているようなSpotifyモデルが有名。
チームに自律性を持たせたマトリックス型の組織を構成することで、高いアジリティをイノベーションを実現できるととが説明されている。
一方で、単なる組織構造だけ真似しても上手くいかず、マインドセットなどが重要であることも知られている。加えてSpotifyも早々にSpotifyモデルから変更したことも知られている。
本書では特にチーム間のコラボレーションに焦点を当てている点が大きく異なる。
チーム間で必要なコラボレーションの量とそのチームの特性に応じてインタラクションモードを選択することで、チームやチーム間の認知負荷を削減して素早いリリースを実現しようとしている。
また必要なイノベーションに応じてインタラクションモードを変更することでコラボレーション量を調整し、チーム間の関係を適応的に変更していく動的組織の重要性を説明している。
このように、チーム間の関係がチーム特性や状況によって異なること、それは動的に変更していかないといけないと明確に認識できたことがよかった。
組織設計の話を扱う書籍のうち本書で触れていない書籍としては「エンジニアリング組織論への招待」などがある。
エンジニアリング組織論への招待では主に不確実性を扱っており、不確実性とは何かに焦点を当てて解説している。
一方で社内の共通言語として問題を認識するためには有効でも、具体的にどのように解決していくのかまでは距離があると感じていた(だからこそ「組織論への招待」なのかもしれない)。
本書では4つのチームタイプと3つのインタラクションモードという、実践的なパターンに落とし込んでいるのでより具体的なイメージを描くことができる。
特にこのパターンは実際のソフトウェア開発組織に非常に近いので、自社であればこのように適用できる、と具体的な解決策の提案まで考えることができるところがよかった。
リリースを最適化するというアプローチとしては「This Is Lean」を思い出した。
こちらはリーンの説明としてリソース効率ではなくフロー効率を重視することで、素早い価値提供を実現する方法について説明している。
This Is Leanはソフトウェア開発だけでなくあらゆる業界に適用できるためソフトウェア開発特有の事情には触れていない。またチーム(リソース)よりもプロダクト(フローユニット)に着目している。
チームトポロジーはプロダクトファーストよりチームファーストのアプローチに着眼している点が大きく異なると感じた。
組織におけるフローを良くするという目的は同じでも、本書はソフトウェア開発を行うチームファーストアプローチを採用している。
また、ソフトウェア開発という不確実性(変動)が高い状況においてはリーンのようなフロー効率を高める方法には限界がある。
このようなケースへの対処としてチームファーストでコラボレーション量を調整することで、イノベーションを実現するというアプローチを知れたとこがよかった。
疑問点
この書籍の問題なのかよくわからないが、本書を読み進めるのに苦労した。なぜ読み進めるのに苦労したのかは上手く言語化できていない。 訳書だからかもしれないし(あまり表現にひっかかることは無かったと思うが)、組織論のような分野があまり得意では無いからかもしれない。LeanとDevOpsの科学やエンジニアリング組織論への招待も苦労したので。
また、書籍の肝である適応的に組織を変更するところは腑に落ちていない。
もちろん、コラボレーションが不足していたらインタラクションモードを変更するとか、必要に応じてチーム構成やチームタイプを変更するという考え方はわかる。
またChapter8に記載されているチームトポロジーを再設計するきっかけとなるシグナルの例もなんとなくわかる。
しかし実際に業務においてこれらのシグナルを観測したとしても、それはチームトポロジー再設計のタイミングだとは気付けない気がする。
チームトポロジーの変更は数ヶ月掛けて変更するものと説明があるので、シグナルを受け取ってその場で判断するのではなく他の施策にいろいろ取り組んでそれでもだめならチームトポロジーの変更を検討するのかもしれない。
これは実際にチームトポロジーを実践して考えてみたい。
