わかりやすいチームトポロジーまとめ
はじめに
フロントエンドエンジニアの谷（@high_g_engineer）です。
本記事に目を通されている皆様は、「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」という書籍をご存知でしょうか？
この書籍は、ソフトウェアの価値提供をすばやく行う為の組織設計について記された内容になっており、ITエンジニア本大賞 2023ビジネス書部門の特別賞を受賞しました。
組織設計というと、経営層やマネージャー層が意識するもので、現場のエンジニアやデザイナーなどは関係ない様に思われがちですが、
チームトポロジーは、現場からボトムアップで組織を変えていくノウハウが詰まっています。
本記事は、チームトポロジーの書籍内容の一部を引用しつつ、自分流に噛み砕きながら、本書を読んでない人にもわかりやすく要点を伝えることを目指した内容になっています。
ソフトウェア開発組織の生産性
効率良く稼げる状態にするには
改めて、ソフトウェア開発を行う組織が何の為に新規のサービスを開発したり、既存のサービスを保守・運用したりをしているかを考えると、ユーザーに価値を提供し、その対価を得る為ですよね。
ソフトウェアを開発・保守・運用する上で、構成するシステムアーキテクチャがシンプルであれば、現場のエンジニアやデザイナーは、少ない労力で素早くアップデートを行うことができます。
開発者体験が良いと、ユーザーへの価値提供が高速になり、利益を生み出す機会が増え、必然的に効率良く稼げるような生産性が高い状態が生み出しやすい訳です。
なぜ効率良く稼げる状態にできないのか
生産性の高い状態が、どんな組織でも簡単に生み出せていたら誰も苦労しないですよね。
長年運用されているソフトウェアのアーキテクチャは、デザインパターンや時代ごとのノウハウを積み重ね、複雑度を増した状態になりがちです。
システムアーキテクチャが複雑であればある程、開発者体験が悪くなり、それに伴ってユーザーへの価値提供が遅くなり、利益を生み出す機会が減ることで、効率良く稼げない状態になってしまいます。
シンプルに考えるなら、開発者体験が良いシステムアーキテクチャをずっと保ち続ければ、効率よく稼げる状態が作れるということになります。
システムアーキテクチャと組織構造
開発者体験が良いシステムアーキテクチャが作ることができれば、生産性が高い状態が作れるということで話が終了したかと思いきや、ここからが本題です。
一般的に、システムアーキテクチャを構築する際、強い力学が働きます。
それはコンウェイの法則と呼ばれるものです。
コンウェイの法則
システム（広義に定義）を設計するあらゆる組織は、組織のコミュニケーション構造をコピーした構造を持つ設計を生み出す。
例えば、開発組織の中に1つの大きなエンジニアリングチームが存在した場合、1つの大きなモジュールの中にたくさんの機能を内包したアーキテクチャが自然と構築されます。
ドメインごとにチームが分かれていれば、チーム数に応じたマイクロサービスアーキテクチャが自然と構築されるといった感じです。
さらに細かく考えるなら、バックエンドエンジニア中心組織であれば、LaravelやRails、フロントエンドエンジニア中心組織であれば、Next.jsやAstroなどのフレームワークが選定されるといった具合で技術選定にも影響を及ぼすとも考えられます。
システムアーキテクチャは組織構造の影響を多大に受け、自然と組織構造をそっくりそのままコピーした形になるという同形性を示す証拠が増えてきています。
つまり、コンウェイの法則の強い力学の影響下では、シンプルで最適なシステムアーキテクチャを生み出す為には、シンプルで最適な組織構造を作ることがマストになってきます。
組織図の問題
ほとんどの企業では、チームや人を見渡す為に「組織図」が存在します。
これは、コンプライアンス遵守を円滑に行う為の指標としては役に立ちます。
しかし、実際のソフトウェア開発では、異なる部署とのコラボレーションが往々にして発生する為、組織図通りに動くことは非効率を極めます。
例えば、「◯◯の承認を得る為には、C部署のリーダーからの承認が必要だが、自分はA部署の一社員。A部署のリーダーにお伺いを立て、リーダー会議に議題を上げていただき、リーダー同士の話し合いがあって・・・」といった律儀な組織図通りのやりとりが発生した場合、コミュニケーションパスが複雑に絡み合っていて非効率を極めます。
この場合、C部署のリーダーと直接話せた方が、コミュニケーションパスがシンプルで何倍も効率的です。
上記は極端な一例ですが、実際に個人が最速で仕事を終わらせるまでに発生するコミュニケーションパスは、組織図が表すものとは異なることが往々にしてあります。
ビジネスや技術の領域が急激に進化する昨今、こういった非効率なことを行っていた場合、競合に勝てないどころか、自身のプロダクトを破滅に向かわせます。
組織図やマトリクスマネジメントといった単一で静的な組織構造の利用は効果的なアウトカムが生み出せないことが徐々に明らかになってきています。
組織を改善する為のチームファースト思考
チームトポロジーでは、上記の様な組織問題と向き合う為に、組織の最小単位をチームとし、徹底してチームを良くする為のノウハウが紹介されています。
なぜ、個人ではなくチームが最小単位となっているかについて、本書に以下の様に記載があります。
Googleが自分たちのチームについて行った研究によれば、チームに誰がいるかということより、チームの力学が重要なことがわかった。
特にパフォーマンスを計測するという点では、個人よりチームがはるかに重要になる。効果的にソフトウェアを提供するには、まずチームから始めなければいけない。
近年のソフトウェア開発では、GoogleだけでなくAmazonやその他の著名人が、チームを最適化することが重要と意見を一致させています。
では具体的に、どういったアプローチを取ればよいのか。
本書では、チームファースト思考という内容で紹介があります。
自分が重要だと感じた箇所を端的にまとめていますが、他にも重要な内容が本書に書かれている為、ここは本書を読んだほうが絶対に良いです。
長続きする小さなチームを基準とする
チームの人数を5〜9人までとする
チームとチームがいる環境を安定させる（3ヶ月はかかる）
チームが単一ソフトウェアのオーナーシップを持つ
チームのパフォーマンスが安定してきたのにメンバーを他のチームにアサインし直すのは、ほぼ価値がない
チームファーストのマインドセットをメンバー全員が育む
メンバーがお互いにチームゴールへの集中を促すこと
自分の新たな仕事を始める前に、他のメンバーの障害を取り除くのを助けること
新しく参加したメンバー、経験の少ないメンバーをメンタリングすること
議論に勝敗をつけようとするのをやめ、良い代替案の探索に合意すること
チーム内の多様性を受け入れる（多様なバックグラウンドを持つメンバーからなるチームの方がより早く創造的なソリューションを生み出す）
チームの認知負荷が高くなり過ぎないようにする
責任範囲を制限し、チームに見合ったものにする
チームが扱うドメインの種類を制限する
チームやメンバーの認知負荷を適切にする（チームを最適化することで、他のチームとの関わり方にまで良い波及効果がある）
信頼、認知、学習のためのチーム活動を促進する
チームや個人がお互いにコミュニケーションしながら学ぶための時間と場所を明示的に確保する
チームインタラクションを助けるために物理的、仮想的な環境を明示的に設計する
プラクティスに日々投資し、技術力を高める
これらの意識を徹底し、実際に行動することで最適なチームを作ることができる為、組織を改善する第一歩となります。
後述する4つのチームタイプや3つのチームインタラクションモードなども大切ですが、
個人的には、チームファースト思考の理解と実行を徹底することが最も重要だと思っています。
4つのチームタイプ
適切な認知負荷の設定ができていると、自然とチームの形が見えてきます。
多くの組織には、様々な種類のチームが存在しますが、
チームトポロジーにおいて、ソフトウェア開発・運用で必要なチームの種類は、たった4つのみです。
運用チーム？サポートチーム？必要ありません。すべて4つのチームタイプのみで完結できます。
4つのチームタイプのみに制限することで、チームの役割の曖昧さを減らし、効果的な組織設計が出来るようになります。
以下でそれぞれのチームタイプについて記述します。
ストリームアラインドチーム
ユーザーに直接的な価値提供を行うチーム
チームで設計、実装、UX、テストQA、分析など全ての責任を持つ
ドメインごとや大きめの機能ごとに存在
組織の根幹となるチームタイプ
他の全てのチームタイプはストリームアラインドを支援する為に存在
ストリームとは、1つのドメインに沿った仕事の流れのことです。
ストリームアラインドチームとは、価値のある単一のストリームで働くチームのことです。
従来のチーム設計では、開発チーム、QAチーム、運用チームなどが縦割りで別々に存在し、それぞれのフェーズに応じて、ドメインを扱うチームが切り替わるスタイルが多いですが、このスタイルではソフトウェアの素早い価値提供ができなかったり、それぞれのフェーズから学び取れることを阻害したりといったことが発生します。
設計、開発、テスト、運用、分析などを同一のチームで行うことで、本番システムから情報を得ながら、ソフトウェアを素早く改善し、ユーザーへの対応力が高めながら各フェーズを理解して学びを深める事ができます。
イネイブリングチーム
特定の技術領域のスペシャリストで構成されたチーム
ストリームアラインドチームがその時点で持っていない必要な能力を獲得することを助ける
ストリームアラインドチームを横断的に支援する
適切なツール、プラクティス、フレームワークなどの調査を行い、正しい情報に基づく提案を行う
大前提として、ストリームアラインドチーム自身が学習するチームであることが大切ですが、ユーザーへの素早い価値提供と新しいスキルの学習/習得を同時に行うことは認知負荷が高い状態になりやすいです。
ストリームアラインドチームが多大な労力をかけずに、効率よく能力を獲得しながら進化するために必要なのがイネイブリングチームです。
注意すべきは、イネイブリングチームが勝手な判断で技術を押しつけないようにし、組織全体の技術的な制約を守ることも必要です。
イネイブリングチームのゴールは、ソリューションの提供ではなく、ストリームアラインドチームの自立性を高めることです。
コンプリケイテッド・サブシステムチーム
スペシャリストの知識が必要となるパーツやサブシステムを開発、保守する責任を持つチーム
ストリームアラインドチームでは対応できないような複雑なサブシステムの開発を担当
サブシステムのイメージは、機械学習、顔認識エンジン、数理モデルなど
このチームは、他チームと比べると発生頻度があまり高くありません。
このチームが作られるのは、ストリームアラインドチームでは対応できないような、スペシャリストの知識が必要なサブシステム開発が発生する場合のみです。
このチームもストリームアラインドチームの認知負荷を下げる為に存在します。
プラットフォームチーム
ストリームアラインドチームが必要とするインフラ、ツールなどの内部サービスを提供するチーム
プラットフォームチームの役割のゴールもストリームアラインドチームの認知負荷を下げることです。
プラットフォームと聞くと、サービスの基盤を開発するチームと勘違いしてしまいそうですが、必要とされる内部サービスを提供する為のチームなので、インフラを扱ったりはしますが、ツールや共通利用するサービスの提供を行うことがメインのチームです。
少し話がそれますが、実際にプラットフォームを開発する場合は、プラットフォーム開発プロジェクトの中にいくつかのストリームアラインドチームが存在し、それを補助するコンプリケイテッド・サブシステムチームとプラットフォームチームが存在するといった形になります。
プラットフォーム開発とプラットフォームチームの意味を文面だけで間違えて捉えないように注意が必要です。
ここまでのまとめ
ユーザ価値を届ける為にストリームアラインドチームが存在し、
ストリームアラインドチームの認知負荷を下げる為にイネイブリングチーム、コンプリケイテッド・サブシステムチーム、プラットフォームチームが存在します。
チームファースト思考が根幹にあることで、チームの責務が適切になり、4つのチームタイプに切り分けることで、認知負荷を下げながら、ユーザーへの高速な価値提供とソフトウェア開発の学びを最大限に得ることができます。
最後に、4つのチームタイプを最大限に活用する為の3つのチームインタラクションモードについてのまとめです。
3つのチームインタラクションモード
上記で紹介した4つのチームタイプについて、これを元にチームをいじってパターンに合わせるだけでは、高い効果は得られません。
コミュニケーションを活発化させる為に、チーム同士のインタラクションを無闇に増やすことも避けなければいけません。
これらを踏まえて、チームインタラクションモードを活用し、チーム間のインタラクションを適切に行うことで、それぞれのチームを最大限活用することができます。
コラボレーションモード
概要
他のチームと密接に協力して作業するモード
境界を曖昧にし、イノベーションと素早い探索の原動力を得る
長期間の利用は避ける
メリット
素早いイノベーションと探索が可能
デメリット
コラボレーションの間は認知負荷が増大し、生産量が減る
制約
1つのチームがコラボレーションモードを利用するのは最大1チームまで
1つのチームが同時に2つ以上のチームとコラボレーションモードを使用してはいけない
例
コンプリケイテッド・サブシステムチームと共同作業するストリームアラインドチーム
プラットフォームチームと共同作業するストリームアラインドチーム
X-as-a-Service
概要
チーム間の接続は最小限で何かを利用または提供するモード
コードライブラリ、デザインシステムを、プラットフォームを提供している様なチームとの接続に適している
提供するチームと利用するチームはお互いのチームの詳細を知らなくても良い
メリット
明確な責任協会のある明確なオーナーシップ
チーム間の詳細やコンテキスト共有が減る為、認知負荷が制限される
デメリット
境界や提供されるAPIが効果的でなければ、フローが適切でなくなる危険性
制限
1つのチームが同時並行で多数のチームとX-as-a-Serviceインタラクションを使う想定が必要
例
プラットフォームチームのPaaSを利用するストリームアラインドチーム、コンプリケイテッド・サブシステムチーム
コンプリケイテッドサブシステムチームが提供するコンポーネントやライブラリを使用するストリームアラインドチーム、コンプリケイテッド・サブシステムチーム
ファシリテーションモード
概要
イネイブリングチームの主な遂行モード
他チームをファシリテーションまたは、コーチングすることで生産性と有効性を高める
他チームがより早く学習し、新しい技術をより理解し、チーム全体に共通する問題や障害を早く取り除けるようにする
メリット
ストリームアラインドチームの障害を取り除くフローを円滑化する
コンポーネント、プラットフォームにおけるギャップ、整合性の取れていない能力や機能の検出
デメリット
構築や運用に従事しない経験豊富なスタッフが必要
ファシリテーションモードに慣れていないチームの場合、おせっかいで奇妙な行動の様に思えてしまう
制限
何チームかと同時にファシリテーションモードを使用する想定が必要
例
ストリームアラインドチーム、コンプリケイテッド・サブシステムチーム、プラットフォームチームを支援するイネイブリングチーム
ストリームアラインドチームを支援するストリームアラインドチーム
ここまでのまとめ
4つのチームタイプを最適に作用させる為には、3つのチームインタラクションをそれぞれのチームが意識する必要があります。
適材適所でチーム間のインタラクションを切り替えることで、チーム同士を適切に接続することができ、過不足がないチーム間のコミュニケーションや働き方が実現可能です。
伝わるかはわからないのですが、NARUTOで例えると、4つのチームタイプは螺旋丸です。それだけで強力で、ある程度の場面で対応できます。
そして、これに3つのチームインタラクションを追加することで、螺旋手裏剣になります。さらに強力で、複雑な課題に対して速度を上げて取り組むことができます。
まとめ
ソフトウェアの開発・運用・保守の生産性を高めるには、良いシステムアーキテクチャが重要
システムアーキテクチャは組織構造の影響を多大に受ける為、
良いシステムアーキテクチャを作るためには最適な組織構造が必要最適な組織構造をつくるには、チームを徹底的に良くする
チームを徹底的に良くする為には、組織内にいる全メンバーがチームファースト思考をインプットする
最適なチームを作り、4つのチームタイプと3つのチームインタラクションモードをかけ合わせることで、最適なチーム運用を行うことが可能
流動的で柔軟なチーム構造をもとにした組織設計をチームトポロジーと呼ぶ
全てを一気に始める必要はなく、まずは今いるチームに対してチームファーストをインプットするところから始める
この記事が気に入ったらサポートをしてみませんか？