「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」を読んだ

はじめに

最近ストリームアラインドチームやイネイブリングチームなどを聞くことがよくあり、きちんと整理しようと思い「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」を読みました。 備忘録として印象に残ったことや感想を書いてみようと思います。

基本的に個人的な解釈・感想です、間違っていたらすみません 🙇‍♂️

Part1 - デリバリーの手段としてのチーム

最初のパートではコンウェイの法則¹に基づいて展開されていきます。 ここで初めて

• ストリームアラインドチーム
• イネイブリングチーム
• コンプリケイテッド・サブシステムチーム
• プラットフォームチーム

が出てきます。

初めに知的労働組織の成功の鍵は、非公式構造と価値創造構造のインタラクションにあるとされます。 公式な構造、非公式な構造、価値創造構造は本書²の中では以下のように説明されていました。

• 公式な構造（組織図）: コンプライアンス遵守を円滑にする
• 非公式な構造: 個人間の「影響力の領域」
• 価値創造構造: 個人間やチーム間の能力に基づいて、実際にどう仕事を終わらせるか

実際、公式な構造というのは何らかをエスカレーションするなど業務上役に立つことは多くありますが、ことソフトウェアのデリバリーにおけるコミュニケーションの構造とは確かに一致しません。 非公式な構造と価値創造構造のインタラクションとはすなわち人とチームのインタラクションと説明されていました。 影響力を持つ個人がチームに対して良い影響をもたらす場面には何度も立ち会ってきた実感がありますし、本書におけるチームの構造も相まってチーム内外の信頼関係を育むことは納得感があります。

組織的な編成などの決定がソフトウェアに対して力学を働かせるということ、逆にそれを利用してコミュニケーションパスを設計するということがこれから展開されていきます。 認知負荷を制限し、チームファーストのアプローチを適用し、組織が必要に応じたチーム間のインタラクションを誘発し、オーバーヘッドを見つけられるようにするというのがチームトポロジーのゴールとされました。

特にチームファーストのアプローチという点が興味深かったです。 人間が安定した人間関係を維持できる認知的上限の人数としてダンバー数に言及し、チーム内の信頼関係を最大化するためにチームメンバーの数を制限するとされていました。 特にダンバー数に関しては知らない概念でしたが、たくさんのメンバーと信頼関係を築くのは時間がかかるというのは当然であり、チームを構成した上で早くチームのパフォーマンスを最大化するためには、人数を抑えることが最も適切であるというのは理解できます。 どの程度の人数が信頼関係を維持できる閾値なのかの根拠があるのは組織を編成する上で説得力があります。 チーム内の信頼関係というのがとても重要視されていて、個人ではなくチームに報いること、メンバーはチームファーストのマインドセットを持つ必要があることについて言及されています。

印象に残っているのはチームの安定とメンバーの固定は別だということです。 直感には反する気がしますが、チームメンバー全員がチームファーストでチームのケイパビリティを高め続けるのであれば、属人化せずチームメンバーが変わったとしても新規メンバーへの投資というのは行われ続けるでしょう。 責任や能力に偏りのあるチームだと、メンバーの異動で不安定になってしまうのはあるあるだと思います。 自分もそうですが、チームを構成したとしても何らかのプロダクトの成功へ個人として意識が依ってしまうと思います。 チームファーストでチームとして足並みを揃えてプロダクトの成功へ向き合うことが、チームの安定、そしてプロダクトの成功を引き出すのだろうと理解しました。

最小単位としてのチームが確立できると、次はチーム間をどのようにコラボレーションさせていくのかということについて言及されます。 チームの認知容量に合わせて責任範囲を制限し、チーム間でのインタラクションの形を定義するということです。 ここでもチームの認知容量とソフトウェアのサブセットの境界を合わせるとされていて、一貫してコンウェイの法則を意識させられます。 チームファーストでソフトウェアを設計する（=チームの認知負荷を制限にあった形で設計する）ことはかなり難易度が高いなと感じました。 しかし、ソフトウェア設計の引き出しを増やしていくと自然と組織設計の選択肢も増えるというのは、マネジメント側へのキャリア形成も可能なのではないかと考えていて、技術とマネジメントは分断されていないことにある種の安心感を覚えています。

Part2 - フローを機能させるチームトポロジー

次は、Part1で紹介程度に出てきていた

• ストリームアラインドチーム
• イネイブリングチーム
• コンプリケイテッド・サブシステムチーム
• プラットフォームチーム

について詳細に説明されるパートです。

まずストリームについて定義する必要があります。 本書の中では、「ストリームとは、ビジネスドメインや組織の能力に沿った仕事の継続的な流れのことだ」³とされています。

ストリームアラインドチームとはこのストリームにそって稼働するチームのことです。 つまりは、ストリームアラインドチームがプロダクトの根幹となるチームだと理解しました。

