「機能を足すたびに、チームの動きが重くなっていく」
レビューにデプロイ、問い合わせ対応と、小さな仕事が積み重なって本来の開発に頭が回らないという悩みは、多くのチームで耳にします。
人数や個人の頑張りの問題に見えがちですが、書籍『Team Topologies』は、そこに任された仕事がチームの認知負荷の限界を超えているという見方を持ち込みました。
あなたのチームは、いま同時にいくつの領域を抱えているでしょうか。
私もテックリードを目指して学んでいる途中ですが、公式サイトや Martin Fowler 氏の解説をたどると、4つのチームの型と3つの関わり方という物差しが見えてきます。
チームトポロジーは「認知負荷」から組織を考える
『Team Topologies』は Matthew Skelton 氏と Manuel Pais 氏の2019年の本で、2021年には日本語版『チームトポロジー』も出ました。
土台にあるのは、コンウェイの法則と認知負荷という2つの考え方です。
出発点はコンウェイの法則
Melvin Conway 氏は1968年の論文で、システムを設計する組織は、自らのコミュニケーション構造を写した設計を生み出すと述べました。
原文は著者のサイトで「How Do Committees Invent?」として読めます。
この法則を逆手に取り、望むアーキテクチャに合わせて先にチームの分け方を変えるのが「逆コンウェイ戦略（Inverse Conway Maneuver）」です。
Fowler 氏は解説記事「Conway's Law」で、システムの分割と開発組織の分割は一緒に行う必要があると念を押しています。
認知負荷は3種類に分かれる
認知負荷は、心理学者の John Sweller 氏が1988年に「作業記憶で使われている精神的な労力の総量」として特徴づけた概念です。
書籍の版元 IT Revolution の抜粋記事「Team Cognitive Load」では、これを3つに分けています。
- 内在的な負荷（intrinsic）: 言語の文法など、問題そのものに根ざした負荷
- 外在的な負荷（extraneous）: 「これ、どうデプロイするんだっけ」のような、作業環境から来る負荷
- 学習に関わる負荷（germane）: 「このサービスは別のサービスとどう連携すべきか」のような、価値を生む考えごと
目指すのは、内在的な負荷を研修や技術選びで減らし、外在的な負荷は自動化などでなくして、空いた頭を価値を生む考えごとに回すことです。
4つのチームタイプと3つのインタラクションモード
チームトポロジーは、チームを4つの型に、チーム同士の関わり方を3つのモードに絞り込みます。
4つのチームタイプ
主役は1つめのストリームアラインドチームで、残りの3つはそれを支える側です。
- ストリームアラインドチーム（Stream-aligned）: 事業領域の流れに沿って、企画から運用まで一通りを受け持つ
- プラットフォームチーム（Platform）: セルフサービスで使える内部の仕組みを、プロダクトとして提供する
- イネイブリングチーム（Enabling）: 専門家が一時的にコーチとして入り、他チームにスキルを根付かせる
- コンプリケイテッド・サブシステムチーム（Complicated-subsystem）: 高度な数学や専門知識が要る部品を専任で受け持つ
Fowler 氏は、フルスタックで運用まで受け持つチームが過大な認知負荷を抱えやすい点に着目したことを、このモデルの鋭さだと評しています。
支える側の3つも、ストリームアラインドチームの負荷を軽くするために置くという位置づけです。
3つのインタラクションモード
型と同じくらい大切なのが、チーム同士の関わり方に名前を付けることです。
- コラボレーション（Collaboration）: 期間を決めて一緒に働き、新しいことを見つける。やりとりは濃いがコストも高い
- X-as-a-Service: 一方が提供し、もう一方がサービスとして使う。やりとりは最小限で境界がはっきりする
- ファシリテーション（Facilitating）: 一方が他方を手助けして障害を取り除く。一時的で目的が絞られている
Fowler 氏も解説記事「Team Topologies」で、組織は4種類と3種類に分けきれるほど単純ではないと認めつつ、その制約がモデルを役立つものにしていると書いていました。
テックリードは「担当領域の棚卸し」から使う
テックリードが組織図を描き直す権限を持っているとは限りません。
それでも、自分のチームの負荷を見立てて言葉にする役なら、明日からでも担えるでしょう。
まず負荷を聞いてみる
抜粋記事が勧める手軽な確かめ方は、責めない口調で「頼まれた仕事に、効果的かつタイムリーに応えられていると感じますか」と問いかけることです。
正確な測定ではないものの、チームが過負荷を感じているかどうかをつかむ手がかりになるとされています。
領域を数えて、種類で分ける
記事「Minimize Team Cognitive Load to Increase Flow」は、受け持つ領域を数えて「単純」「込み入っている」「複雑」に分ける方法を紹介していました。
示されている目安は次の4つです。
- 1つの領域は1つのチームに任せる。大きすぎるなら先に領域を分けてから割り当てる
- 単純な領域なら、1チームで2〜3個まで
- 複雑な領域を持つチームには、他の領域を持たせない
- 込み入った領域を2つ、同じチームに持たせない
棚卸しを書き出すなら、例えば以下のようなメモのイメージです。
# チームが受け持つ領域の棚卸し（例）
team: 決済チーム
domains:
- name: 決済API
kind: complex # 試行錯誤しながら解く
- name: 請求書PDFの生成
kind: simple # やることが決まっている
- name: CI/CDパイプラインの保守
kind: complicated # 分析してから直す
# ... 問い合わせ対応やオンコールも書き出すこの例は、複雑な決済APIに加えて2つの領域を抱えており、3つめの目安から外れています。
表にしておけば、人ではなく仕事の置き場所の話として、どれを他チームへ渡すかを相談できるのです。
外在的な負荷から削る
同じ記事は負荷を空ける手として、会議やメールを減らす、問い合わせ窓口を担当者に集める、やり方ではなく目標を伝える、などを挙げています。
技術を一つ足すたびに運用と覚えることが増える、という技術選定の考え方も、負荷を抑える話と地続きです。
取り入れるときの落とし穴
分かりやすいモデルだからこそ、誤った使い方に陥りやすい面も見えてきました。
一つめは、チームの型だけを組織図に貼り替えて終わることです。
公式サイトの「Key Concepts」は注意書きで、このモデルは組織図を作り直す方法ではなく、チームの型だけを使っても大きな成果は見込みにくいと明記しています。
二つめは、逆コンウェイ戦略を即効薬と考えることです。
Fowler 氏は、硬い既存システムを抱えたまま組織だけを変えても開発者とコードの食い違いが改修の摩擦になりやすいとし、フィードバックを見ながら小さく進めるよう勧めています。
三つめは、コラボレーションをずっと続けてしまうことです。
公式サイトの図にも「チーム同士の関係は変わっていく」と添えられており、関わり方は期限つきで決めて見直すものと捉えるのが自然でしょう。
最後は、仕事を足すばかりで減らさないことです。
公式サイトの原則には、有能なチームでも何も取り除かずに仕事を積み増し続ければ機能しなくなるという趣旨の一文がありました。
最後に
チームトポロジーの出発点は、チームの詰まりを人の力量ではなく抱えている領域の量と種類で見ることにあります。
4つの型と3つのモードを負荷を減らすための共通の言葉として使えば、組織図を動かせない立場からでも提案の材料になるでしょう。
チームの形を変えればアーキテクチャも一緒に動くので、作り直すか少しずつ直すかの分かれ目もあわせて押さえておくと役立ちます。
私も、まずは身近なチームが抱える領域を書き出すところから始めてみます。
以上です。
コメントを残す