Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
効率的な技術組織が作れる!書籍『チームトポロジー』要点まとめ
Search
iwamot
PRO
December 25, 2024
Technology
2
500
効率的な技術組織が作れる!書籍『チームトポロジー』要点まとめ
2024-12-25
ENECHANGE I/O Day LT⼤会(社内イベント)
iwamot
PRO
December 25, 2024
Tweet
Share
More Decks by iwamot
See All by iwamot
これがLambdaレス時代のChatOpsだ!実例で学ぶAmazon Q Developerカスタムアクション活用法
iwamot
PRO
6
960
Developer Certificate of Origin、よさそう
iwamot
PRO
0
15
復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた CODT 2025 クロージングイベント版
iwamot
PRO
1
79
復号できなくなると怖いので、AWS KMSキーの削除を「面倒」にしてみた
iwamot
PRO
3
75
IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて
iwamot
PRO
14
11k
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
4
1.1k
名単体テスト 禁断の傀儡(モック)
iwamot
PRO
1
540
クォータ監視、AWS Organizations環境でも楽勝です✌️
iwamot
PRO
2
550
Cline、めっちゃ便利、お金が飛ぶ💸
iwamot
PRO
22
22k
Other Decks in Technology
See All in Technology
ACA でMAGI システムを社内で展開しようとした話
mappie_kochi
1
310
【Oracle Cloud ウェビナー】クラウド導入に「専用クラウド」という選択肢、Oracle AlloyとOCI Dedicated Region とは
oracle4engineer
PRO
3
130
[Codex Meetup Japan #1] Codex-Powered Mobile Apps Development
korodroid
1
190
「使い方教えて」「事例教えて」じゃもう遅い! Microsoft 365 Copilot を触り倒そう!
taichinakamura
0
330
速習AGENTS.md:5分で精度を上げる "3ブロック" テンプレ
ismk
4
690
Adapty_東京AI祭ハッカソン2025ピッチスライド
shinoyamada
0
270
職種別ミートアップで社内から盛り上げる アウトプット文化の醸成と関係強化/ #DevRelKaigi
nishiuma
2
160
E2Eテスト設計_自動化のリアル___Playwrightでの実践とMCPの試み__AIによるテスト観点作成_.pdf
findy_eventslides
2
600
関係性が駆動するアジャイル──GPTに人格を与えたら、対話を通してふりかえりを習慣化できた話
mhlyc
0
140
衛星画像超解像化によって実現する2D, 3D空間情報の即時生成と“AI as a Service”/ Real-time generation spatial data enabled_by satellite image super-resolution
lehupa
0
140
GoでもGUIアプリを作りたい!
kworkdev
PRO
0
130
ガバメントクラウドの概要と自治体事例(名古屋市)
techniczna
2
220
Featured
See All Featured
jQuery: Nuts, Bolts and Bling
dougneiner
65
7.9k
Context Engineering - Making Every Token Count
addyosmani
5
230
How GitHub (no longer) Works
holman
315
140k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
9
590
Music & Morning Musume
bryan
46
6.8k
GitHub's CSS Performance
jonrohan
1032
470k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
53k
What's in a price? How to price your products and services
michaelherold
246
12k
Designing for humans not robots
tammielis
254
26k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
Docker and Python
trallard
46
3.6k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.1k
Transcript
効率的な技術組織が作れる! 書籍『チームトポロジー』要点まとめ 2024-12-25 ENECHANGE I/O Day LT大会(社内イベント) VPoT兼CTO室マネージャー 岩本隆史
『チームトポロジー』(2021) 副題:価値あるソフトウェアをすばやく届ける適応型組織設計 2/18
同書の主張 疎結合なソフトウェアは、疎結合な組織から生まれる 小さなチームで、認知負荷を制限すべき 組織は静的ではなく、進化させるべき ※ 重要な意見をピックアップし、自分なりに整理したものです 3/18
疎結合なソフトウェアは、疎結合な組織から生まれる システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出して しまう(コンウェイの法則) アーキテクチャー設計に従うようチームに求めるのではなく、システムに反映し たいアーキテクチャーに合うようなチーム構造にする(逆コンウェイ戦略) 明瞭なチームインタラクションだけにコミュニケーションパスを限定すること で、モジュール化した疎結合なシステムが生まれる 4/18
小さなチームで、認知負荷を制限すべき チームとは、5人から9人のメンバーからなる安定したグループで、共有されたゴ ールのために働く単位のこと グループのサイズが大きくなると、必要なレベルの信頼関係を維持できなくなる 認知負荷容量を考慮しないと、チームの責任範囲と担当領域は広がりすぎること になる。自分の仕事に熟達するだけの余裕がなくなり、担当業務のコンテキスト スイッチに悩まされる 5/18
組織は静的ではなく、進化させるべき 技術、マーケット、顧客やユーザーの要望、規制の要件などが急速に変化してい るため、成功している組織は当然、組織構造を定期的に適応させ進化させる必要 がある 組織図やマトリクスマネジメントのような単一で静的な組織構造を利用していて は、現代のソフトウェアシステムで効果的なアウトカムを生み出せないことが 徐々に明らかになってきている 6/18
同書が提示したモデル 4つのチームタイプ 3つのインタラクションモード 7/18
4つのチームタイプ ストリームアラインドチーム プラットフォームチーム イネイブリングチーム コンプリケイテッド・サブシステムチーム 8/18
ストリームアラインドチーム ビジネスの主な変更フローに沿って配置されるチーム。職能横断型で、他のチー ムを待つことなく、利用可能な機能をデリバリーする能力を持つ 組織で根幹となるチームタイプで、残りの基本的なチームタイプの目的は、スト リームアラインドチームの負荷を減らすことにある 9/18
プラットフォームチーム 下位のプラットフォームを扱うチームで、ストリームアラインドチームのデリバ リーを助ける。プラットフォームは、直接使うと複雑な技術をシンプルにし、利 用するチームの認知負荷を減らす プラットフォームチームの知識は、長大な利用マニュアルではなく、セルフサー ビスの形でウェブポータルやプログラマブルなAPIとして提供され、ストリームア ラインドチームは簡単に活用できる 10/18
イネイブリングチーム 転換期や学習期に、他のチームがソフトウェアを導入したり変更したりするのを 助ける 特定のテクニカル(プロダクト)ドメインのスペシャリストから構成され、能力 ギャップを埋めるのを助ける うまく機能すれば、ストリームアラインドチームは、イネイブリングチームから の支援を数週間から数か月で必要としなくなる 11/18
コンプリケイテッド・サブシステムチーム 普通のストリームアラインドチーム、プラットフォームチームが扱うには複雑す ぎるサブシステムを扱うためのチーム。本当に必要な場合にだけ編成される サブシステムの例としては、動画処理コーデック、数理モデル、リアルタイム取 引裁定アルゴリズム、金融サービスのトランザクションレポートシステム、顔認 識エンジンなどがある 12/18
3つのインタラクションモード コラボレーションモード X-as-a-Serviceモード ファシリテーションモード 13/18
コラボレーションモード 特に新しい技術やアプローチを探索している間、2つのチームがゴールを共有して 一緒に働く。学習のペースを加速する上で、このオーバーヘッドには価値がある ペアプログラミング、モブプログラミング、ホワイトボードでのスケッチのよう な基本的なコラボレーションスキルに関するトレーニングやコーチングは、コラ ボレーションモードを使用するチームに有益 14/18
X-as-a-Serviceモード あるチームが、別のチームが提供する何かを利用する(API、ツール、ソフトウェ ア製品全体など)。コラボレーションは最小限になっている コアとなるユーザーエクスペリエンス(UX)とデベロッパーエクスペリエンス (DevEx)のプラクティスに関するトレーニングやコーチングは、X-as-a-Service モードを使用するチームに有益 15/18
ファシリテーションモード あるチーム(通常はイネイブリングチーム)が、新しいアプローチの学習と適用 を促すため、他のチームをファシリテーションする ファシリテーションのやり方や他のチームから助けてもらう方法に関するトレー ニングやコーチングは、ファシリテーションモードを使用するチームに有益 16/18
基本形と進化の例 17/18
まとめ 同書の主張 疎結合なソフトウェアは、疎結合な組織から生まれる 小さなチームで、認知負荷を制限すべき 組織は静的ではなく、進化させるべき 同書が提示したモデル 4つのチームタイプ 3つのインタラクションモード 18/18