効果的なリモートワークを可能にする - チーム・トポロジーからの原則とパターン

効果的なリモートワーク・チームの相互作用のための構造

COVID-19の流行は、ソフトウェアを開発する企業が過去10年間すでに実験していた傾向、すなわちソフトウェアを開発する組織がリモート環境で効果的に活動できることを加速させた。リモートワーク下では、柔軟性が増し、ワークライフバランスが向上し、不必要な通勤を避けることができ、さまざまな場所から人を雇うことができるようになるなど、多くの利点がある。現在では、多くの組織が"ハイブリッド・セッティング"という働き方に向かっているようだが、リモートワークが今後も続くことは疑いない。

リモートワークとは、SlackやZoomを導入し、在宅勤務のあり方について新しい方針を打ち出すだけのものではないのだ。このアプローチは甘く、いくつかの驚きをもたらしてきた。リモートでは、人々が物理的に分離され、コミュニケーション能力が制限されるため、チームの交流方法、主に組織内の情報の流れ方について、いくつかの課題が生じる。リモート環境では、オフィスで仕事をしていたときのように、簡単に人と人が"ぶつかる"ことはない。リモート環境では、人々やチーム間の健全で管理しやすい相互作用を可能にする構造を育てることに、より慎重である必要がある。要するに、ツールやハイレベルな働き方だけではないのだ。リモートワークの課題をよりよく解決するためには、チームや組織の構造をより根本的に変える必要があることを認識しなければならない。

図1：リモートワークの戦略に関するいくつかの選択肢

図1.Aは、"リモートワーク戦略"をツールやポリシーに集中させるだけでは不十分であることを示す。もっと意図的な仕組みづくりをおろそかにしてしまったとしよう。その場合、チームの境界や業務範囲が不明確となり、"全員があらゆることに取り組んでいる"ことになる。つまり、組織の構造設計が不十分なために、余計な認知負荷（ワーキングメモリで使われる精神的努力の総量）やエネルギーを使って、不必要な負担を克服することになる。このような境界の不明確さは、リモートワーク下ではさらに深刻化する。

組織は、完全なリモートワークであれ、ハイブリッドであれ、新しいワーク環境をサポートするための基礎的な要素や構造を開発し、採用することに、より慎重であるべきだ。すなわち、図1.Bに示すように、チームの境界線と仕事の範囲をより明確にし、依存関係をより明確にすることである。これらは、より効果的なリモートワークの状況を実現するために必要不可欠な構造となっている。

この記事では、リモートワークにおける相互作用をより良くサポートするために、組織が構造の設計と進化に取り組む際に役立つ、チームトポロジーのアイデア、原則、およびプラクティスを紹介する（関連トピックも含む）。また、一般的な組織設計、特にリモートワークをサポートする場合の影響を示す例も紹介する。

より効果的なリモートワークのためのチームトポロジーの原則とパターン

多くの組織のリモートワーク戦略は、"働き方"、"ツール"や"マネジメントスタイル"に焦点を当てた、戦術的なものになりがちである。しかし、組織の社会技術システムの基礎構造を積極的に設計し、進化させていくことも必要である。以下のセクションでは、チーム・トポロジーの3つの核となる原則とパターンに焦点を当てる。これらは、より効果的なリモートワークの条件を可能にするために不可欠なもので、チームの依存関係、境界線、相互作用である。リモート環境でのチーム・トポロジーの適用に関する詳細は、"Team Topologies Remote Interactions Workbook（RTIW）"で確認できる。また、このワークブックでは、これらのアイデアを組織内でどのように適用するかについての実践的な実践例も紹介している。

チームの依存関係

効果的なリモートワークを実現するためには、チームの依存関係を理解し、行動することがもっとも重要な要素の1つである。チーム・トポロジーの基本原則の1つで、依存関係を理解し、進化させることで、チームが変化の速い流れ（アイデアから顧客の前で価値を発揮する能力）を達成できるようにすることに焦点をあてている。

