Zenn
Open5

プロダクトの価値から考える（チームトポロジー編）

#
チームトポロジー
たなかゆうきたなかゆうき

現状企業は何をしなければならないか。

「LeanとDevOpsの科学」で紹介されている

  • デリバリーのリードタイム
  • デプロイ頻度
  • サービス復旧の所要時間
  • 変更失敗率
    の４つの指標を追い求めることが企業の成功につながることが示されている。
    つまりは「ユーザーに対して素早く、頻繁に、安定的に価値を届け続け、問題があれば素早く復旧する」必要がある。
    早く安定していることを重視しているが、これを妨げるのは
  • コンウェイの法則の無視
  • チームにとって大きすぎるプロダクト
  • モチベーションの低いチーム
  • etc...

コンウェイの法則・・・システムを設計する組織は、そのコミュニケーション構造とそっくりな構造の設計をしてしまう。

チームトポロジーとは？

  • フローを実現するためのもの
  • 適応型の組織設計モデル
  • 普遍的な公式ではなくパターン
  • チーム間の相互関係の効果の向上を目指す
  • 技術、人、ビジネスの変化に継続的に対処できるようにする
    →技術、人、ビジネスの変化に継続的に対処できるようにすることを目的とした、フローを実現するためのパターン

要素

  1. 逆コンウェイの法則・・・組織はチーム構造と組織構造を進化させ、望ましいアーキテクチャ を実現すべきという考え方

  2. チームファースト
    チームを価値を生み出す基本的な構成要素として扱う。価値提供してんからチームをみる必要がある。ただ、だからと言って「チーム間の情報共有を増やそう！」は必ずしもいいとは限らない。コミュニケーションの複雑性を抑える（コンウェーの法則を考えよ）。チーム間を疎結合にする必要がある。プロジェクトの規模を小さくする必要がある。
    [思ったこと1]横連携はインターフェースとなる人を据えるのもいいかもしれない
    [思ったこと2]必要な機能（価値を出している機能）のみを残すという視点も必要

  3. チームAPI
    上の思ったこと１の話だ
    また、プラスして、APIは仕様書をチーム外に提供する必要がある。このチームが何を提供しているチーム化をしっかりと外にわかってもらう必要がある。

  4. 4つのチームタイプ

  • ストリームアラインドチーム・・・ビジネスの主な変更フローに沿って配置する中心チーム
  • プラットフォームチーム・・・インフラや共通サービスなどの内部サービスを提供するチーム
  • イネイブリングチーム・・・他のチームが新しい技術やスキルを身につけるのを支援するチーム
  • コンプリケイテッド・サブシステムチーム・・・複雑なサブシステムやコンポーネントを担う専門チーム
  1. 3つのインタラクションモード
  • コラボレーション・・・２つのチームが探索を目的として協力し合う。責任協会が不明確で効率は悪いが学習は進む
  • X-as-a-Service・・・一方のチームが他方のチームが提供するものをサービスとして利用する関係性
  • ファシリテーション・・・一方のチームが他方のチームが新しい技術を身につけたり学習したりするためにファシリテーションする。他チームの障害を取り除く。

  1. 組織的センシング
    環境の変化を感知できなければ、やることは意味をなさない

  2. トポロジーを継続的に進化させる
    トポロジーは静的なものではなく動的なもの
    プロダクトやサービスの成長、チームの学習などに合わせて適応させていく

まとめ

「ユーザーに対して素早く、頻繁に、安定的に価値を届け続け、問題があれば素早く復旧する」ためにプロダクトだけでなく、価値提供に関わる全ての変数を最適化する必要がある。そしてその変数とは、チーム、プロセス、技術。そしてチームトポロジーはチームとチーム間のコミュニケーションにフォーカスをしたもの。
プロダクトと一緒にチームも進化していく必要がある。

https://slide.meguro.ryuzee.com/slides/109
https://amzn.asia/d/f9fkNdg