こんにちは。OLTAの柴田です。 おじさんは筋トレ、ランニング、登山が好きなのがずっと不思議だったのですが、僕も35を超えたら全部始めていました。時間の流れを感じます。
それはそれとして、先日、チームトポロジーという本を読んで社内に共有しました。せっかくなので、テックブログにもまとめて共有しようと思います。先日とはいっても数ヶ月前なのですが・・
チームトポロジーとは
最近(とはいっても2021年。原本は2019年です）出版された本の名前です。ソフトウェア開発に特化した組織設計論で、原則+パターンのようになっていて、デザインパターンみたいな感じです。マシューさんというコンサル会社の人が書いています。なので、Google流〇〇のような組織のコンテキスト依存が強い本より汎用的だと思いました。汎用的な代わりに抽象的です。どう実践するかは自分で考える必要があるなと思いました。
また、ソフトウェア開発の文脈に閉じていることに注意が必要です。会社全体の組織論をカバーしているわけではありません。チームトポロジーを使って営業組織を作ることはおそらくできません。
エンジニアが知っておく必要はあるかどうか
ありません
〜〜興味がない人はここで終わり〜〜
詳しく知りたい人向け
以下のリソースが非常に参考になりました。 書籍は細かいニュアンスをリファレンスとして参照するような使い方でもよいのではないかと思います。
30分でわかるチームトポロジー
fukabori.fm チームトポロジー回
このリソースを読んでください、だとこの記事は終わってしまうのですが、せっかくなので、この記事では私が重要だと思ったキーワードを紹介します。
紹介すること
- 逆コンウェイの法則
- チームファースト
- 認知負荷
- 4つのチームタイプ
この４つを紹介します。
逆コンウェイの法則
「システムを設計する組織は、そのコミュニケーションを真似た構造の設計を生み出してしまう」というのがコンウェイの法則です。1967年にプログラマーのコンウェイさんが発表しました。システムのアーキテクチャと組織構造が対立すると、後者が勝ってしまう、ということです。ソフトウェアの設計、開発に携わったことがある方であれば、一度は身に覚えがあるのではないでしょうか・・？
逆コンウェイの法則は、このコンウェイの法則を逆手にとり、望ましいシステムアーキテクチャをまず考え、それに合わせて組織設計すればうまくいく、という方法論です。望ましいアーキテクチャはどこの誰が考えるのか、とか突っ込みどころはある気がしますが、実用的なので受け入れられてるようです
チームファースト
現代のソフトウェア開発で、1人で全てを担当して価値を出すことはほぼ無理です。(フロント、バックエンド、インフラ、デザイン、ビジネス、スケジュール管理、etc…)ただ、チームとしてはその全てを担当できるのが望ましいです。
チームとは5~9名の安定したグループのことです。こうすることで、プロダクトのオーナーシップをチームで持つことができます。メンバーのマインドセットもチームファーストになるようにします。安定したチームを作って、そこに仕事を流し込む、という考え方がチームファーストです。
仕事があって、そこに人をアサインする、だと後述の認知負荷の問題もありなかなか機能しません。
認知負荷
「ワーキングメモリで利用される心理的労力の総量」として提唱されたものです。扱うコードが複雑で巨大になっていくと認知負荷が上がっていきます。これはソフトウェアデリバリーが遅れる要因になります。
チームトポロジーでは、この認知負荷を減らすようにチーム、システムをデザインしていきます。チームの分割、システムの分割を考える時に使います。
認知負荷が厳しい例としては
- 単一のコードベース + その全領域で使われるutilクラス
- コンテキストが全く異なる複数のプロダクトを保守、開発しないといけないチーム
があります。
4つのチームタイプ
チームは4つに分類できる、ということになっています。
- ストリームアラインドチーム
- イネイブリングチーム
- コンプリケイテッド・サブシステムチーム
- プラットフォームチーム
ストリームアラインドチーム
いわゆる機能開発を行うチームです。「ストリーム」は、ビジネスドメインや組織の仕事の継続的な流れのことです。「ストリームアラインド」なので、ストリームにそってチームを組成します。「プロダクトチーム」「フィーチャーチーム」ではありません。
🙅♀️：全社統一フロントエンドチームを作って、UIタスクを全てそこに放り込む
🙆♀️：開発チームで、フロントエンド、バックエンドのタスクを行う（フロント、バックエンドでストリームは分かれてない）
イネイブリングチーム
特定の技術のスペシャリストで構成されたチームです。ストリームアラインドチームの能力向上を助けます。ツール、プラクティス、正しい情報に基づく提案などを行います。
コンプリケイテッド・サブシステムチーム
ストリームアラインドチームで開発するといっても、何やってるか理解するだけでも専門的な知識が必要なパーツはあります。そういう時に作るチームです。システムの中でスペシャリストの知識が必要なパーツを開発、保守する責任を持ちます。画像・動画処理、数理モデルなどです。
このチームを作るかどうかの判断基準はストリームアイランドチームの認知負荷です。
プラットフォームチーム
ストリームアラインドチームが自律的に仕事を進められるようにするのが目的のチームです。開発チームが開発を自律的に進められるためのプラットフォームを提供します。アプリケーション開発に専念できる環境を提供する、というゴールになることが多そうです。インフラチーム、SREチームと似てるが別概念です。
OLTAでは
取り入れてるわけではありません。本を読んでストリームアラインドチームを作るぞ！！とかやるのは超アンチパターンだと翻訳者の方も言っていました。新しいチームを作る時に、認知負荷などの概念は参考にした程度です。(このチームがうまくいっていないのは認知負荷高すぎなのが原因なので責務をばらそうなど
組織、事業のフェーズ変わってくると今の形では対応できなくなってくる部分が出てくるので、必要に応じて取り入れていこうとは思っています。
ソフトウェア開発を行う組織を作る時に、なんとなくうまくいくパターン、そうじゃないパターンを言語化してくれてるので、頭を整理する意味で使うと良さそうです。
また、これは社内のエンジニアチームに伝えたことなのですが、最高のマネジメントと最高のチームを作っても、自分の技術力以上のものは出来ない、という事実から目をそらさないようにするのが重要なのではないかと思っています。ビジネス要件を整理して、認知負荷が低いチームを作って、余裕のあるスケジュールをひいても、技術力が低いと結局品質が低いものしかできません。
当面私の時間はソフトウェア開発を行える環境を整えることに使っていこうと思うので、OLTAのエンジニアは自分の技術力を磨いてチームで成果を出すことに集中してもらえるとよいなと思っています。
