チームトポロジー Vol. 1 「30分で分かるチームトポロジーの基礎」 吉羽 龍太郎

詳細をお話する前に今の世の中の状況、コンテキストについて復習します。今、ビジネスや技術における変化の速度が昔と比べてとてつもなく早くなっています。僕が仕事をするようになったのは20年前ぐらいなのですが、その頃はとてものんびりしてました。それが今はどうなっているかというと、プロダクトの大規模化が進んでモバイルやクラウド、IoTといったさまざまな技術の組み合わせが必要とされるようになり、非常に複雑化が進みました。ガラケー時代なんかが懐かしく感じたりもします。

変化が激しい上に規模も大きいので、システムの構築や運用に非常に多くの人手を要するようになりました。その一方で組織構造や仕事の進め方はあまり変わっていません。この状況に対応出来るようになっていない。しかし、価値を素早く生み出して顧客に届け続けなければ企業は競争に負けてそもそも存続が出来ません。これが今の状況です。今日はこういったコンテキストで話していきます。

こうした状況で企業のソフトウェア開発に関するパフォーマンスをどのように測定するかですが、よく使われるのが『LeanとDevOpsの科学』という本で紹介されている4つのキーメトリクスです。

毎年行われているDevOpsの調査でもこのスライドにある4つの指標が高い組織が成果を出しているという結果が出ています。

この4つを重要視しているわけですが、よくある疑問として「スクラムでいうベロシティのような生産性に関する指標の方が良いのではないか？」といったものがあります。

しかし、生産性や生産量を示すメトリクスというのは結構、悪用が可能なんですね（笑）チーム間の協力も阻害してしまって、自分のチームの成果だけを追い求めようという風になりがちです。これは良くありません。更にはたくさん作ることだけを目指すとビルドトラップと呼ばれる症状に陥ってしまいます。

チームが忙しく働いたかどうかみたいな話を指標にしてしまうと、計画外作業のような予想外な作業や改善作業が出来なくなることにも繋がってしまいます。

この4つの指標が良いという話ですが、この4つのキーメトリクスをまとめると

顧客に「素早く」「頻繁に」「安定的に」価値を届ける 

問題があれば素早く復旧する

つまり、これが組織に求められています。

さらに言い換えると

安定した速いフローを重視しよう

という話になります。

安定した速いフローを実現して、その結果として早いフィードバックを貰って、次にやることに反映していく。これが組織に求められています。

フローが何よりも重要である、という話はDevOps界隈では良く言われますし、本書でも重要視しているところです。

速いフローが重要であることは分かったのですが、これがなかなかうまくいかなくて、この点に課題のある組織は非常に多いです。

いくつか紹介をすると、1つは組織設計の問題で引き継ぎが多い組織なんかにしてしまうとそもそもフローは遅くなります。それに関連して、経営層が稼働率ばっかり重視して組織変更を行うと最悪なことにもなります。

あとは何をするにも特定のチームが関わらないと進みませんみたいなことになるとそのチームがボトルネックになって遅くなることもありますし、あとは単純に大きすぎるソフトウェアを1つのチームで扱っていて何をするにも調査・調整が必要で遅くなる、みたいなこともあります。色々な遅くなる理由があるわけです。

チームトポロジーはこうしたフローを阻害する要因の解決をして、素早く安定したフローを実現するためのものです。でもこれ自体は銀の弾丸でもなんでもなくて、どちらかというと適応型組織設計モデルのテンプレートみたいなもの、考え方の雛形、土台みたいなものだと思ってください。チームの目的と責任を明確にして、チーム間の相互関係、つまりインタラクションの効果を上げることを目指しています。

書籍の内容は、チーム構造とかコミュニケーションのパターンが中心で、こういったものってビジネスの状況、プロダクトの状況やチームの状況とかによっても変わります。一つの構造が続くっていうことはなくて、ビジネスのステージが変われば当然、組織の構造も変わっていきます。適応型って書いてあるのもそういうことで、変わり続けることを前提として使い続けられるフレームワークみたいな理解をしていただけると良いんじゃないかと思います。

ということで、チームトポロジーではフロー重視をしているわけですが、どんなアイデアが中心になっているかというとスライドに書いてある7つです。

