チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 [Kindle]
- 日本能率協会マネジメントセンター (2021年12月1日発売)
本棚登録 : 245人
感想 : 17件
- Amazon.co.jp ・電子書籍 (354ページ)
感想・レビュー・書評
-
前半のチームのキャパシティを超えないように認知負荷を押さえないといけないという問題提起はよかったです。
一方で、解決方法が抽象的というかふわっとしてしまったなという印象の本です。
ストリームアラインドチーム、イネイブリングチーム、プラットフォームチーム、コンプリケイテッドサブシステムチームの 4 つのチームタイプ、コラボレーション、ファシリテーション、X-as-a-Service の 3 つのチームインタラクションに分類してますが、この分類がちょっと根拠レスに感じました。
著者の経験からくる一つの案という感じです。
また、既存の組織をこの形にスムーズに移行するにはどうしたらいいかが全然イメージが湧きませんでした。
いまいち他人におすすめしづらい本に感じます。
2
詳細をみるコメント0件をすべて表示 -
組織における実践的なチーム設計の考え方であるチームトポロジーについてまとめた本。
4つのチームタイプと3つのインタラクションモードを軸にしてしたモデルであり、また本書ではチームトポロジーの前提となる考え方についてコンウェイの法則やチームファースト思考についても言及されています。
チームを分割する理由として、認知負荷を上げており、メンバーが処理できるなチーム設計を行う必要がある旨が書かれているのが好印象でした。
個人的にはチームトポロジーの説明で慣れないカタカナ語が多くて読むのに苦労した印象があります。しかし、その混乱が過ぎれば納得いくチーム設計の理解が得られる一冊だと思います。
1
-
組織設計は色々な方法があると思うが、最近では一番しっくり来た内容。ただし流行りだからと取り入れるのは危険でもあるので、各チームの必要性は充分検討した方が良いと感じる。
0
-
チームの設計をチーム間のコミュニケーションの負荷を下げることに注目して考えた組織論。
開発組織をメインに扱っているので、ビジネスサイドにどう適用するかは難しいが、認知負荷をなるべく下げるような組織構造を取り、疎結合で組み合わせていく発想は有効だと思った。
◯４つのチーム
・stream island team: ストリームは仕事やサービスの場合も機能一色の場合、ユージャージャーニーの場合もあるが、価値ある単一のものをさし、他のチームへ引き継ぎの必要がない。
・フローに沿った形で最適化、価値の継続的デリバリーを実現し、フィードバックサイクルに対応するのに必要な全てを備えている。
・組織の根幹で、他のチームはこのチームの負荷を減らすことにある。
・enabling team: 特定のスペシャリストから構成され、SITの能力ギャップを埋めるのを助ける。複数のSITを横断的に支援し、適切なツール、教訓、フレームワーク、選択肢の探索、正しい情報に基づく提案を行う。
(必要な能力獲得を自分でやるのに必要な労力がチームに与える影響は10〜15倍過小評価されている)
・最終ゴールは、sitの課題に注力することで、その自律性を高めること。うまく機能すれば数週間から数ヶ月で必要なくなる。継続的な依存関係は作るべきではない。
・complicated subsystem team: スペシャリストの知識が必要になるパーツを開発、保守する責任を持つ。
・SITの認知負荷を減らすため、サブシステムの複雑さに取り組む。
◯組織図からの脱却
・組織図が仕事の終わらせ方やチーム間のやり取りを忠実に表したものだと考えてしまうと、仕事の割り当てや責任について効果的な判断ができない
・３つの異なる組織創造がある
1. 公式な構造(組織図): コンプラ遵守を円滑化
2. 非公式な構造: 個人間の影響領域
3. 価値創造構造：個人間やチーム間の能力に基づいて、実際にどう仕事を終わらせるか
◯コンウェイの法則
・システムを設計する組織は、その組織をそっくり真似た構造の設計を生み出してしまう
・必須のアーキテクチャ設計に従うようチームに求めるのではなくらアーキテクチャに合うチーム構造にする必要がある
◯チームファースト思考
・効果的に動けるチームの最大サイズは7人程度、人数が増えたらチームを分け、担当領域が被らないよう、認知負荷が下がるように境界、責任を設定する。
・チームが効果的に動けるようになるには0-5〜3ヶ月以上かかるのが一般的、チームの変更を頻繁に行うとパフォーマンスが落ちる
・仕事によってチームを変えるのではなく、チームに仕事を流れ込ませる
・エドワードデミングのout if the crisis では年次個人目標と目標設定によるマネジメントの廃止を挙げている。
・個人のパフォーマンスについて報酬を与えることは悪い結果を与えやすい。チームに対して報酬を与える。
◯チームトポロジー
・継続的な設計によるチーム構造をチームトポロジーと呼ぶ。チームの責任範囲を明確にしながら、組織内にチームを意図的に配置する。
・必ずこれがいいという型があるわけではなく、チームの成熟度によっても解は変わる。しかしチームのみを見てはならず単にそのチームのパフォーマンスが上がっても他のチームとのコミュニケーションに支障が出るトポロジーは最適解では無い。
◯チームファーストな境界
・チーム間の複雑なやりとりをへらすため、ソフトウェアをチーム間で分割するが
・ソフトウェアのシステムを簡単に自然に分割できる繋ぎ目のことを節理面という
・ほとんどの節理面はビジネスドメインで境界づけられたコンテキストに合わせるべき。
◯チームのインタラクションモード
・最も避けないといけないのは、全てのチームがやりとりを必要としてしまうこと。
・3つの基本的なモード
1. コラボレーション: 他のチームとして密接に作業。ほぼ一体のようになるのめ、一つのチームがこのモードを使えるのは1つまで。
2. X as a service: 最小限のコラボレーションで何かを利用または提供すること。予測可能なデリバリーが必要とされ、チームの責任が明確にしたいときに適する。
3. ファシリテーション: 障害を取り除くために他のチームを支援したり、支援を受けたりすること。イネイブリングチームの主な職務遂行モード。
0
-
『チームトポロジーでは、チームが新しい状況にすばやく対応し、ソフトウェアを高速かつ安全にデリバリーするのに役立つ動的なチーム構造とインタラクションモードをいかにして実現するかに焦点を当てている。現時点では、これがあなたにとって最大のボトルネックではないかもしれない。だが、いずれは、コミュニケーション不足や不適切なプロセスによって硬直したチーム構造がデリバリーを遅くするという問題に直面する。』(p.33)
『チームについて、サイズ、形、配置、責任、境界、インタラクションを網羅している。チームトポロジーでは、ストリームアラインドチーム、プラットフォームチーム、イネイブリングチーム、コンプリケイテッド・サブシステムチームという４つの基本的なチームタイプと、コラボレーション、XasaService、ファシリテーションという３つのインタラクションモードを定義している。チームトポロジーは、コンウェイの法則、チームの認知負荷、センサー組織になる方法などを踏まえたものであり、ソフトウェアシステムを構築、運用するための効果的かつ人間的なアプローチになっている。』(p.37)
ものごとを分離しチーム内にとどめておくことが重要で、それができているかどうかを常に確認しよう。
0
-
なんか今までに試行錯誤やってきたものが、体系化されて表現されていた。
その結果、なんだか救われた気がする。読んでよかった。
あとその先に何があるのかの見通しがちょっとだけよくなった気がする。
0
-
組織設計における、基本的なチームの4タイプと、チーム間のコミュニケーションの3タイプについて明らかにされている。この分類をもとにすれば、組織設計について議論するときに目線を合わせやすそう。
0
-
チームトポロジーは、ソフトウェア開発チームの構成・チーム間のコラボレーションの組織設計モデル。本書ではアンチパターンを交えながら近代的な組織論をまとめている。
コンウェイの法則(システム設計は組織のコミュニケーション構造を真似たものとなる)を踏まえ、望ましいシステム設計の実現のためチームや組織構造を進化させようようという逆コンウェイ戦略の実現が主旨で、
文中より「チームトポロジーのゴールは、コラボレーションが必要な場所やタイミング、実行に集中してコミュニケーションを減らすべき場所やタイミングを、組織が適応しなら動的に見つけられるようなアプローチとメンタルルールを提供すること」とあるように、ソフトウェア開発チームの設計に関して4つのチームタイプと3つのインタラクションモードを言語化しパターン化している。
読み返す際には、全体の内容がまとまっているChapter 9からが良さそう。
また、チーム設計のためのテンプレートも用意されているので、自チームのデザインをするのに利用できそう。
・https://github.com/TeamTopologies/Team-API-template
・https://teamtopologies.com/infographic/getting-started-with-team-topologies-infographic-jp
0
