メモ：チームトポロジー Part2

概要

『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』（日本能率協会マネジメントセンター）を読んだメモとポエムのPart2。

• Part1: https://zenn.dev/black_tr1007/articles/f798fd4e70e4be
• Part3: To Be Continued...

Part2 TL;DR

• その場しのぎや頻繁なチーム設計の変更はデリバリーを遅くする
• トポロジーを検討する際の観点
  • 唯一絶対のトポロジーは無いが、どの組織にとっても不適切なトポロジーは存在する
  • 技術面や文化面での成熟度、組織の規模、技術面での規律は欠かせない
• チームの責任を分割することでサイロを壊し、他のチームの能力を高める
• 4つの基本的なチームタイプによってチーム間のインタラクションは単純化できる
  • 業界によくあるチームは基本的なチームタイプにマッピングできる
    • オーナーシップの不明瞭さ、過負荷・低負荷なチームを取り除き、組織を成功に導ける
  • 中心となるのはストリームアラインドチーム
    • その他のチームは全てこれをサポートする
• チームファーストのアプローチを活用してソフトウェア境界を選択する
  • デリバリーチェーンにおける隠れモノリスや結合に気を付ける
  • ビジネスドメインの境界を踏まえたソフトウェアの境界を利用する
    • 必要に応じて異なる境界を検討する

Chapter 4: 静的なチームトポロジー

• チームトポロジー
  • 効果的なチームにするには継続的にチームを設計する必要がある
  • 継続的な設計によるチーム構造をチームトポロジーと呼ぶ
  • 実際にはチームの責任範囲を明確にし、ある思想・意図を元に組織内にチームを配置すること
• チームのアンチパターン
  • 場当たり的なチーム設計
    • インシデント後の再発防止策でとりあえず作ったQAチームとか
  • チームメンバーの入れ替え
    • 新しいチームの立ち上がりのオーバーヘッドやコンテキストスイッチを見落としがち
• 組織に必要なチーム設計における質問
  • 自分たちの現状からすばやく安全に成果を出すのに役立つチームタイプは？
    • スキル、制約、文化、エンジニアリングの成熟度、望ましいソフトウェアアーキテクチャ、ビジネスゴールなど
  • 主な変更フローにおけるチーム間の引き継ぎを無くす／減らすには？
  • システムを実行可能に維持しつつ速いフローを促進できるシステムの境界と、チームがどのようにそれに合わせればよいか？
• 組織的なフィードバックメカニズム（センシング）の獲得
  • デリバリー担当のチーム
    • 職能上の枠に縛られず、1チーム内でシステムの設計・開発・テスト・デプロイ・運用に必要なスキルを全て兼ね備える必要がある
      • 『LeanとDevOpsの科学』（著：ニコール・フォースグレンetc.）
  • 本番システムからの情報のフィードバックに価値を置く
    • ソフトウェアを素早く改善できる
    • 顧客やユーザーへの対応力が高まる
  • 多くの部署にまたがる職能型サイロ、アウトソーシングの多様、繰り返される引き継ぎ　といった組織では獲得できないもの
• 優れたセンシング能力を獲得するには
  • 組織にとって、現場のスタッフやチームが組織の扱うマーケットや環境に価値のある情報源であると考える
• センシング能力をストリームアラインドチーム以外にも様々なチームが獲得することを目指す
  • 様々なレイヤーの問題を素早く発見・対処することができる
  • IT全体の有効性を高めるための戦略的能力を高められる
• DevOps
  • デリバリーチェーンにおけるチーム間のインタラクションの負荷に対処する概念
    • 開発と運用で責任が完全に分離されているとデプロイ頻度を増やすアジャイルの流れに対応できなくなった　など
  • Dev - Ops間の話として扱われるが、同じ問題はQAやセキュリティとのインタラクションでも起きている
    • 要はデリバリーチェーン内のインタラクションに着目して問題に対処していきましょうという話
  • DevOpsの成功パターンは組織やプロダクトの規模、技術的な成熟度などのコンテキストで異なるというのが重要
• DevOpsトポロジーカタログ
  • チーム設計とインタラクションに関するパターンとアンチパターンのオンラインコレクション
  • チームの責任範囲、インターフェース、チーム間のコラボレーションについての会話の導入として使える
