話題になっていたので読んだ。わりと面白かった。
骨子
- チームを構成しよう。チームというのは比較的長続きする目的と機能をもった集団である。チームというのは価値創造の重要な構成単位だ。また他のチームを待たず独立して仕事を実行できる。
- 前提
- 認知負荷というものがある。認知負荷のキャパというものがある。それを超えると破綻するので、人の認知負荷のキャパを超えない単位に仕事を分割しチームや仕事の仕方を整理する必要がある。チームの認知負荷を抑制し、適切にチームを分割し、チーム間のインタラクションをいい感じにする。
- 全てのチームは以下の4タイプのどれかであるとする。全てである。
- ストリーム・アラインメントチーム
- 価値を生み出すストリーム本体
- コンプリケイテッド・サブシステムチーム
- 他のチームから切り出された運用や構築に特殊な専門性が必要なサブシステムを扱う
- プラットフォームチーム
- 他のチームが利用するプラットフォームを提供する
- 他のチームが自律して仕事を果たせることを目的とする
- 他のチームのニーズをもとに活動することが多いが、要望の集合体がプラットフォームとなるわけではない
- イネイブリングチーム
- 他のチームに対して新しい力を与える
- ストリーム・アラインメントチーム
- チームとチームは基本的には独立している
- チームとチームはコミュニケーションをする。コミュニケーションのスタイルは以下の3つのうちのどれかである。
- コラボレーション
- 一緒に仕事に取り組む。基本的にコラボレーションスタイルでコミュニケーションとってるときは、コラボレーションのアウトカムに対しては両チームが共同責任を持たないといけない。
- 探索的な仕事に向いている。情報共有や仕事の引き継ぎが楽。認知負荷が高い。
- コラボレーションを長く、または高頻度でやってるとチーム間の依存度が高くなりやすい。
- コラボレーションはコストが高い。探索や能力の向上、弱点の補強など、価値が説明できることだけに限定するべきである。
- X as a Service
- コード、規約、ドキュメント、フォーム、などによりサービスを提供する。利用側は決まった手続きでそれを利用する。
- 変化は相対的にしづらくなる。うまく設計できれば利用側の認知負荷はもっとも低くなる。
- 適切にサービス境界を切らないとうまく機能しない。「X as a Service モデルがうまく機能するのは、サービス境界が正しく選択、実装され、サービスを提供するチームが優れたサービスマネジメントを実践している場合に限られる」
- X as a Serviceは予測可能性を提供する。「役割と責任の明快な境界のもとで期待されるふるまいを定義し、『見えない電気柵』と呼ばれるものを回避することで、信頼を促す」
- そのために可能性を制限するのでイノベーションは遅め。
- ファシリテーション
- コラボレーション
- 「チームがある分野で経験を積んだり、新しい技術が出現したり、組織の規模が拡大したり縮小したりすると、チームと経済の力学は変化する」ので、チームが適切な振る舞いをしているか、効果的に機能しているかはどんどん変化していく。チームのタイプとコミュニケーションモードの選択は不都合の検出に役に立つだろう。
- 「こういう理由でこのモードを選択している」というロジックがわかりやすくなるから、ということかな。
- コンウェイの法則とそれを利用した逆コンウェイ戦略を理解する。アーキテクチャが進化するので、チーム・トポロジーも同様に進化していかなければいけない。探索から確立へのサイクルを常に回すのだ。
おわり
突飛なことはそれほど言っていない。個人的には X as a Servicesスタイルがチーム間コミュニケーションにおける選択肢の一つという見方が得られたのでよかった。たぶんこの本で扱われている世界観では、かなり一つのチームの関心ごとは絞られている。自分がふだん見ている世界はもうちょっと入り組んでしまっているので、このように物事を組み立てるならかなり整理は必要だな、という感想です。
