「Team Topologies」前半読んだ #デッドライン読書会

読むのがホネな（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第37回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。ここ最近はこんな本を読んでいる。

今回のお題は話題の「チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計」である。

Kindle版を読んでいるので分厚さが実感できないが、2スプリントに分割。今回は冒頭からPart.2までを読んだ。

「チームトポロジー」の現時点での感想

非常に良い本だと思うし、本書で使われた用語はしばらく業界内で通用しそうな気がする。中堅以上の、ソフトウェア開発のチームリード的立場の人は必読ではないだろうか。

ソフトウェアシステム開発組織をどう設計するのかというのは実に悩ましい問題で、この組織設計を真正面に捉えた本書は、なんというか芯を喰っている手ごたえを感じた
- もちろん、これまでも「組織パターン」のような武器はあったのだけれども、抽象度が高くて使いこなしにくいという背景もあったと思う
コンウェイの法則も、逆コンウェイ戦略も知っているけど、どーすりゃいいんだよーと頭を抱えている人にはとっても助かる本だろう
表紙の「Spotify、Netflix、Google、Amazonから学んだチームとアーキテクチャーが同時に進化する実践的モデル」はちょっと盛りすぎのような気がする。
- Spotify、Google（SRE）、Amazon（2-Pizza Team）はいいとしても、Netflixの話はあんまり見えてこない（参考文献には出てくるけど）

ところで、トポロジーって何だっけ

ちょっと気になったのは、なぜ「トポロジー」なのかだ。パターンじゃだめなの？
ja.wikipedia.org

おそらく「何らかの形（かたち。あるいは「空間」）を連続変形（伸ばしたり曲げたりすることはするが切ったり貼ったりはしないこと）しても保たれる性質」を念頭に置いているのだと思うけれど、用語の解説は本書には無いような気がする（見落としているかも）
本書のベースとなった DevOps Topologies でも良い説明は見つけられなかった

MicroserviceやDDDを前提にしていない点が好感度たかい

途中まで読んで、いちばん良いと思ったのは、MicroserviceやDDDを前提としていない点である。
チームはコンテキスト境界で分けましょう、とだけ言われても、現実世界のソフトウェア開発チームは下を向いてしまう事も多いだろう。
Chapter 6 チームファーストな境界を決める、ではチームの境界を検討するための概念として節理面という概念（たぶん原著ではJoint Faceなのかなぁ）を使って説明していて、これは非常に刺激となった。チーム構成を検討する際に、チームトポロジーで紹介される基本の4つのチームタイプとあわせて考える良い観点になると考えている。

なお今回は抜き書きは省略。ちょっと調べたところ、以下の記事が（本書で書かれたことを思い出すためには）有用っぽいので、興味がある方は見ていただくのが良さそう。