読んだ本
『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』
著：マシュー・スケルトン、マニュエル・パイス
訳：原田騎郎、永瀬美穂、吉羽龍太郎
実現したいこと
ソフトウェアシステムの素早く安定したデリバリー。
デリバリーを妨げる要因
コード、ドメイン、コミュニケーションなどの様々な複雑さから認知負荷が増加し、それが組織の認知容量を超えてしまうことによりパフォーマンスの低下を招いている。
しかし実際には（特に組織設計で）認知負荷について議論されることはほとんどない。
認知負荷とは、ワーキングメモリ（情報を一時的に保ちながら操作するための能力）に対する負荷。
チームトポロジーのアプローチ
複雑性をコントロールするために重要になる２つの設計、「ソフトウェアの設計」と「組織の設計」。
このうち「組織の設計」に取り組むことで認知負荷の解決を目指すのがチームトポロジーのアプローチ。
コンウェイの法則
"システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう"
メルヴィン・コンウェイ 『How Do Committees Invent?』
特に設計やデリバリーの問題を扱うシーンで見かけることが多いが、チームトポロジーでもこの法則を重要視しており、ソフトウェア設計を組織から独立したものと考えるのは根本的な間違いだと結論付けている。
チームファースト
チームトポロジーでは近年のソフトウェア開発において、ソフトウェアを開発して進化させていくには個人では継続不可能として、「チーム」に注目している。
チームの認知不可を軽減させ、チームやチーム連携のパフォーマンスを最大化させることを目指している。
４つのチームタイプと３つのインタラクションモード
チームの役割やコミュニケーションの曖昧さを減らすため、組織設計のテンプレートをたった４つのチームタイプと３つのインタラクションモードに限定している。
４つのチームタイプ
- ストリームアラインドチーム
- プラットフォームチーム
- イネイブリングチーム
- コンプリケイテッド・サブシステムチーム
価値のある単一の仕事のストリームを扱うストリームアラインドチームと、それを支援する３つのチーム。
３つのインタラクションモード
- コラボレーション
- X-as-a-Service
- ファシリテーション
４つのチームは、その都度適切なモードでインタラクションする。
組織設計を進化させる
ソフトウェアと同じく、組織設計も最初から正しいものができるわけではないし、状況は常に変化する。組織的センシングに投資することでそのきっかけを捉え、適切に修正していくことで、デリバリーを継続していくことが可能になる。
感想
仕事の規模が個人を超えて組織的になり始めた頃から、認知負荷が増大しているのを感じている。組織が拡大するについれて組織構造や労働環境の向上に着手することが多いが、それはあくまで一般的な組織についてのそれであり、ソフトウェア開発を扱う組織としてはそのプラス要素を覆して余りある。
コンウェイの法則については、個人的な経験からも、組織構造からくる意思決定は多いと感じるし、システムの境界付近は一際複雑になっていることが多い。
デリバリー速度増加の需要とそのために組織へのアプローチが必要な点は、GoogleのDORAチームのレポートなどからも見て取れる。
"当社の調査では、サービスやチーム間の細かな依存関係を解消することで、ITパフォーマンスを向上させることができることが分かっています。"
『Accelerate State of DevOps 2021』（DeepL翻訳）
このような複雑さの増加とスピードの要求が高まるなかで、チームトポロジーのようなアプローチを持って、ソフトウェア開発に適合する組織を設計していく必要を感じている。
（おまけ）最近読んだ書籍からコンウェイの法則に言及しているもの
"さらにコンウェイは、組織図が最初のシステムデザインをまず反映するが、そのデザインはほとんど正しくないに決まっている、とまで言っている。システムデザインが自由に変更できるものだと言うなら、組織も変更に対応できなくてはならない。"
フレデリック・P・ブルックス 『人月の神話』
"システム開発者は、コミュニケーションコストの坂道と同じようにシステムの構造を作っていくという行為が最も効率的な設計であると思ってしまいます。これが、「コンウェイの法則」という経験則が生まれる背景です。"
広木大地 『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリング』
「コンウェイの法則」はソフトウェア開発の原理・原則なのだろう。