こんにちは。Mirai Translator 開発チームEMのchika (@chika-mirai) です。
今回は書籍「チームトポロジー 」（通称：ちいとぽ）を読んだのでその感想エントリです。
本書は昨年末頃の書籍プレゼント企画に個人的に応募して運良く当選した結果頂いたものですが、3ヶ月かかってようやくブログ投稿にこぎつけました。
#ちいとぽ 読んだよ！とようやく言えます。
プレゼントいただいたアトラクタさん、ありがとうございました。
これはどんな本？
本書の概要は、翻訳者である吉羽さんのお知らせエントリを読むのが早いのですが、 一言で言えば、ソフトウェア開発チームの構成・配置に関して書かれた本で、「実践的で段階的かつ適応型の組織設計モデルを提供する」ものです。
この感想エントリを書き始めたところ、「チームトポロジーを成功させる実践方法の探求」というイベントが3/16に開催され、そこで 吉羽さん(@ryuzee) が本書の内容を30分にまとめて話すという神セッションを披露されていたので、上記お知らせエントリと併せてこのセッション動画を観るのが最速で概要を掴める（読んだ気になれる）方法と思います。
↓セッション資料
また本書「はじめに」によると、 チームトポロジーの狙いは「明快なパターンを提供すること」であり、「飛び抜けて優秀なプレイヤー向けの指示書ではなく、様々なチームや組織が取り入れたり応用したりできるようなわかりやすいもの」とされています。
ソフトウェア開発組織のためのデザインパターン
これまでのソフトウェア開発チームは、一般的な事業組織と同じく縦、横、マトリックス、プロジェクト、タスクフォースのような従来の組織構造をベースに複数の「○○開発チーム」（縦割り）と「インフラチーム」や「QAチーム」（横断）のような職能別に分けた組織が作られたり、所属組織とは別に各々のチームから人を集めて「▲▲プロジェクト」が作られたり...ということが一般的で、ソフトウェア開発という事業を踏まえた特別な組織設計手法が確立されてはいませんでした。
また、うまくいっている組織設計の事例や、多くの企業で抱える開発組織の課題について語られることはあっても、それを踏まえて汎化されたノウハウになることは無かったように思います。
もはやそれが普通だとすら感じていたところに、DevOpsなどの現代的な開発を踏まえた組織設計モデルを登場させた、という点で本書はとても画期的だと感じます。
また、チームトポロジーが面白いのはソフトウェア開発チームを設計する共通言語（パターンランゲージ）を提供していることです。つまり、チームトポロジーを学べば、ソフトウェア開発チームの設計や変化のしかたについて一般化して人に伝えたり、他社と比較して課題を見つけたり参考にしやすくなるという期待も出来ます。
開発組織のデザインパターンといえばチームトポロジー、と言われるようになるかもしれません。
取り上げたい話題
本書における重要なキーワードはいくつかありますが、自分の印象に残ったポイントを以下順番に挙げていきます。
不必要なコミュニケーションの制限
「隣のチームで何をやっているかよくわからないんですよね」
「うーん、じゃ週1回お互いの状況を共有するMTGを設けますか」
これは結構日常的にやってしまいそうなシーン。縦割りになっているチーム間の接点が希薄になるのを恐れて接点を増やすことが「コミュニケーション設計」の一環だと思い込んだりしがちですが、本書の一節を読むとそれが安易な考えであると戒められます。
「全員がすべての人とコミュニケーションする必要はない」（Chapter 2）
コンウェイの法則は、こういった多対多のコミュニケーションは、速いフローをサポートしない、モノリシックで、こんがらがっていて、結合度が高く、相互依存するシステムを生み出す傾向にあることを示している。コミュニケーションを増やすことは必ずしもよいことではないのだ。
隣のチームと話す機会が減ると何をしているか分からずどこか不安に感じることがありますが、それは一方の活動が他方に影響する恐れがあるからであって、それぞれのチームがお互いにブロックせず開発フローが流れているのであれば何の問題もないとも言えます。
また、先日 ファインディ社主催のエンジニア組織づくりに関するトークセッション の中で 言及されていたことですが、リモートワークがベースとなった今では組織のサイロ化は起きて然るべきだとみんな気づいてきています。サイロ化を受け入れた上で情報共有の仕組みを構築する必要があります。結果的にMTGを設けることもありますが、安易にコミュニケーションパスを増やすとMTG地獄になるため、どのように開催するか、そもそも本当にMTGが解決手段なのか、よく考える必要があります。
認知負荷
Chapter 3では「チームファースト」としてチームパフォーマンスを上げること、そのために小さく長続きするチームを作ることの大切さを説いています。
その中で印象に残ったキーワードが認知負荷。
認知負荷は人間が一度に扱える情報量（ワーキングメモリ）に対する負荷のことですが、チームの責任範囲を適切に制限して認知負荷を下げるよう努めないとチームのデリバリーのボトルネックになるのはもちろん、メンバーのモチベーション低下、離任につながってしまうというわけです。
認知負荷が上がる要因は様々なものがありますが、チームとコードベースの対応についての以下2点の言及が特に印象的でした。
「複数のチームに同一のシステムまたはサブシステムの変更を許すと、その変更と、変更がもたらす混乱について、誰もオーナーシップを発揮しなくなる危険がある」
「チームが複数のコードベースを扱うとオーナーシップを失うだけでなく、システムを理解し健全に保つための心理的な余裕も失ってしまう」
（いずれも Chapter 3 より）
これを読んだとき、見透かされているのかと思うほどリアルに想起される場面が頭に浮かび、メチャクチャ刺さりました。
サービスが成長して組織の規模が大きくなりチームを分けることになってもコードベースが小規模の頃から変わらないというのはよくありますが、そうするとチームとコードベースが N対N という関係になりこの問題が起きてしまいます。
チームを再編する場合にコードベースやアーキテクチャもそれに合わせてガチャッと変えられるわけではないのですが、可能な限りチームとコードベースの関係を1対1にするためにどうするかを考える重要性を改めて感じた次第です。
フルサイクルエンジニアリングと認知負荷
また、認知負荷を下げるべし、という指摘で一つ思い出したことがあります。弊社開発チームで掲げているフルサイクルエンジニアリングについてです。
雑に表現すると「チームで開発のフルサイクルにコミットする」という方針なのですが、単に1チームで開発全工程を担当すべし、みたいに考えてしまうと認知負荷を増大させてしまう一方なので、担当するドメインや1回あたりの開発サイズを小さくすることが重要になってきます。
これまではこの「担当範囲を小さくする」という重要性は感覚的なものでしかなかったのですが、認知負荷の問題はそれを見事に言語化しているような気がしました。
チームトポロジーの前提
チームトポロジーとは何たるかのコアとも言える「4つのチームタイプと3つのインタラクションモード」。この説明がされるのはPart II、Chapter 5 になってから。
なぜそんなにもったいぶる(?)のかと考えましたが、これはチームトポロジーを用いた組織設計には2つのことが前提として求められるからだと理解しました。
1.コンウェイの法則を理解していること
1点目は、お知らせエントリにもある通り、本書の主旨が「逆コンウェイ戦略の実現」なので、そのためにはまずコンウェイの法則に対する理解が必要ということです。
Part I （Chapter 1〜3）ではコンウェイの法則についてかなり丁寧に説明しています。
これまで私はコンウェイの法則で言及される、組織構造を真似てしまう「アーキテクチャー」とは何なのか？逆コンウェイ戦略を実現するのに考えべきアーキテクチャーの要素とは何か？という点について、単に「チーム境界がドメイン境界になるから適切に分けましょう」という程度の理解だったのですが、この Part I を読んで、自律・独立したチームになるように分けることと、チーム間の適切なコミュニケーションパスを設計することが重要なのだと理解しました。
2.スモールチームで価値をデリバリー出来ている（アジャイルチームである）こと
2点目は、Chapter 3 で「チームファースト」として色々と説明されている内容で、また 69. チームトポロジー(前編) w/ miholovesq | fukabori.fm で翻訳者の1人である永瀬さん (@miholovesq) が「アジャイル開発とチームトポロジーの関係は？」という質問に対して「スモールチームでアジリティのある動き方が出来ていることが前提」と答えていました。
もともと認知負荷が高くてデリバリーが遅いという場合は、まずはアジャイル、DevOpsを基本とした小さなチームを作り、長く安定させることから始める必要があります。
この前提を自信をもってクリアできていると言えるチームはそれだけでかなり良いチームでは。笑
4つのチームタイプと3つのインタラクションモード
と、ここまで引っ張って満を持して説明されるチームトポロジー、4つのチームタイプと3つのインタラクションモードとは？
お知らせエントリに簡単にまとめられているのを参照すると以下の通りです。
4つのチームタイプ
- ストリームアラインドチーム : ビジネスの主な変更フロー（つまりバリューストリーム）に沿って配置するチーム。職能横断型で、他のチームを待たずにデリバリーできる。いちばん中心となるチームタイプ
- プラットフォームチーム : インフラやツール、共通サービスなどを提供するチーム。これによってストリームアラインドチームは詳細を知る必要がなくなり認知負荷が下がる
- イネイブリングチーム : 他のチームが新しい技術やスキルを身につけるのを支援するチーム。永続的に支援するのではなく、短期的な支援となるのが普通
- コンプリケイテッド・サブシステムチーム : 名前のとおり複雑なサブシステムやコンポーネントを扱う専門チーム。必要なときだけ構成する
どれもカタカナだと噛みそうで脳が拒否しそうな名前ですが、説明を見ると多くの開発組織で「なるほど、うちはコレとコレだな」と思えるほど見事にパターン化されています。 ちなみに、ストリームアラインドチーム は ストリーム"アイランド" チームと誤解されるケースが多いようです。笑
3つのインタラクションモード
文字通りチーム間の協業の形やコミュニケーションの仕方が定義されているわけですが、これらは固定的な関係を表すのではなく、チームの状況によって変えていくものだということです。
チーム設計例
これらの組み合わせは書籍の中ではカラフルな図で表現されています。図のフォーマットは Team Topologies の 公式サイト で使われているものですが、その中にあるクイックリファレンスカード（QRC）について、角谷さん(@kakutani) が日本語版を作成され QRC Team Topologies-ja として公開されているので参考になります。
また、チームタイプとインタラクションの説明、基本的なチーム連携の例と進め方、他社のチーム構造例、実践する際の課題などがうまくまとめられた資料があったのでこちらもとても分かり易くおすすめです。
チーム設計のための豊富なテンプレート
なお、このチームトポロジーの図のテンプレートはGitHubで Miro 、Figma、パワポ など様々なお絵描きツールに対応したものが公開されているため、同じフォーマットで自分のチームのデザインをするのに使えます。
今の自社の開発チーム編成は4つのチームタイプと3つのインタラクションモードに当てはめるとするならどう表現されるだろうか？というのは読者なら気になるところです。すでにRettyさんでやっている例を見かけましたが（以下）、今度自分も描いてみてチーム内で話してみようかなと思います。
チームトポロジーの進化
最後に、当たり前かもしれないですがチームの状況とタイミングに応じてチーム構造を進化させるべきということをちゃんと意識していなかったなと感じました。
単にメンバーの増減や事業拡大等によってチーム構成を変更する必要性に迫られるということはありますが、チームの認知負荷やデリバリーの速度を観測してチームを再設計するというアクションがチームの進化には必要です。
また頻繁な変更は禁物であるにしても、一度設計したチーム構造は変えてはいけないわけじゃないので、失敗を恐れずに変更することも重要だと改めて思いました。
おわりに
チームトポロジーは「明日から使える」特効薬のようなものではないですし、本書を読んでいきなり大掛かりな組織変更を考えるようなことはしてはいけませんが、Mirai Translator 開発チームでも今後リーンな開発を目指すチームを作っていく上で、チームトポロジーの考え方は適宜参考にしたいと思います。
みらい翻訳では、私たちと一緒にチームを進化させるエンジニアを募集しています！
ご興味のある方は、ぜひ下記リンクよりご応募・お問い合わせをお待ちしております。
