BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Manuel Pais氏のCOVID-19の中のTeam Topologies

Manuel Pais氏のCOVID-19の中のTeam Topologies

原文(投稿日:2021/03/10)へのリンク

InfoQの編集者であり、「Team Topologies: Organizing Business and Technology Teams for Fast Flow」の共著者であるManuel Pais氏は、先頃、Capra Consulting主催のWebキャストで講演した。Capra consultingのCEOでチームリーダであるAslak Ege氏とØrjan Bøe Thygesen氏がPais氏に加わり、彼らのTeam Topologiesジャーニーについて話した。Capraは、トポロジを適用して、チームを階層構造からよりストリームに合わせて「根本的に再設計」していた。彼らは、COVID-19の期間中の旅について説明した。意図的に平らな構造に移行した結果、配置と従業員のNPSの改善が計測された。Team Topologiesが現在の風土でCapraのようなビジネスにどのように役立つかを理解するためにPais氏に話を聞いた。

Team Topologiesは、効果的なコラボレーション、自律性、デリバリへの焦点、およびプロダクトの調整のための組織を構築するのに役立つレンズを提供する。Pais氏は、チームの自律性というアジャイルの夢が、効果的なクロスファンクショナルチームに必要なさまざまな能力にどのような困難があるかについて話した。彼が提案したソリューションは、Team Topologiesを意図的に使用することで効果を発揮できる「チームファミリー」だった。

Thygesen氏は、Capraがバリューストリームのステージに合わせて自律的なチームに向けてどのように再構築したかを説明した。彼は、Capraの目標の1つが「会社をより堅牢に、変化に迅速に対応する」ために「自律性と柔軟性」を高めることであったことを共有した。Ege氏は、「他のチームで開始される前に何が変化する必要があるか」を学ぶために、「1つまたは2つのチームから開始した」方法について話した。彼はまた、チームがどのように自律的で、コミュニケーションが豊富で、組織全体のOKRと連携しているかについても説明した。

別の先頃のQEDx 2021での講演「テトリスのプレイと認知的負荷 (Cognitive Load) 」で、Pais氏は、特定のバリューストリームに合わせたプロダクトチームが、ミッションへの集中を維持するためにどのようなチームの「サポートシステム」が必要とされるかについて説明した。彼は、プロダクトのデリバリはテトリスのゲームのようなものであり、新しい機能を確実にデリバリするために、さまざまな能力がスムーズに組み合わされようとしていると説明した。Pais氏は、クロスファンクショナルチームがこれに対処するためによく見られる方法について話したが、これを「現代のソフトウェアチームが知っていると期待するのは、すべての全体像を考えると」まだ困難だ。彼は、自律性の価値と、必要なすべての能力を確保することに伴う困難との間の緊張関係について次のように述べている:

プロダクトを正しく構築するだけでなく、適切なプロダクトを構築するために必要なスキルの範囲ははるかに広くなっています。顧客が何を必要としているかを実際に見つけ、それによってより多くの価値を提供すること... それが組織にとって得られる収益であろうとその他の価値であろうと。

Pais氏は、多くのチームが必要な能力の完全なセットに達していないことを説明した。これはしばしば不完全な自律性をもたらし、チームは「近道をとるか、急いで物事を行う」ことを余儀なくされた。彼は、そのような状況がどのようにして長期的により多くの費用がかかり「顧客と組織のニーズにあまり適合しない」結果を生み出すのかについて説明した。Pais氏は「認知的負荷」を考慮してチームを設計することにより、フローをどのように改善できるかを説明した。Team Topologiesは、精神的努力、能力、およびチームに必要な知識について測定された認知的負荷の概念を使用する。

Pais氏は、この本で「ストリームに合わせた」プロダクトチームがサポートチームのファミリーにオフロードすることで認知的負荷を軽減できるようにする4つのトポロジについて説明した。彼は次のように記述している:

  • プロダクトチームの実現を目的とするバリューラインにサービスするプラットフォームチーム。
  • チームを必要な能力と機能をデリバリおよびコーチできるようにする。
  • 低認知的負荷の抽象化の背後に複雑なドメインの認知的負荷が隠れた複雑なサブシステムチーム。この本では「リアルタイムの貿易調整」や「顔認識」などの専門的な機能を提供するチームの例でそれが説明されている。

4 Fundamental Team Topologies

2020年に、InfoQはPais氏による「Remote-First Team Interactions for Business and Technology Teams (ビジネスおよびテクノロジーチームのためのリモートファーストチームインタラクション) 」というタイトルの講演の録音を公開した。この講演は、パンデミックの初期にAssurity ConsultingのBringing the Future Forward募金活動で行われ、Team Topologiesの実践がより顕著な機能障害を回避するために、リモートコンテキストでのチームコラボレーションにどのように適用できるかを説明した 。Pais氏は、チャットと「仮想空間」は「良好な相互作用のために設定できる」と指摘した。彼は、Slackやその他の仮想空間が大きいほど、チームが「話し合うべき相手」を見つけるのが「難しくなる」と説明した。Pais氏は、誰が協力しているかを説明する明確な命名規則を使用して、意図的に設計された仮想空間を使用することを提案した:

