Remote Team Interactions Workbookまとめ

Remote Team Interactions Workbook: Using Team Topologies Patterns for Remote Working

Remote Team Interactions Workbookは、
チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計を書いたMatthew SkeltonとManuel Paisによるチームトポロジーをリモートワークに適応させることに焦点を当てた本です。

チームトポロジーについては、以下の訳者の方の資料がわかりやすいです。

https://www.ryuzee.com/contents/blog/14566

2020年以降のCOVID-19の大流行は、多くの企業の働き方を変化させ、新たなリモートファーストの世界を到来させました。特にIT業界においては多くの企業がリモートワークに切り替えを行い、この変化は非可逆のものだと感じています。

しかし多くの企業はその変化に適応するのに苦労していて、

物理的なオフィスが十分に定義されていないチームや責任範囲を覆い隠し、DevOpsの推進やビジネス全体の健全性と成功をカバーしていたことに気づきはじめています。

"フル出社"が当たり前の時代にはもう戻らず、New Normalな日々が続くでしょう。リモートファーストな働き方に適した組織運営がますます求められています。

そのような中書かれたこの本では、リモートファーストな働き方の組織にフォーカスし、チームトポロジーのモデルを適応して組織を成功させるためのパターンを紹介しています。
本記事では、その内容を簡単にまとめます。

リモートファーストのアプローチを成功させるには、物理的な空間とオンラインスペースを使用したチーム間のコミュニケーションを明確に設計する必要があります。

鍵となるのは、明確に定義されたチームの相互作用です。

チームトポロジーの要約

チームトポロジーでは、ビジネスの変化の速い流れに適応する組織の設計とチームの相互作用のための実用的な優れたアプローチを紹介しています。

チームトポロジーの組織モデルでは、チームの4つの基本的なタイプと3つの主要なチーム間の相互作用モードが、ソフトウェアの構築と運用に対する現実的なアプローチを定義します。

チームの4つの基本的なタイプは次のとおりです。

• Stream-aligned team: 事業の根幹となるビジネスのStream(プロダクトや機能の開発など)に沿って仕事をする職能横断チーム。他のチームはこのチームがStreamに集中できるようにする役割を持つ。
• Enabling team: Stream-aligned teamに欠けている新技術やプラクティスの導入を支援し、能力を獲得するのを支援するチーム。
• Complicated-subsystem team: 数学、画像処理など技術的な専門知識が必要となるサブシステムを研究、開発する責任を持つチーム。
• Platform team: Stream-aligned teamによる自律的なデリバリーと運用を加速するための内部サービスを提供するチーム。

それらのチーム間の相互作用モードは3つあります。

• Collaboration: 2つのチームが特定の目標を達成するために、定義された発見期間、一緒に働く
• Facilitating: あるチームが別のチームの能力ギャップを検出したり、スキルや意識を向上させたりするのを支援する。
• X-as-a-Service: 1つのチームが「サービスとして」何かを提供し、もう1つのチームがそれを使用する。コミュニケーションは最小限。

チームトポロジーの基本原則は、そのアプローチによってビジネスのフローの阻害要因を解消することです。

ここからは、本の内容をまとめます。

Chapter 1:リモートチームの相互作用に焦点を当てる

リモートファーストの世界で成功するために組織には何が必要か？

• リモートファーストのアプローチを成功させるには、単にチャットやビデオツールを導入するだけでは不十分
• 基本的なルールやプラクティスを持っている必要がある
• チーム内の相互作用が明確に定義されていること
  • 組織内のさまざまなグループ間の関係や様々な活動の目的が明確になり、チームにかかる認知的負荷を最小限に抑え、組織内の仕事の最も重要な側面に集中できるようになる

認知負荷とは

• タスクまたは一連のタスクに使用されている精神的な努力の量
• チームの場合、認知負荷はチーム全体が使用している精神的な努力の総量

チームAPIアプローチによる、責任とチームフォーカスの定義と伝達

