「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」を読んだ
はじめに 最近ストリームアラインドチームやイネイブリングチームなどを聞くことがよくあり、きちんと整理しようと思い「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」を読みました。 備忘録として印象に残ったことや感想を書いてみようと思います。 基本的に個人的な解釈・感想です、間違っていたらすみません 🙇♂️ Part1 - デリバリーの手段としてのチーム 最初のパートではコンウェイの法則1に基づいて展開されていきます。 ここで初めて ストリームアラインドチーム イネイブリングチーム コンプリケイテッド・サブシステムチーム プラットフォームチーム が出てきます。 初めに知的労働組織の成功の鍵は、非公式構造と価値創造構造のインタラクションにあるとされます。 公式な構造、非公式な構造、価値創造構造は本書2の中では以下のように説明されていました。 公式な構造（組織図）: コンプライアンス遵守を円滑にする 非公式な構造: 個人間の「影響力の領域」 価値創造構造: 個人間やチーム間の能力に基づいて、実際にどう仕事を終わらせるか 実際、公式な構造というのは何らかをエスカレーションするなど業務上役に立つことは多くありますが、ことソフトウェアのデリバリーにおけるコミュニケーションの構造とは確かに一致しません。 非公式な構造と価値創造構造のインタラクションとはすなわち人とチームのインタラクションと説明されていました。 影響力を持つ個人がチームに対して良い影響をもたらす場面には何度も立ち会ってきた実感がありますし、本書におけるチームの構造も相まってチーム内外の信頼関係を育むことは納得感があります。 組織的な編成などの決定がソフトウェアに対して力学を働かせるということ、逆にそれを利用してコミュニケーションパスを設計するということがこれから展開されていきます。 認知負荷を制限し、チームファーストのアプローチを適用し、組織が必要に応じたチーム間のインタラクションを誘発し、オーバーヘッドを見つけられるようにするというのがチームトポロジーのゴールとされました。 特にチームファーストのアプローチという点が興味深かったです。 人間が安定した人間関係を維持できる認知的上限の人数としてダンバー数に言及し、チーム内の信頼関係を最大化するためにチームメンバーの数を制限するとされていました。 特にダンバー数に関しては知らない概念でしたが、たくさんのメンバーと信頼関係を築くのは時間がかかるというのは当然であり、チームを構成した上で早くチームのパフォーマンスを最大化するためには、人数を抑えることが最も適切であるというのは理解できます。 どの程度の人数が信頼関係を維持できる閾値なのかの根拠があるのは組織を編成する上で説得力があります。 チーム内の信頼関係というのがとても重要視されていて、個人ではなくチームに報いること、メンバーはチームファーストのマインドセットを持つ必要があることについて言及されています。 印象に残っているのはチームの安定とメンバーの固定は別だということです。 直感には反する気がしますが、チームメンバー全員がチームファーストでチームのケイパビリティを高め続けるのであれば、属人化せずチームメンバーが変わったとしても新規メンバーへの投資というのは行われ続けるでしょう。 責任や能力に偏りのあるチームだと、メンバーの異動で不安定になってしまうのはあるあるだと思います。 自分もそうですが、チームを構成したとしても何らかのプロダクトの成功へ個人として意識が依ってしまうと思います。 チームファーストでチームとして足並みを揃えてプロダクトの成功へ向き合うことが、チームの安定、そしてプロダクトの成功を引き出すのだろうと理解しました。 最小単位としてのチームが確立できると、次はチーム間をどのようにコラボレーションさせていくのかということについて言及されます。 チームの認知容量に合わせて責任範囲を制限し、チーム間でのインタラクションの形を定義するということです。 ここでもチームの認知容量とソフトウェアのサブセットの境界を合わせるとされていて、一貫してコンウェイの法則を意識させられます。 チームファーストでソフトウェアを設計する（=チームの認知負荷を制限にあった形で設計する）ことはかなり難易度が高いなと感じました。 しかし、ソフトウェア設計の引き出しを増やしていくと自然と組織設計の選択肢も増えるというのは、マネジメント側へのキャリア形成も可能なのではないかと考えていて、技術とマネジメントは分断されていないことにある種の安心感を覚えています。 Part2 - フローを機能させるチームトポロジー 次は、Part1で紹介程度に出てきていた ストリームアラインドチーム イネイブリングチーム コンプリケイテッド・サブシステムチーム プラットフォームチーム について詳細に説明されるパートです。 まずストリームについて定義する必要があります。 本書の中では、「ストリームとは、ビジネスドメインや組織の能力に沿った仕事の継続的な流れのことだ」3とされています。 ストリームアラインドチームとはこのストリームにそって稼働するチームのことです。 つまりは、ストリームアラインドチームがプロダクトの根幹となるチームだと理解しました。 他のチームは適切なタイミングで、適切な方法でサポートすることでストリームアラインドチームの認知負荷が増えないように働きかけます。 イネイブリングチームは特定のドメインのスペシャリストで構成されるチームで、ストリームアラインドチームが多大な労力をかけずに新たな能力を獲得するのを助けるように振る舞います。 Enabling SREと言われたりするチームもこのイネイブリングチームのひとつでストリームアラインドチームがSREのプラクティスや信頼性にコミットできるように動くチームですね。 コンプリケイテッド・サブシステムチームは、「システムの中でもスペシャリストの知識が必要となるパーツを開発・保守する責任を持つ」4と説明されています。 これだけ読んだ時はイネイブリングチームとは違わないのではないかと感じたのですが、ストリームアラインドチームと関わる目的が異なります。 イネイブリングチームはストリームアラインドチームが新たな能力を獲得するために短期間にやりとりを行います。 ストリームアラインドチームの問題を解決するためではなく、チームの進化に寄与するためコラボレーションを行うということです。 対して、コンプリケイテッド・サブシステムチームはストリームアラインドチーム単体で開発した場合よりも認知負荷を抑えてデリバリーを加速させることが目的です。 そのため密接にコラボレーションを行うのは開発中やまだサブシステムが安定していない期間です。 ただ、保守も行うためストリームアラインドチームのニーズに合わせて適切なものをデリバリーする必要があります。 プラットフォームチームは、ストリームアラインドチームが下位のサービスを開発する必要をなくし認知負荷を下げるためのチームです。 ここで言われているのはプラットフォームはプロダクトであり、プラットフォームを利用するストリームアラインドチームはプラットフォームチームにとって顧客であるということです。 これはプラットフォームエンジニアリングを推進する文脈でもよく聞く考え方ですね。 ...