チームトポロジー [PART1] 読んだまとめ


全体の構成

基本全部読んで欲しいという前提のもと、読み方を最初に書かれている。

チームタイプの違いとどのチームが効果的かを明らかにしたい: 1→4→5
大規模でモノリシックなソフトウェアシステムを分割したい: 6→3
ソフトウェアシステムのアーキテクチャを改善したい: 2→4→6
ソフトウェア開発チームの実効性を向上させたい: 3→6→5
チームの士気をあげ、実効性を向上させたい: 3→5
予想した成長を達成するためにはどの領域に注力すればよいか知りたい: 1→5→8
変化するビジネスニーズに合わせてどうチームタイプを進化させればよいか: 7→8

とはいえ、この記事シリーズでは最初から順番に見ていく。
後で見返すときに、これを元に見返すと効果があるかもしれない。(かもしれない)

組織図の問題

組織図は上下に線が描かれることが多い。だが、実際の人間は誰とでもコミュニケーションを取るし、時にはルールを曲げる。組織図として描かれる図はミスリードになりかねない。
チームトポロジーでは動的なチーム構造とインタラクションモード(コミュニケーションの各種方法)をいかに実現するかを考えていく。

組織構造は実は3種類ある。
・公式な構造:組織図のこと。コンプライアンス遵守を円滑
・非公式な構造:個人間の影響力の領域
・価値創造構造:能力に基づいた実際に仕事を終わらせる
チームトポロジーでは下2つに重要性を求めている。
他チームとのインタラクションは明示的に合意してふるまいを明確にする。

組織を再編後のふるまいを静的なものとして見る代表的なものとして、「マトリクスマネジメント」があった。
これは管理ラインを複数持たせ、メンバーは複数のマネージャへの報告が必要になっていた。そのため責任範囲が不明瞭になるなど混乱が生じていた。

チームトポロジーのアプローチ

4つのチームタイプと、3つのインタラクションモードを定義している。
また次のものを踏まえている。
・コンウェイの法則
・チームの認知不可
・センサー組織になる方法

組織設計は環境によって柔軟に対応できるよう設計された「適応型モデル」。
チーム間のインタラクションには明確な優先順位がある。

認知不可

チームの責任やソフトウェアの担当範囲を割り当てる時、定量化が難しいため、実は認知不可について議論されることはほとんどない。
ただし、チーム構成において重要なこと。余裕がなくなり、コンテキストスイッチに悩まされることになる。

チームトポロジーではチームの認知不可を制限し、チーム間コミュニケーションを明確に設計している。

コンウェイの法則

「システム設計がそのまま組織構造に反映されてしまう」という法則。
この理論上においては、理想的なアーキテクチャだとしても組織と合わなければアーキテクチャ・組織のどちらかを変えなければならない。

様々なところでこの法則は実証されて(しまって)おり、再評価を受けていた。そのため、アーキテクチャを独立した設計可能と考えるのはないと思って良い。
余談だがこの本においてはどちらかというと、というアプローチとなっている印象。(Chapter.6あたりと書かれている)

逆コンウェイ戦略

効果的なソフトウェアシステムを構築する可能性を高めるための1つのアプローチ。チーム構造から変えて、アーキテクチャへ反映していく。
例えば、マイクロサービスにしたいのであればマイクロサービスに一致するようチームを設計するなど。
データベース設計者などを置けばモノリスな共通DBのシステムになる。

チームを編成する前にソフトウェアアーキテクチャを理解する必要がある。
実証済みのグッドプラクティスは以下の通り。
・疎結合:コンポーネント同士は強い依存性を持たない
・高凝集性:コンポーネントは明確に責任境界を持ち、内部要素は強い関連
・バージョン互換性:明確かつ適切となっているべし
・チーム横断でのテスト実行:明確かつ適切となっているべし

組織設計にはエンジニアを巻き込む必要がある。
コンウェイの法則を受け入れると、自然と組織設計とアーキテクチャは密接になってくる。組織はアーキテクチャに強い影響を与えてしまう。
技術リーダーの意見を聞かずにチームの形成、責任、境界を決定するのはNGとなる。

不必要なコミュニケーションを制限することも考える。
コミュニケーションパスは最小にし、かつチーム間のコミュニケーションを誘発する構造になるのが望ましい。
全員がすべての人とコミュニケーションする必要はない。(必要なら組織構造に問題がある)

チームファースト

標準とするのは「長続きする小さなチーム」
5~9人のメンバーからなるピザ2枚で収まるグループ。これは1人の人間が密接な関係を保てる最大人数に起因している。(これ以上だと信頼関係が失われる)

チームを作って効果的に働けるようになるには2~3ヶ月くらいかかる。ただし、一体になったら何杯も効果的に働けるようになる。
数ヶ月のプロジェクトを完了してメンバーを解散するのはもったいない。
メンバーが増えることも単純計算のように行かなく、助走期間ができることも考慮にいれる。(初期はむしろスピード落ちる)