他のチームは適切なタイミングで、適切な方法でサポートすることでストリームアラインドチームの認知負荷が増えないように働きかけます。

イネイブリングチームは特定のドメインのスペシャリストで構成されるチームで、ストリームアラインドチームが多大な労力をかけずに新たな能力を獲得するのを助けるように振る舞います。 Enabling SREと言われたりするチームもこのイネイブリングチームのひとつでストリームアラインドチームがSREのプラクティスや信頼性にコミットできるように動くチームですね。

コンプリケイテッド・サブシステムチームは、「システムの中でもスペシャリストの知識が必要となるパーツを開発・保守する責任を持つ」⁴と説明されています。 これだけ読んだ時はイネイブリングチームとは違わないのではないかと感じたのですが、ストリームアラインドチームと関わる目的が異なります。 イネイブリングチームはストリームアラインドチームが新たな能力を獲得するために短期間にやりとりを行います。 ストリームアラインドチームの問題を解決するためではなく、チームの進化に寄与するためコラボレーションを行うということです。 対して、コンプリケイテッド・サブシステムチームはストリームアラインドチーム単体で開発した場合よりも認知負荷を抑えてデリバリーを加速させることが目的です。 そのため密接にコラボレーションを行うのは開発中やまだサブシステムが安定していない期間です。 ただ、保守も行うためストリームアラインドチームのニーズに合わせて適切なものをデリバリーする必要があります。

プラットフォームチームは、ストリームアラインドチームが下位のサービスを開発する必要をなくし認知負荷を下げるためのチームです。 ここで言われているのはプラットフォームはプロダクトであり、プラットフォームを利用するストリームアラインドチームはプラットフォームチームにとって顧客であるということです。 これはプラットフォームエンジニアリングを推進する文脈でもよく聞く考え方ですね。

4つの基本的なチームタイプについて理解すると、既存のチームを基本的なチームタイプへと変換することができるはずです。 4つの基本的なチームタイプに既存のチームを変換するだけでもほとんどの組織では大きな効果が得られるとされています。⁵ 基本的なチームタイプへ置き換えるだけでも、各チームが自身の立ち位置と他のチームとの関わり合い方を再認識し、チームファーストで取り組むことができます。 また、チームを管理するレイヤーからしても各チームの責任が明瞭になり、安定したチームが長続きするという結果を得られるのではないでしょうか。

Part3 イノベーションと高速なデリバリーのためにチームインタラクションを進化させる

Part2で説明された4つの基本的なチームタイプの間のインタラクションの仕方を紹介しているパートです。 以下の3つの基本的なインタラクションモードが定義されています。⁶

• コラボレーション: 他のチームと密接に協力して作業すること
• X-as-a-Service: 最小限のコラボレーションで何かを利用または提供すること
• ファシリテーション: 障害を取り除くために他のチームを支援したり、支援を受けたりすること

それぞれのインタラクションモードの強みと弱みについても説明されています。 例えばコラボレーションでは、素早く新しい情報や技術を探索する場合には適しているが、チーム間の境界が曖昧になるなどです。 各チームの振る舞いにもありましたが、インタラクションを行う期間というのは重要な関心事であると再認識しました。

多くの具体的なコラボレーションの例が示されているので詳しくは是非読んでみて欲しいです。

ここで印象に残っているのは、チーム間の関わり方というのは有機的であるということです。 先に挙げたようにコラボレーションモードでは、チーム間の境界が曖昧になるとありましたが、これは長い期間コラボレーションモードである場合に顕著になる問題だと理解しています。 チーム間のインタラクションモードが上記のどれなのかを正しく判断することができ、それによって得られるメリットとリスクを把握していれば、ストリームに沿って良きタイミングで異なるインタラクションモードへ遷移することや自立することができるのではないかと思います。 チームファーストなメンバーで構成されたチームであれば、現在のインタラクションモードがどのようなリスクを孕んでいるのかを理解して、チームのために動くことができるはずです。 組織のなかで各所でこういったはたらきが起こることで、密接に相互作用し協調する組織へと適応していくのでしょう。

感想

あまり組織関連の本は読んでこなかったので単純に新鮮でした。 とはいえ今回はコンウェイの法則から入ったのでソフトウェアの話のような感覚でもあります。

思い返せばいろんなところで聞いたことがあるようなスタンスもあり、虫食いだったものが補完されたのかなと思います。 ソフトウェア関連の組織のマネジメント層だけでなく、現場のエンジニアにも呼んでみてほしい本でした。

チームトポロジー - JMAM 日本能率協会マネジメントセンター 「人・組織・経営の変化」を支援するJMAMの書籍

リンクを開く

pub.jmam.co.jp