今日は駆け足ではありますが、この7つ全部を紹介出来たらと思います。

1つ目はコンウェイの法則です。

「システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう」とメルヴィン・コンウェイが1968年に出した論文に書かれているものです。これは結構有名ですね。

組織設計によってソフトウェアの設計もおのずと決まっちゃうよ、と言っているわけです。職能別組織みたいな構造にしてしまうと、その構造を反映してめちゃくちゃコミュニケーションが必要な複雑なシステムが出来上がります。これは本の中では同形力なんて呼んだりもしています。

それと、アーキテクチャーのコンサルをしているルース・マランという人が「システムのアーキテクチャーと組織のアーキテクチャーが対立する場合、組織のアーキテクチャーが勝つ」と言っています。理想のテクニカルアーキテクチャがあっても、組織構造がそうなってなかったら組織構造に引きずられてしまうということなんですね。

組織構造がアーキテクチャに反映されてしまう例です。

左の図がチームの構成を表していて、チームが4つあってフロントエンドとバックエンドの開発者がそれぞれにいます。フロントエンドの開発者はバックエンドの開発者としかコミュニケーションを取りません。そして、バックエンドの開発者は一人しかいないDBAとコミュニケーションをします。このようなチーム構成にした場合、アーキテクチャは右側の図みたいになります。

つまり共有DBが一つ出来上がるわけです。それからフロントエンドとバックエンドのレイヤーが分かれた三層アプリケーションになります。コンウェイの法則ではこのように言っています。まあ、ありがちな話です。

そこで、この書籍ではどう対応しているかというと「逆コンウェイ戦略」というアプローチを提唱しています。

要はコンウェイの法則に逆らってはいけないということです。それを戦略的に活用しようと考えたわけですね。言い換えると、望ましいアーキテクチャを実現するためには、それに合った組織構造やチーム構造にした方が良いということになります。

では、望ましいアーキテクチャとは何か、というと素早く安定的に価値を届けるフローの実現が出来るアーキテクチャです。ということでこれが可能になるチーム設計を目指しましょうということになります。

それを実行した例がこちらのスライドですね。

左側がマイクロサービスアーキテクチャです。新しくソフトウェア、アプリケーションを作る時にマイクロサービスでやりたいな、と考えた時に、当然、マイクロサービスなので各サービスは独立していて独自にデータストアを持つことになります。これを実現するためのチームが右側です。

それぞれのアプリケーションごとに個別に開発者を置いて、データベース開発者もそのチームの中に入れます。そうすると外部のチームに依存することなく全部を1チームの中で完結出来るようになります。これによりフローが早くなるわけです。

もうちょっと踏み込むと、右側のチームの中で一人の人がAPIも開発出来るし、データベースも触れますといった感じで複数のことを出来るようになれば、チームはさらに強くなるといえます。望ましいアーキテクチャを実現するためにチームを構成する例でした。これが一つ目のコンウェイの戦略の話ですね。

2つ目の話はチームファーストです。

チームが1番ということですね。これをチームトポロジーでは非常に重視しています。先程の例のような職能別、スキルで分業するようなチーム構成だと引き継ぎや受け渡しが多くなってボトルネックが生まれやすいのでデリバリーが速くなりません。

先程もお話したように素早く安定的に価値が届けられるアーキテクチャを実現するには、それにあったチーム構造にする必要性があります。この帰結として、価値をデリバリーする上ではチームが一番大事という話になります。個人よりもチームの方が大事である、ということですね。

権限やスキルを持ったチームは受け渡しや引き継ぎを必要とせず、自分で判断をして進められるようになるので、いわゆるアジリティが上がります。これはアジャイル開発でも良く言われることで、そのチームがエンドツーエンドでデリバリー出来るようになるとフローは非常に速くなります。

今の複雑で変化の速い世の中では、コマンドコントロールで誰かの指示を待っていても正しい答えは得られない上に時間が掛かります。重要なことはチームが自律的に仕事することです。ということで個人ではなくチームを基本的な構成要素として扱います。個人の成果達成ではなく、チームの成果達成、ビジネスとしての成功が大事、ということです。