• チームAPI
  • 組織内の他のチームがそのチームとどのように相互作用するのか、またすべきなのかを定義する仕様のようなもの
• チームAPIがカバーする範囲
  • チームが所有する成果物(ライブラリ、アプリケーション、サービスなど)
  • バージョン管理とテストのアプローチ
  • Wikiとドキュメント
  • プラクティスと原則
  • ロードマップと優先順位
  • コミュニケーションの好み(いつ/どのように)

これらを定義することにより、チームは目的の明確さを高め、他のグループがそのチームが組織内でどのような立ち位置にいるかを理解するのに役立つ

シンプルなツールを使用して依存関係を追跡し、阻害要因となっている依存関係を削除する

• すべてのチームは、多かれ少なかれ、他のチームに依存している
  • ある種の依存関係は、今は問題なくても、数カ月後には依存するチームの速度があまりにも遅くなり始めたりする
  • チーム間の依存関係を現在から未来にかけて追跡する必要がある
    • どの依存関係が問題があって取り除くべきで、どの依存関係が今のところ「制御下にある」のかを特定する
• 問題のある依存関係は、大幅な遅延をもたらしたり、予測が難しかったり、依存チームの仕掛品（WIP）を増やしたりして、チームの速度を大幅に低下させる
• リモートファーストの環境の特徴的な課題
  • 他のチームの誰かのデスクに行き、進捗状況を尋ねることは不可能
  • 進捗状況を尋ねるチャットメッセージが絶え間なく流れてくるのは、認知的な負担となる

他のチームが作業を終えるのを待つことに時間を費やすのではなく、これらのフローの依存関係を追跡し、取り除くことに集中することが重要

十分な量の文書を使用してオーバーコミュニケーションを行う

• リモートワークの環境では、「オーバーコミュニケーション」が重要
• 主にテキストメッセージやチャットでコミュニケーションをとる場合、文化の違いによる言い回しの問題はもちろん、トーンや緊急性を見極めるのは難しい
• リモートワークの世界では、自分が何に取り組んでいるのか、なぜそれに取り組んでいるのか、どのように仕事を完成させているのか、いつまでに完成させるべきなのか、常に明確にすることが不可欠
• オーバーコミュニケーションの形式
  • チャットツールで小さな決定を共有
  • Wikiやドキュメントで大きな決定やデザインを書く
  • 重要な概念を説明するプレゼンテーションやレポートを作成する

メッセージは自己完結させる

• リモートファーストの組織やチームでは、人と人とのやりとりのほとんどがチャットやテキストメディア（Wikiや文書など）を介して行われるため、優れた文章力を重視することが重要
• 単に文章をたくさん打てばいいというわけではない
• 文章は、それ自体で見たときに文脈があることが必要
• 「あなたはどう思いますか?」という問いに答えるには、メッセージを読む人が文脈を把握していなければ理解できない
• 「こんにちは。Aの性能に問題があるため、コンポーネントAをコンポーネントBに変更すべきだと思いますか？」と聞けば、読み手に十分な文脈を与え、元の質問やチャットのスレッドを探し出す必要はない
• メッセージは自己完結させる

Chapter 2:チームの依存関係

ここからのChapter2,3,4では、リモートファーストのチームの仕事を改善するための3つのパターンを紹介しています。
Chapter 2では、リモート環境で機能するチーム間の依存関係を追跡・管理するテクニックを紹介しています。

• チーム間の依存関係は、最小化しようと思っても、どんな組織にも存在する
• 依存関係が把握できていないと、スケジュールや優先順位付けの問題にぶつかり、デリバリーの流れが遅くなってしまう
• チーム間の依存関係を把握するためには、各チームが行っている作業を可視化する必要がある
  • この依存関係を追跡することができれば、健全な依存関係を促進し、遅延やブロックとなる依存関係を取り除く（またはその影響を最小化する）ことに目を向けることができる

Team API

