チームトポロジー の商品レビュー

マシュー・スケルトン(著者),マニュエル・パイス(著者),原田騎郎(訳者),永瀬美穂(訳者),吉羽龍太郎(訳者)

2026/01/16

会社の輪読会用に再度読んだ。
社内のエンジニアの共通認識が作れたのでよかった。
昔初めて読んだ時にブログに書いていた。
https://zenn.dev/rescuenow/articles/93d354e50d19a1

2025/08/15

チームや組織の設計に、いわゆる「よい」ソフトウェア設計の考え方を適用して考えられる、というのが新しい視点でした。
各チームがチームAPIというインターフェイスを通じて協調的に・自律的に仕事を進めていく、と考えると、ソフトウェアシステムと類似点が多く面白い。認知負荷が高くなっているチームは「神クラス」的なものだと捉えると、確かに責務≒担当するドメインちゃんと分割しないとね、って考えやすい。
本書を通じて、ちょっとチームづくりに興味を持ちました。

2025/05/05

話の1/3も理解できなかった。
組織の作り方関連の入門書から理解すべきか

また、ありがちだが和訳した本は分かりづらいし、和訳ミスが目につく

テックイベントで紹介されたので手に取ったが
イマイチ得られるものがなかった、、

2024/10/18

1章では逆コンウェイ戦略についての重要性を述べ、
2章で4つのチームタイプ、3章では3つのインタラクションモードについて述べている。
総じて逆コンウェイ戦略とチームファーストについて説いていると思われる。
個人→チームに目を向けていく開発者にとって、
LeanとDevOpsの科学とならべてとってもよい書籍。
ぜひまた読み返したい。

2024/09/25

認知負荷に対処するため不要なコミュニケーションを制限するアプローチとして逆コンウェイ戦略や4つのチームタイプ、3つのインタラクションモードによる組織設計する方法の紹介。
認知負荷に焦点を当てるという取り組みを理解できたのがよかった。また、チームの状況に応じてインタラクションモードを変更し適応的に組織変更することが有効であると理解できたのがよかった。

https://thaim.hatenablog.jp/entry/2024/09/24/232625

2024/01/22

カタカナ語と抽象的な概念が多くやや掴みにくさはある。コンウェイの法則は、ソフトウェアと開発チームの関係性を指し示す概念で真を食っていると感じる。

セントラル方のアナリティクス組織に置き換えた時に3つのコラボレーション全てが当てはまるので、組織を最適化させる際には切り分けて考える必要がありそう。

① コラボレーション
② X as a Services
③ ファシリテーション
↓
①例：ビジネスパートナー活動・レポート作成
②例：tableauダッシュボード提供（作成ではなく
③例：セルフBI活動

2023/12/23

# 多方面からプロダクトに立ち向かうための、戦略的組織論

## 面白かったところ

- 組織とソフトウェアアーキテクチャは密接に関わり合っており、人こそがソフトウェアであり組織を良くも悪くもすることがわかった
- 自分が管轄外のプロダクトには適切な境界線（interface）を切って、異なる概念を持ち込まない・持ち込ませない制約があるとイイことを改めて学べた点

## 微妙だったところ

- 引用がとても多く、著者自身の熱い思いがあまりなかった点。チームトポロジーのフレームワークはすごいしやってみる価値はあるんだけど、イマイチ引き込まれれる何かがなかった。

## 感想

現場での課題図書として上がっていた一冊。なにもないところから著者の真意を汲み取ることは難しいだろうなとは思いつつ、現場での組織構成を擬えて見るとかなりイメージが進んだ。

人間一人の認知負荷にも限界があり、チームのそれにも限界がある。この前提を踏まえたうえで、自チームで担当すること・しないことのドメイン境界を切ってinterfaceでハーネスをかける。

「〇〇チームは▲▲機能の担当」という境界を　Package by Featureで区切る。多機能とやり取りするときは必ずInterfaceを切って、他チームとコミュニケーションを図る。

なるほど。今やっている僕らの軌跡はこの本からやってきたんだと腑に落ちた。

2023/08/07

近年のソフトウェア開発における組織のあるべき姿をシンプルに解説した良書。
4つのチームと3つのインタラクションモードという切り分け方は、実際の業務においても納得感があった。
一方で、このプラクティスを適用できる段階・できない段階の組織というものはそれぞれありそう。
本書に登場する単語は独特なものばかりで、概念を知らない人には伝わりづらい部分がある。
とはいえ、難解な概念は少なく、昨今の組織戦略の文脈では多く登場するのもあって、理解と咀嚼に時間を割く価値はあるなと感じた。

コミュニケーションパスの制限による開発速度の向上は実感としても感じるものがあるが、チーム間のコミュニケーションによって生まれていた何らかが生まれづらくなる懸念があるのではないかと感じた。
そういった部分を俯瞰的に見る役目はイネイブリングチームか、あるいはEM的な立場の人になるんだろうか。

2022/08/25

少し前に話題になって積読していたのですが、組織単位の課題発見をするヒントになるかと思い、読みました。チートポ。論旨としては、「チーム内外のコミュニケーションを最適化するように組織構造をつくり、逆コンウェイの法則によって設計もいいかんじにしよう」みたいなかんじ。組織構造として、ロールごとに4つのチームタイプを紹介しています。この手のエンジニアリング組織本は、論理の積み上げではなくて実情の課題をとく方策を提案するせいか、自分にはあまりうまく読めないです。結局、解こうとしている課題があまりわからないまま目が滑って途中で読むのをやめました。認知負荷を軽減するという視点は参考になりました。

2022/07/18

あまり解説されない職能横断型チームやこの10年のソフトウェア開発組織パターンがまとまった良書。ただ引用と独特な用語が多すぎて難しい