タックマンモデルという、チームの成長を4段階で説明するモデルが有る。
1.形成期:メンバーが集まる
2.混乱期:個性により差が出てくる
3.統一期:一緒に働く標準的なやり方を進化させる
4.機能期:高い効果がでてくる
・・・が、実は正しくない。混乱は常に付きまとう。継続的にこれを繰り返していくのが現実。

ソフトウェアの(パーツの)オーナーはチーム単位

システム、サブシステムのオーナーが単一のチームで、仕事の計画について自立していれば、探索・開発・実行段階に至るまで生存可能性について考慮できる。
PRを出したりは他のチームでもOKだが、直接変更は基本NG。信頼しているチームに一時的にアクセスを許可するのはあるが、オーナーシップを渡すことは基本ない。

1点、縄張り争いにならないことには注意。
コードを自分のものにしたいというものではない。自分たちはコードの占有者ではなく、世話役と考えよう。ガーデニングのようなもの。

マインドセット

デリバリーの基本単位はnot 個人 but チーム。
個人のニーズよりチームのニーズを優先しないといけない場面もある。
このようなマインドセットを持つもしくは育む必要がある。

チームの多様性についても受け入れたほうが、創造的になり、他のチームとも共感しやすくなるという示唆もある(らしい。根拠は書かれてない)。

認知負荷の軽減

チームが扱うコードベースのサイズと複雑さが認知の増大させている。
なるべく責任範囲をチームが扱える認知負荷に見合ったものにする。
認知負荷を3種類に定義された。
・課題内在性負荷:タスクに関連するもの
 (基本的なプログラミングの知識とか)
・課題外在性負荷:タスクの実施される環境に関連するもの
 (例えばコンソールのコマンドの詳細とか)
・学習関連負荷:学習や性能の実現のために特別な注意が必要なもの
 (例えば動画などの複雑な処理のアルゴリズムとか)

過度な認知ストレスはチームのパフォーマンスを落とし、個人の集まりのように振る舞い始める。(チームの関心ではなく、個人のタスクに集中するなど)

チームに認知負荷を知るには中立の立場から以下を聞くと良い。
「チームは、頼まれた仕事に対して、効果的でタイムリーな対応ができていると思うか?」
おそらく、負荷に圧倒されているかどうかを回答から予測できる。

チームのドメインの種類を制限

適切なドメイン数などは定義は難しいが、相対的にドメインの複雑度を定義し、それを用いて推測をする方法もある。

手順としては以下。
1.取り扱うドメインを特定
2.難易度を分類
 ・シンプル:明確な作業手順がある
 ・煩雑:変更の分析が必要で、数回の繰り返しが必要
 ・複雑:実験・探索が必要
3.チーム間で比較していく

考慮すると良さそうな知見を3つほど記載しておく。
・ドメインが大きければサブドメインに分割したうえでチームを割り当てられないか検討しよう。
・逆に、シンプルなドメイン過ぎてメンバーのモチベーションが下がるようなリスクも有る。それなら複数個のドメインを持つこともできる。
・複雑なドメインを割り当てたチームは、それ以外のドメインを持たないことを前提としよう。

チームAPI

チームのインタラクションの手段。コミュニケーションのネットワークを定義しておくのも1つのアイデア。
・コード:チームが作成しているエンドポイントやUIなど
・バージョン管理:コードやサービスの変更についてどうコミュニケーションするか
・Wikiやドキュメント:ハウツーなど
・コミュニケーションツール

ソフトウェアのオーナーを有効にするには継続的にAPIを定義して公開し、ヒアリングやテストしながら進化させていく。

まとめと感想

昔読んだけど忘れかけていた本。
スクラムなんかと比較しながら考えていくと、チームのダンパー数(人間の認知の上限)が決まっているなど共通なことも多い。
スクラムは割と全員がすべてできる前提に考えられたりしているが、きっちり責任分界点を作って認知を下げようという手法なのは好印象。

この章の基礎的なチームとしての考え方を元に、次の章の具体的なインタラクションモードなんかを考えて、実際の組織構造へ反映させると良いのだろう。

ただ、コンウェイの法則は考えれば考えるほど難しい。
実際に自身が管理するプロダクトをどう分割したものかと少し考えてしまう。
例えば、とあるフロントの画面に特化したAPIを作るなどは組織構造を考える上でNGとなる可能性もある。
チームAPI的な考えだと、API側はパラメータに応じた値を返すだけで、画面に特化した表示に整形するのはフロントの責任範囲・・・とできる。(バックとフロントを別チームにする場合。ただしこれはアンチパターンとなるからやらないけど)


いいなと思ったら応援しよう!

この記事が参加している募集