for Startups Tech blog

このブログのデザインを刷新しました。(2023/12/26)

チームトポロジーを読んだよ

f:id:forStartups:20220121160503j:plain

どうも、ばやし(@bayashimura)です。

首を長くして待ち望んでいた「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」を読みました。とても勉強になったので感想を書いていこうと思います。

 

どんな本?

社内に複数チームを抱えるサイズになった企業が、どういうチーム構成にしてどのような相互作用をすればよいのかというのを説明してくれる本です。

そのために4つのチームタイプと3つのインタラクションモードのモデルを提示し、高速に価値をデリバリーする組織の形をパターンとして伝えてくれます。

 

具体的なまとめ内容に関しては翻訳者の一人のryuzeeさんのブログがわかりやすいです。

www.ryuzee.com

 

認知負荷を減らす

これまで私がプロダクトやチームがスケールする現象に抱いていた認識は「複雑になってしんどい、セクショナリズムとか発生してしんどい」といったふわっとしたものでした。

本書ではそれに対して認知負荷という切り口で「チームの認知容量には尊重すべき上限が存在する」と定義してくれたことで、スケールした際のしんどさの正体を明らかにしてくれています。

組織やプロダクトが大きくなるにつれて、少人数では手に負えなくなってきますよね。何故手に負えなくなるかと言うと、プロダクトにせよ人にせよ把握できない部分が増えてくるからです。大量のソースコードや多岐にわたる複雑なドメインに常に気を配らせながら開発をしていると、開発は全然進みません。これが認知に負荷がかかっている状態です。

チームが取り扱える認知負荷は限りがあるので、できるだけ減らしていこうというのがこの本の考え方です。じゃあどうやって減らしていこうかというと、まぁチームを分割します。そして分割したチームを4つのタイプに種別しています。

これはこの本の見所だと思っていて、例えばLeSS(Large Scale Scrum)だと、「クロスファンクショナルなチームが良い」や「長生きなチームが良い」など、どういうチームが良いのかといった部分にのみ言及されています。

less.works

f:id:bayashimura:20220121161900p:plain

そのため、チーム同士はどうコラボレーションすると良いのか、チーム毎に特徴はあるのかといったことは読み手側に委ねられており、ノウハウを一から自分たちで積む必要があります(これはLeSSがフレームワークとして未熟であるというよりはLeSS自体がScrumに則り最小のフレームワークを目指していることによるものだと思います)。

f:id:bayashimura:20220121161927p:plain

この「チーム毎に特徴(タイプ)はあるのか?」という話と「チーム間はどう関わるのが良いのか」という疑問に対してパターンを紹介してくれるのがチームトポロジーで出てくる4つのチームタイプと、3つのインタラクションモードです。

 

4つのチームタイプ

ストリームアラインドチーム
メインになるチームです。バリューストリームに沿って配置されます。職能横断型で他のチームに依存することなくデリバリーできるよう構成されたチームです。なぜプロダクトチームやフィーチャーチームという呼び名ではないのかというと

このように複数チャネルと高度に結合されたコンテキストでは、「プロダクト」はいろいろな意味を持つ。これが「プロダクトチーム」の責任範囲を理解しづらくしている。 (chapter 5より引用)

だそうです。

プラットフォームチーム
その名の通りプラットフォームを提供するチームです。共通化されたインフラ、ツール、プラグインなどを提供します。複数のストリームアラインドチームが共通して取り扱う複雑なものを抽象化して提供することで認知負荷を下げます。

イネイブリングチーム
他のチームのスキル習得をサポートするチーム。

コンプリケイテッドサブシステムチーム
チーム全員が認知するには負荷が高い複雑なサブシステムやコンポーネントを扱うチーム。

またこのチーム同士の関わり方、インタラクションの仕方も3つのモードを提示しています。

 

3つのインタラクションモード

コラボレーション
2つのチームがお互いオーナーシップを持って協働するスタイル。一番認知負荷がきついが、学習は進む。

X-as-a-Service
明確に責任領域を分けて一方が他方にサービスを提供する形です。利用者はインタフェースだけを把握すればよく認知負荷は低そうですね。

ファシリテーション
一方が他方のチームに学習が進むようファシリテーションをするスタイルです。

 

チームパターンの時代

私がこの本を読んで第一に抱いた感想は「新しい時代がきたなぁ」でした。

まずこの本はこの一節から始まります。

"システムを小さくシンプルに保つことは価値あるゴールだが、成功しているシステムの多くはそうなっていない。(まえがきより引用)"

そうなんですよね。チームもシステムも小さくシンプルに保つことは素晴らしいことですし、その努力を怠ってはならないんですけど、プロダクトが1チームを超えるタイミングはありますよね。成功していたらなおさら。