• 組織全体に各チームが現在行っている作業と優先順位を明確にし、可視化する
• 各チームがその情報をチーム外の人々に向けてわかりやすく示す必要がある
• チームAPI
  • チームの所有権、コミュニケーションの好み、プラクティス、原則に関連するさまざまな側面を記述する明確なインターフェイスのこと
    • チームはどの成果物を所有しているのか？
    • その成果物を開発し、テストし、バージョンアップし、提供するために、どのようなプラクティスを用いているか？
    • 今後の作業のロードマップ
    • どのチャンネル（チャットツール、ビデオ会議、電子メール、電話など）を使うか
    • コミュニケーションをとるのにどの曜日と時間が適しているか
    • 非同期のコミュニケーションにおける期待応答時間
• 情報やチームへのアクセスを可能な限り明確にすることで、他者の認知的負荷を最小限に抑えることができる
• 特定の質問に対して誰に話せばいいのか、また必要なときに特定のチームにいつ、どのように話せばいいのかがすぐにわかるようになる
• チームは互いに独立して自分たちのAPIを定義することができる
• チーム外の人々が利用しやすい一貫した形式に従っていれば、チーム間のコミュニケーションと相互作用をより明確にし、より目的を持ったものにすることにつながる

依存関係の追跡

• チームトポロジーの原則を適用する場合、システムやサービスの所有権を個々のチームに与えることで、チーム間の依存関係を減らすことが目標の1つになる
• しかし、すべての依存関係を完全に根絶することはでない
• 依存関係には様々な種類があることを認識することも重要
  • ブロッキング（仕事の流れを止める、待ち時間を発生させる）
  • ノンブロッキング
  • 健全
  • 不健全
  • 頻繁
  • 稀
• 依存関係を完全になくすことはできないため、チーム間の依存関係とその種類を現在および長期にわたって追跡することが重要
• 問題のある依存関係は、大幅な遅延を引き起こし、予測不可能性をもたらし、依存するチームの仕掛品（WIP）量を増加させる可能性があるため、チームが抱えている依存関係を記録し、どの依存関係が「制御下」にあり、どの依存関係が対処する必要がある問題なのかを特定することに目を向ける必要がある

ネットワークの構築:コーヒー、雑談、社内会議

• オフィスでの仕事での非公式なネットワークの構築
  • コーヒーメーカーの近くで誰かに会う
  • ランチタイムに誰かとおしゃべり
• リモート環境でも、知識を共有し、人々が互いに交流し、社会的な接触を保つことを目的としたこのような交流を継続させることが重要
• このような活動は、将来的に互いに信頼し合えるような人々の非公式なネットワークを育成するのに役立つ
  • バーチャルコーヒー休憩
    • リモートワークで孤立する傾向に対抗するため、いくつかの企業では、15分または20分のバーチャルコーヒー休憩を意図的に作っている
  • コミュニティ・オブ・プラクティス（CoP）やギルド
    • 他のチーム内の意識や能力を高め、より広く知識を共有する機会を用意することも有用
    • より広範な知識の共有を可能にし、同じような関心を持つ人々の共有文化や帰属意識を育むのに役立つ
  • 社内カンファレンス
    • 部門を超えた複数のチームでの学習を促進する
    • 組織の共有、学習、コミュニケーションのレベルに大きな影響を与えることができる

このような場を通じて、将来起こりうる共同作業をサポートするための非公式な知識共有のネットワークを構築・発展させます。

Chapter 3:チーム境界の設定

• チーム間の信頼と行動のダイナミクスは、グループの規模によって異なる
• 「私達と彼ら」の状態を避けることが重要

グループの信頼境界

• 組織内のチームやその他のグループの境界を考慮するときは、グループの信頼レベル(特定のサイズのグループ内に存在できる信頼関係の量)を考慮することが重要
• 高い信頼関係があれば、グループは迅速に意思決定を行い、フローを改善できる
• 信頼にはよく知られた限界がある

ダンバー数