• 成功しているチームのパターン
  • フィーチャーチームがエンジニアリングにおいて高い成熟度と信頼を獲得している
  • プロダクトチームが自律的で外部への依存関係がノンブロッキングになっている
    • ノンブロッキングな依存関係≒他のチームが開発・維持するセリフサービス型の能力
      • アプリのクラウド管理をするチームがいるのではなく、アプリがクラウドを利用できるベースを提供する
    • 専門知識が必要なときにスペシャリストのサポートが得られる
    • など
  • クラウドチームがアプリケーション用のインフラを作らない
    • アプリケーションに必要な環境の構築や監視はプロダクトチーム
    • クラウドチームはプロビジョニングもするが、ポリシーの適用や監査など
  • SREチームは大規模なソフトウェアシステムで採用する
    • SREチームはオプションであり、ソフトウェアの規模が小さくなればチーム内でSREを担当する
• トポロジーの選択で考慮すること
  • 技術的成熟度と文化的成熟度
  • 組織のサイズ、ソフトウェアの規模、エンジニアリングの成熟度
  • 責任の分割によるサイロの解消
  • チーム間の依存関係と待ち時間
• 結局の所、現在のコンテキストに合ったトポロジーをまずは選択し、進化させていくことが重要

Chapter 5: 4つの基本的なチームタイプ

ストリームアラインドチーム

• ストリームアラインドチーム
  • ビジネスドメインや組織の能力に沿った仕事の継続的な流れに沿って働くチーム
    • ストリームは仕事やサービスの場合もあるし、機能一式やカスタマージャーニー、ペルソナの場合もある
  • なるべくチーム内で価値を届けるのに必要な権限委譲がされている
  • 組織で根幹となるチームで、他のチームはこのチームの負荷軽減がミッション
• チームが備えるべき能力
  • アプリケーションセキュリティ
  • 事業成長性分析と運用継続性分析
  • 設計とアーキテクチャ
  • 開発とコーディング
  • インフラと運用性
  • メトリクスとモニタリング
  • プロダクトマネジメントとオーナーシップ
  • テストとQA
  • UX
• 期待されるふるまい
  • フィーチャーデリバリーの安定したフローを作る
  • 最新の変更に対するフィードバックに基づいて素早く修正する
  • プロダクトの進化に対して実験的なアプローチを採用し、学習と適応を繰り返す
  • 他チームへの引き継ぎを最小限（理想は0）にする
  • 技術的負債に対応する時間を持つ
  • 積極的かつ定期的に支援を受ける他のチームタイプと連携する
  • チームメンバーは自律・熟達・目的を達成しようとする（達成していると感じる）
• 評価
  • チームが実現した変更フローの安定性
  • 技術面・チームの健全性の観点での補助的なメトリクス

イネイブリングチーム

• ハイパフォーマンスなチームは優位性を保つため能力向上に継続的に取り組んでいる
  • ストリームアラインドチームはデリバリーと運用対応のプレッシャーに常に晒されており難しい
• イネイブリングチーム
  • 特定のテクニカル（プロダクト）ドメインのスペシャリストから構成される
  • ストリームアラインドチームの能力ギャップを埋めるのを助ける
    • 適切なツール
    • プラクティス
    • アプリケーションスタックのエコシステム（フレームワークなど）の調査
    • オプションの探索
    • 正しい情報に基づく提案
  • テクニカルコンサルティングチームとも
• 期待されるふるまい
  • 積極的にストリームアラインドチームのニーズを探索し、定期的なチェックポイントを設け、コラボレーションが必要なタイミングについて合意する
  • ストリームアラインドチームが実際に必要とする前に専門領域での新しいアプローチ、ツール、プラクティスについて先んじておく
  • 良いニュースも悪いニュースも伝える
    • 技術面のライフサイクルマネジメントの支援のため
    • 良いニュース：新しいフレームワークの話など
    • Deprecatedになった機能やフレームワークの話など
  • ストリームアラインドチームが直接使うのが難しい内外のサービスのプロキシとなる
  • 組織内の適切な情報共有を促すキュレーターとなる
    • チームを横断した学習の促進のため

コンプリケイテッド・サブシステムチーム

