開発チームをどう配置させどう動くか？
困ってはいませんか？
私は困りました、というより、チームが困りました。
チームをどう配置させどう動くか
私たちの開発チームは0->1のプロダクト初期を乗り越え、これからビジネスとしてもプロダクトとしても大きくなろうとしているタイミングです。
このときに、チームを分けるか？と唐突的な問いにぶつかりました。
チームをわけないと、人を増やせない、はある程度の経験則ですが、
- ほんとうに私たちのチームはチームを分けていくべきか
- そうすると、どう分けるか？
- 分けてどう運用していくか？
といったことに解が出せませんでした。
そこで手に取ったのが、「チーム・トポロジー」でした
チーム・トポロジーの内容
一言で言うと、ハイパフォーマンスで継続的デリバリーを可能にするプロダクトチームを組成するためには、逆コンウェイ戦略でチームを設計しよう、ということ
コンウェイの法則=チームの組織図がプロダクトの設計に反映されるというもの
つまり、チームトポロジーとは、あるべきるプロダクトの設計、構成に合わせて組織を構築せよ
チームのサイズには限界があり(ダンバー数)、単一チームが取り扱える認知負荷には限界があると知る必要がある
日々の個人間のコミュニケーションよりチーム間のコミュニケーションを重要視する
チームトポロジーの考え方では、チームを4つのシンプルな役割に沿って分けるのが、モダンな開発と運用のためには有効だと考えている
- ストリームアラインドチーム
- イネイブリングチーム
- プラットフォームチーム
- コンプリケイテッド・サブシステムチーム
イネイブリングチームは、ストリームアラインドチームが持ち合わせていない必要な能力を獲得するのを助けるチーム
ストリームアラインドチームに依存し続けていると、イネイブリングがうまくいってないと捉える
支援なのでペアワークという手法は向いてる
コンプリケイテッド・サブシステムチームは、複雑なシステムを利用する際のイネイブリングの認知負荷を下げることを目的とする
習得や育成が難しい領域を担当する
プラットフォームチームは、ストリームアラインドチームが自律的に価値を届けられるようにすることを目的とする
そのために内部サービスを提供しストリームアラインドチームの下位のサービス開発を不要にする
コラボレーションモード
ある分野や領域においてアウトカムを最大化させるために、2つのチームが1つのことを共に作業をする方法である
- 責任境界が不明瞭になりやすいので、2チームどちらもが結果責任を共同で負うことが大事
- コストは高いが得られるアウトカムも大きくなるモードである
- 成果を確実に出さなくてはならない
X-as-a-Serviceモード
デリバリーチームが最小のコストで最大のリターンを得られるように、サービスを提供する方法である
- コンポーネントやAPIを提供する
- 提供する側でプロダクトマネジメント(ドキュメント管理、サービスのバージョン管理等)が適切に行われていることが重要
- オーナーシップ(=お互いの責任の境界)が明確になっていて、デリバリーチームはサービスについて小さな認知負荷で効果を得られる
ファシリテーションモード
他の多くのチームへ支援と能力を提供し、生産性と有効性を高めるための手法
- 1つ以上のチームが、作業の一部をサポート、コーチしてもらう場合に適している
- より早く学習し、より早く実現する、より簡単に障害を取り除く責任が生まれる
4つのチーム、3つのインタラクションモードを適応したところですぐになにか結果が変わることはない
長い時間と努力を経て、ビジネスに適合していきはじめていい組織状態になる
用語関連
- コンウェイの法則
- 組織の構成によってプロダクトの設計や構成は決まる、という経験則
- 認知負荷
- 小さなチームが作れずすべてを担当するチームでは、「知っていなければならない」という認知負荷が高くなってしまう
- 7〜9、最大15人くらいが、認知や尊敬、失敗を許容しあえるチームの最大数である
- 時にはコミュニケーションを制御することも大事
- 深索ではなく実行が求められる領域では、コミュニケーションは不必要なオーバーヘッドになりうる
- ボーイスカウトルール
- 自分が来た時もよりもコードを綺麗にして帰る
- これをしなければ時間と共に技術的負債が溜まったいく(というより、しなくても負債は溜まっていくと考える方が筋が良いため、リファクタリングをついでにしないと負債の量は1.x倍になる)
- サイトリライアビリティエンジニアリング(=SRE)
- ソフトウェアエンジニアに運用機能の設計を依頼したとこに起こること
