Booklog - Team Topologies 価値あるソフトウェアを素早く届ける適応型組織設計

はじめに、まえがき、用語集 ~ 訳者紹介。昔途中で積んでたので最初からやり直す。 本書は卓越して優秀なプレーヤー向けじゃなくて幅広いチームや組織が取り入れたり応用するための明確な適応型組織のパターンを提案する。 参考文献と脚注が邦訳書に置き換わってないから芋づる的に知識を引き寄せるのはちょっと難あるな。パッと見でも結構翻訳されてる本あるが、本文中にしか和書タイトルがないぽく探すの大変かも。 ちいとぽは、基本的に「環境設計による行動誘導」で自律性を発揮させるのが狙いなんじゃないかなと思うが、行動変容の観点から見て外発的な刺激に起こされた自律性が定着して内発的動機づけによる自律性に転化するのは稀だという懸念がある。 PART Ⅲで進化に触れるらしいからそこでこの話題が出るかどうかやな。仕組みの中でうまくいくだけなのはもうわたしの興味の範疇でないねんよな。 でも世間で好まれるフレームワークだし教養として押さえておきたい。あとあれ、色多いしビジュアル言語的な何かに今なら気付けるかもってところ。どうも色や図形に意味があるらしいし。

2026-04-24, read count: 1, page: i ~ xxii, 228 ~ 252, pages read: 47

Part Ⅰ Chapter 1, 2 。従来の組織構造はコミュニケーションと意思決定の経路を考慮していない。 適応型の組織にするにはティール組織やホラクラシーに見られるようにチームに権限を与える必要がある。 そのためにコンウェイの法則を逆手に取りシステムを疎結合にし、認知不可を制限して自律性を高める構造を導く。 Chapter 2 では逆コンウェイの法則による組織とアーキテクチャの設計について。 ヒトのコミュニケーションパスと意思決定に関してはわたしも同様の理解で、 AI の時代でもこれは変わらないと思う。 とはいえ数年間 10 人未満の開発組織にいるから逆コンウェイの法則が必要な場面に遭遇しなくなって久しくピンとこなくなってる。 もし変わる可能性があるとしたら、 AI が代替することで逆コンウェイの法則が有効だった規模が縮小して得られる効果が減ずるとか？ 各人に権限さえあればアーキテクチャを分離することもできそうだないというのはもうわかってるし、 AI を率いる人たちは程度が高いから十分な権限を持つだろうとうことで。

2026-04-25, read count: 1, page: 1 ~ 35, pages read: 35

Part Ⅰ Chapter 3 。認知負荷を低減するためダンバー数に従いチームの規模を制御し、高信頼のチーム(5 ~ 8 人)・組織を設計する。 高信頼な組織ではチームにヒトが出入りしても機能を落とさず長続きする。長続きすればソフトウェアの所有権をチームに帰属することができる。 Part Ⅰ は良く知られたマネジメントや組織設計の話をベースにして本題に入る前の地ならしをしてるのかな。認知負荷を理由にしてる辺りが新鮮なのかな。 参考文献が散りばめられているのは素晴らしいので読んでない本は積読候補とする。 Auto Trader のディスプレイ数制限の例は、まさにコラボレーションと創造性がトレードオフである好例やなと思った。 Spotify のトライブ/スクワッドに突然言及してるが用語の説明ないため事前知識がないヒトは記憶に残らずスルーしそう。 またこの本は索引がないからそういう単語が出てきてもどこで出たか調べる術がない。 あと参考文献に言及してるところで邦訳書の出版年に変えてしまってるから、人月の神話が古典と言いつつ 2014 年と書いてて歴史改竄で知らないヒトの理解の妨げになるなと思った。 図 3.2 でしれっと複雑・煩雑を変えてる＆変更前後の例で人数が違い過ぎるのも、意図がわからなかった。 これらは初版第 1 刷だから誤記かなと思うが正誤表を見つけられなかった。どっかにあるのかな。

2026-04-26, read count: 1, page: 36 ~ 69, pages read: 34

Part Ⅱ Chapter 4。銀の弾丸となるトポロジーはないがどんな組織でも不適切な、場当たり的なチーム設計・解散するチーム、といったトポロジーは存在する。 組織の技術力・文化・成熟度といった状態に合わせた選択が重要となる。 例として、職能横断型のチームが横断的な仕事をするには高い信頼を必要とする、プロダクトチームがプロダクト開発に集中するためにクラウド等を簡単に使えるようサポートが必要な点、 SRE の導入が大規模組織だから意味がある、など。 内容自体は普通て適応範囲についての前置きをしてるんだと思う。 Chapter 5 からパターンみたいだからそれの免責事項ということかな。 フロー最適化するための責任境界。わかるがわたしが最も機能する小さな組織では、最適な手段ではなさそうだし中の人としても面白くなさそう。 パターン化されてて効果も言語化されていることは管理する側にとって説明のしやすさやという価値があるんやろな。 本質的には少しずつ試して継続して変化していくことが重要だけど、型がないと理解を得られない組織は多かろうしな。

2026-04-27, read count: 1, page: 70 ~ 94, pages read: 25