• システムの中でスペシャリストの知識が必要となるパーツを開発・保守する責任を持つ
  • チームメンバーのほとんどがその分野のスペシャリストでないと理解や変更が難しいようなサブシステムを担当
  • ストリームアラインドチームの認知不可の低減
• 例えば
  • 動画処理コーデック
  • 数理モデル
  • リアルタイム取引裁定アルゴリズム
  • 金融サービスのトランザクションレポート
  • 顔認識エンジン
  • など
• 期待されるふるまい
  • 担当するサブシステムの開発状況を意識して適切にふるまう
    • 初期の探索・開発の段階ではストリームアラインドチームと密接にコラボレーションする
    • サブシステムが安定してきたらインタラクションを減らし、サブシステムのインターフェース・機能の使用状況や進化に集中する
  • 担当するサブシステムのデリバリー速度と品質を向上させる
  • サブシステム利用者のニーズを尊重し、適切な優先順位をつけてデリバリーする

プラットフォームチーム

• ストリームアラインドチームが自律的に仕事を届けられるようにするのが目的
  • 内部サービスを提供することでストリームアラインドチームが下位のサービスを開発する必要性をなくし、認知不可を下げる
• 期待されるふるまい
  • ストリームアラインドチームと密接にコラボレーションし、ニーズを理解する
  • 高速プロトタイピングの手法を使い提供しているプラットフォームに対するフィードバックを素早く得る
  • 提供するプラットフォームをプロダクトとして扱う
    • 提供するサービスのユーザビリティと信頼性に強い関心を持つ
    • サービスの合目的性と利用容易性を定期的に検査する
  • 手本を示すことでリードする
    • 提供したサービスをストリームアラインドチームと一緒に使う
    • 他のプラットフォームチームがオーナーのプラットフォームを使う
  • 新しい内部向けのサービスの採用は他の新技術と同じように時間がかかることを理解する
    • テクノロジー採用ライフサイクルの採用曲線に沿って進化することを理解する

これまでのチームを4つのチームタイプに変換する

• ほとんどのチームを長続きする柔軟なストリームアラインドチームにする
• インフラチームをプラットフォームチームにする
  • 実はシンプルでも簡単でもない
    • プラットフォームは実績のあるソフトウェア開発テクニックを使って管理するべきプロダクト
    • この考えはインフラの担当者には馴染みが薄いことが多い
• コンポーネントチームをプラットフォームか別の種類のチームにする
  • コンポーネントが下位のプラットフォームに属するコンポーネントならプラットフォーム
  • ストリームアラインドチームにとってのコンポーネントの利用容易性による
    • 簡単なら技術コンポーネントに基づくチームをイネイブリングチーム
    • 複雑すぎるならコンプリケイテッド・サブシステムチーム
• ツールチームをイネイブリングチームかプラットフォームチームの一部にする
• サポートチームを変換する
  • 変更のストリームに沿ってチームを配置する
  • インシデントに対しては動的にチーム横断で活動する
• アーキテクチャとアーキテクトを変換する
  • アーキテクチャチームが必要な場合はパートタイムのイネイブリングチームにする
    • パートタイムであることが重要
    • アーキテクチャチームが行うべきことを明確化する
    • 判断の多くは実装チームが担当するべき
  • バーチャルチームは定期的に集まり、アーキテクチャの進化について議論する
    • 他にチームに設計や技術選択を強制しない

ポエム

チームトポロジーについて調べていると、身近な例でチームを考えてみた記事がおもしろかったので引用しておく。

『Team Topologyで色々なものを読み解いてみる』

https://qiita.com/yamamorisoba/items/be5f55701aef6dcc2be2

自分が現在関わっている案件はストリームアラインドチームのように振る舞えているチームがほとんどで、そこにシステム基盤全般を担当するプラットフォームチームがくっついているような状態になっている。
ただ、イネイブリングチームは存在せず、チーム横断のバーチャルチームが時折発足しては解散してなんとか進んでいる感じなので、ここを専任にするかどうかというのは本章で何度も出てくる「状況による」ということなのかな。

Chapter 6: チームファーストな境界を決める

• モノリシックなシステムを疎結合なサービスに変える
  • 新しいアーキテクチャが関係するチームに与える影響について考える
  • チームの認知容量、所在、新サービスへの関心度合いなどを考慮する