依存関係を理解し、最小化することは、リモートワークの基本である

依存関係は避けられないものであり、チームが、組織が顧客のために価値を創造するための、より広範なシステムの一部であることを反映している。しかし、一般的には、すべてのチームが協力し合い、互いに依存し合うことは望まない。それは困難であり、全員のペースを落とす傾向がある（膨大な調整課題）。目標を達成するために必要な依存関係だけを持つようにしたい。これらの考え方は、物理的なオフィス環境における組織やソフトウェアアーキテクチャ設計のための良い一般原則を形成している。しかし、リモート環境では、チーム間の依存関係やコミュニケーションがより複雑で高価になるため、その重要性はより顕著になる。したがって、組織は、チームの依存関係を最小化することを促進する運営モデルを採用しなければならない。

図2：チームの依存関係を可視化し理解する

図2のように、チームの依存関係を可視化することで、その依存関係を観察し、どのようにアプローチすればよいかを理解できる。それによって、その依存関係を取り除くために必要な会話や開発のきっかけを作ることができるはずだ。すべての依存関係を取り除くことはできない。しかし、依存関係を"ノンブロッキングな依存関係"に変える方法を模索できる。これによって、2つのチームは、変更のたびに毎回調整しなくてもよくなるため、互いに独立して進めることができる。

次のセクションでは、依存関係を追跡、理解、最小化するのに役立ついくつかのパターンとプラクティスについて説明する。

依存関係を戦略的に追跡し、進化させる

チームの依存関係を可視化し、追跡を開始する簡単な方法は、依存関係マトリックス追跡ツールを使用することである。

図3：クレジット

Spotifyは2010年代前半にこれを使った。この方法は、組織やチームがチーム間の依存関係を追跡し、理解し、必要なアクションを引き起こす方法を始めるのに、今でも有効な方法である。このアーティファクトをTeam APIの一部とすることができる。Team APIを使えば、チームの目的や作業範囲を記述することができる。さらに、チームの依存関係やその他の要素を可視化することができる。Team Topologiesの用語では、依存関係は単なるソフトウェア統合（例えば、生産者と消費者のAPI関係）以上のものである。また、「コラボレーション」（与えられたものや境界を発見し形成する）、「ファシリテーション」（あるチームが別のチームが特定のトピックやスキルを学ぶのを助ける）といった一時的な相互作用も定義することができる。この組み合わせは、チームが依存関係を追跡し、必要な会話をサポートする優れた方法を提供することができる。このような会話のきっかけは、リモート環境では非常に重要である。なぜなら、前述のように、オフィスでは以前のように簡単に「お互いにぶつかる」ことができないからである。

また、近年では、依存関係の追跡や把握のために、より自動化された方法を採用する企業も見られる。例えば、Spotifyやbol.comでは、Backstage（ソフトウェアカタログと開発者向けプラットフォーム）を使って、チームがすべてのシステムを記述し、視覚化できる。Backstageでは、チームがどのようなシステムを所有しているかを観察し、チーム間の依存関係も調べることが可能だ。これらの洞察は、"広義のシステムを設計する組織は、その組織のコミュニケーション構造のコピーである設計を生み出す"という、コンウェイの法則を受け入れるための素晴らしいツールになる。一言で言えば、組織と技術のシステムアーキテクチャのミラーリングを意識することは、システム（組織と技術）の進化に不可欠であると認識することだ。それはリモートワークにおいてはさらに重要である。

チームの境界線

効果的なチームの境界線は、チーム・トポロジーのもう一つの基本原則であり、チームファーストの考え方において重要な役割を果たす。優れたチーム境界は、チームが明確な所有意識を持ち、認知的負荷を軽減し、自律性、熟練度、目的を向上させるのに有効だ。チーム間の境界を誤ると、認知的負荷が増大し、コンテキスト・スイッチングが起こり、リモート環境では、チームの士気と組織の変化の速い流れを達成する能力に壊滅的な打撃を与える可能性があるのだ。

