チームトポロジーに学ぶ組織の在り方
チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計を読んだ。ソフトウェア・テック企業に勤める人の組織編成の手掛かりに。
英題は、Team Topologies: Organizing Business and Technology Teams for Fast Flow.
PARTが3つに分かれており、チームトポロジーの話はPART2がメイン。DevOpsの潮流とあわせて、テックカンパニーが目指した組織の在り方が見えてくる。個人的にはPhase1のデリバリーの話が特に興味深かった。
コンウェイの法則と逆コンウェイ戦略
Fast Flow（例：デプロイ・リリース）を目指すために組織の編成を考える。本書ではコンウェイの法則の再評価と精緻化を目指す。組織の設計はソフトウェア設計を知った上で行わないといけない時代なんだと気付かされる。
逆コンウェイ戦略
組織は望ましいアーキテクチャー実現のために、チームや組織構造を進化させるという戦略
P.228
求めるアーキテクチャにあわせてトポロジー（組織の柔軟化と）を変化させる。そのためには、コンウェイの法則を意識した戦略も出てくるということだ。その実例の数々がおもしろかった。
「私たちはKubernetesを使いたいから組織を変えたのではない。組織を変えたいからkubernetesを使ったのだ。」
We didn’t change our organisation because we wanted to use Kubernetes, we used Kubernetes because we wanted to change our organisation.
P.190
原文：Convergence to Kubernetes
https://pingles.medium.com/convergence-to-kubernetes-137ffa7ea2bc
例えば上記より、チームとアーキテクチャの扱い方を融合的に捉えることができれば、チーム編成案を繰り出せもする。この視点で組織の再評価をする必要があると感じた。
なお、kubernetesとはシステム選定ツール。手段の一つ。つまり、手段の目的化に見える話が実はそうでもないとも言える。作るものを作りたいとすれば、自ずと組織を変えなければうまくいかない教えに思えた。
タックマンモデルの混乱期
あと、タックマンモデルはあるあるとして組織の成長の参考指標として覚えていたが、近年は、混乱期に当たる混乱はそもそもずっと続くのでは？という指摘もある（本書P.42NOTEより元の話）。
この本でも指摘しているチームの編成タイミングの慎重さ。うまくいっているチームを解散させたりいじることは危険を伴う。その上で混乱期が続くなら常にチームの細かい気づきやチューニングは必要で実感もする。
どこかにチームのゴールがあって、ある程度成熟したらその次は新しい人を入れることでまた混乱期を乗り越える。そのようなサイクルがあるのがチームだと捉えていたが、この考えに固執しないほうがよさそうだ。
チームファーストでいるという目線のもと、互いの対話を繰り返してよりよい環境の用意と、適切なコミュニケーションパスのコントロールを組織を作る側は気にしておく必要がある。
ソフトウェア業界に学ぶ組織マネジメント
本書のように、ソフトウェア業界から組織のあり方について学ぶことが多い。本書も学術的な視点や引用より、それぞれの分野で活躍した実践値がつめこまれている。
PART1で好きな話にコミュニケーションパスの話がある。コミュニケーションをしないと解決しない問題が、そもそも不要なのにコミュニケーションしていれば間違っていると。逆もしかりで必要なら誘発を促す必要もある。
他にも本書では認知負荷の話がおもしろくコミュニケーションパスとあわせて意図的な組織設計が必要だと感じた。人のコンテキストスイッチはできるだけ削りたいものだ。
これらは、どの組織においても気にする話で、階層的な組織であればあるほど、縦の繋がりや横の繋がりに全体共有の話が出てくる。それをどこまで広げるのか、広げることに意味があるのかを組織単位で気にする必要がある。
チーム人数の最適化の話もGoogleの研究データでまとまってもいる。今、変化にあわせてリリースを繰り返す組織のことについて学ぶ必要がある。本書は、その手掛かりの一つになるのではないか。
作りたいものに合わせて組織を作るという順番は汎用的で、どの現場であっても活かせるはずだ。