• 英国の人類学者Robin Dunbarによるソーシャルネットワークの規模、つまり人が有意義な関係を持つ事ができる人の数についての研究
• 個人のソーシャルネットワークのサイズは、典型的には100~200人のオーダーである
• オンラインのソーシャルネットワークについても同じような信頼関係の境界線、同じような社会的グループ分けが存在する
• 典型的な人は、ソーシャルメディア（FacebookやTwitterなど）上で150人以上の有意義な関係を維持することはない
  • つまりFacebookの友達が5,000人いたとしても、実際に交流しているのは約150人程度ということ
• その関係性にも境界があり、5,15,35のように数が小さくなるほど信頼関係が強固なグループとなる

ダンバー数を用いたチームのスケーリング (Chapter 3 Figure 3.1より)

• 組織が高いパフォーマンスを発揮するためには、成長するとき、チームを連携させるとき、影響範囲を考えるときに、信頼の境界線を見る必要がある
• 組織内のグループがこれらの信頼関係の境を超えて大きくなると、結束と信頼を維持することが難しくなり、「我々と彼ら」という態度になり、パフォーマンスが落ちる可能性が高くなる

オンラインスペースの設定

• オンラインコミュニケーションツールはしばしば、巨大なオープンスペースのオフィスのようなもので、人々はフロアの中で大声で話し、全員がすべての詳細を聞くことを期待してしまっている
• オンラインスペースでのコミュニケーションは、最良の結果を得るためにデザインされ、育成されなければならない
• オンラインスペースのサイズが信頼の境界線（50人や150人など）に達したとき、同じオンラインスペースにさらに人を追加するのではなく、新しいスペースを作成する
• 重要なことは、信頼関係の境界線を念頭に置いてオンラインスペースをデザインすること
• それぞれのオンラインスペースは組織内の異なる職務の「機能」ではなく、「変化の流れ」に関係するものでなければならないということが重要
• 人事、法務、マーケティング、IT などの機能的専門性に対して別々のオンラインスペースを作ることは推奨されない
  • 変化の速い流れに逆行する
• 同じビジネスエリアやバリューストリームに取り組むチームのグループごとに、専用のオンラインスペースを用意することは理にかなっている
• 管理のしやすさ、請求のしやすさ、複数のグループの観察のしやすさなどを最適化することは、フローを阻害する可能性がある

チャットツールのチーム向けルール

• すべての従業員がチャットツールにアクセスできるようにするだけでは、リモートファーストを成功させるための最初の一歩にすぎない
• あまりにも多くの組織が、チャンネル名、表示名、絵文字の意味、あるいはエチケットについてほとんど一種の自由裁量を許可している
  • 急速にチャットツールが注視しなければならないものになると同時に、信じられないほど使いにくいものになることにつながる
• 効果的なリモートワークのためには、チャットツールのルールが必要
• チャットツール内の仮想空間は、予測可能で発見可能である必要がある
• #homepage_discussion、#increase-conversions、#ninjas のような任意のチャンネル名は、トピックを議論するためにどこに行くかを知ることは困難

予測可能性と発見可能性を向上させる一連のルールを定義する

• チャンネル名にチーム名およびチームのタイプを含ませる
  • #streamteam-green: ストリームチーム "Green "のパブリックチャンネル
  • #streamteam-blue: ストリームチーム "Blue "のパブリック・チャンネル
  • #platformteam-data: プラットフォームチーム "Data "のパブリック・チャンネル
  • #platformteam-infra: プラットフォームチーム "Infra "のパブリックチャンネル
  • #enablingteam-k8s: イネーブリングチーム "k8s "のパブリックチャンネル
• 共通のインフラやツールのサポートやヘルプを得るためのチャネル名を明確にする
  • #support-environments: 環境のためのサポートチャンネル
  • #support-logging: ロギングをサポートするチャンネル
• 誰もが質問や助けを求めるのに最も適した場所を簡単に見つけることができるようになる
• 各人のチャットで表示される表示名を説明的にする
  • Jimやsara_bという表示名は、Jim Ngo (Infra Platform Team)やSara Brown (Green Stream Team)といった表示名よりもずっと文脈が分かりにくい
  • より説明的な表示名では、その人が誰で、組織内でどのように関連しているのか、すぐにコンテキストを得ることができる