図4

効果的なリモートワークには、適切なチームの境界線が不可欠である

多くの組織は、エンジニアリング、オペレーション、テスト、マーケティング、セールスなど、機能的なサイロを中心に組織化されている。このような組織では、"全員があらゆることに取り組む"というシナリオになりがちで、プロジェクトを利用した仕事の調整が必要になることがある。このようなプロジェクトベースのアプローチでは、プロジェクトが終了した後、次のプロジェクトのために、これまで築いてきたものを捨て、また新たに学び直さなければならず、結果としてコアとなるドメイン知識が失われることになる。また、コンテキスト・スイッチも発生し、認知負荷が増大してストレスや不安、燃え尽き症候群につながる可能性もあるのだ。リモート環境では、このような機能的な組織は、#ask-salesや#ask-engineeringといった粗い粒度のコミュニケーションチャネルにもつながりかねない。このような設定では、従業員は、エンジニアリング部門の誰かが応答してくれるかもしれないという期待からメッセージを"ブロードキャスト"することによって、問題について相談する"適切な"人々を見つけようとするため、フラストレーションが溜まることになりかねない。このように共有コミュニケーションチャンネルを使いすぎると、ノイズが多くなり、チャンネルを"ミュート"してしまうため、使い物にならなくなることがある。

Team Topologiesでは、組織設計にチームファーストのアプローチを採用することを提案している。このアプローチは、チームの認知負荷の範囲内でビジネス領域の明確なオーナーシップを持ち、さらにダンバー数を用いて適切な信頼の境界線に保たれた、小さくて長持ちする独立したチームを作ることを促進する。ダンバー数とは、人類学者ロビン・ダンバーが定義したもので、人々の間の信頼関係が所属する集団の大きさによってどのように変化するか、つまり、小さな集団は大きな集団よりも信頼度が高いということに関連している。グループの規模がダンバー数、例えば15、50、150に達した場合、信頼ダイナミクスは変化する。詳しく知りたいという方は、Dunbar’s number and Communities of Practice を参照されたい。

このようなチームファーストのアプローチに移行するためには、特にリモート環境では、チーム間の境界をどのように定義するかを再考することが不可欠である。これは、ユーザーニーズマッピング（UNM）や独立サービスヒューリスティック（ISH）などの技法を用いてシステムを別の角度から見ることで、潜在的な分断面（システムを分割する方法）を特定し、それを可能なチームの境界として検証することによって達成できる。これらの境界は、共通の目標、共通の目的、より高い信頼レベルを持つ、長寿の小規模なクロスファンクショナルチームを提供するために使用できる。UNM や ISHについてもっと知りたいと思ったら、これらの記事を参照されたい。

信頼境界の効果を実際に見た例として、特にスタートアップ企業では、チームが8人から15人に増えたときがある。このシナリオでは、チームサイズが15人に近づくにつれて、グループが8人と7人の2つの別々のチームのように振る舞うようになり、この時点で、その2つのグループ間の境界を再評価し、2つの別々のチームを形成することが理にかなっていると言える。別の例として、Oyster HRの記事で、オンラインツールを設計する際に、チームの境界線と信頼レベルを考慮しなかったために、明確な境界線がないことによる副作用を経験したことが紹介されている。100人程度の従業員で転換期を迎えるまでは、すべてが順調だった。"人々は、あらゆることについて互いに話すためにSlackに傾倒していた"。それは、全員の認知負荷とコンテクストスイッチングに大きな影響を及ぼした。詳しくは、Using Slack for remote teams: Where we got it wrongの記事で解説している。

チームの境界を良好にするためのオンラインコミュニケーションチャンネルを設計する

チームの境界線が明確でないことがもたらす悪影響を認識し、その原因を理解すれば、リモートワーク特有の落とし穴に対処するためのオンラインコミュニケーションツールの設計に着手することが可能になる。