Part Ⅱ Chapter 5 。ここからが本番かな。基本的なチームタイプが組織内の役割を明確にすることが組織設計の成功につながる(この先意味を読み違えるので英語で書く)。 Stream-aligned team は機能やユーザージャーニーのような継続的な仕事の流れに責任を持ち、なるべくそのチームだけで価値を届けられるような独立した権限を持つ。 Enabling team は技術スペシャリストで構成される小さなチームで、 Stream-aligned team が低コストで進化を獲得できるまでの短期間サポートし、獲得後は別の Stream-aligned team のサポートをするのを繰り返す。 Complicated Subsystem team は画像処理や数学的知識のように複雑かつ専門的知識を要するサブシステムを Stream-aligned team から切り離し認知負荷を低減するためのチーム。 Platform team は社内プラットフォームを提供することで Stream-aligned team が下位レイヤを開発する必要性をへらし認知負荷を低減する。プラットフォームの対象はインフラやそれより上位レイヤのもの(API とかかな)も含み、単なる Wiki なこともある。 Stream-aligned team が基本となり、他のチームがサポートする。 Stream 指向が重要なのは変化を流れで捉えて継続的に適応するのが重要なため。 すごく分析されてて興味深かった。自分の境遇とは規模がまるで合致しないが、役割として Enabling や Platform 提供してるというのは小規模でもありそうやな。 インシデントの時のスウォーミング(一時的な組織化)はあれど、基本的に各チームが独立した権限で自律性を持って取り組むように仕向ける、というインセンティブ設計なんやろな。 Stream-aligned team がやりやすいよういだけ進めてるとバカが育つ気がするので、職能横断的な方が良いというのは team に技術力や専門性を持たせる目的もあるだろう。

2026-04-28, read count: 1, page: 95 ~ 135, pages read: 41

Part Ⅱ Chapter 6 。モノリスの例、つまりチームがモノリスになる条件のパターンを紹介。 またチームを分かつ自然な境界を、モノリス同様に石に例えて節理面と呼び(柱状節理なんかの節理)、その代表的なパターンについての紹介。 ここで紹介される、どういう依存関係でモノリスになるのか・どういう節理面が考えられるかはよく知られたものだと思う。 ここまでの本書のパターンだとそれらに名前を与えたのに意味があるんやろな。 モノリスの条件も摂理面も絶対に NG なパターンというのはなく、その組織とサービスの文脈においてフローを阻害するか・最適化できるかが重要な観点となる。 パターンとしては適用可能な条件を比較的明確に示してるけど、パターンを使う側がその状況を読みきれない可能性が高いというのは、どっかのパターンでも見た景色じゃないかな。 地理的な距離が節理になるというのは、デマルコ本や Pixar の本でもチームが一箇所に集まる爆発力みたいなものはずっと触れられてたから、あるのはわかる。 でもフルリモ勢としては節理だと切り分けられると中々厳しいものがあるな。偶々現状は 1 人チームなので節理面が問題にならないけど、ずっとそうじゃないだろうし。

2026-04-29, read count: 1, page: 136 ~ 157, pages read: 22

Part Ⅲ Chapter 7 。チーム同士の対話方法として 3 つのインタラクションモードを紹介。 コラボレーションは密な協力関係が革新や探索を早めコンテキストの共有もできるが、反面責任境界が曖昧になる。 X-as-a-Service は明確な責任境界を持つが革新や探索には劣る。また明確に設計されたチーム境界がなければできない。 ファシリテーションは謂わばコーチングなので、運用・構築のような通常の仕事を行わないチームが必要になる(Enabling team がそう)ため資源の余剰が必要。 4 つのタイプと 3 つのインタラクションモードで状況の変化に応じて適切な組み合わせを探り当てていく感じ。 インタラクションモードが習慣になるというくだりがあったが、何故習慣になるかよくわからなかった。インセンティブは多少触れられているが組織設計として強制されるからかな。そうは問屋が卸さんと思うが惰性がそうさせるのかな。 あと不確実性を減らすみたいな文脈があり、減るのは確かだろうがなくなりはしないので、それに対処するにはスウォーミングのような一時的な組織化を行うんかな。 TEAM OF TEAMS 的には不測の事態に対処できてこその現代的な組織と思うが、まずは矯正ギプスということかな。

2026-04-30, read count: 1, page: 158 ~ 186, pages read: 29

Part Ⅲ Chapter 8, 9 。絶えず変化を続けるチームタイプとインタラクションモードについて。 コラボレーションモードでの探索と適切なチーム節理面の発見・分離の繰り返し等。代表的なチーム分割のシグナル。コレで本書は終わり。途中から目が滑る感じがしてあんま理解できてないかもな。 でもなんとなく世間で人気なのがわかった。 DDD との親和性からも読者が方法論と受け取りそれに従っていけば良いんだという明確な道筋を見出せる点が好まれるのかな。 経営層や株主のような利益享受者が曖昧な活動を許容しにくいという特性から、説明責任や KPI を持つ経営層や中間管理職からしたら、ちいとぽは銀の弾丸に見えるんじゃないかな。 しかし、記載されたパターンとインタラクションモードの組み合わせを随時組み換えて組織の成長や市場の変化に適応していく必要があるのは本書でも触れられていて、静的構造だけで多分十分ではない。 パターンに従えば壊れにくい組織にはなるが、壊れにくさと変化への適応性は別物。更に本書が示す適応性獲得の方向性は兆候で駆動する進化であり、高い不確定性の中では仮説で駆動する進化に比べ後追いになるリスクがある。 本書が取り扱わない事前的な変化が必要な実践者は、何に気を払うべきなのかを悩むでしょうな。しらんけど。 わたしが好む組織論は、こういう静的構造と事後的な進化の話よりも、組織の動的な振る舞いと事前的な進化の話なんやろなと、今回理解した。

2026-05-01, read count: 1, page: 187 ~ 227, pages read: 41