よくある落とし穴として

「チーム間の情報共有を増やそう！」

とか

「チーム間の連携やコミュニケーションを活発にしよう！」

なんて会社の中で良く言われますが、実はこれは微妙で、やればやるほど開発に使える時間が減るんですよね。要は価値を生み出す時間が減ってしまう。

そもそもコミュニケーションしないと仕事が進まない状況であれば、リードタイムは長くなっていくのでフローが遅くなります。なんでもかんでもコミュニケーションを取ろう！　というのは良くないよね、と言えます。

それを表しているのがこちらのスライドで、コミュニケーションの複雑性を抑えようという話です。

図は1つのチームの中のコミュニケーションパスを表しています。人数が増えると劇的にコミュニケーションパスが増えていきます。14人いると91本のコミュニケーションパスがあるということが分かります。つまり1つのチームの中でもコミュニケーションパスを制限しないといけなくて、1チームは10人ぐらいにしておかないといけません。チームトポロジーでは5人〜9人、AmazonだとTwo pizzaルールで10人ぐらい、スクラムでも10人ぐらいみたいなことを言ってます。

これに関係する数字としてダンバー数（1990年代にイギリスの人類学者ロビン・ダンバーが提唱した理論。 人がスムーズかつ安定的に関係を維持することができる人数）というのがあるのですが、書籍の中ではそうした数字も紹介されています。

これは1つのチームの話なのですが、同じことがチーム同士にも言えて、コミュニケーションが必要なチームの数が増えれば増えるほど、面倒なことになります。なのでプロジェクトやプロダクトの境界を上手く作って、出来る限り小さい独立したプロジェクト・プロダクトとしてチーム間を疎結合にしないといけませんよ、という話になるわけです。

これはAPI MandateとかBezos Mandateって呼ばれていて、Amazonのジェフ・ベゾスが2002年に各チームこういうやり方をしなさい、ということで社内に通達したドキュメントです。

これを見ると各チームはネットワークを介したサービス・インターフェースを通じてデータや機能を公開しなさいと、そして外部公開可能な形で設計をしろ、という風に言っています。これは意図的に制約を課すことでチーム間の密結合や調整をそもそもなくそうという組織設計にしているわけです。それが望ましいアーキテクチャだということです。

なのでこのアーキテクチャを実現するための組織設計になっているのですが、実際に僕も（Amazonで）3年ぐらい働いていたことがあるので分かるんですが、本当にこんな感じになっています。

Amazonのチーム構造の例は実際にチームトポロジーの中にも事例として出てくるのですが、まさにチームトポロジーずばりそのものという事例になっています。

1チーム10人ぐらいまでの人数で構成されていて、Two Pizzaルールなんていったりもしていますが、これ以上チームの人数が増えそうになると、チームを分割します。そして、1つのチームは1つのプロダクトとか1つの機能群を担当していて、チーム単位で独立してデプロイが出来るので、1時間に最大1万回とかデプロイ出来るわけです。

チーム間のコミュニケーションは出来るだけやらなくて良いような構造になっているということです。開発言語とかプロセスとかも最低限の会社のルールはありますが、各チームに裁量があるのがAmazonのやり方ですね。

では、チームが小さければそれで良いかというとそれだけでは不十分です。これはタックマンモデルというチーム形成のモデルで、チームが機能するようになるまでは段階があるって言っています。

形成期、混乱期、統一期、機能期それから解散期と。こういった段階を踏んでチームが成長するんですけど、これらを通してチームが機能するようになるまでは時間がかかります。3ヶ月とか半年とかかかることもざらにあります。このモデルだとチームは最後に解散期で解散しちゃうんですけど仕事が終わる度にチームを壊すってひじょ〜〜〜にまずいわけです。

アラン・ケリーという有名なアジャイルコーチは「ハイパフォーマンスなチームを解散するのは単なる破壊行為では済まない。企業レベルのサイコパスと呼ぶべきものだ」っていう風に言っています。

これは僕もそう思います。チームを機能させるまでに時間がかかるのにチームを解散させてしまうのは勿体ないです。人を交換可能なリソースと考えて切った貼ったすれば良いかというと全然そんなことないですよね。良いチームは維持するべきです。