良好な種類の相互作用を促進するためのツールをどのようにセットアップするかを考える必要があります。実際には、それぞれの仮想空間に収容できる人数に制限を設けるのは良いことです。それぞれのSlackで、適切なチャネル (channel) が何かを考えることはできますか? ...仮想空間内で、理解しやすい規則があると、見つけられる可能性が高まり、認知的負荷が軽減されます。

私たちはTeam Topologiesと現在のそれらの重要性をよりよく理解するために、Pais氏に話を聞いた。

InfoQ: Team Topologiesは、企業が外部要因によって強制されたパンデミック関連の変化に適応するのにどのように役立ちますか?

Manuel Pais氏: Team Topologiesのアイデアは、さまざまなチームの目的 (基本的なトポロジ)、および必要な相互に対話する方法とタイミング (コア対話モード) について組織がじっくりと考えるのに役立ちます。Team APIのような手法は、チームの作業慣行、ロードマップ、優先するコミュニケーションパターンなどを周囲のチームに公開し、コミュニケーションのオーバヘッドと、チームが他のチームからチャットツールでほぼリアルタイムの回答を期待するなど、期待のずれを明示的に削減しようとします。

現在のパンデミックの状況では、しかし一般的にはリモートファーストのアプローチでは、ソーシャルネットワークやカジュアルな情報交換がオフィス環境で行われることはもはや可能ではないことから、チームの相互作用 (いつ、なぜ、どのくらいの期間) に明確な期待を抱くことが重要になります。そうしないと、サイロがより定着し、競合が激化する傾向があります。一部の組織は、チームの依存関係を管理するために厳密なプロセスを倍増する可能性がありますが、それはチームの自律性とパフォーマンスの低下という犠牲を伴います。

チームの依存関係を追跡して、可視性を高め、不健全な依存関係に対処し、理想的にはそれらを削除するか、少なくともフローへの影響を最小限に抑えることができ、すべきです。

このチームファーストのアプローチは、組織がリモートファーストのコンテキストでより高速なフロー (およびフィードバック) を達成する機会であるため、パンデミックはその意味で加速する可能性があります。パンデミック前のオフィス内の状況で過小評価していた可能性のあるチーム間での作業方法と相互作用の方法の重要性を明確にしましょう。

ところで、私たちは実際にこれらすべての側面をカバーするリモートチーム向けのTeam Topologiesワークブックを完成させています。当初はIT Revolutionから無料のPDFとして出版されます。

InfoQ: 4つのトポロジのうち、実装が最も難しい課題はどれでしょうか?

Pais氏: おそらく、上級の技術スタッフが他のチームの能力のギャップを埋めるのに役立つ教育とメンタリングの役割を引き受けることに慣れていないために、できるチーム (Enabling teams)です。専門家は、他の人が学ぶのを助けるのではなく、重要な仕事を実行するために使われます。しかし、仕事の実行を常に専門家に依存していると、特定の専門分野がデリバリライフサイクルのボトルネックになることがよくあることは誰もが理解しています。「The Phoenix Project (The DevOps 逆転だ!)」の本を読んだことがあるなら、今はきっとBrent氏のキャラクタについて考えているはずです、そうでしょう?

イネーブラとしての専門家は、マネージャにとっても管轄外の考えである傾向があります。さらに、これらのチームの成功は他のチームの能力の向上によって測定されるため (おそらく「Accelerate (LeanとDevOpsの科学)」本の主要なメトリックによって測定されます)、専門家による制御の欠如の感覚があり、マネージャはこれらのチームの正確なROIを計算できません。成功の推進力としてのチームのエコシステム、または必要に応じて「チームのチーム」の重要性を理解する必要があります。

とは言うものの、プラットフォームチームは、技術や新しいサービスを開発するための大きな計画を延期することに苦労することがよくあります。彼らは社内チームに価値を提供することに熱心ですが、早期にそれらサービスの明確な価値の提案を確立し、プラットフォームをプロダクトとして扱うことに焦点を当てる必要があります (私たちの顧客とユーザペルソナは正確には誰でしょうか? 彼らは何を必要としていますか? 何がプラットフォームの採用を止めているのでしょうか?)。社内チーム (プラットフォームの顧客) との十分なコラボレーションと検証が行われる前に、プラットフォームチームがX-as-a-Serviceの提供を急いでいることがよくあります。これにより、まだ全体的な採用の準備ができていない、これらのサービスを使用したヘルプとサポートのリクエストが殺到する可能性があります。プラットフォームチームは、火消しとサポートリクエストへの対応にすべての時間を費やす状況で動けなくなる可能性があります。

InfoQ: リモートとオンサイトチームの間で、Team Topologiesの適用にどのような違いがありますか?

