はじめに
マシュー・スケルトン＆マニュエル・パイス著の「Team Topologies」を読み学んだことをアウトプットしてみます。
全体を通しての感想
自社のエンジニアが増え、チームの生産性向上に課題を感じはじめたのがきっかけ
なかなか難解だったが自分なりの解釈はできたように思う。
そして、自社で試してみたいことも多々あり、とても勉強になった。
振り返りを兼ねて、特に印象に残ったことをつらつらと書いていきます。
章ごとの感想
Chapter1 組織図の問題
「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」
というコンウェイの法則が初めて登場し、この書籍全体の軸となっている。
組織が設計に影響する？正直このタイミングではピンとこなかったが、読み進めていくうちになるほどと納得がいくようになる。
この章では「認知負荷」が印象に残った。今の自社組織を考えると、かなり高負荷状態に陥っていることに気付かされる。
Chapter2 コンウェイの法則が重要な理由
必要なソフトウェアアーキテクチャに一致するようにチーム設計する「逆コンウェイ戦略」
なるほど・・・
エンジニアリング組織をマネジメントする人は技術がわかってる人じゃないといけない。と言われる所以か
速いフローを実現するには、不必要なコミュニケーションを制限する必要がある。というのは、自社で感じていた課題感とも一致する。
チームの垣根を越えて助け合うという、今まで培ってきた組織文化を踏まえてどう向き合っていくか。
Chapter3 チームファースト思考
いわゆるピザ2枚ルール、そもそもそんなに人がいないと思ってたが、少しずつメンバーも増え、パートナーさんの存在も考えると、適切なチームサイズを保つことは気をつけておかねば。
「長続きする小さなチームを標準とする」なるほど
チームがソフトウェアのオーナーとなる。当たり前のようだけど、実際には難しい、でもSaaSベンダーとしてはとっても大切な価値観。
それを育むためにも、チームが扱うソフトウェアも適切なサイズにおさえないといけない。認知負荷、認知負荷、認知負荷。
業務量と釣り合わない余裕の無さは、ここが大きく起因してるような気がしてきた。
チームAPIという言葉も新鮮だった。
デリバリーの基本的な単位はチームである。だからチームAPIを設計してチーム間の交流を促進していく。個人対個人ではなく、あくまでもチーム対チーム
AWSでは厳格なチームAPIを採用してるとのことで、説得力がある。
Chapter4 静的なチームトポロジー
意識的ではないがアンチパターンは回避できてるようだ。
変更フローへの最適化については、本番システムからの情報を開発チームが受け取れる状態にはなっているが、正直それは課題だと思っていた。
チームがもっと開発に専念できるようにするには？→運用を別チームに切り離した方がいい。
というのは短絡的だったと反省させられる。
私にとってこの章がとても難解に感じるのは、DevOpsの理解が圧倒的に足りないからだろう。
それでも、自社がセオリーを大きく外していないのは、技術統括室長がさりげなく促してくれているからだろう。さすが頼りになる。
Chapter5 4つの基本的なチームタイプ
この書籍の肝となる章、「ストリームアラインドチーム」「イネイブリングチーム」「コンプリケイテッド・サブシステムチーム」「プラットフォームチーム」が説明されている。
4つのチームにはそれぞれ役割があるが、「速いフローの実現を目指してストリームアラインドチームのエンパワーメントに注力する」という共通目的があり。
シンプルかつ明快、生産性を高めるってそういうことだよね。自社組織も今後この4つのチームタイプに明示的に割り当てていこうと思う。
ストリームアラインドチーム
なるべくこのチームだけで価値を提供できるようにする。
そのための能力一式をチームに備える必要があるが、個人ではなくあくまでもチームで。人数が限られる自組織としては意識しておきたいポイント
「you build it, you run it」自社事業としてやっているとこうならざるを得ないが、これ自体が悪い訳ではないというのは大きな収穫
イネイブリングチーム
特定テクニカルのスペシャリスト集団、そのスキルによってストリームアラインドチームの進化を手助けする。
別称の「テクニカルコンサルティングチーム」がイメージしやすい。
ストリームアラインドチームとは数週間〜数ヶ月の短期間の関わりが理想。確かに長期になるとチームに組み込まれ技術支援ではなく業務代行になってしまいそう。
自社に照らすとSREやQAがこれに該当するように感じる。但し関係者内の共通認識に閉じてるのでオフィシャル化していかねば。
コンプリケイテッド・サブシステムチーム
スペシャリストの知識が必要となるパーツの開発・保守を専任するチーム
今のところ、これを必要とするような技術は自社には存在しないが、それこそが課題。
プラットフォームチーム
内部サービスを提供することでストリームアラインドチームの認知負荷を下げる役割で、まぁ名称のままのチーム
組織が拡大してくると、このプラットフォームチームが4つのチームタイプを内包し、入れ子の構成になることもある。
利用者つまりストリームアラインドチームに対してのUX・DXにフォーカスすることが重要
自社の場合、技術統括室が担ってくれているいくつかの機能を、このチームタイプとして配置することができそう。でも人がいないな・・・
Chapter6 チームファーストな境界を決める
適切な境界を決めないことでオーナーシップの欠如・エンゲージメントの低下・デリバリー速度の極端な低下を招く。
モノリス（1つの石）にはいくつかの種類がある。
アプリケーションモノリス・データベース結合モノリス・モノリシックビルド（すべてをリビルド）・モノリシックリリース（すべてをまとめてリリース）・モノリシックモデル（画一的な視点）・モノリシック思考（標準化）・モノリシックワークスペース（オープンプランオフィス）
自社も既に該当するものがちらほらあるが、特にモノリシック思考については、このタイミングで学ぶことができてよかった。
生産性を高めるために標準化を推し進めていかねばと考えていたが、それは浅はかだったようだ。標準化を錦の旗にしてはならない。自由度を抑制することによって生産性とエンゲージメントが損なわれるのであれば本末転倒だ。
しかし、それには責任が当然ながらセットとして求められる。「you build it, you run it」
ソフトウェアを簡単に複数に分割できる自然な継ぎ目を「節理面」と言い、ビジネスドメイン・規制遵守・変更のケイデンス（頻度）・チームの地理的配置・リスク・パフォーマンスレベル・技術・ユーザーペルソナなどがある。
今後分割する際や、既存チームの見直しを行う際には参考にしたい。
Chapter7 チームインタラクションモード
Fortniteでおぼえた「インタラクション」という言葉、直訳すると相互作用
インタラクションにはコラボレーション・X-as-a-Service・ファシリテーションの3つのモードがあり、速いフローを実現するために、チームタイプや状況に応じて使い分けが必要。
目的達成のために他チームとコラボするのか、他チームをサービスプロバイダーのように扱うのか。
コラボレーションモードが、密なコミュニケーションを必要とする新システムの初期フェーズ等に向いてるというのはしっくりくるし、無意識的にそういう体制を組んできた。
意識すべきは、徐々に疎結合にしていきX-as-a-Serviceモードに移行していくことだと思う。
また、X-as-a-Serviceモードがうまく機能するのは「サービス境界が正しく選択・実装され、サービスを提供するチームが優れたサービスマネジメントを実践している場合に限られる」という文面にはすごく納得した。
これが担保されていないとチーム間のコンフリクトを招き、生産性はむしろ落ちるように感じる。
Chapter8 組織的センシングでチーム構造を進化させる
達成することに応じてインタラクションモードを変化させるという前半部分は、前章の繰り返しのように感じたが、「意図的に」が重要であることを伝えたいのだと理解した。
チームが「自分たちは何を発見しようとしているのか？どのくらいの速さで？」を自問して、それに適したインタラクションモードを自分たちで選択する。それによって認知負荷がおさえられ、チーム内のエンゲージメントが高まる。
自社では、まず本書で書かれているチームタイプやインタラクションモードの概念を浸透させた上で、チームへ自律的な変化を促していくステップを踏む必要がある。
チーム再設計のきっかけとして挙げられていた「ソフトウェアが大きくなりすぎている」「デリバリーのリズムが遅くなり始めている」「大量の下位サービス群に依存している」は納得。
しかし、突然その状態になる訳ではないので、検知するための仕組みが必要
そこで活躍するのが高精度な入力センサー。運用部門から提供される可用性・信頼性・ユーザビリティ・セキュリティなどの情報をそれに位置付ける。
自社に照らすとビジネス部門から得られる情報もそれに類すると考える。
ソフトウェアは「ユーザーのプロダクト」というより「ユーザーとの継続的な会話」として期待されている。
全く同意だが、「保守」または「通常業務」チームを別でつくるのはフィードバックループを壊すというくだりには焦った。
プロダクトのフェーズごとにチームを分けた方が生産性は高まるのではという仮説を持っていたため、考え直すための貴重な学びをもらった。
Chapter9 次世代デジタル運用モデル
全体のおさらいと、チームトポロジー以外の大事な要素と、チームトポロジーの始め方
チームトポロジー以外の大事な要素として挙げられているのは「健全な組織文化」「良いエンジニアリングプラクティス」「健全な投資・財務プラクティス」「ビジョンの明確化」
2割出来てる、8割出来てないって感じかなぁ。
その課題にも向き合いつつ、チームトポロジーの始め方に従って、実際に取り組んでいこう。
迷わず行けよ、行けばわかるさ。