「Team Topologies」を読んで

GWの空き時間に「Team Topologies」という本を読んだ。

最近、いろいろお手本にしているチームのエースエンジニアの方が「Team Topologiesを読んでいる」と話していたので、それに触発されて読んでみた。

一言で感想を書くと、「チーム作りを考える上でとても参考になる本だな」と思った。

例えば、個人的に、「Microservices」、「Two-pizza teams」、「疎結合」などについて概念としては知っているが、「何故、それを採用すべきなのか？」はよくわかっていなかった。要は、ぼんやりとは理解していても、他人に論理的・合理的に説明するほどには深く理解していない状態だった。

この本を読んだ今は、その「何故」をパシッと言えるようになったという感覚がある。

これから新しくチームを作ろうと思う方は必読の書だと思う。

というわけで、（いつものように）この記事では「なるほどな」と思ったところをいくつか備忘録としてまとめたい。

この本では、以下の3つの考え方に基づきチームのあるべき姿を考えている:

この切り口が素晴らしいなと思う。

自分の言葉で説明すると、

Dunbar’s Numberにより、チームの人数は5～9人にすべき
Innovationを起こすためには、お客様の反応に基づき、Flexibility & Agilityを持ってサービス／プロダクトを進化させていく必要がある
そのためには、1つのチームでDesign/ Develop/ Test/ Operateの全てを行うべき
とは言え、チームにはCognitive Load（認知負荷）という考え方があり、Cognitive Loadが大きくなりすぎると、上手くいかなくなる
よって、チーム、及び、チーム間の相互作用は、Cognitive Loadをいかに下げるかに基づいてDesignすべき
例えば、APIを用いた疎結合にすることで、Cognitive Loadが下がる。あるいは、Managed ServicesやPlatform化されたServicesを使うことでCognitive Loadが下がる
最後に、コンウェイの法則に基づき、そのチームに合ったソフトウェア／システムのアーキテクチャを採用すべき

ということかと思う。

この7個の箇条書きで、Microservices／Two-pizza Teams／疎結合の「何故」を説明することができている（と個人的には思う）。そこがこの本の凄みだなと思った。

この本では、チームは、以下の4つに限定すべきと言っている:

ポイントは、「Stream-Aligned Teamがチームの基本であり、残りの3つのチームタイプはStream-Aligned TeamのCognitive Loadを下げるためにある」である。

このわかりやすさが素晴らしいなと思う。

また、チーム間の相互作用に関しては、以下の3つに限定すべきと書いてある:

こちらにおいても、「Cognitive Loadを意識しつつ、チーム間の相互作用を考える」というその切り口が素晴らしいなと思う。

このわかりやすさは、チームを作る上で非常に参考になるし、チームメンバーも意図するところを理解できるので素晴らしいなと思う。

（若干、しつこいが）このCognitive Loadという考え方は、「コミュニケーションは必ずしも良いものではない」に基づいている。

これは、言われてみると当たり前だが、なかなか気づいていない部分だなと思う。

例えば、昔、いた部署では、多くの人がいろいろな打ち合わせに出席していて、1人で作業する時間を取ることができず、夜な夜な残業する、ということが多かった。

この「打ち合わせ」を「コミュニケーション」と捉えると、まさにコミュニケーションは必ずしも良いものではないなと思う。

言い換えると、コミュニケーションはコストが高いということを認識した上で、どのようにコミュニケーションを行うかをデザインすることが大事だなと思う。

Fool on a hill