X-as-a-Service での対話を促進する

• X-as-a-Service での対話を促進するために、チームによって提供されるサービスを提供するチャネルのヘッダーに使用方法へのブックマークを追加する
• ほとんどのチャットツールはチームへのリクエストを標準化する簡単な方法を提供している
  • Slackワークフロービルダーのテンプレート

Chapter 4:意図的な相互作用

• 非効率的な組織の解決策として、「コラボレーションを増やす」ことがよく提案される
• しかし、コラボレーションは意図しない効果や認知的過負荷を発生させることがあるため、慎重に管理される必要がある

チームの相互作用モードについて

• チームトポロジーの中で述べているように、"私たちはもっとコミュニケーションをとり、コラボレーションをするべきだ、つまり、みんなとすべてを話せばいいのだ！"というのはよくある神話
  • 残念ながら、それほど単純ではない
• 2018年に発表されたハーバード・ビジネス・スクールの研究によると、ナレッジワークでは、全員が常に他の全員に話しかけている組織の方が、チームやグループがたまにコミュニケーションやコラボレーションをする状況よりも、パフォーマンスが悪い
  • チーム間でより目的にかなった相互作用を行う必要があることを裏付けており、私たちはチーム間でもっと目的意識を持った交流をする必要がある
• 重要なのは、各チーム間の相互作用がきちんと定義されていること
• チームトポロジーの中で、著者らは3つのコアなチームの相互作用モードを定義している
  • 現在から将来にわたって、組織が盲目的に従うべき静的なモデルではない
  • 固定されたチームデザインではなく、ある一瞬のスナップショットを表している
• 各チームが現在の相互作用と将来予想される相互作用を認識、記録、更新し続ける。それをチームAPIを通じて組織内の他の人が簡単に見られるようにすることが重要

Collaboration

• 2つのチームが特定の目標を達成するために、定義された期間一緒に働くモード
• 2つのチームのコラボレーションは、短期間であれば効果的な結果を得ることができる
• コラボレーションが長期間続くと、効果は薄れる
• 異なるスキルを持つ2つのチームのコラボレーションが長期間続くと、やりとりが負担になり、どちらかのチームに欠けている能力や機能が潜在的にあることを示唆することがある
  • コラボレーションの必要性を繰り返し引き起こすチーム間の依存関係を軽減する方法を探す必要がある

Facilitating

• あるチームが別のチームの能力ギャップを検出したり、スキルや意識を向上させたりするのを支援する
• 2～3週間程度の短い有効期間、2つのチーム間でファシリテーションを行うことは、良いこと
• しかし、もしそのファシリテーションが6ヶ月後にも続いているとしたら、それは何かがおかしい

X-as-a-Service

• 1つのチームが「サービスとして」何かを提供し、もう1つのチームがそれを使用する
• X-as-a-Serviceは、提供されるサービスが受け取り側のチームによって容易に使用されることを条件として、より長期的な相互作用モードとなる
• そのサービスがX-as-a-Serviceに適しているかどうかは、サービスを受ける側のチームがそのサービスを使用するかどうかで決まる
• サービスを提供するチームは、受け取り側のチームからのフィードバックに常に耳を傾け、以前うまくいったことが現在もうまくいっていることを確認することが重要
• あらゆる種類の社内プラットフォームを開発・運営する上で最も重要なことの1つは、社内顧客（プラットフォームを利用するエンジニアリングチーム）からのフィードバックによって、プラットフォームの機能とユーザビリティを継続的に改善すること

開発者や他のエンジニアからのフィードバックを形にするために有効なテクニック

• Internal Platform Survey
  • 社内プラットフォームの使い勝手や使用感について、簡単な質問をする
  • フォームをさまざまな社内顧客（開発者やその他のエンジニア）に送信する

本では、開発者の体験に関するアンケートのテンプレートが提供されています。

Internal User Personas

