今年読んだ本は今年のうちにレビューしてしまおう、ということで第一弾「Team Topology」です。
Team Topologyはソフトウェア開発の規模をスケールさせるために様々なチーム編成と、チーム間のコミュニケーションについてベストプラクティスについて書かれています。 基本的な考え方として、チームの認知負荷(Recognitive load)を一定以下に抑えることと、システムアーキテクチャと組織アーキテクチャを一致させること(いわゆるコンウェイの法則)を重視しています。 その考え方に基いて、チームの型を4つ(Stream aligned team, Enabling team, Complicated-subsystem team, Platform team)、チーム間コミュニケーションのモードを3つ(Collaboration, X-as-a-Service, Facilitating)に分類しています。
チームの特性についての記述で興味深いところは、ダンバー数をベースとした適切な規模(5ー8名)と、コードのオーナーシップについてです。 昨今では、チームが開発から運用までオーナーシップを持つことが一般的となりつつあると思いますが、コードのオーナーシップは排他的なものではなく、他チームを排除するべきではない、とされています。オーナーシップは悪くするとセクショナリズムに陥りかねないので、この考え方を浸透させることは重要に思います。
またコミュニケーションについて、コストの高いコミュニケーション、つまりX-as-a-Service以外のモードでは、事前にコミュニケーションが必要とされる期間を決めておくところは慧眼だと思います。 個人的な経験としても、チーム同士のコミュニケーションが当初ほどは効果的ではなくなっても、なんとなく継続されていて、気付いた時にはあまり効果はなくコミュニケーションのオーバーヘッドだけが残っていた、ということがありました。あらかじめ期間を決めておくことは、効率的なコミュニケーションを維持する上では有効そうです。 また、逆に開発チームが本来は自分のチームでやるべきタスクをSREやPlatformチームに依存してしまい、その状況がずっと続いてしまう、ということもよくあります。これを避けるためにも決められた期限までにX-as-a-Serviceのコミュニケーションに移行する、と合意しておくことも大事でしょう。
その他の内容も面白いですが、チームとチーム間コミュニケーションの分類が、自分の経験としてもかなり的を射ているように思われ、今後、チーム構造やコミュニケーションパターンを議論する際の共通言語とできると良さそうです。
邦訳も最近でたので読み易くなってお勧めです。