"チームのモデルやスケールデリバリーモデルはたくさんあるが、一見しただけでは個々の違いはわからない。さらに、チームのふるまいのパターンが示されておらず、他のチームとどのように効果的に接するべきかのガイドラインもないままだ。"

という文の通り、今までスケールはするなという教えが先行し、スケールした後にどういうコミュニケーションを取ればいいのか、それぞれのチームに個体差はないのか、といった議論はあまりされていなかったように感じます。

そこに対して、チームのタイプやインタラクションモードをパターンとして記述したこの本は、私としては新時代の到来を感じました。ここで取り上げられた、4つのチームタイプと3つのインタラクションモードはこれから色んなところで共通語になってきそうですね。

振り子?それとも螺旋?

f:id:bayashimura:20220121161953p:plain

振り子と螺旋の話はt_wadaさんの技術選定の審美眼から引用させていただいております。 

speakerdeck.com

 

振り子は同じところを行ったり来たりしている、螺旋は行ったり来たりするように見えて実はどんどん進歩していっているという表現です。

大体の新しいものは現状の悩みごとから出てくるものです。本書も、出てきた背景は「スモールチームで上手くやれるようになったけど、スケールすると上手くいかない」ではないでしょうか。私が読もうと思ったきっかけはそうです。

"システムを小さくシンプルに保つことは価値あるゴールだが、成功しているシステムの多くはそうなっていない。(まえがきより引用)"

前書きの一番最初に出てくるこの一文が示す通り、チームやプロダクトを小さくシンプルにするのはとても大切です。しかしプロダクトが続いていく上でその原理原則通りにやっていけるわけではありません。実際プロダクトが続けば続くほど、人気が出れば出るほど満たさなければならない要求も増え、プロダクトは巨大に複雑になっていきます。

採用も上手くいきチームもプロダクトも大きく複雑になってしまったときにどうすればいいのか、それについての本は私を含め多くの人が読みたかったのではないでしょうか。

ただ少し待ってください。この4つのチームタイプや3つのインタラクションモード、見覚えありませんか?実は多くの既存の大企業がこの形になっていないでしょうか。

システムごとに部署があって、みんなが使う共通のプラットフォームを作る部署があり、難しい技術をレクチャーする部署があり、法務やセキュリティなどの専門領域に対処する部署がありませんか。

自分がアジャイルにハマったきっかけを思い出してみます。膨大なコミュニケーションコスト、何を書いていいかわからない申請書、至るところで発生するセクショナリズム、こういったものに嫌気が指し私はアジャイルスクラムが提唱するスモールチームに惹かれていきました。

この4つのチームタイプと3つのインタラクションモードは組織をあの頃の重厚長大な組織に戻す第一歩だったりしないか?もしかしてスモールチームでうまくやっていた人達が、大企業になっていく中で同じようなペインを抱えてあの頃の大企業になっていくだけの話?果たしてこのチームトポロジーは振り子なのでしょうか。

いいえ、私は螺旋だと思います。

 

まず本書は大前提として

長続きする小さなチームを基準とする

チームがソフトウェアのオーナーとなる

などのチームファーストな思考がベースとなっています。

スモールチームがアジリティ高く価値を継続的にリリースするという、コアな価値観は変わっていません。

これまでのチーム構成が静的でトップダウンで決まるのに対して、この本書でのチーム同士の関わり方は動的に決まります。責務の切れ目が理解できないうちはコラボレーション、理解できてきたらX-as-a-Serviceに徐々に変更していくところなどは、経験主義が息づいてそうです。

使いづらい社内サービスを使わされていた苦い過去を持つ方。プラットフォームチームが提供してくるX-as-a-Service怖いですね。安心してください。本書の中でも明言してくれています。

X-as-a-Serviceモデルがうまく機能するのは、サービス境界が正しく選択、実装され、サービスを提供するチームが優れたサービスマネジメントを実践している場合に限られる (chapter 7より引用)

まだまだ挙げればキリが無いのですが、至るところに「このチームタイプの大事なポイント」「このインタラクションモードの大事なポイント」が存在し、それは以前までの大企業のモデルとは違うことを示唆してくれています。

ということで、チームトポロジーはスケールするチームを支える新しいやり方だと、私は思いました。

ただし「4つのチームタイプと3つのインタラクションモードにすればいいんだろ」といった理解で現場に適用しようとすると「これまでの大企業のやり方と何が違うんだっけ」となりかねないので本書を一読し、コラムなどにも目を通した上で参考にすることをおすすめします。

以上、チームトポロジーの感想文でした。

 

We are Hiring!

f:id:forStartups:20211020192743p:plain

フォースタートアップスでは共に働く仲間を募集中です。本記事を読んで興味を持っていただけましたら採用情報をご覧ください。