Pais氏: オンサイトチームは、なぜ他のチームとのやり取りを明確にする必要があるのか疑問に思うことがあります。一部の組織では、チームの依存関係に対処するためにプロセスに過度に依存しており、より自律性の恩恵を受けるチームと結び付けていることがあります。別の組織では、すべてのチームが他のチームと協力して「物事を成し遂げる」ことができると期待されています。

リモートワークに不慣れなチームは、流動的なコミュニケーションの主な障害がツールではなく仕事とコミュニケーションの方法を明確にすることであることをすぐに理解します。最初はチーム内ですが、すぐにチーム間でも。これまでは別のチームの同僚のところまで歩いて行くことでできましたが、今では取り組まなければならない調整のオーバーヘッドを必要とするようになりました。

したがって、ある意味で、リモートチームは、前述のTeam APIやコアインタラクションパターンなどの手法を介して、他のチームとのインタラクションを改善する必要性についての理解を深めています。また、好みのコミュニケーションパターン (他のチームにはどのようにコンタクトしなればならないか? 何日の何時に? 回答はいつ期待できるか?) を設定していくらかの自律性 (と時間) を取り戻し、「ズーム疲労 (Zoom fatigue)」(どこで、オンサイトすべての対面ミーティングをビデオ通話に置き換えようとしているか) を回避することに役立ちます。これは、プラットフォームチームのような強力なサポートの役割を持つチームにとって特に重要になります。

InfoQ: 本をリリースしてから、Team Topologiesに関するあなた自身の考え方はどのように進化しましたか?

Pais氏: Team Topologiesを採用している企業から、本を書くときに必ずしも考慮していなかった新しい有用なパターンを学びました。たとえば、プラットフォームチームは、プラットフォームサービスが支援するドメイン (例えば、監視、テレメトリ、インフラストラクチャの自動化など)の事実上の専門家であるため、同様に実現の役割も果たします。プラットフォームのエンジニアは、これらの社内サービスを開発およびサポートできるだけでなく、他のチームがそのドメインに関するグッドプラクティスの理解を支援することもできます。

また、初期の技術的な「インフラストラクチャ」(広義の) サービスを超えて、よりビジネス固有のサービスに採用されたプラットフォームパターンも確認しました。たとえば、Uswitchでは、最初の「クラウドインフラストラクチャ」プラットフォームが成功した後、「消費者データ」プラットフォームと「アフィリエイトマーケティング」プラットフォームを作成しました。Uswitch業界の例は、私たちのWebサイトで入手できます。

InfoQ: ここからトポロジーはどこに向かっていくと思いますか?

Pais氏: さて、何人かの人々は、Team TopologiesをITを超えて適用できることを私たちは確認しました。たとえば、高い使いやすさと摩擦の少ないプラットフォームにキュレーションされたセルフサービス機能は、組織の多くの領域 (HRサービス、財務などが考えられる) に適用できる一般的なパターンであり、自己完結性を高め、社内の「顧客」(チームまたは個人と読む) の成果を加速します。初期の採用を見ることからはじめて、2021年に共有できる具体的な例がいくつかあることを望んでいます!

一方、Team Topologiesパターンを使用している企業の業界での例が私たちのWebサイトにすでにいくつか記載されています。今後も、耳を傾け学習しながらさらに追加していきます。たとえばFootasylumは、どのようにTeam TopologiesとWardleyマッピングを組み合わせたかについてのすばらしいストーリーがあります。

また、Team Topologiesとドメイン駆動設計の交差についてNick Tune氏のような人々によって行われているかなり新しい考え方があります。どちらのアプローチもシステムとビジネス開発を社会技術的な見方をしています。

InfoQ: 読者はどこでもっと学ぶことができるでしょうか?

Pais氏: オンラインには無料のTeam Topologiesリソースがあり、Team Topologiesとリモートファーストチームとの対話のための特定のリソースもあります。また、Team TopologiesのYouTubeチャネルで新しい会議や交流会の講演を公開したり、よくある質問への回答を含む短い動画を公開したりしています。

また、Team Topologiesのさまざまな側面に関する詳細なライブオンライントレーニングセッションも提供しています。Team Topologiesを初めて使用する人向けのオンデマンドビデオトレーニングもあります。

新しい業界の例や公開トレーニングが利用可能になったときに最新情報を入手するには、ニュースレターを購読するか、TwitterまたはLinkedInでTeam Topologiesをフォローしてください。

Ege氏は、パンデミックの中でTeam Topologiesの採用に成功したことの誇りについて語り、プレゼンテーションを終了した:

また、パンデミックの最中にこれを行ったという事実を本当に誇りに思っています。変化を一時停止したりキャンセルしたりしなかったのです。家に閉じ込められていたにもかかわらず、私たちはそれを続けました、そして今のところその結果はとても良いです。

この記事に星をつける

おすすめ度
スタイル

BT