オンラインコミュニケーションにおいて、純粋な"オープンスペース"モデルを避けるために、チャネルを設計する際に意図的に行うことが重要だ。その代わりに、グループの信頼関係の境界線に基づいたグループやコラボレーションスペースの作成をより明確にする必要がある。チーム専用のチャットルームやチャンネルを持つことは不可欠なのだ。また、チームが所属する大きなグループや部署内で、特定のタイプのコミュニケーションのための専用チャンネルを作成することも同様に重要であり、これにより、グループメンバーはより密接に関連したことに取り組んでいる可能性があるため、より密接な信頼境界を持つことができる。

実際の例として、チームトポロジーの社内チャットツールでは、特定のワークショップに関する議論に集中するために#tt-products-p89-blockers-to-flow、特定の顧客に対する仕事に関する議論に集中するために#tt-customer-xxxといった名前のチャンネルを使っている。このようなシンプルな命名規則により、特定のトピックについてコミュニケーションするのに最適な場所を簡単に発見できる。例えば、組織内のオンライン・コミュニケーション・チャンネルを再構築する可能性を模索しているとしよう。その場合、RTIW（Remote Team Interaction Workbook）では、オンラインスペース評価ツールを使って、人数ともっとも近いダンバー信頼境界に基づいて、組織内のオンラインスペースが信頼問題の影響を受けている可能性があるかどうかを評価することを提案する。これは、チャネルの焦点をより小さなユーザーセグメントに変更することを検討すべきかどうかを判断するのに役立ち、認知的負荷を軽減するためにチャネルの命名規則を導入することで実現できる。

リモート環境で使用する場合、上記のOyster HRの例で説明したような#ask-engineeringのような粗い粒度のチャンネルではなく、#platform-security-askや#stream-acquisition-askといった、はるかに焦点を絞ったコミュニケーションチャンネルを作ることができるようになる。RTIWの48ページには、120以上のチームを持つテレコミュニケーション企業の優れたチャンネル例が掲載されている。ここでは、#tribe-payments-card-managementのようなチャンネル名を使用している。これは、支払い部会の中のカード管理チームと解釈でき、組織内の人々が"tribe"を検索するだけで、部会関連のすべてのチャンネルが見つかるため、認知負荷を減らし、発見をより簡単にする。

目的に応じたインタラクション

チームがどのように交流するかは、Team Topologiesの基本的な側面である。チームのタイプや認知的負荷に注目するだけでは十分ではない。チームがどのように相互作用するかに注目することも重要である。チームの相互作用の定義が不十分だと、摩擦や非効率の大きな原因となり、特にリモート環境ではそれが顕著となる。

図5

目的に応じたインタラクションの必要性

組織が苦境に立たされているとき、よくこんな主張を耳にする。"もっとコラボレーションして、この問題を解決しよう"こうした行動は、真の課題（例えば、不健全な境界線や相互作用を持つチーム）への対処を避け、そうした不健全な構造を補おうとする会議や一般的なプロセスを増やすことで問題を悪化させる、誤った救済策になりがちである。結局のところ、コラボレーションを増やすことが答えになることはほとんどない。むしろ、ハンドオーバーの必要性やチーム間の依存関係を遮断する要因など、構造的な課題を理解し、対処することにもっと焦点を当てるべきである。チームがいつ、どのように交流するかを明確に理解することは、チーム間の交流の選択肢が少なくなるリモート環境では特に重要である。

前項のチーム間の依存関係で述べたように、チーム間の依存関係は"ノンブロッキング"であることを目指さなければならない。もし、他のチームが作業を完了するのを待たないと続行できないようなシナリオに直面したら、これは"ブロッキング"であると考え避けたい。このような厄介なインタラクションを認識した上で、チームは短期間のコラボレーションを意図的に行い、X-as-a-serviceインタラクションを構築し、消費するチームが今後のインタラクションでセルフサービスをできるようになる。