• チームのことを考慮せずに進めると？
  • サービス同士の依存性の高い複雑なシステムを作り出すリスクが有る
    • 分散モノリスとも
  • すべての変更で他のサービスの更新が必要になったりする

隠れモノリスと結合

• アプリケーションモノリス
  • 多くの依存関係や責任を持つ単一かつ巨大なアプリケーション
  • 本番環境の動作が不安定
    • モノリスを擬似本番環境で動作させていても本番リリースまでに他の変更が入っている
• データベース結合モノリス
  • 同一のデータベーススキーマと結合している複数のアプリケーションやサービスから構成されている
    • サービスを個別に変更、テスト、デプロイするのが難しい
  • データベースをビジネスのコアとしている組織で起こりやすい
• モノリシックビルド
  • コンポーネントの新バージョンのために巨大なCIでビルドを行う状態
  • 基本的にはアプリケーションモノリスがもたらす
  • 小規模なサービスでもコードベース全体をビルドするようなCIでは起こりうる
• モノリシックリリース
  • 複数のコンポーネントをまとめてリリースしなければいけない状態
    • ビルドは個別に可能でも起こる
  • サービスのモックを使わず、共有の固定環境でしかテストできない場合など
  • QAチームのキャパシティ不足で起こる可能性もある
• モノリシックモデル
  • 単一のドメイン言語と表現（フォーマット）を様々なコンテキストに強制的に適用とする状態
  • 小さなチームではある種の一貫性を持つことも大事
  • 組織内のチームやドメインが増えるとつらくなる
• モノリシック思考
  • 技術面やチーム間の実装アプローチの「標準化」を強制する状態
  • なんでもかんでも標準化
    • 管理は楽
    • 単一の技術スタックやツールの強制は学習意欲と選択の自由がなくなる
  • 『LeanとDevOpsの科学』
    • 標準化の強制が学習と実験の減少と貧弱なソリューションの選択につながるという研究結果について言及
• モノリシックワークスペース
  • チームや個人に適用する単一のオフィスレイアウトのパターンのこと
  • Chapter2でも触れていたが、オフィスレイアウトはチームと個人の状態に依る

ソフトウェアの境界、または「節理面」

• モノリスにはデメリットがあるが、ソフトェアを複数チームで分割する場合も気を付けるべきポイントがある
• 節理面
  • ソフトウェアシステムを複数に分割できる自然な継ぎ目
  • これを探し出せれば自然な分割が行えるようになるはず
    • 通常はビジネスドメインが最善
• 節理面の種類
  • ビジネスドメインのコンテキスト
    • ほとんどの場合適用されるべき境界
  • 規制遵守
    • PCIDSSやISO27001のようなルールに準拠する場合に有効
    • 規制対象をサブシステムに閉じ込めて監査とコンプライアンスを容易にする
  • 変更のケイデンス
    • 変更頻度の異なる機能で構成されていると、変更頻度が最も遅い機能に律速されることがある
    • 変更頻度で分割することで各機能が自律的に動き出せるようになる
  • チームの地理的配置
    • 同じビルでもフロアが異なれば地理的に分散していると考える
  • リスク
  • パフォーマンス
    • 大規模な需要のピークが一瞬だけある機能と定常的に需要のある機能など
  • 技術
    • フロントエンド、バックエンド、データ層など
    • 基本的にはフローで分割されるべきだが、有効な場合もある
      • 古いシステムや自動化しにくい技術の場合など
  • ユーザーペルソナ
    • 機能間の結合や依存関係を取り除くのは大変
    • ペルソナで分割されることでユーザーの体験に集中できるようになる
  • 特定の組織や技術にとって自然なもの
    • その他

ポエム

今参加してる案件がちょうどデータベース結合モノリスなシステム群を抱えているが、この章だけを読んでもどうやって分割するべきかわからなかった・・・。
それとも実際にはモノリシックなシステムになっていなくて、一つのビジネスロジックを実現するための複数のシステムが1つのデータベースに依存しているだけという状態？
だとしても、システムの境界はデータベースではなくMessage QueueやAPIなどになっているべきなのだろうなと思ってしまった。