『チームトポロジー』と Platform Engineering

2024/2/6に行われたPlatform Engineering Meetup #7で登壇した時の資料です。
https://platformengineering.connpass.com/event/307275/

1. 『チームトポロジー』と Platform Engineering 株式会社アトラクタ 永瀬 美穂 (@miholovesq) 2024/2/6 Platform Engineering Meetup #7
2. 永瀬 美穂 @miholovesq ✤ 株式会社アトラクタ 取締役CBO アジャイル コーチ ✤ 一般社団法人スクラムギャザリング東京実 行委員会 理事 ✤ 一般社団法人アジャイルＰＢＬ振興会 理事 ✤ TDDワイワイ会 運営 ✤ 東京都立産業技術大学院大学 客員教授 ✤ 筑波大学非常勤講師 琉球大学非常勤講師 ✤ 著者・翻訳者
3. 3 （前書き） （寄稿）
4. 今日の話: 『チームトポロジー』とPlatform Engineering ✤ 2021/12/1 日本能率協会マネジメントセンター刊行 ✤ マシュー・スケルトン、マニュエル・パイス著 ✤ 原田騎郎、永瀬美穂、吉羽龍太郎訳 ✤ ITエンジニア本大賞2023 ビジネス書部門ベスト3・特別賞 ✤ 本スライド掲載の図表は本書より引用しています 4 #pfem #ちいとぽ
6. Platform Engineer? ✤ プラットフォーム開発担当？ ✤ インフラエンジニア？ ✤ SREエンジニア？ ✤ 保守運用担当？ ✤ 基盤担当？ 6
7. IT技術トレンドの変遷 7 開発者の認知負荷の変遷（「Platform Engineering 101: What You Need to Know about This Hot New Trend」を元に草間 一人（jacopen）氏が作成） CodeZine『プラットフォームづくりを成功に導く！開発者のための「Platform Engineering」入門』より
8. IT技術トレンドの変遷＋開発手法と組織論 8 開発者の認知負荷の変遷（「Platform Engineering 101: What You Need to Know about This Hot New Trend」を元に草間 一人（jacopen）氏が作成） CodeZine『プラットフォームづくりを成功に導く！開発者のための「Platform Engineering」入門』より Agile DevOps Team Topologies Dynamic Reteaming
9. アジャイルマニフェスト 9
10. アジャイル開発の原則12個(まとめ) ✤ 顧客満足を最優先し早期にデリバリー ✤ 変化を歓迎する ✤ 期間に区切って頻繁にデリバリー ✤ 毎日のコラボレーション ✤ 信頼とモチベート ✤ フェイス・トゥー・フェイス ✤ 動作するソフトウェアが指標 ✤ 持続可能なペース ✤ 技術的卓越 ✤ シンプルに保つ ✤ 自己組織化したチーム ✤ 継続的なプロセス改善 10
11. 現代のIT組織の目指す適応型機能設計 ”組織図やマトリクスに過度に依存して仕事を分割、管理している組織は、速いペースで のデリバリーとイノベーションへの適応の両立に必要な環境を作り出すのに失敗してい ることが多い。これを成功させるには、組織に、安定したチーム、効果的なチームパターン とインタラクションが必要だ。権限が与えられており、スキルを持っているチームに投資 しなければいけない。このチームがアジリティと適応性の基礎となるからだ。” (p.9) 11
12. チームトポロジーのアプローチ ✤ 逆コンウェイ戦略 ✤ フローに最適化したチーム構造により最適なアーキテクチャを実現する ✤ 不必要なコミュニケーションを制限する ✤ チームファースト思考 ✤ 長続きする小さなチームを標準とする ✤ チームの認知負荷を下げる ✤ チームのインタラクションを設計する 12
13. 機能しているチームを長く保つ アラン・ケリー 『Project Myopia』 ハイパフォーマンスなチームを解散する のは、単なる破壊行為では済まない。企業 レベルのサイコパスと呼ぶべきものだ “ ” 13
14. 小さくて長続きするアジリティの高いチームってきっと… ✤ 価値のデリバリーとフィードバック ✤ チームによる繰り返しの実験と学習 ✤ コミュニケーションとコラボレーション ✤ 自律的かつ自己組織的 ✤ 予測主義より経験主義 ✤ すばやい意思決定 14
15. プロジェクトって難しい 15 2011 2012 2013 2014 2015 成功した 29% 27% 31% 28% 29% 課題が残った 49% 56% 50% 55% 52% 失敗した 22% 17% 19% 17% 19% 出典： Standish 2015 CHAOS Report ※ 成功要因の定義（期日通り、予算通り、満足のいく結果）を用いて、 　 2015年まで過去5年間のプロジェクトの成果を要約したもの
16. アジャイルならうまくいくのか？ 16 手法 成功した 課題が残った 失敗した アジャイル 39% 52% 9% ウォーターフォール 11% 60% 29% ※ 2015年まで過去5年間のプロジェクトの成果1万件超をアジャイルとウォーターフォールに区分したもの 出典： Standish 2015 CHAOS Report
17. 規模が小さければうまくいく 17 規模 手法 成功した 課題が残った 失敗した 大 アジャイル 18% 59% 23% ウォーターフォール 3% 55% 42% 中 アジャイル 27% 62% 11% ウォーターフォール 7% 68% 25% 小 アジャイル 58% 38% 4% ウォーターフォール 44% 45% 11% 出典： Standish 2015 CHAOS Report ※ 2015年まで過去5年間のプロジェクトの成果1万件超をアジャイルとウォーターフォールに区分したもの
18. 認知負荷 ✤ Cognitive Load ✤ システム1とシステム2 ✤ システム2が頻繁に起動されるとフローが阻害される ✤ フロー効率の低下＝アジリティの低下 18
19. 4つのチームタイプ ✤ ストリームアラインドチーム：変更のフ ローに最適化して速いフローを実現する ✤ イネイブリングチーム：ストリームアライ ンドチームに技術支援をする ✤ コンプリケイテッド・サブシステムチー ム：複雑なサブシステムやコンポーネン トを担当する ✤ プラットフォームチーム：基盤を提供す る
20. チームタイプとインタラクションモード 20 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p••）
21. チームタイプ別の主なインタラクションモード 21 コラボレーション X-as-a-Service ファシリテーション ストリームアラインドチーム 典型的 典型的 偶発的 イネイブリングチーム 偶発的 典型的 コンプリケイテッド・ サブシステムチーム 偶発的 典型的 プラットフォームチーム 偶発的 典型的 あるチームとインタラクションするときに、一時的にモードを変えることもある 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p.176）
22. チーム構成の例 22 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p165、p177）
23. ストリームアラインドチームをエンパワーする ✤ 「速いフローの実現を目指してストリー ムアラインドチームのエンパワーメント に注力しよう」（p.135） ✤ X-as-a-Service 23 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p165）
24. プラットフォームはプロダクトやサービスとして利用される ✤ 機能を作るのではなくユースケースを実現する ✤ 「プラットフォームチームは、ユーザーエクスペリエンス（UX）、とりわけデベロッ パーエクスペリエンス（DevEx）にフォーカスする必要がある」(p.124） ✤ 最低限のプラットフォーム（TVP=Thinnest Viable Platform） ✤ 「ソフトウェア開発者はプラットフォームを作るのを好む。プロダクトマネジメントか らの確かな情報もなしに、必要以上に大きなプラットフォームを開発してしまう」 (p.123) 24
25. プラットフォームはフラクタル ✤ 「プラットフォームチームも、内部スト リームアラインドチーム、イネイブリン グチーム、コンプリケイイテッド・サブシ ステムチーム、場合によっては下位のプ ラットフォームチームで構成される」 (p.135) ✤ プラットフォームチームもストリーム アラインドチームを基本としたチー ムトポロジーである 25 コンプリケイテッド・ サブシステムチーム 論理的プラットフォーム フロー ストリームアラインドチーム ストリームアラインドチーム プラットフォームチーム 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、 2021、p117、p165の図より筆者が改変して作成）
26. まとめ ✤ ストリームアラインドチームが基本です ✤ ストリームアラインドチームは当然アジャイルであるべきです ✤ 機能横断型のスモールチームで価値を効果的にデリバリーで きるようになってから効率を求めましょう ✤ 認知負荷の高まりがフロー効率を下げるようならチームタイ プの導入を検討しましょう 26
27. おまけ あと5分残っていれば宣伝の時間 2024/2/6 Platform Engineering Meetup #7
28. IT技術トレンドの変遷＋開発手法と組織論 28 開発者の認知負荷の変遷（「Platform Engineering 101: What You Need to Know about This Hot New Trend」を元に草間 一人（jacopen）氏が作成） CodeZine『プラットフォームづくりを成功に導く！開発者のための「Platform Engineering」入門』より Agile DevOps Team Topologies Dynamic Reteaming
29. 宣伝： Agile PBL祭り 2024 開催 ✤ 2024/3/16 (土) 麻布台ヒルズ ✤ 学生＋社会人合わせて最大10チームが発表予定 ✤ 発表チームは今週いっぱい募集中ですのでぜひ！ ✤ スポンサーも大大大募集中です！ 29 https://agilepbl.org