はじめに
最近プラットフォームエンジニアリングという言葉を聞くことが多くなりそのなかで
いつもチームトポロジーの本が紹介されていたので気になって読んでみました。
目次
PART I デリバリーの手段としてのチーム
- Chapter1 組織図の問題
- Chapter2 コンウェイの法則が重要な理由
- Chapter3 チームファースト思考
PART Ⅱ フローを機能させるチームトポロジー
- Chapter4 静的なチームトポロジーチームのアンチパターン
- Chapter5 4つの基本的なチームタイプ
- Chapter6 チームファーストな境界を決める
PART Ⅲ イノベーションと高速なデリバリーのため にチームインタラクションを進化させる
- Chapter7 チームインタラクションモード
- Chapter8 組織的センシングでチーム構造を進化させる
- Chapter9 まとめ:次世代デジタル運用モデル
ざっくり内容を知るには
ざっくり内容を知るには翻訳者のひとりの吉羽龍太郎さんの記事が最高にまとまっています❗
ただやはり詳細は本を読まないとわからないのでスライドに目を通して自分なりの疑問を持って読むと理解が深まると思いました。
気になった用語など
用語や、気になったところなどを書いてみます。
チームトポロジーとは？
組織設計のモデルであり、現代ソフトウェア集約型企業が、ビジネスや技術の観点で戦略の変更が
必要がと感知した時に、技術にとらわれない重要なメカニズムを提供するもの
組織内のチームがどのように構成され、相互にどのように関連しているかを示すフレームワークで、チームの役割、責任、協力方法が含まれています。
目的は、効率的なコミュニケーション、効果的なコラボレーション、および組織の目標達成を最適化することによって、全体のパフォーマンスを向上させることです。
チームトポロジーは、プロジェクトの成功を支える組織構造とプロセスを設計するのに役立ちます。
節理面
ソフトウェアシステムを簡単に複数に分割できる自然な「継ぎ目」のこと
節理面を利用してソフトウェアを分割し、別々のリポジトリに格納する必要があると書かれています。
これは DDD でいうところの 境界づけられたコンテキスト と似ているのかなと思います。
理由としては分割された内部では一貫したビジネスドメイン領域を表しているからです。
コンウェイの法則、逆コンウェイの法則などからマイクロサービス、 DDD の境界づけられたコンテキストまで組織的なところからインフラアーキテクチャ、システムアーキテクチャ、プログラムまでフラクタルな構造になっているような印象を受けました。
4つのチームタイプ
ストリームアラインドチーム
単一の価値ある仕事のストリームに剃ったチームのこと
自分が所属しているチームはまさにストリームアラインドチームで備えるべき能力は以下のように定義されていました。
- アプリケーションセキュリティ
- 事業性調整分析と運用継続性分析
- 設計とアーキテクチャー
- 開発とコーディング
- インフラストラクシャーと運用性
- メトリクスとモニタリング
- プロダクトマネジメントとオーナーシップ
- テストとQA
- ユーザーエクスペリエンス（UX）
確かに全部必要だなとは思いますが、実際少人数でこれだけの内容を網羅するのはしんどく、、それぞれの得意不得に左右されるところが大きいのでスキルギャップを埋めるための施策や認知負荷低減のためのツールの用意が必須だなと思います。
イネイブリングチーム
特定の技術領域やプロダクト領域のスペシャリストから構成されているチームのことで、能力ギャップを埋める役割を果たす
まさに欲しいと思ったチームです。
ストリームアラインドチームを支援する役割で、うまく機能すれば数週間から数ヶ月の支援で知識移転が完了するということです。
イネイブリングチームは組織横断で支援活動を行うもので特定チームが継続的な依存関係を作るべきではないとも書かれています。
コンプリケイテッド・サブシステムチーム
特別な知識に大きく依存しているシステムを構築、維持する責任を持つチームのこと
主な目的はストリームアラインドチームの認知負荷を下げることにあるそうです。
レスキューナウの場合は災害情報の取り扱い部分などもしかしたらコンプリケイテッド・サブシステムチームになったりするのかなと思いました。
プラットフォームチーム
ストリームアラインドチームが相当な自立性のもとでデリバリーすることを可能にするチームのこと
内部的なサービスをストリームアラインドチームに提供することで下位のサービスを開発する必要性を無くし、認知負荷を下げる役割を担います。
結局、イネイブリングチーム、コンプリケイテッド・サブシステムチーム、プラットフォームチームはいかにストリームアラインドチームの認知負荷を減らし効率的な開発の支援をおこなえるかが求められています。
確かに、認知負荷が高い状態のまま開発を行うとクオリティの高いサービスを提供するのが難しいだろうなと感じました。
3つのインタラクションモード
コラボレーション
チームが別のチームと密接に連携して働くこと
初期フェーズで有用なインタラクションモードのことで新しいものをすばやく探索するのに向いているそうです。
これを行うにはチーム間の優れた連携や共同作業に対する意欲と野力の高さが必要とされています。
ただ責任の境界が曖昧になりがちということなので長時間行うのは適切では無く、継続的にコラボレーションが必要になる場合はドメイン境界やチームの責任が間違っている可能性やチームのスキルの組み合わせが正しく無い可能性があります。
また制約として、１つのチームが同時にコラボレーションモードを利用するのは最大１チームまでとしています。
X-as-a-Service
最小のコラボレーションでプロデューサーとコンシューマーの関係を実現すること
例えば A チームが B チームにサービスとして何かを提供している関係です。
※ 何かとは例えば、API や開発者向けツールやプラットフォーム丸ごとなど
この場合は責任の所在が明確でチーム間の連携もコラボレーションモードで作業するよりもコミュニケーション部分が限定されるので認知負荷が下げられます。
ただしサービスを提供するチームは優れたサービスマネジメントが求められます。
ファシリテーション
障害を取り除くために他のチームを支援したり、支援を受けたりすること
１つ以上のチームが別チームから積極的に作業の一部をファシリテーションまたはコーチしてもらうようなインタラクションモードのこと。
主にイネイブリングリームのモードとされている。
最後に
今までサービスごとに１チームのような運営が多かったので、チームトポロジーを読んで価値あるソフトウェアをすばやく届けるための適応型組織設計を知れて大変興味深かったです 👀
また本の後半に チームトポロジーだけでは、効果的なITの達成には不十分 という段落があり以下の４点が書かれていました。
- 健全な組織文化
- 良いエンジニアリングプラクティス
- 健全な投資・財務プラクティス
- ビジネスビジョンの明確化
まさに大前提だなと思ったので以前読んだシステム運用アンチパターンなどを思い返して自分から行える改善活動や提案をしていきたいと思いました 💨
すごくおすすめの本でした💪
Discussion