そう考えるとチームに仕事が流れ込むようにしないといけません。機能しているチームを壊さないということは、プロジェクトとかプロダクトに合わせてチームを作るのではなく、先にチームがあってそこに仕事を割り当てる形になるのが基本です。もちろん、人の成長のために適当なタイミングでローテーションすることも重要なんですが、そういうことはゆっくりやりましょうっていう話なんですね。

一気にチームを半分にして人を減らしたり、バラバラにしたりしていると辛いので、安定したチームを作ってゆっくり変えていきます。Pivotalなんかでも1年ぐらいでメンバーはチームを異動してるんですが、これも一気にやっているわけではなく、ゆっくりやっていてあくまでも安定したチームを維持することが優先されています。

それからチームが機能するためには、本書のキーワードでもありますが「認知負荷」を考慮する必要があります。人間がそもそも脳にとどめておける情報量には限りがあるんですね。これはチームでも同じです。一つのチームでなんでもかんでも幅広く責任を持ちすぎると、コンテキストスイッチが大きくなったり、順番がつけられなくなって結果的にモチベーションが下がります。

なのでチームが扱う領域を制限しようと、認知負荷を減らすためにこれを組織的にやっていこうよ、ということになります。もちろん、チームによってどこまで認知負荷に耐えられるかっていうのは全然違います。技術とか経験によって変わってくるんですが、少なくともストレスが高い状態では自律的に働けないのでそういう風にならないようにしましょう、という風にチームトポロジーでは言っています。

認知負荷、本書の中でも重要なキーワードですが、認知負荷には3種類あります。これは細かい話になってしまうのでスライドを読んで理解して頂ければと思います。

重要なのは認知負荷に合うように責任範囲を制限しないといけませんよ、ということです。つまり、チームが扱うソフトウェアのサイズは制限しないといけません。

大きいソフトウェアなんかだと、チームの認知負荷にあわせてソフトウェアの境界を決めることが重要になります。ドメインで切るのは良くあるやり方の一つですね。で、この切り方はビジネスドメインだけではなくて他のアプローチもあります。

ちょっと紹介をしておくと、規制遵守、それからリリースの頻度によってもチームの境界は分けられるでしょうし、地理的配置やリスクの高い低いなんかでも境界を決めることが可能だと思います。他にも高い性能を必要としているかどうかとかレガシー技術とそうじゃないところでも分けられるかもしれないし、と。色々あります。

これらの、ソフトウェアの切れ目をチームトポロジーの書籍内では節理面って翻訳しているんですが、要は裂け目みたいな感じで自然に力を入れずとも割れる場所、つまり上手くソフトウェアを分割出来るポイントを見つけて分割していきましょうということになります。

その際は互いに依存しないように上手く割らないといけません。そうすることで認知負荷を下げることが出来ます。要するに長生きするチームを作って、認知負荷が高くない状態で集中して仕事が出来るようにすることが重要なわけです。

チームファーストのセクションでチーム間のコミュニケーションの複雑性を抑える必要があるという話をしましたが、そこで登場するのが3つ目のトピックである「チームAPI」です。

チームで担当しているコードや実施しているバージョン管理の仕方とかそういった仕事のやり方とかインターフェースを定義しておこうというお話です。その上で他のチームとのやり取りにもこの考え方を用いていこう、ということです。他のチームと自分たちが働く時にはやり方は明確で簡単か、というのは常に確認しておきましょう、ということでインターフェースを明確にするということになります。

こちらのスライドはチームトポロジーのGitHubレポジトリで公開されているチームAPIのドキュメントテンプレートです。こんな感じで「うちのチームこういう仕事してまーす」とか「こういう仕事の仕方をしていまーす」ということを定義して他のチームに公開していくわけです。

次は4つのチームタイプです。ここが実際一番取り上げられている部分になるのですが、多くの組織は色々な種類のチームをバラバラと作って、良くわからないことになっていることが多いんですね。

そこでチームトポロジーではチームの種類を4つに絞り込んで、チームのタイプに応じた目的や役割を担わせる、という考え方をしています。この4つの組織タイプをテンプレートとして活用するので、基本的にはどんなチームもこの4つに分類されます。

