概要

チーム指向の組織設計で開発組織の機能不全を解消する

想定読者

エンジニアリングマネージャー、開発組織の設計・改善に携わるエンジニアリングリード、組織課題に向き合うテックリード

こんな人には向いていない

• 個人の開発技術(コーディング・アーキテクチャ実装)のみを深めたい実装エンジニア
• チームトポロジーやコンウェイの法則をすでに実務で適用し組織設計の体系が整っているマネージャーには既知情報が多い
• 2〜3人の小規模チームで組織設計の複雑性がまだ顕在化していない段階のエンジニア

読了後にできるようになること

• 内部品質の低下・コミュニケーションコスト増大・フロー効率悪化につながる16のアンチパターンを識別し、自組織への当てはめができる
• チームを最小設計単位とする6つの原則を用いて、再現性のある組織設計の判断基準を言語化できる
• チームの機能と配備を決める7つのガイドラインを使い、チーム責務の境界を定義できる
• アジャイル・リーン・DevOps・チームトポロジー・コンウェイの法則を組織設計の文脈で統合的に解釈できる
• 組織のリファクタリング・リアーキテクティングのアプローチを段階的に計画できる

本書のキー概念(章解説)

• 第 1 章 チーム指向の組織設計 — 本書の基本概念を定義する章。組織設計をチーム単位で考える枠組みを最初に把握すると、以降の章が読みやすくなる
• 第 2 章 組織のパフォーマンスを蝕む問題から捉える組織設計 — 現場の「うまくいかない」状況を類型化する章。自組織の課題照合に使える
• 第 3 章 内部品質を悪化させる組織設計アンチパターン — 技術的負債の根源が組織構造にある、という視点を具体的に展開。開発速度の低下に悩むマネージャーに直結する章
• 第 4 章 コミュニケーションコストとフロー効率を悪化させる組織設計アンチパターン — 依存関係の増大・待ち時間・意思決定の遅延をアンチパターンとして体系化。DevOps観点の読者は本章と第1章から入るのが効率的
• 第 5 章 チーム中心の組織作りのためのチーム設計の原則 — 6原則が本書の処方箋。第2〜4章で問題を把握した後に読むと腹落ちしやすい
• 第 6 章 チームの機能と配備を考えるためのチーム責務定義ガイドライン — 7つのガイドラインを実務に当てはめる章。組織再編を検討中のマネージャーは本章を実務ワークシートとして使える
• 第 7 章 組織のリファクタリング・リアーキテクティング — 段階的な移行アプローチを扱う。現行組織を壊さずに改善を進めるうえで最も実務的な章

ハイライト

• チームという単位をないがしろにする組織は、うまく機能しません。日々の業務フローが複雑で入り組み、非効率になりがちになります。たとえプロジェクトが成功したとしても、再現性がありません。(本書の問題意識の核心。「成功しても再現性がない」という指摘が、読者に自組織の状態を内省させる起点になっている)

編集メモ

Qiita言及0件・likes合計0件・楽天ランキング情報なし。2025年8月刊行の新刊であり外部シグナル蓄積前の段階。書誌の内容構成は実務的な体系を持つが、現時点での定量シグナルは存在しない

読む前に押さえておきたいこと

• ソフトウェア開発チームでのリード・マネジメント経験(複数チームの調整や採用・評価を担った経験があると抽象論が具体化しやすい)
• アジャイル・スクラムの基本概念(本書は実施手順ではなく組織設計の文脈で言及するため、用語理解が前提になる)
• コンウェイの法則の概要(説明はあるが、実際のシステム設計で意識した経験があると本書の主張が深く刺さる)

学習のコツ

• 第2〜4章のアンチパターン群は自組織の現状診断として使える。読み進めながら「自社に当てはまるか」をメモしておくと、第5〜6章の原則・ガイドラインを即座に実務文脈に接続できる
• チームトポロジーを先に読んでいる場合、本書はその日本の開発組織への適用版として読むと理解が速い。逆に本書が初読であれば、第1章の概念整理を丁寧に読んでから進むとよい
• 第7章は「今すぐ組織再編はできない」という状況でも読む価値がある。漸進的な改善アプローチが示されており、現行組織の制約の中で動けるレバーを把握できる