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

〇タイトル

チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 | 読書(81/1000)
著者 マシュー・スケルトン, マニュエル・パイス

○学んだ点

・コンウェイの法則

メルヴィン・コンウェイが提唱した、「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」というもの。
例えばインフラチームの中でもGCPとAWSとDatabricksとでチーム編成が分かれるとその構造をそっくり真似たアーキテクチャが出来上がる。（良くも悪くも）

この法則を逆手に取った、逆コンウェイの法則も存在する。
理想の組織体制を構成することで、理想のCI/CDを構築できる。
仮にもし、どのシステムを作る必要があるのか、どのチームが構築するべきかをマネージャーが決めていたら、システムのアーキテクチャをマネージャーが決めていることと同義になる。

・認知負荷を減らす

ジョン・スウェラーが提唱するに認知不可とは「ワーキングメモリで利用される心理的労力の総量」のこと
そして、認知不可は大きく3タイプに分かれる
課題内存在負荷：問題領域の本質的なタスクに関連するもの。ex：Javaのクラスの構造は？
課題外存在負荷：タスクが実施される環境に関連するもの。ex：再度デプロイするには何をしたらよい？
学習関連負荷：学習を進めたり高性能を実現したりする上で、特別注意が必要なタスクに関連するもの。ex：このサービスは自社の他サービスとどのように関わるべき？

この認知負荷を測る際に、中立の立場の人から「チームは、頼まれた仕事に対して、効果的でタイムリーな対応ができていると思うか？」と質問を行う。
チームが負荷がかかっている場合は、ネガティブな反応が出てくるため効果的なチームにするためにアクションを行う必要がある。

・組織を再編させるための問い

本書で大々的に書かれてはいないが、この部分をもとに組織再編を行うかどうかを考えると良い。
・自分たちのスキル、制約、文化とエンジニアリングの成熟度、望ましいソフトウェアアーキテクチャー、ビジネスゴールを踏まえると、素早く安全に成果を出すにはどのチームタイプが役に立つのか。
・主な変更フローにおいて、チーム間の引き継ぎをなくしたり減らしたりするにはどうすればよいか？
・システムを実行可能に維持しつつ速いフローを促進する上で、ソフトウェアの境界をどこに設定すべきか？
・チームはどうそれに合わせればよいか？

・本書が掲げる4つの組織

多くの組織には様々なチームが存在する。チームの種類を4つに絞ることで組織間の関係性を言語化する。
チームの種類は　「ストリームアイランドチーム / プラットフォームチーム / イネイブリングチーム / コンプリケイテッド・サブシステムチーム」の4種類。
各チームの具体的な役割・関わり方は以下のURLにまとまっているので以下を参照してもらいたい。

https://www.ryuzee.com/contents/blog/14566