チームトポロジー入門
チームトポロジーとは？
チームトポロジーはコンウェイの法則を踏まえたチームファーストのアプローチです。 「チーム構造と組織構造を進化させて、望ましいアーキテクチャーを実現する」という逆コンウェイ戦略を実現するために、4つのチームタイプと3つのインタラクションモードを定めています。
チームはソフトウェアデリバリーにおける最も効果的な手段で、じゃあどうするの？というのがチームトポロジー、と具体的に解法を提案しています。
トポロジーってなに？
「位相幾何学」という意味の英単語。図形を連続的に変形しても保たれる抽象的な性質を研究する数学の一分野だが、IT分野では複数の装置や機器を結ぶ配線や接続形態の類型をトポロジーという。
例えば、ネットワーク機器の接続について論じる時に、各端末をどのように接続するかはリング型、ツリー型など自ずと一定の型になっていきます。こうした接続形態の類型を『トポロジー」と呼びます。
コンウェイの法則
組織はそのコミュニケーションパスを反映した設計を作り出す、という法則。
コンウェイの法則（Conway’s law）とは、組織がシステム開発を行う際、その組織のコミュニケーション構造と同じ構造の設計を行ってしまうという法則のこと。1967年にアメリカのコンピュータープログラマーのメルヴィン・コンウェイ（Melvin Edward Conway）が提唱した。
システムやソフトウェアの開発には組織やメンバー間のコミュニケーションが不可欠である。組織の境界によってその関係性が阻害されていればコミュニケーションは阻まれ、統合されたシステムの開発は難しくなる。そのため、システムの構造は組織構造に依存したものになり、コミュニケーションがうまくいっていない領域のシステム連携には課題が多くなる。コンウェイはほとんどの技術領域において当てはまるとしている。
4つのチームタイプと3つのインタラクションモード
チームトポロジーの基本となるアイデアは、４つのチームの形態と変化の流れ、チーム同士の対話を定義する『チームインタラクションモード」があります。
チームタイプ
ストリームアラインドチーム
イネーブリングチーム
コンプリケイテッド・サブシステムチーム
プラットフォームチーム
ちょっと良くわからないですね
イネーブリングチーム
特定のテクニカル（プロダクト）ドメインのスペシャリストから構成され、能力ギャップを埋めるのを助ける」 専門家グループ
コンプリケイテッド・サブシステムチーム は、
「システムのなかでスペシャリストの知識が必要となるパーツを開発、保守する。ほとんどのチームメンバーがその分野のスペシャリストでなければ理解や変更が難しいようなサブシステムを担当する」グループです。
プラットフォームチーム
プラットフォームチームの役割は、「ストリームアラインドチームが自律的に仕事を届けられるようにすること」とされています。ストリームアラインドチームが価値を届けるうえで使用するモノ（ツールやサービス、知識、情報等）を、セルフサービス的に容易に活用できるようにします
ストリームアラインドチーム
ストリームとは、「ビジネスドメインや組織の能力に沿った仕事の継続的な流れのこと」で、ストリームアラインドチームは、「価値のある単一の仕事のストリームに沿って働くチーム」で一つの価値の流れに関して、出発点から到達点までのすべてに対してオーナーシップを持っており、他チームへの仕事の引継ぎを必要としません。他のチームはストリームチームの負荷低減が目的です。
トポロジー・変化の流れ
「図は変化の流れを左から右に示しています。
ストリームに合わせたチームは、ビジネス ドメイン (またはその他のフロー) のスライス全体をエンドツーエンドで所有します。ストリームに準拠したチームは、「You Built It, You Run It」チームです。いかなる目的であっても他のチームに引き継ぐことはありません。
※この図はある時点のスナップショットです。新しい目標が設定され、チームが新しいことを発見すると、チームの関係も変化します。」
チームインタラクションモード（チーム連携の種別）
チーム間のコミュニケーションや協力方法の定義は３つ
コラボレーション：他のチームと密接に協力して作業すること
X-as-a-Service：最小限のコラボレーションで何かを利用または提供すること
ファシリテーション：障害を取り除くために他のチームを支援したり、支援を受けたりすること
上記に該当しない場合は無駄であり、チームの責任境界や目的が適切に割り当てられていないことを意味すると述べられています。関係や求められる結果を明らかにして自分たちが何をしているのか、意識しやすくなる手助けになりそうです。
QIITから拝借した画像ですが、
もとはこちら
４つのキーメトリクス
DepOpsのdev評価の指標となるものは具体的に以下があります。実際の施策とその検証は以下の要素を『計測』することで評価します。
デリバリーのリードタイム
デプロイの頻度
サービス復旧の所要時間
変更失敗率
速い、安い、うまい、的なことで「速く、頻繁に、安定して」お客様にサービスを届け、問題の復旧も速い（問題は起こる前提）という事でしょう。
組織設計には技術的な専門知識が必要
ここまで読むと、「はーん、専門的やな。。。」と感じるかと思います。
チームトポロジーのサイトにはこんな一文が。
「マネージャーに決めさせれば。。。どのサービスがどのチームによって構築されるか、暗黙的にマネージャーがシステム アーキテクチャを決定します。」
日本の低予算開発などによく見る問題として
「PMやBAが開発経験がない」
「なんならPMの上司も開発経験がない」
「やったことはあるけど石器時代」
などが往々にしてあります。SEなる言葉があるように、営業のために珍妙な職種を作り出してきた業界ですので、
『飛行機やビルだったら人が死ぬよ？』とコンサルを頼まれたら言いたくなる状況があります。
「建築家であると主張する人には、技術的スキルと社会的スキルの両方が必要であり、人々を理解し、社会的枠組みの中で働く必要があると、これまで以上に私は信じています。また、純粋なテクノロジーよりも幅広い権限も必要です。組織構造や人事の問題で言えば、彼らはマネージャーでもある必要があるのです。」
これは全く同意見です。どちらか、ではなく、どちらも！必要なのです。
『だってそんなこと言っても、居ないんだからしょうがない」と言う言い訳が聞こえてきそうですが「それはそれ、これはこれ」。
問題先送りで成長やチャンスを逃すかもしれません。
相対的なドメインの複雑さを使用して認知負荷を測定する
チームに聞く
「自分は有能で、頼まれた仕事にタイムリーに対応できると感じていますか?」
コード行、モジュール、クラス、メソッドの数などの単純な尺度を使用してソフトウェアの認知負荷を判断しようとするのは間違っています。
認知負荷を測定する場合
私たちが本当に重視していること = ドメインの複雑さ
私たちがソフトウェアで解決しようとしている問題はどれくらい複雑ですか?
ドメイン = ソフトウェアのサイズよりも広く適用できる概念
チーム第一主義
Google が独自のチームで調査
チームのダイナミクスよりも、チームに誰がいるかは重要ではない
パフォーマンスを測定する場合、個人よりもチームが重要
※注意したいのは「チーム間で仲良くしてもらう、チーム間の情報共有をする」という情緒的な話ではありません。構造の話です。それぞれのチームが最大の力を発揮する要件について考察しています。
小規模で存続期間の長いチームを標準として使用する
チーム」＝共通の目標に向かって一丸となって取り組む5～9人の安定した集団
チームが魔法の 7 対 9 のサイズを超えて成長できるようにすると、そのチームによって構築されているソフトウェアの実行可能性が危険にさらされます (ダンバー数)
信頼が崩れ始める
不適切な決定が生じる可能性がある
組織はチーム内の人々間の信頼を最大化する必要がある
それはチームメンバーの数を制限することを意味します
小さいサイズが信頼を育む
人類学の研究は、私たちが人々と築くことができる関係の種類と深さには明確な限界があることを示しています。また、ヒトの脳が一度に把握できる量には限界があるため、人数が増えると様々な負荷が発生しモチベーションが低下します
5 人程度 - 親密な個人的な関係と作業記憶を維持できる人の限界
深い信頼関係を築けるのは15人程度
50人くらい、信頼できる限界の人たち
約 150 人 - 私たちが覚えている能力のある人の限界
その他の要件
個人ではなくチーム全体に報酬を与える
チームメンバーにはチームファーストの考え方が必要
米軍などでも取り入れられている
これと似たことは米国の海兵隊の組織研究で読んだことがあります。
軍隊の１単位である小隊の人数は、第２次世界対戦では１０数名、その前の次代は数十名、古代では１００名と、時代が進む（＝高度化する）と人数が減っているそうです。
戦争は広い面積で作戦をする物理要求があるため、数や兵力が重要でありITとは比較にならなさそうですが、現代ではたった一人の兵士が前線からドローンを呼び出し大きな火力を使用できるため、人数＝兵力ではないケースが増えたことが前提にあります。
現代では研究で最前線で高度な作戦に当たる小隊の人数は隊長含め６人以下が適正と言われており、その研究を元も過酷な作戦を前線で行う海兵隊がまず取り入れているという事です。アメリカのGMなど大企業も取り入れているとありました。
戦争では同士討ちによる死傷が実は非常に多いことも、課題となっています。
チームAPI設計
チームの周りにあるモノをAPIとして定義します。
文書、コード、仕事の方法など。キーワードの定義、日報、チーム設計そのもの、バージョニングの方法、ミーティングのスケジュール、Slackのチャネルなど、実は多くのAPIに囲まれて仕事をしています。
結論
こんな感じで様々な視点から、よりより開発のため強いチームを作り以下に生産性（＝モチベーション）を維持するか、様々なヒントを与えてくれています。結論では以下の様な注意をしています
▶チーム トポロジだけでは、効果的なソフトウェア配信および運用組織を生み出すことはできません。本書で提案されている構造とダイナミクス以外にも、成功の重要な追加要素として次のものが挙げられます。
健全な組織文化:
個人とチームの専門能力開発をサポートする環境
どの人が力を与えられていると感じているか
安心して話せる
組織は継続的に学習することを期待しています
優れたエンジニアリングの実践:
システムのあらゆる側面におけるテストファーストの設計と開発
継続的デリバリと操作性の実践に重点を置く
コードレビューのためのペアリングとモビング
インシデントの単一の「根本原因」の探索を回避する
テスト容易性を考慮した設計など
健全な資金調達と財務慣行:
CapEx/OpEx の悪影響を回避する
プロジェクト主導の期限や大規模な予算編成を可能な限り回避する
トレーニング予算を個人ではなくチームまたはグループに割り当てる
ビジネスビジョンの明確さ:
経営幹部またはリーダーシップが明確なビジョンと方向性を提供する
人間に関連したタイムスケールでの視野をもつ
優先順位の背後にある明確な理由
したがって、組織内の人々は、これらがどのように、そしてなぜ選ばれたのかを理解できます。
ドラッカーの言う「基本
どうやって始める ？
チームから始めましょう
チームが次のことを行うためには何が必要ですか:
効果的なチームとして行動し、運営していますか?
ソフトウェアの一部を効果的に所有していますか?
不必要な認知負荷を軽減しますか?
ソフトウェアと情報を使用して他のチームに提供しますか?
適切な変化の流れを特定する
最も薄く実行可能なプラットフォーム (TVP) を特定する
これらの流れにおける信頼性の高い迅速な変化の流れをサポートするために必要なサービスを特定する
チームのコーチング、メンタリング、サービス管理、および文書化における能力のギャップを特定する
さまざまなインタラクション モードを共有して実践し、新しい働き方の背後にある原則を説明する
ドラッカーいわく
チーム優先、少人数のほうが効率が良い、などは言当たり前のことに感じますが実際には開発要求に対して量的にただ人を増やし、それでも間に合わず慢性的なデスマーチというのはスマホゲーム開発などではよくある光景かと思います。 ゲームのように作る量が膨大でなくても、思いつきで始まったようなプロジェクトで変更に変更を重ねて気がつけばアプリは巨大化、様々な開発負債がある中で苦しい気持ちで開発を続けるというケースもあるでしょう。そして多くの場合、開発者の本意ではないでしょう。
考えるにオンライン化、大規模サーバー、高速インターネット、複雑なUIと仕事は増えているのにアプリは無料。フリーミアム経済が拡大しユーザーに対して「無料なのだから」という不誠実な企業の態度と資本力でユーザーを取り合うマネーゲームのために開発競争をするため膨大な作業者の負担、というおかしな構造が業界のモラルを下げたこともこうした本がでる土台になっている気がします。
「基本と原則に反するものは、例外なく時を経ず破綻する」
とは故ピーター・ドラッカーの名言ですが、生身の人間で構成されるチームが破綻することのないようにしたいものです。
また、実際に変化を起こすとなれば、多数は反対する可能性が高いでしょう。それは落伍すれば不利益になると直感で感じるからです。
チームトポロジー変革のリーダーには厳しい作業が待っていそうな気もします。
※ここに書かれているチームは米国の話であり、世間一般より高い給与・待遇で世界的な労働市場から優秀な人を集めている dev 世界が前提になっています。
スクラム・アジャイルもそうですが、日本のような未経験・会社でやったことだけ/学校で『やってる感」教育だけの人たちを前提にはしていません。海外（アメリカ沿岸部、中国韓国IT、インド、ロシア、イスラエルなどIT優遇国）の開発者は猛然と自ら学び国際的な流動性のある過酷な労働市場の中で高給を得ていますので、日本国内を前提にしていないことに留意してください。
また、GAFAMなどがアジャイルに否定的だったり、流行と実績は別です。盲信せずあくまでも知識、アイデアとしてまずは取り込んでいただければと思います。
この記事が気に入ったらサポートをしてみませんか？