目的地
「チームトポロジー」に至る道筋
この本にたどり着くために、先に読んでおきたい本を依存関係から逆算しました。基礎から順に並んでいます。
ここまでの道筋（10冊）
なぜ先に読むのか: 命名や関数分割といった可読性の基礎を押さえたら、それらを「なぜそうするのか」の原則へ束ねる段階に進む。クリーンコードは個別テクニックを職業倫理と設計原則の体系へと接続する。
なぜ先に読むのか: 達人の心構え（割れた窓を放置しない・DRY を徹底する）を得たら、それを関数やクラス単位の具体的な品質基準へ落とし込む。クリーンコードは「良いコードとは何か」を原則と実例で体系化する。
なぜ先に読むのか: 関数やクラス単位の品質が身についたら、次はシステム全体の依存の向きと境界を設計する視点へ広げる。クリーンアーキテクチャは詳細を外側へ追いやり、ビジネスルールを中心に据える原則を与える。
なぜ先に読むのか: システム内部の境界を設計できるようになったら、その境界をプロセス＝サービスへ分割すべきかという次の判断へ進む。Monolith to Microservices は「まずモノリスから」という現実的な指針のもと、分割の動機・進め方・落とし穴を体系立てる。
なぜ先に読むのか: アーキテクチャ特性とトレードオフの語彙を得たら、その判断を分散システムという具体に適用する。マイクロサービスは独立デプロイと自律性のために、あえて結合を切る設計を要求する。
なぜ先に読むのか: マイクロサービスの原則を理解したら、既存モノリスからの現実的な移行戦略へ進む。多くの成功例はモノリスから段階的に切り出しており、最初から分散させない判断も含めて学ぶ。
なぜ先に読むのか: 境界づけられたコンテキストを引けるようになったら、その境界をチーム編成へ写像する。コンテキストとチームを一致させると認知負荷が下がり、価値の流れが速くなる。
なぜ先に読むのか: サービスを切り出す移行を進めると、分割の単位がチームの認知負荷と一致しているかが問われる。逆コンウェイ戦略で、望むアーキテクチャに合わせてチームを編成し直す。
なぜ先に読むのか: 『The Phoenix Project』は IT 運用の混乱を小説仕立てで追体験させ、なぜ DevOps が必要かを腹落ちさせる導入書。問題意識を得たら、同じ Gene Kim らによる『The DevOps ハンドブック』でその解決策を体系的な実践技法として学ぶのが王道の流れ。
なぜ先に読むのか: DevOps を技術プラクティスとして導入しても、組織構造が縦割りのままでは速い流れは生まれない。Skelton & Pais『チームトポロジー』は4つのチームタイプとインタラクションモードでコンウェイの法則を逆手に取る組織設計を示し、技術と組織の両輪を揃える。