「チームトポロジー」を読んだ
Twitterで話題になっていた組織設計の本、『チームトポロジー』を読んでみた。組織設計についての学びがいくつか得られた。
どんな本か
『コンウェイの法則』を中心に、激しい変化にさらされる現代のソフトウェア開発に適した組織設計を解説した本。多くの組織に適用できる考え方を説いており、4つのチームタイプと3つのインタラクションモードの組み合わせで組織とシステムの問題を解決するとしている。膨大な論文や書籍を参考資料として書かれているのも特徴的。
2021年12月10日発行。日本能率協会マネジメントセンター。著者はソフトウェア開発に関わるコンサルタントのマシュー・スケルトン氏とマニュエル・パイス氏。訳者はスクラム界隈で有名な原田騎郎、永瀬美穂、吉羽龍太郎の3氏。
要約
本書で言われている事を要約するとこのような感じと受け取った。
コンウェイの法則と認知負荷を念頭に置き、4つのチームタイプと3つのインタラクションモードを使い分け、常に現状に適応する組織設計をすべし。
以降は、特に重要なキーワードと思われるものを個別で要約していく。
コンウェイの法則
多くの組織には組織図が存在するが、単一の組織図通りに仕事を分割するのは困難である。レポートラインに沿わないコミュニケーションやコラボレーションが必要になる。ソフトウェア開発ではこの問題が顕著である。組織構造を考える際にはコンウェイの法則を意識する。
コンウェイの法則とは、『システム設計は組織構造を反映させたものになる』という考え方。単一のチームでシステムの面倒を見続けようとすればモノリスなシステムに育っていく。ここに働く力を同形力と呼ぶ。
この同形力を逆手に取ったのが逆コンウェイの法則。アーキテクチャが組織構造を反映するなら、まず目指すべきアーキテクチャに合った組織構造にすることで、アーキテクチャを組織構造に従わせる。
認知負荷
認知負荷とは、業務上処理する情報の量や種類によってチームまたはメンバの認知にかかる負荷。例えば、覚えるべきルールが多い、メンテナンス対象のコードや仕様が複雑で膨大である、業務中のコンテキストスイッチが多い、など。
認知負荷について議論される機会はとても少なく、組織設計において考慮される機会もまた少ない。だが、認知負荷が高まることによりチームの価値提供速度は確実に落ちるため、組織設計においてはチームの認知負荷を低く保つことが重要である。
チームファースト思考
現代の複雑なソフトウェア開発において、チームなくしてシステムの進化は成し遂げられない。加えて、チームが偉業を成し遂げるのは個々の資質だけでなく、メンバがまとまったひとつの生命体となるからである。
チームファースト思考では、チーム内の信頼の最大化と、認知負荷を少なく保つことを意識する。
チームの信頼を維持するためには『ダンバー数』を元に組織のメンバ数を制限する。
5: 親密さとワーキングメモリを維持できる人数
15: メンバ相互で深い信頼を維持できる人数
50: メンバ相互で信頼を維持できる人数
150: メンバ相互で他人の能力を覚えられる人数
最小単位のチームは5〜9人が適している。
4つのチームタイプ
本書が提唱する4つの基本的なチームタイプ。
- ストリームアラインドチーム
- イネイブリングチーム
- コンプリケイテッド・サブシステムチーム
- プラットフォームチーム
ストリームアラインドチーム
モダンなソフトウェア開発組織においては、ほとんどのチームがこのタイプに該当する。4つの中でも最も基本のタイプと考えて良い。
ストリームとはビジネスドメインの仕事の流れ。価値のある単一の仕事のストリームに沿って動く。流れに注目して変化を捉えることが重要。
素早いデリバリを実現するため、自チームだけでリリースできる権限を持つ自己完結型の組織。
イネイブリングチーム
雑に言うと技術コンサルチーム。
特定の技術ドメイン、能力のギャップ埋め、技術調査、新規技術導入など、ストリームアラインドチームが扱わない領域のサポートを専門とする。
ストリームアラインドチームが通常開発をしながら技術調査や新規技術導入を行うのはコストがかかる為、専門のチームにて担当する。
コンプリケイテッド・サブシステムチーム
システム、プロダクトの中でも特定の専門知識を必要とする開発を担当するチーム。ストリームアラインドチームの認知負荷軽減の為に立ち上げる。
例えば、高度な数学的知識を必要とするサブシステムがあったとして、ストリームアラインドチームのメンバがビジネスドメインの知識に加えて数学的知識を求められるのは認知負荷が高い。専門知識が必要な機能をサブシステムに切り出して専任チームに任せる。
プラットフォームチーム
一般的なインフラストラクチャの拡張版(という認識を持った)。ストリームアラインドチームが、下位レイヤのサービスを開発、維持する必要性を無くすことで認知負荷軽減を目指すチーム。
インフラストラクチャに加えて、システム内で共通利用される機能やAPIを担当する。
3つのインタラクションモード
チームタイプに加えて、チーム間のインタラクションを3つ定義している。場合に応じてインタラクションモードを選んで行動する。インタラクションモードを意識しない共同作業は不明瞭な責任を生み、軋轢に繋がる。
- コラボレーション
- XaaS(X-as-a-Service)
- ファシリテーション
コラボレーション
別チームと一緒に仕事をする。最もコストが高いがイノベーションが生まれやすく、課題感も明確になりやすい。一方で責任範囲が曖昧になりやすい。目的を達成するまでの取り組みであり、永続的にとるモードではない。
XaaS
別チームの業務をサービスとして利用する。
依頼書を作って作業をお願いしたり、社内APIを通じて機能提供してもらうイメージ。サービスとして利用する業務は相手の責任範囲となるため、オーナーシップが明確になる。
コラボレーションモードで協働することでお互いの業務における最適な境界を見つけ出し、その後はXaaSとして関わるようになっていく流れが理想的。
ファシリテーション
スポットで一定期間だけ育成などの支援をしてもらう。技術コーチに入ってもらうイメージ。こちらも永続的な取り組みではなく、チームが必要なスキルやノウハウを身に付けたら解消する。
チームタイプとインタラクションモードの組み合わせ
4タイプのチームがすべてのインタラクションモードで動くかと言うとそうではなく、基本となるインタラクションモードが存在する。
イネイブリングチームはファシリテーションモードで関わることが典型的。コンプリケイテッド・サブシステムチームとプラットフォームチームはXaaSモードでストリームアラインドチームと関わるのが典型的なパターンである。
典型となるインタラクションモードに応じて、チームに求められる専門知識も異なる。ファシリテーションモードを主とするイネイブリングチームには、メンタリングやファシリテーションを得意とするメンバが求められる。プラットフォームチームにはプロダクトマネジメントやサービスマネジメントの知識が必要。
所感
難しい本だった。組織設計について語られているけど、システムアーキテクチャの書籍を読んでいるかのような気になる。ソフトウェア開発におけるチームやコラボレーションのあり方を極限まで抽象化した結果だと思う。ただ、難しいは難しいけど重要な概念を繰り返し説明してくれるので、CHAPTER後半になる頃には話に付いていけるようになっていて優しさを感じた。
今までチームの括りをフロントエンド、バックエンド、インフラ、SREというような分け方でしか考えたことがなかったので、新たな視点を得られたのは大きい。
また、チームのタイプ以上にインタラクションを3モードに分ける考え方は目から鱗だった。組織設計はどのようにチーム分けするかに目が行きがちだけど、別チームとどのように関係するかも同じくらい重要なのは確か。CHAPTER1で触れられていた「組織図通りにコミュニケーションは行われない」を考えると、組織図に現れてこないインタラクションにも目を向けておく必要があるのも納得できる。
インタラクションに関連して、ドキュメントやコミュニケーションツールを『チームAPI』として考えるのも興味深かった。他チームのリポジトリを覗いた時の理解しやすさは、API使うときのドキュメントを見るのに似ている。
今後の他チームとのコラボレーションや、チーム拡張の際には本書の考え方を取り入れることもありそう。