logokimromi/Reports

「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」の感想

  • Book
image

https://www.amazon.co.jp/dp/B09MS8BML8/

1回読んだけど再度読んでみる。2022年4月で自チームの組織改編が携わって、その際に参考にした本。この本のおかげでEnablingチームが立ち上がって、プロダクト開発とは別軸に改善をしたり開発チームとコラボしたりできるようになった。もうちょっと深堀りしてみたいので読む。

事前インプット

まえがき

ソフトウェア開発には「システム設計」と「組織設計」が重要で、コンウェイの法則を踏まえて開発組織の設計に取り組む本。明確な責任と境界を持つチームにすることで認知負荷を減らしていこう、というのが肝。無限の認知負荷というのをどこかでみたな。

はじめに

  • PART1: コンウェイの法則の掘り下げ
  • PART2: 実績のあるチームのパターン
  • PART3: 組織設計を進化させる方法

実際のコンテキストに合わせたChapterの流れについての説明と、あとは本書に影響を与えているものについての説明。

PART1 デリバリーの手段としてのチーム

コミュニケーション構造と組織図がかけ離れている問題。組織図=やるべき仕事ではなくて疎結合なチームがコラボレーションするのがいい言っている。認知不可を下げるという意味合いが大きいのかな。

コンウェイの法則の説明。システムを設計する組織は、その穀蔵をそっくりまねた構造の設計を生みだしてしまう というフレーズが有名だけど、厳密には組織図ではなくて組織のコミュニケーションパスと得られるソフトウェアアーキテクチャに強い総関係があるとのこと。逆コンウェイ戦略はシステムに反映したいアーキテクチャに合うようなチーム構造にする という考え。「LeanとDevOpsの科学」でも逆コンウェイ戦略の重要さが書いているとな!

あとは認知負荷の話。マイクロサービスアーキテクチャも詳しく理解しているわけではないけど、認知負荷の軽減を目的にしているはずなので、その辺にも繋がりそう。PART1はコンウェイの法則の話チームの認知負荷を制限し、チーム間のインタラクションを促進したほうがいい、という話だった。全員がすべての人とコミュニケーションする必要はないというのも印象的。チームは小さく長続きさせることで信頼感を生むことが大事。

PART2 フローを機能させるチームトポロジー

まず考え抜こうという話。現在のコンテキストに合っていないその場しのぎになってしまいアンチパターンを踏んでしまう。うん。

有名な4つの基本的なチームの話。

  • ストリームアラインドチーム
  • イネイブリングチーム
  • コンプリケイテッド・サブシステムチーム
  • プラットフォームチーム

運用チームは存在しない。運用もサポートもストリームに沿って実施して、別のチームに引き継ぐことはしないと。ストリームアラインドチームがDevOpsをまるっと体現するチームなのか。

ストリームアラインドチーム

根幹のチームで、その他チームは負荷を減らす役割。you build it, you run it (自分で作ったら自分で運用する)。SREチームはストリームアラインドチームの一種なのか。プラットフォームチームかと思ってたけど違った。

「ストリーム」は継続的なフローであることを強調してる。開発の中心で継続的にDevOpsをやっていくチーム。他チームへの引き継ぎも理想はゼロということでまぁ全部をやるチームということか。サービスが大きくなるとドメインを分割して認知負荷を上げないor下げるようにクロスファンクショナルなチームを複数作っていくイメージかなー。

イネイブリングチーム

テクニカルドメインのスペシャリストから成るチームでストリームアラインドチームの能力を補う。テクニカルコンサルチームとも。

ストリームアラインドチームのニーズを探索する、新しい技術について先んじる、組織内の情報共有を促すなど。目的は新しい技術、アプローチなどの能力を高めるために存在する。のかー。

育成みたいな言葉は出てこなかった。

コンプリケイテッド・サブシステムチーム

ほとんどのチームメンバーがその分野のスペシリストでなければ構成が難しいチーム。ストリームアラインドチームの認知負荷を減らす役割。

プラットフォームチーム

ストリームアラインドチームが自律的に仕事を届けられるようにする役割。下位のサービスを開発する必要性をなくして認知負荷を下げる。

  • サイロ化を防ぐ
  • 「運用」チームは不適切
  • 職能横断型チーム
  • 認知負荷の低減

  • ほとんどのチームをストリームアラインドチームに
  • インフラチームをプラットフォームチームに
  • コンポーネントチーム(職能チーム)は解散して別のチームに
  • アーキテクトはイネイブリングとして、あくまで実装チームが手動する

Based on https://github.com/kimromi/notes/issues/2