• 社内のユーザー・エクスペリエンス（UX）の専門家と協力して、社内の顧客（開発者やその他のエンジニア）に対する一連のユーザー・ペルソナを定義する
• 最も重要なことは、その妥当性を確認すること
• 実際のユーザーを使って仮説を検証することが非常に重要
  • この確認プロセスにより、顧客に構築または提供する必要があるものについての期待値を調整する
• ユーザーペルソナの最も単純なバージョンは、プラットフォームで作業する各タイプのエンジニアの目標と不満を特徴付けること
  • 彼らは何を達成したいのか？彼らは何を達成したいのか、何を困難と感じているのか？

チーム内のやりとりに耳を傾ける

• チームの相互作用における困難やぎこちなさは、組織を正しい方向に進化させるための一種のセンシングメカニズムとして利用することができる
• 組織内で発生するコミュニケーションは、組織図の通りになることはなく、異なる部署の人たちとも互いにコミュニケーションをとっている。同時に、組織の一部が孤立している場合もある
• 組織図の問題点は、多くの知識労働や発見活動において、異なる部署の上下にしかコミュニケーションが起こらないということはありえないということ

実際のコミュニケーションラインを示した組織図。(Chapter 4. Figure 4.2より)

• 重要なのは、形式的なプロセスや組織図の決定ではなく、真のニーズがチーム間の相互作用を促進させる必要があるということ
• "真のニーズ"とは、顧客や実際にソフトウェアシステムを使用している人々のニーズを満たすこと
• フローを重視することで、これらのニーズをできるだけ効果的かつ迅速に満たすことができる
• 組織図がチーム間のコミュニケーションを制限するような状況は避けるべき
• 明確に定義された相互作用とチームAPIを使用して、システムのさまざまな部分を構築するために他のチームと通信する必要がある

ダイレクトメッセージの誘惑の沼

• リモートワークの文脈では、チャットツールが他のチームとの通信を可能にするため、ダイレクトメッセージや人々が特定の個人に連絡する沼に陥りやすくなる
• もし、オフィスでの仕事であれば、自分のデスクを離れて、その人のところまで歩いていかなければならない
  • このようにハードルが高いからこそ、人は一旦立ち止まって、コミュニケーションを考えることができる
• リモートワークの文脈でダイレクトメッセージの誘惑の沼を避けるために、我々には明確に定義された相互作用モデルが必要

プラットフォームとサービスの目的の明確化

• チームAPIは、チームの目的とそのチームが他のチームとどのように相互作用するかについての情報を表面化するのに便利
• 組織内のプラットフォームとサービスでは、利用者がそれらとどのように相互作用できるかを理解できるように、明確に定義されたインターフェースを持つことが重要
• チームトポロジーでは、最も薄い実行可能プラットフォーム（TVP）の導入について説明している
  • 巨大なプラットフォームを構築することを目指しているわけではないので、薄いプラットフォームを構築するという考えかた
  • TVPは、外部サービスを使用する方法に関する重要な情報をキャプチャするwikiページのような単純なものであってもいい
  • TVPを担当する専門のプラットフォームチームの必要性が出てきたら、そのチームに対して「インターフェース」を公開する必要がある

TVPのインターフェイス

• 営業時間
• 提供するサービスの簡単な説明
• オンボーディングのためのドキュメント
• 典型的なレスポンスタイムの例
• 開発中の機能に関するロードマップ
• サポートチームへの優先的な連絡方法
• チャットツール、電子メール、電話などのコミュニケーションチャネルに関する詳細

本では、TVPのテンプレートも紹介されています。

まとめ

Remote Team Interactions Workbookの内容を紹介しました。この本はチームトポロジーをよりリモートワークの視点から解説した副読本と言えるのではないでしょうか？
本の中には、チームトポロジーの該当ページや参考になるリソースやリンクなども書かれているので、この記事を読んで興味が出た人はぜひ読んでみてください。
チームトポロジーと一緒に読むのがいいかもしれませんね。

参考文献

• Remote Team Interactions Workbook
• チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
• 30分で分かった気になるチームトポロジー