私たちは、フィットネス業界のある企業で、ブロック型インタラクションからX-as-a-serviceインタラクションへの進化の素晴らしい例を観察した。そのコンテキストでは、ストリームに沿ったチームが新しいテストメンバーアカウントを必要とするときはいつでも、電子メールでメンバーシッププラットフォームチームに新しいアカウントを作成するようリクエストすることが必要だった。このリクエストはメンバーシッププラットフォームチームのバックログに追加され、メンバーが時間のあるときにアカウントを作成することになる。このため、ストリームに沿ったチームは、テスト用アカウントがなければ機能開発を続けることができないため、ブロッキング依存が発生した。しかし、コラボレーションを重ねた結果、プラットフォームチームは、シンプルなチャットボットを作成し、ストリームアラインドチームがシンプルなチャットインターフェイスでテストアカウント作成をリクエストできることを突き止めた。

リモート環境でプラットフォームを活用する

チーム・トポロジーが導入した手法のうち、特にリモート環境で有効なものの1つに、Thinest Viable Platform（TVP）がある。このコンセプトは、ブロック化されたインタラクションをノンブロッキングに変更するもっともシンプルな方法を検討することをチームに促すものである。多くの場合、Wikiページに情報を追加し、組織の他のメンバーにも見えるようにするだけで、リモート環境にいる従業員の認知負荷を大幅に軽減できるのだ。TVPについては、Thinnest Viable Platform (TVP)とは？で詳しく解説している。

TVPを使った業界の実例は、Andy Norton氏（FOOTASYLUMのエンジニアリング責任者）が書いた記事で見ることができる。FOOTASYLUMは、TVPの概念を用いて、自分たちのプラットフォームに必要な実際のデータについて、チームで話し合うことを奨励した。シンプルな問いになるが、"このサービスは最小実行可能バージョンか？"そしてTVPの考え方（つまり、データの性質とサービスに求められる結果を問う）を念頭に置くことで、プラットフォームチームは、他のチームが利用するために構築しているサービスについての仮定を検証するのに必要な時間を短縮できた。このケースでは、最初の要件をサポートするために静的なデータを使用しただけであり、これは現在も有効である。もっと詳しく知りたい方は、FOOTASYLUMのTeam Topologiesのケーススタディを見て欲しい。

総括と次のステップ

組織はそれぞれ異なり、意図的に設計に取り組むには文脈を理解する必要がある。しかし、この記事では、より良いリモートワーク環境を設計する際に、いくつかの原則とパターンを紹介した。特に、リモートワークで成功するためには、”Slackとzoomを追加する”ことや、いくつかの管理的実践を超える必要があることを強調する。私たちは、組織が基礎的な構造、すなわちチームの依存関係、チームの境界、チームの相互作用を大切にしなければ、リモートワークで効果的に働くことは難しくなることを示した。また、非常に重要なことだが、これは1回限りの再設計ではない。これらの側面は、組織の運営モデルの一部となるべきである。つまり、リモートワークをサポートするための健全な状態を維持する能力を維持するために、基礎的な構造を進化させるべきなのだ。

この2年間の経験から、リモートワークを効果的に行うためには、これらの側面に留意することがいかに重要であるかがわかった。例えば、bol.comで働いていたとき、進化のための明確な境界線と構造を持つことで、チームがリモート環境へ効果的に移行できることを観察したことがある。しかし、私たちのコンサルティング活動では、主にリモート環境で働く場合、組織がチームの境界や組織構造をより明確しなければならないことがよくある。

チームの境界と依存関係をよりよく理解することから始めるのが重要だ。この記事では、境界を特定し、Team APIや依存関係トラッカーの成果物に集約するなど、そのアプローチ方法を紹介している。さらに、チーム内の依存関係をより正確に記述するために、Team Topologiesのインタラクションモードを採用し始めることもできる。そうすることで、既存の依存関係を記述するための優れた共有言語と、それをどのように変換するか、あるいは新しい依存関係を特定するかがわかるようになるはずだ。

リモートワーク環境を改善するためのその他のガイダンスについては、Team Topologies Remote Team Interactions Workbookを確認してほしい。