1つ目がストリームアラインドチームです。ストリーム「アイランド」ではありません。

これは主なビジネス的な変更フロー、ストリームに沿って配置されるチームですね。一番中心的なチームタイプで、数が多いのもこのチームタイプです。残りの3種類のチームタイプは全てこのチームの負荷を減らすために存在しています。

ストリーム自体はビジネスやサービスであることもあれば機能群や特定のペルソナだったりもします。色々なストリームが併存します。ストリームというのは要はエンドツーエンドの価値を届けることを意味するので、職能横断型のチームで独立したデリバリーが出来る能力を持っていることがストリームアラインドチームの条件です。さっき紹介したAmazonのプロダクトチームなんかは正にストリームアラインドチームになるわけです。

次はプラットフォームチームですね。

インフラやツール、共通サービスみたいな内部サービスを提供するチームです。いわゆる、共通基盤や内部プロダクトと言われるようなものかなと思います。これで良く使う部分を隠蔽します。

ストリームアラインドチームは詳細を知らなくても、Kubernetesのプラットフォームが使えるとか、簡単に使えるので学習が不要みたいなことになって認知負荷が下がるわけです。これは良く出てくるパターンですね。色々なサービスをやっている会社だと良く登場するチームかなと思います。

次はイネイブリングチームです。これは他のチームが新しい技術などの習得をするのを支援するチームになります。

いわゆる、特定の技術や製品、プロセスなどのスペシャリストで構成されるチームになります。このチームは実作業を代わりにやるのではなくて、あくまで支援するチームになります。スキルを身につけるのを支援するチームですね。

例えば、ビルド、継続的デリバリーやTDDにアジャイル、Infrastructure as Codeとかこういったものの知識やテンプレート、ガイダンスなどを提供するチームになります。基本的には短期で支援をして、スキルトランスファーをしたらお終い、というチームになります。

4つのタイプの最後がコンプリケイテッド・サブシステムチームです。噛みそうになる名前ですが、名前の通り複雑なサブシステムを扱うチームになります。

殆どのメンバーがその分野のスペシャリストでないと扱えないような難しい領域を担当します。例えば機械学習のチューニングとか特殊技術や特殊パッケージ、他だと数学的なアルゴリズムとかの一定の専門性を要する事柄を担当します。

これも結局はストリームアラインドチームの認知負荷を減らすために存在します。ストリームアラインドチームから見るとブラックボックスとして扱えるといった形になります。

この4種類のチームのチーム間コミュニケーションを定義するのが3つのインタラクションモードというものになります。コラボレーションモード、X-as-a-Serviceモード、ファシリテーションモードを順番にお話していきたいと思います。

コラボレーションモードは2つのチームが探索や学習を目的にお互い協力している状態です。密にコミュニケーションするので引き継ぎとかはあまり発生しません。ですので、素早く探索や実験が可能になります。

その一方でチーム間の責任分界点みたいなものは曖昧になりがちで、生産性は落ちます。生産性は落ちてしまうので、あくまでも探索や実験の時だけこのモードを利用するのがより良い使い方かなと思います。基本的にずっとこのモードでやる、ということはあまり得策ではありません。

ビジネスやプロダクトの初期フェーズでは良く登場するモードです、つまり分からないことが多い状況ではコラボレーションモードを活用することが多くなります。

次がX-as-a-Serviceモードです。これはas-a-Serviceとも書いてあるように一方のチームが他方のチームが提供するものをサービスとして利用する、ブラックボックスとして使います、ということです。

利点としては責任境界が明確でオーナーシップもはっきりしているので、イチイチ色んなこと共有しなくて良いことです。認知負荷は高くなりません。。ただ一方で明確に責任分界点を設定しているので、相手の領域に踏み込まないという力学が働きます。こうなってしまうと境界付近でのイノベーションが起こりづらくなります。

ただ、特にインフラチームなんかとコミュニケーションする時は、このX-as-a-Serviceモードでインタラクションすることが非常に多くなります。あくまでも社内のインフラをサービスとして利用する、というイメージです。

最後がファシリテーションモードです。

