『チームトポロジー』を読んだ
原著の『Team Topoligies』を昨年、 Twitter のタイムラインで何度か見かけていて、読もうかなと興味を惹かれていたのだが、ありがたいことにそのタイミングでちょうどよく翻訳版が出てくれたのでそちらを読んだ。
興味を惹かれた理由としては、 SRE としての価値最大化を考えていると、組織論を外すことができないという問題意識が強くなっていたから。SRE は開発速度と信頼性のバランシングが責務となるはずだが、専任の SRE チームとして組織すると開発チームとの間でコミュニケーション上のロスが発生し得る。ならば開発チームの中に SRE が属すれば良いかと言えば、 SRE 間の横のつながりも必要なのでそう単純な話でもない。このあたりの SRE チームの構造に関する問題は SRE at Google: How to structure your SRE team | Google Cloud Blog にも言及があるが、ソフトウェア開発全体というレイヤーから組織論を学ぶことで、何かヒントを得たいと考えていた。
追記（2022-01-16 11:05）
昨年、原著を Twitter 上で見かけていた背景として、 State of DevOps Report 2021 で言及されていたというのが大きかったのかもしれない。
チームトポロジーとは何か
トポロジー、直訳したところの「位相幾何学」はちょうど最近大学でも学んだところだが、ネットワーク・トポロジーという言葉もあるし、動的に変化する構造、ぐらいの意味で使われているように思う。チームトポロジーとは、組織や技術の成熟、進化に合わせて、チームの構造も継続的に進化させていく動的なアプローチを指す。
チームの構造を考える上でのキーとしては、認知負荷とコンウェイの法則が繰り返し出てくる。チームの人数はダンバー数を反映して、適切な関係を保てる人数に維持しなくてはならない。またチーム間の関係性もまた、認知負荷を引き下げるべく、何かを共有するのではなく、適切に分離された状態が求められる。本書では API を模した「チームAPI」と呼ばれる仕組みを、他チームからのコミュニケーションの窓口として設けることを提唱している。
そして組織構造を考える上では、コンウェイの法則もまた考慮する必要がある。疎結合で凝集性の高いソフトウェアアーキテクチャとしたいのならば、組織構造もまた、それに倣ったものでなくてはならない。
プラットフォームチームを兼任する SRE チーム
チームの役割を曖昧で無制約なものとしないために、本書では各チームを4つのチームタイプに当てはめることを提唱している。そのうち、ストリームアラインドチームは従来フィーチャーチームなどと呼ばれていたような、あるドメインの開発からリリースまで一気通貫に実行できるチームタイプを指す。また、プラットフォームチームは、ストリームアラインドチームが下位のレイヤー（インフラストラクチャーなど）を意識する必要を減らすために、横断的な内部サービス提供を行うとされる。
SRE チームは、このストリームアラインドチームの特殊な類型の1つとされている。横断的なチームであり、各ストリームアラインドチームとコラボレーションしながら、ソフトウェアの変更が適切なストリームに則るようサポートを行う。確かに SRE book でも、 SRE は各プロダクトに常時関わり続けるわけではなく、必要になった段階でコミットし、自律的に信頼性が維持されるようになればコミットを終えるといった動的なサイクルを辿る者とされている。
ただ僕自身もそうだが、国内の SRE チーム（国外の情勢は詳しくない）はインフラチームが改組したもの、インフラチームの役割を兼ねているものが多く、チームトポロジー掲載のチームタイプで言えば、プラットフォームチームの性格を持っている場合が少なくない。言うなればプラットフォームチームと、ストリームアラインドチームの一端とを兼ねた状態になるわけだが、本書に照らし合わせればこれはあまり良い状態とは言えないのだろう。
プラットフォームチームと、ストリームアラインドチームとしての SRE を完全に分離している例としては、僕が知っている範囲では国内ではメルカリが実現している（参考 : どのようにPlatformチームの組織変更をしたか | メルカリエンジニアリング）。しかし、これは人数を必要とする構造であり、特に小さい開発組織では容易なことではない。現実的には、例えば SRE チームがプラットフォームチームとストリームアラインドチーム双方の性格を持ちうることを受け入れつつ、プラットフォームチームに関してはなるべく開発チームとの関係性を疎結合に保ち、密なコラボレーションは SRE としての責務に集中させるなど、 SRE のような横断的なチームについては、その構造とコミュニケーションパスをより深く考える必要があると感じた。
運用からのフィードバックの重要性
個人的に、本書で最も重要なポイントは組織構造を「動的」なものとして捉えるという点だと思っている。そのために、組織構造を変化させる必要のある状況に的確に気付く、「組織的センシング」の必要性が説かれている。
その1つとして、運用から開発へのフィードバックが重要だとされている。これもまた SRE の役割として考えなくてはならないことのひとつだ。 SRE は Embedded な形ではないにしても、適切に開発チームへフィードバックができる状態は保っておく必要がある。 SLO はそのものずばり、運用フェーズから開発へとフィードバックされる、客観的に可視化された指標に成り得るものだし、 SRE が積極的に開発チーム（ストリームアラインドチーム）へ介在しなくとも、アラートやレポートによって、ストリームアラインドチームが自律的にフィードバックループを回すための仕組みとして機能し得るのではないだろうか。
Conclusion
本書は必ずしも目新しい話ばかりというわけではない。ストリームアラインドチームは、自律性やオートノミーを持ったチームとしてもしばしば耳にしてきた覚えがあり、『Scaling Teams』 などでも言及されているなど、個々の概念自体は従来から存在してもいる。ただ、チームをトポロジー = 動的構造として見ること、認知負荷の観点から適切な構造を探ることなど、既存の組織論をよりもう一歩踏み込んで実践させるための書だと感じた。
いろいろと書いてはみたが、組織論である以上、個人で知見を持っていても仕方ないことであるのも事実であり、仕事の中でも必要に応じてこういった知見を共有しながら検討は進めていきたい。