Team Topologies(by Manuel Pais)のキーポイント
この記事について
CaSEというPodcastを時々聴いているのだけど、その最新話がTeam Topologiesの著者であるManuel Pais氏のゲスト回だった。すごく学びが多く、同じ悩みをもつ人も多いと思ったので内容や思考を整理してみたものを記事化してみた。ちなみに書籍のTeam Topologiesは読んでいません。
“two pizza” チームの挑戦
話はAmazon CTOのVerner Vogelのインタビューから始まる。2006年頃にジェフベゾスがTwo pizzaチームの話をしたのは有名だが、面白いのはAWSはまさにプラットフォームチームをX as a Serviceモードにした結果になっていて、意図的ではないにしろトポロジーを体現していたのだと思った。これは後半のプラットフォームチームの話にも繋がってくる
本題に戻ると、Two pizzaサイズで自己組織化に向かったチームが次に直面した認知負荷[1]という問題にまずPaisは焦点を当てた。
背景には当時アジャイルがまだ普及期であり、実態とギャップがあるという課題や 「DevOpsのためにチームをどう編成するか」という課題があった。
ソフトウェアエンジニアリングの世界では、開発チームはますます多くのことを求められるようになってきた（サービスのインフラやセキュリティ、サービスのドメイン知識や多様化する技術スタックなど）。そのため、この認知負荷問題が大きくなってきているわけだが、それらに対処する術として意外に身近なところをヒントとしている。
それは、UX・UIに携わる人々は、ユーザーや顧客があるタスクを実行する際に、「どのくらいの認知負荷がかかるのか」の考え方を非常に重視する傾向がある という事実。
どうすればその認知負荷を軽減できるのか？どうやってシンプルにするかを常に考えている。それらの考え方は開発チームレベルでも応用できると考えた。
チームトポロジーでは、認知負荷とは何かをよく理解し、さまざまなタイプの認知負荷に分けて考えることで、多くのチームが抱える問題に対処できる可能性が高まる と考えている。
認知負荷の3つのタイプ
内在的(intrinsic)認知負荷
ソフトウェアエンジニアとして、ソフトウェアデリバリーチームの一員として、仕事をするために必要なスキルのこと。使用する言語やツールなどによって必要なスキルは異なるが、例えば、銀行アプリケーションのJavaプログラマーの場合は、Javaについての知識、使用するフレームワークについての知識に加えて、サービスを実行するためのアプリケーションをどのようにビルドするかなどの知識も必要になる。
余計な（extraneous）認知負荷
内在的認知負荷に加えて、デリバリー作業の仕組みなどに関連する余計な認知負荷がある。オペレーションの仕事も同様。
例えば、このサービスをKubernetesにデプロイするにはどうすればいいか、検証環境のデータをどう用意するかなど、記憶に力を入れる必要があるとき常に当てはまる。テスト用のデータベースにアクセスするにはどうすればいいのか？受け入れテストを行うにはどうすればいいのか、これらの精神的な努力を必要とするすべてのことは、一種の余計な認知負荷である。
適切な(germane)認知負荷
実際の問題領域に関連するすべてのことを言う。例えば、2人のお客様が月々の振替をより簡単に行えるようにするとか、解決しようとしている問題やお客様のために構築しようとしている機能、これらはすべて本質的な部分であり、これこそが私たちが実際に組織や顧客に価値を与えている理由である。
この3種類の認知負荷を理解すると、「全体的な認知負荷を軽減するには内在的な認知負荷を最小限に抑えることが重要である」ことがわかる。
例えば、ペアプログラミング、社内でのトレーニングなどは基本的に個々のスキルアップに役立つ。日常的に行うべきことにギャップがある場合には、それらを通して内在的な認知負荷を軽減できる。さらに余計な認知負荷も軽減したい。そこで重要になるのが、余計な認知負荷の一部をプロビジョニングやデプロイパイプライン、モニタリングなどを行うための便利なサービスを提供するプラットフォームに移すこと。すべての人に自分ですべてのスタックをセットアップして、すべての異なるツールについて学んでもらうのでは時間がいくらあっても足りない。チームのニーズを理解すれば、誰もが使える汎用的なサービスではなく、チームにとって何が必要なニーズに対応した優れたプラットフォームサービスを構築できる可能性が高くなる。
要するに、余計な認知負荷と内在的認知負荷を最小限に抑えることができれば、結果的に顧客のニーズに集中するための本質的な能力を高めることができるはず という仮設に繋がった。
参考 学習科学の基礎：余計な認知負荷（cognitive load）をなくす方法
認知負荷の測定
開発者たちは自分たちが何をどの程度やるべきか分かっていない事も多い。
認知負荷が大きすぎるかどうかは、どうやって測定すればいいのだろう？
認知負荷評価 という指標をPaisはひとつ作ったが、これはあくまでも一例であって、汎用的ではない。適切な(germane)認知負荷については、どの業界でどのような状況で仕事をしているかによって全く異なる。
経験のないチームにただ「パブリッククラウドを使って次に何をやんなきゃいけないかを探し出して」と言ったら認知負荷は爆発する。こういったとき人は何かに追われていて、立ち止まってどうすればいいのか考える時間がないと感じる といった主観的な感覚がある。
このような認知負荷の評価を行うことは可能である。
GitHubの例では、テスト、デプロイ、ビルド、本番での問題解決、問題の発見や診断など、多くの構築・運営チームに共通するような経験を、チームメンバーに質問している。
重要なのは、「私たちの認知負荷が高すぎるのではないか」という会話をすること。
本当に苦労している分野は何か？デプロイは非常に骨の折れる作業かもしれない。デプロイに1週間も2週間もかかっているかもしれない。このような場合には、デプロイメントに投資して、より良いアプローチをとるべきで、時間をかけていくつかのことを自動化し、継続的な配信を適切に行う方法をよく理解することから始めよう。
他にも来年（2022年）あたりには、チームが現在の状況を把握するのに役立つシンプルなツールを提供したい と計画されている。
4つの基本的なチームトポロジー
4つのタイプのチームは、PaisとMatthew Skelton（共著者）が、顧客を支援したときの経験に基づいている。
顧客は大抵、DevOpsや継続的デリバリーに関する支援を求めていたが、どのようなタイプのチームが存在するのか、何を目的としているのか、実際にはほとんど明らかになっていなかった。
奇跡的に一つにまとまることを期待していたようだが、必要だったのはチームのタイプを明確にすることだった。「このチームの顧客は誰か？エンドユーザなのか？組織内の顧客なのか？このタイプのチームに期待される行動は何か。サービスを構築して運営するオーナーシップを期待されているのか、他のチームに教える役割をサポートすることを期待されているのか？」
それらの問いから4つのチームタイプが生まれ、異なるチームがお互いにどのように関係し助け合うのかをより明確にした。それによって組織の働き方を改善するだけでなく、組織に価値をより早く提供することができるようになると考えられている。
ストリームアラインドチーム
基本的にはチームを仕事の流れに沿ったものにすべきだと考えている。つまり、（可能な限り切り離された）仕事の流れは何かを特定する必要があり、これはバリューストリームを特定するという考えに戻るもの でもある。しかし、バリューストリームの中にも、複数のプロダクトがあったり、製品の中に複数のストリームがあったりする場合がある。
そういったケースでも、1つのチームが顧客を理解し、顧客は何を必要としているのかというディスカバリーを行い、サービスやソフトウェアをより大きな製品の一部として、できるだけ独立して構築し、テストし、デプロイし、実行できるようなライフサイクルをEnd-to-Endで所有することを目指している。
依存関係がないわけではないが、ソフトウェアと同じようにチームを疎結合にするアプローチをしている。理想的には、異なるバリューストリーム、異なるプロダクトを特定し、それにチームを合わせることができるようにする。（逆コンウェイ）
ストリームアラインドチーム以外のタイプのチームがなければ、これらのチームの認知負荷は非常に高いものになる。これはすぐに想像がつく。求められている機能を提供しながら他のことを学ぶにはどうすればよいかという問題に直面する。そこで、他のタイプのチームが必要になってくる。
プラットフォームチーム
プラットフォームチームは、必ずしもサービスやツールにフォーカスするだけでなく、むしろプラットフォームをより体験的なものとして捉えている。もちろん、サービスやツールは必要だが、プラットフォームの体験や使用方法がチームの認知負荷をどのくらい軽減するだろうか？と考える。もし提供するプラットフォームが煩雑で理解するのが難しく、APIが期待通りに機能しなかったり、よくメンテナンス中であったりしたら、チームの助けにはならない。ストリームアラインドチームの助けにはならないのならプラットフォームサービスはむしろお荷物となる。
書籍では「プラットフォーム・チームの出発点は、認知負荷を軽減することである」と述べられていて、プラットフォームとUXに関してとても高いレベルの開発者の経験を提供することで、余計な認知負荷をプラットフォームに振り向けることができるようになる（とあるらしい）。
また、ストリームアラインドチームにとっての余計な負荷がプラットフォームチームにとっては、適切な（germane）認知負荷になる。それはつまり社内の顧客に役立つことに取り組むことである。
イネーブリングチーム
Paisらのコンサルティングの経験から、組織内の多くのチームが同じようなギャップを抱えていることがわかった。それは、効果的なテスト自動化の方法を知らないことだったり、継続的インテグレーションの方法を知らないことだったり、UXを知らないことだったり、分野は様々。
組織はそうしたチームのニーズを満たすのに苦労している。なぜならすべてのチームにUXの専門家やテストオートメーションの専門家を雇うことはできない。なので採用に頼るのではなく、社内でチームを結成し、2～3人の専門家を集めるのが理想的としている。
このチームは、他のチームをファシリテートしたり指導したり。ペアリングやワークショップ、ビデオベースのトレーニングなど、社内のチームが特定の分野で必要なスキルを身につけるためのあらゆる支援を行う。同時に、このチームは、ストリームアラインドチームにとって有用なプラットフォームの機能やサービスを見極めるのにも適した立場にある。
このようにして、自分たちの目的が何であるかをよく理解し、組織全体やチームがより良くなるためにどのように貢献しているのかを理解しているさまざまなタイプのチームが集まった、いわばエコシステムのようなものができあがる。
コンプリケイテッド・サブシステムチーム
実は非推奨。
例えば、顔認識やリアルタイムの金融取引など、非常に複雑なアルゴリズムや技術を必要とする場合、たとえそれが顧客に直接使用されないものであっても、そのサブシステムを所有するチームが必要になることがある。しかし、ストリームアラインドチームに「この博士号レベルの理解を必要とする機能モジュールも所有してくれ」とお願いするのは非現実的であることが多いためやむを得ないケースになる。
また、DevOpsの周りに複雑なサブシステムを作れとか、Kubernetesの周りに複雑なサブシステムを作れと言っているわけではない。
おそらくプラットフォームタイプのチーム、その技術を使おうとしているチームに合わせるべきであって、非常にニッチな知識を必要とするサブシステムを構築・運用するチームであり、その知識がある人を簡単に見つけることはできない。
インタラクションモードの3つのモード
これら各チームの詳細や難しさに触れる前にインタラクションモードについての説明があったほうがよい。
コラボレーション
2つのチームが特定の期間、特定の目的のために協力すること と定義されている。
より明確に定義されているという意味で、単なる自由なコラボレーションではない。本当の意味では、他のチームと関係を持っている状態である。
しかし結論、特定の問題を解決するためであればなんでもいい。
ファシリテーション
イネーブリングチームの典型的な例と述べたが、ストリームアラインドチーム間でも起こり得る。ストリームアラインドチームとプラットフォームチームの間でも起こり得る。あるチームがある分野の専門知識を持っていて、別のチームが助けを必要としているような場合、知っている側のチームはファシリテーションを行うことができるが、その期間は決められており、変更されることもある。
X-as-a-Service
典型的なプラットフォームで、他のチームが利用するサービスを提供する。サービスの品質、信頼性、使いやすさが十分に確保されていて、他のチームが独立して利用することができるため、実際にはチーム間のやり取りの必要がない。
イネーブリングチームの象牙の塔問題
イネーブリングチームは象牙の塔になりやすいという問題がある。従来の神格化されたアーキテクトと同様。
また、イネーブリングチームが、ストリームアラインドチームの仕事を遂行する上で、依存関係になってしまうことも避けたい。自分たちのアプリケーションのために新しいライブラリを作る際、イネーブルチームに頼まなければならないようなやり方は、イネーブルワークではない。
何が良い方法なのかというと、イネーブリングチームがストリームアラインドチームの周りを回るのが良い。
イネーブリングチームがテスト自動化を実現することは期待されもしないし、より具体的には、全くテスト自動化の経験を持っていないストリームアラインドチームが、数週間でテスト自動化のすべてを学ぶことは期待しないし、そうではなく、良い自動化テストを作るための基本的な知識を身につけるところから。すべてを教えようとするのではなく、2週間ほどかけて彼らを助け、ペアを組んだりする。そして2ヶ月後に戻ってきて、チームがどうなっているかを見てみる。身についているか、応用に入ることができているか。テストの数が多すぎてパイプラインでの実行に時間がかかりすぎるなど、ある時点で別の課題が出てくることもある。そうなるとテストをより独立したものにしたりパフォーマンスを向上させたりすることを考える必要が出てくる。
このようにチームが多くの助けを必要としている分野の場合は特に、イネーブリングチームはこのチームの現在地を理解して、少しずつ助けていくべきである。そして、2、3ヶ月後には、次のステップのための支援が必要になる。これは象牙の塔というよりはセンター・オブ・エクセレンス型のアプローチに近い。
つまり、イネーブリング・チームは現場にいるということ。象牙の塔のように「これは誰もが従うべきグッドプラクティスだ」というものではない。
チームがすでに過負荷状態にあるとき、彼らがガイドラインを受け取って変化を学ぶことを期待できるか。依存関係にならないようにハンズオン的なアプローチをする。他のチームと一緒に教え、他のチームを助けているが、彼らのために仕事をしているわけではないし、彼らのために納品作業をするわけでもない。
彼らが学び、知識を向上させるのを助けているのである。しかし、そのバランスをとるのは言うほど簡単ではない。
（※やったことがある人なら痛いほどわかると思う）
ただ単に「これは○○だ」と言うだけでは・・・、みんなが 「そうですね」と言うだけで終わるから。。。
イネーブリングチームに関しては、この本が出版されて以降、実際に採用する組織は出てきているようだが、より多くの疑問を生み出すチームタイプであり、なぜイネーブリング・チームに投資しなければならないのか、明確になっていないところも多い。
そもそもイネーブリングチームを作らなくてもいいのではないかという疑問もしばしばあって、他のストリームアラインドチームにいる人が、ファシリテーターとして他のチームを助けてもよいので、答えとしては「必ずしも作らなくてもよい」となる。
イネーブリングチームのインタラクションモード
ファシリテーションモードと呼ばれるモードでは、2週間とか1週間に1日とかのペースでファシリテーターを2、3ヶ月間続ける。プラットフォームチームは、インフラの自動化などの専門家でもあるので、場合によってはイネーブリングも行う。彼らは、単にプラットフォームを使うだけでなく、例えばインフラストラクチャの自動化に関するグッドプラクティスを理解するために、ストリームアラインドチームを支援することができる。
チーム内のギャップに臨機応変に対処するという考え方である。常にイネーブリングチームに頼って学習するのでは拡張性がない。イネーブリングチームが必要なのか、それとも他のストリームアラインドチームの助けやファシリテーションが必要なのか、あるいはプラットフォームチームの助けが必要なのか をその都度見つけ出す。
いくつかのオプションがある中で、どれがよいか確信が持てない場合は、イネーブリングチームを作ることになるが、それは必ずしも専任チームである必要はなく、最初に何らかのファシリテーションを行うだけでもやむを得ない。
プラットフォームチームは何であって何でないか
プラットフォームチームを持っている会社は多いが、それらプラットフォームチームが何をしているのかもまた必ずしも明確ではない。単にインフラを提供したり、アカウントを作成したり、Kubernetesのメンテナンスをしたりするだけなのか？
「プラットフォーム」という言葉はチームトポロジーにおいては明らかに過剰な表現というか何かに依存されるイメージになる。本来、独立して成果を出せるようなストリームアラインドチームを作るということであれば、仕事の実行中に依存関係があってはならない。
インフラをプロビジョニングしてもらったり、ファイアウォールやファイアウォールのポートを開いてもらったり、こういったリクエストベースの作業をするのではない。チームトポロジーのプラットフォームチームは、他のチームの代わりに何かをしたり、サービスの運用面を維持したりするチームではない。
普段我々が何かのプロダクトを使って生活を便利にするときのように、実作業の面でプラットフォームチームに直接依存することはない。もし依存関係が生じるなら、プラットフォームチームがリクエストに優先順位をつけなければならないという問題が発生し、チームが他のチームを待っているという矛盾が生じてしまうことになる。
高速なフローを実現するのが目的なので、こういった状況は最も脱却しなければならないものになる。この世界に存在する良質なプラットフォーム製品は高いユーザーエクスペリエンスと簡単な操作性を備え、フローをブロックするような依存性はない。それらをイメージするとよい。
繰り返しの表現になるが、依頼したことをプラットフォームチームがやってくれるのを待っているわけではない。
結論、プラットフォームとは"Platform as a Service"のPlatformであるという考え方になりそう。
プラットフォームのプロダクトマネジメント
ただし、プラットフォームをプロダクトにするという話は言うほど簡単ではない。社内に顧客がいて、プロダクトマネージャーが必要でサービスサポートも必要。
プロダクトロードマップを社内の顧客全員で検証し実行する。
それがプラットフォームチームにとっての主な困難の1つになる。プラットフォームの技術的な詳細を理解しているプロダクトマネージャーを見つけるのは容易ではないが非常に重要なことである。Paisたちは、ジュニア・プロダクトマネージャーではなく、最高の、より経験豊富なプロダクトマネージャーをプラットフォームに配置することを推奨している。[2]
そして強力なプロダクトマネジメントが必要なのは確かだが、やり過ぎないように注意することもまた必要となる。
巨大なロードマップを持つことになったプラットフォームチームが忙しすぎるために、ストリームアラインドチームと会話ができないとしたら、それは何か間違ったことをしている予兆だろうし、ロードマップが半年や1年のもので軌道修正の柔軟性がないとしたら、それもまた何かが間違っている。
プラットフォームチームのインタラクションモード
X-as-a-serviceモードでサービスを利用できる（e.g. 実際にAWSのエンジニアと話をしなくても、自分たちで仕組みを理解しサンプルを見て使えるようになる）。
それがプラットフォームチームの目指す地点ではある。
もう一つの必要なインタラクションモードは、ストリームアラインド・チームとプラットフォームチーム間のコラボレーションモードである。
ストリームアラインド・チームあるいはイネーブル・チームがプラットフォーム・チームに、「ここにはギャップがあるので、プラットフォームが何らかの機能やAPIで助けてくれると思う」と言ったりする。その場合、プラットフォームチームはストリームアラインドチームとアジャイルな方法でコラボレーションする必要がある。
プラットフォームチームの典型的なインタラクションモードは、この2種類。
この2つのモードを常に交互に繰り返すことになる。
安定していて使いやすいサービスがあり、新しい機能が追加されたとする。そこで再びコラボレーションモードに入ることになる。少なくともその機能については、再び使えるようになるまで、このサイクルとフィードバックが必要である。
再び安定すれば「これはX-as-a-Serviceだ」と宣言することになる。このサービスが社内で一般的に利用できるようになったとしても、サポートの依頼が多くなり、エラーが多発したりすると、「X-as-a-Serviceにするのが早すぎたのではないか」ということになる。そういうときが今一度、何が起きているのかを理解するタイミングだ。
それらのモードチェンジも含めて言えることは
プラットフォームが成功すればどのチームからも多くの要望が寄せられるようになるため、それを実現するには優れたプロダクトマネジメントが必要となる。
必ずしもプラットフォームチームがやらなくてもよいこと
ストリームアラインドチームが、既存のものとは別のツールや別のアプローチが必要だと考えている場合がある。彼らはそれが価値をもたらすと信じているからこそ、自分たちでコストをかけて実行するという選択肢があるべき。「いや、それはプラットフォームチームにしかできないことだ」などと邪魔してはならない。「インフラに関わることだから」と領域を守ろうとすべきではない。
ストリームアラインドチームが新しいアプローチを開拓することは可能で、むしろ意味がある。ただプラットフォームチームがいろいろな新しいツールを試すことに意味があるか？それは、プラットフォームチームの目的ではない。
あるクライアントの例で、さまざまな業界の広告を扱っている中のあるチームが、広告に動画を掲載する最初のチームになる必要があった。普通なら動画処理をサポートするプラットフォームをプラットフォームチームに依頼するのは理にかなっていると思うかもしれない。しかし、ある一つのチームのためにプラットフォームチームが最初に基盤を作ることは意味がない。そこではストリームアラインドチームが率先して、自分たちのニーズに合わせてこれを行うべきで、そのうち他のチームにも必要になるかもしれないその時に、このコードをプラットフォームに搭載して、他の多くのチームが使えるようにする。それができるかどうかを考えるのはプラットフォームチームである。
結局のところ、「これはプラットフォームチームにしかできない」というような厳しい境界線は設けないということになる。
チームトポロジーを適用できる規模は
小さなスタートアップではプラットフォーム・チームはないし、チームを実現するための資金もない。小さな組織では何ができるだろうか？
どんな規模でもチームトポロジーのアイデアを見知ることはできるが、違いがあるとすれば、見い出せるトポロジーの違いになる。もしチームが2つしかないとしたら、イネーブリング、プラットフォーム、ストリームアラインドチームは当然できない。
そのケースでのアイデアとしては例えば、2つのチームがあったとして、片方のチームは長く製品に関わってきた経験があるのなら、何がうまくいったのかを知っている。アーキテクチャへの意思決定がなぜ下されたのかなども。そのチームは、新しく作られたチームに知識を提供するのに適した場所にいるので、専門のイネーブルメントチームがなくても、イネーブルメントのアイデアは実現でき、トポロジーにはなる。プラットフォームについても同様。
プラットフォームとは、これらのサービスを利用するための優れたアプローチを文書化したwikiページのようなものであってもよい。
最善ではないにせよ、これにより各チームが「インフラをどうやってセットアップするか」への認知負荷が下がり、スピードアップにつながる。
トポロジーのスケールについて
ダンバー数では信頼の境界が150人とあるが、30人、40人、50人でも規模が大きくなってくると、力関係が変わってたり、作業量が増えて、すべてのチームで共有される知識が少なくなっていく。最初のうちはうまくいっていたものがうまくいかなくなる。
そのため、信頼の境界線を越えたときに、何がどう変わるのかを調べるとよい。うまくいかなくなったならイネーブルの方法を変えてみたり、プラットフォームチームが必要だったりするかもしれない。
終わりに
気になったところをメモっていたら、どれもよくて捨てられず随分長文になってしまった。。
最後の二つの章にもあるが、考え方自体はどのような組織でも適用しうるように思えるので、知識としてもっておくだけでも有効と感じている。感覚として「難しいだろうな」と思うところは「難しいところ」とはっきり言っていたので、このTeam Topologiesもまた銀の弾丸ではないよね。
そしてここまで書いていて、最後にTeam Topologiesの訳本が出版されるというお知らせがありました。
なんとタイムリー。興味をもった方はそちらを買いましょう。
Discussion