【書評】チームトポロジー: 価値あるソフトウェアをすばやく届ける適応型組織設計
最近はチームビルディング周りに興味津々なのと、タイムラインでよく見かけることもあって読んだ。
気づきメモ
- 認知負荷:人が把握できる量には限界がある→チームの守備範囲が広がりすぎると認知負荷が上がりパフォーマンスが落ちてしまう
- 全員が全チャットを見る、全ミーティングに出る、みたいなことが起きているなら組織設計に問題がある
- 組織の関係を考慮せずにツールを統一する、ということがあってはならない 管理や評価の都合で組織再編を
- 繰り返すのは悪手→業務を通して必要なコミュニケーションに基づいて組織は設計されるべき
- 新メンバーがこれまでのやり方や視点との違いを受け入れるには感情的な負担がある(これはタックマンモデルの混乱期のこと
適切な境界
- 3種類の認知負荷がある、1. 2. を早期に解消することで 3. にフォーカスできるように整えていく
- 課題内在性負荷:本質的な負荷(実装における課題など
- 課題外在性負荷:環境の負荷(デプロイ方法など
- 学習関連負荷:学習する上での負荷
- 認知負荷を抑制するためにチームが扱うシステムをや範囲を小さくする(分割と分担)
- 事例:あえてリードを無くし、チーム全体で判断させることでモチベーション向上が起きる
- Spotify モデルにおけるギルドのようなコミュニケーションが自然発生しやすい環境があることで、本来のチームにおけるコミュニケーションの練習が行われる
チームの分類
チーム | 概要 | 詳細 |
---|---|---|
ストリームアラインドチーム | エンドツーエンドで開発を行う | プロダクトや機能単位ではなく、ストリーム全体に沿うというあり方が必要になってきている |
イネイブリングチーム | 特定ドメインのスペシャリストチーム | ストリームアラインドチームが直面する課題解決を補佐する |
コンプリケイテッド・サブシステムチーム | 保守が必要な特定パーツやシステムのスペシャリストチーム | ストリームアラインドチームの認知負荷を下げるために特定ドメインの開発に責任を持つ |
プラットフォームチーム | 下位の内部サービスを提供する | 例えばサーバインスタンスの構築やセキュリティなどを管轄するサービスを提供する |
- 同一のチーム内で設計から開発、テスト、デプロイ、運用ができるべきである
- イネイブリングチームは能力向上が目的であり、短期の密接なコラボレーションを前提とする
- 技術視点のみで分割すると、透明性が下がりコミュニケーションが遅くなりリスクがある
チーム間インタラクションの分類
インタラクション | 概要 |
---|---|
コラボレーション | 他チームと密に連携する |
X-as-a-Service | 依存を最小限にして何かの機能を利用する |
ファシリテーター | 特定課題を解決するための支援や補佐 |
- インタラクションをあらかじめ形式化することで、チーム間で期待されるインターフェースを明確にできる
- コラボレーションは認知負荷が高くコミュニケーションが大量になる、その代わり素早く課題を解決する上で大きな推進力を得られる
- 約束理論:強制ではなく、セマンティックバージョニングの各数値が示すような約束事によって成り立つ関係性
- チームやインタラクションは固定すべきでない、自分たちの今の目的は何か?期待される速度は?を常に考えチームに反映する必要がある
- 特定のワークフローは特定の個人に割り当てられがちだが、分かっているのは誰かを軸に計画を設計すると作業フロー全体に悪影響がある
- 理想を言えばチームから見た外部依存を減らしたい、たとえば QA チームを作るとそこがサイロ化し、すべてのチームが QA チームを待たなければいけない状況になりがち
感想
ストリームアラインドチームという形で責任範囲を一気通貫させつつ、認知負荷を下げるというのが最初よく分からなかった。 おそらく、その分だけドメインを限定する(ストリームアラインドチームとしての責務定義)、技術領域を分割する(コンプリケイテッド・サブシステムチームへの委譲)ことを意識すべし、ということだと理解した。
インタラクションを命名するという考えは初めてだったが、それによりチーム同士の期待値(インターフェース)を明確にするというのは腑に落ちた。 現職でチームビルディングを考える際も、最低限相互に何を期待するか、どんな情報を同期するのか、という点を重視しながら検討を行っているため、ここに繋がるものを感じた。
QA チームの例は前職でも非常に感じたことだが、一方で各チームにアサインするほどメンバーがいないというのもあり、兼任する分いかに負荷を下げられるかという点が課題ではないかなと感じた。