一方のチームが新しい技術などを身に付けたり、学習したりするために他方のチームをファシリテーションしてあげます。主に支援系の文脈になりますので当然コーチングスキルだったりティーチングスキルなどを要することになり、経験豊富な人が必要になります。

ということでチームタイプ別のインタラクションモードを見ていくとこのようになります。これについてはお話した通りでもありますし、スライドを見て頂ければ良いかなと思います。

ここでチーム構成の例を見ていきましょう。左側の例は3チーム存在していてAがストリームアラインドチーム、Bがコンプリケイテッド・サブシステムチーム、Cがプラットフォームチームになっているんですが、AとBの間では今複雑なサブシステムの境界を探そうとして協力している状態、コラボレーション状態です。一方でAチームとCチームの関係は、Aからはプラットフォームチームをサービスとして使うというような表現がされています。

右の例になるともう少し複雑で、コンプリケイテッド・サブシステムチームが担当している複雑な箇所については一定部分は完成していて、その部分は満ん中のストリームアラインドチーム（D）にサービスとして提供が出来ていて、その一方でAのストリームアラインドチームとのやり取りについては新しく境界を見つけようとしていて、新しくコンプリケイテッド・サブシステムにしないといけない部分を探すべくコラボレーションしている状況です。それから右側の上の方、Eというイネイブリングチームがストリームアラインドチームの学習を支援している状況です。

こんな風に図を書いて、組織の構造を見える化すると、分かりやすいですし共通の文脈で会話が出来るのがチームトポロジーの良いところの1つなのではないかなと、思います。

6番目は組織的センシングです。

変化が早くて複雑な世の中では環境の変化は兎に角、早く気付かなければいけません。これが出来ないと無駄なものをたくさん作ることになってしまいますから環境の変化については皆が気付く必要があります。

なので本番環境のソフトウェアから色々なことに気付いて学習しないといけません。その他にも他チームとのコミュニケーションを通して学びや気付きを得られるようになっていないといけないわけです。

例えば、凝り固まった組織だと期初に部門ごとなにか目標を掲げて、それがお互いに相反する目標だったりして、他のチームやその他外部からのインプットを全部無視しちゃう、なんてことがあったりするわけですが、こんなんじゃまずいですよね。

あらゆるところをセンサーにして、それを次にやることに反映していかなければいけないことをチームトポロジーでは重要視しています。

いよいよ最後ですが「トポロジーを継続的に進化させる」です。

選択したチームタイプやインタラクション、プロダクトに関するチーム構成ってあくまでもその時点のものです。時間の経過や環境の変化によって構造は変わります。つまり動的なんですね。staticじゃなくてdynamicにゆるやかに変わっていきます。

これはプロダクトの成長によって関わるチームが増えた時はもちろんですし、チームが成長して認知負荷に耐えられるようになった時も変わります。チームはゆるやかに必ず変化します。むしろ、変えていかなければならないことをチームトポロジーでは謳っています。

では、どういった時にチームの構成を見直さなければならないかというと、ソフトウェアが大きくなり過ぎているとか、デリバリーのリズムが遅くなってたり、あちこちに依存関係が増え過ぎていたり……そういった時は認知負荷が高くなり過ぎていないか？　と考えて、チーム構成を見直したりしないといけないのではないかなと思います。

もちろん、この3つはあくまでも一例なので他にもいっぱいあると思いますが、そういった状況に直面した時は一度立ち止まって、今の構造は正しいのか、そうじゃないとしたらどうしたら良いのかを組織的に考えることが大事です。

そして、変える際も一気に変えるのではなく、ゆっくり変えていくことが必要になってきます。ですので、今日話を聞いて、本を読んで「よし、大規模組織改変だ！」っていうふうになってはダメで、あくまでもゆっくりやってください。いきなり変えると事故ります。変化を見ながら、ゆっくり取り組んで頂ければと思います。

30分でちゃんと出来たかどうか不安なんですが、概要についてお話しました。

詳細を知りたい方は是非、書籍を手に取って頂ければ嬉しいです。感想なんかもTwitterなんかで僕や担当編集の山地さん（@EYamaji）に送って頂けると嬉しいです。

それでは本日はご静聴ありがとうございました！