Close

チーム トポロジ

4 つの基本トポロジは DevOps 変革にどのように影響するか。

Ian Buchanan

プリンシパル ソリューション エンジニア

寄稿、編集: Shana Vu

ストリーム基準のチームのメリットを取り上げて、このチームがプラットフォーム チーム、サブシステム チーム、イネーブリング チームと連携してどのように顧客に価値をもたらすかを詳述します。

チーム トポロジの概要


エンジニアリング チームは、顧客に価値を提供するために、かつてない速さで変化に対応することが求められています。クラウド、SaaS、常時稼働サービスの台頭によって、顧客は新機能、バグの減少、99.99% (またはそれ以上) のアップタイムを期待しています。

これらの要求に対応するために、組織はアジャイル プラクティスを採用して、さらに最近では DevOps プラクティスを採用しています。これによって、市場投入までの時間/リード タイムの短縮、デプロイ頻度の改善、チーム文化の向上、チーム/部門間のコラボレーションの向上が約束されます。

DevOps プラクティスの採用は言うほど簡単ではありませんが、『Team Topologies』という書籍では、最も効果的なチームの種類など、組織が DevOps を自社に組み込むためのインサイトに富んだ方法が紹介されています。この書籍は、チームに関するアトラシアンの考え方の出発点となっています。ここでは、書籍から得た知見を改めて紹介するのではなく、チーム タイプに関する当社独自の見解を共有します。

DevOps 変革の第一歩は、現場の組織構造を識別することです。しかし、最近はどの企業も多くの異なるチーム タイプを有しており、場合によっては単一のチームが複数の役割と責任を担うこともあります。この無秩序な増加によって、リーダーは組織全体の状況を可視化して、次のような質問に答えることが困難になりつつあります。

ソリューションを見る

チーム全体の DevOps ツール

関連資料

DevOps 文化の構築

  • 適切なチームが配置されているか
  • 担当チームのいない分野に対する能力の欠落があるか
  • チームの自律性と他のチームからのサポートの間で、必要なバランスが取れているか

開発および運用のリーダーは、チーム トポロジのレンズを通して組織を見ることで、適切なチームが配置されているかどうかを的確に把握できます。チームのバリエーションの数を 4 つの基本チーム トポロジにまで減らして、経営幹部と実際のチーム メンバーの両方が容易に理解できるようにすることをお勧めします。

  • ストリーム基準のチーム
  • プラットフォーム チーム
  • 複雑サブシステム チーム
  • イネーブリング チーム

これらのチーム タイプは、企業の規模と成熟度に応じて異なる形態を取ることにご注意ください。実際には、複数のタイプのチームを組み合わせたりチームを別のタイプに転換させたりすることが、多くの場合で最良のアプローチとなります。

ストリーム基準のチーム


ストリーム基準のチームは、影響力のある 1 つの作業ストリームに集中します。これは、単一の製品またはサービス、単一の機能セット、単一のユーザー ジャーニー、または単一のユーザー ペルソナです。チームは、作業の一部を実行するために他のチームにハンドオフすることなく、顧客またはユーザーの価値を可能な限り迅速かつ安全に単独で構築して提供できます。

ストリーム基準のチームはデリバリーの全範囲に取り組むため、必然的に顧客に近づき、通常はすでにアジャイルの形態を取っています。このチームは、本番環境でソフトウェアを保守しながら、開発サイクルに顧客からのフィードバックを取り入れます。

多くのソフトウェア企業ではストリーム基準のチームが一般的ですが、その他の組織ではデリバリー ストリームではなく、部門別に編成されたチーム構造 (つまり、エンジニアリング、設計、QA ごとに個別のチームを持つ) がよく見られます。

ストリーム基準のチームは組織で最も一般的なチーム タイプであるため、他のチームの役割はストリーム基準のチームに対する比較で定義されます。ストリーム基準のチームは、サポート チーム (複雑サブシステム、イネーブリング、プラットフォームの各チーム) に定期的に連絡して、製品とサービスのデリバリー速度と品質を継続的に改善する必要があります。

プラットフォーム チーム


プラットフォーム チームは、ストリーム基準のチームが実質的な自律性を持って作業を遂行できるようにする役割を担います。ストリーム基準のチームは本番環境でアプリケーションを構築、実行、修正するための完全な所有権を保持しますが、ストリーム基準のチームが使用できる内部サービスはプラットフォーム チームから提供されます。

プラットフォーム チームは、オーバーヘッドをほとんど伴わずに、多数のストリーム基準のチームが使用する機能を作成します。プラットフォーム チームは製品を最適化することで、ストリーム基準のチームのリソースと認知的負荷を最小限に抑えます。プラットフォーム チームはさまざまなユーザー エクスペリエンスまたは製品全体で一貫したエクスペリエンスを作成できるため、エンド ユーザーにとっても恩恵があります。

アトラシアンでは、プラットフォーム チームが当社のすべての製品 (ID 管理など) で使用されるサービスを構築して、ストリーム基準のチーム向けにドキュメント、サポート、コンサルティングを提供することが求められています。

複雑サブシステム チーム


複雑サブシステム チームは、特定のスキルと知識に依存するシステムの一部を構築して保守する責任を担います。ほとんどのチーム メンバーは、サブシステムを理解して変更を加えるうえで、特定の知識分野の専門家でなければなりません。

このチームの目標は、サブシステムを含む、またはサブシステムを使用するシステムで作業するストリーム基準のチームの負荷を軽減することです。複雑サブシステム チームの専門知識と能力を借りることで、ストリーム基準のチームは日常業務としては複雑すぎる分野で相応の能力を構築する必要がなくなります。このチームのチーム メンバーは、特定のマイクロサービス (つまり請求サービス)、アルゴリズム、さらには人工知能に関する専門知識を持っている場合があります。

よくある落とし穴は、サブシステムを使用するすべてのストリーム基準のチームに専門家を組み入れることです。これは効率的であるようで結局は費用対効果が低く、ストリーム基準のチームにとっては対応範囲外になります。

イネーブリング チーム


ストリーム基準のチームは常にプレッシャーの中で、迅速にデリバリーを遂行したり変化に対応したりしなければならず、新しいスキルを研究、学習、実践する時間を確保するのが困難になっています。

特定の技術 (または製品) 分野の専門家で構成されるイネーブリング チームが、この能力ギャップを埋めるのに貢献します。これらのチームは、ツール スタックに影響を与えるツール、フレームワーク、エコシステムの選択について、情報に基づいた提案を行えるように、研究と実験に重点を置いています。

これによって、ストリーム基準のチームは主要目標に向けた時間を減らすことなく、能力を獲得して進化させる余裕が生まれます。イネーブリング チームは、ソリューションではなく問題に焦点を当てて能力を成長させることによって、ストリーム基準のチームの自律性を高めることを目指しています。

イネーブリング チームがその役割をうまく果たせば、そのサポートを受けているチームは数週間程度で自律するはずです。イネーブリング チームは、永続的な依存関係を与えてはいけません。

ストリーム基準のチームと見なされる条件


ストリーム基準のチームであるかどうかは、次の質問から判断できます。

チームは安定した機能フローを作り出していますか?
成熟したチームは週に複数回、場合によっては 1 日に複数回リリースします。この目標を追求するには、成熟したチームは継続的インテグレーションと継続的なデリバリー (CI/CD) を使用して、機能を頻繁にリリースする必要があります。

最新の変更からのフィードバック (顧客または社内) に基づいて、チームはすぐに方向転換できるか?
製品を進化させるには、多くの場合は実験的なアプローチを使用するのが最善手です。成熟した DevOps プロセスでは、テストが自動化されて高品質なコードのリリースが保証されています。しかし、実験は単純なユニット テストや受け入れテストの域に収まりません。機能フラグを使用して一部のユーザーへのロールアウトを自動化したり、アルファ リリースとベータ リリースでユーザーのフィードバックや行動を依頼して測定したり、コメント、サポート チケット、コミュニティ フォーラムを通じて定性的かつ継続的なフィードバックを得たりすることによって、製品が顧客に最大の価値をもたらすように取り図らえます。

自分のチームから他のチームへの作業のハンドオフは最小限か?
この点には、2 つの観点から当てはまるはずです。チームが自己完結型であること、そして迅速なデリバリーを保証するために直属のチームメイトと協力して作業を行う必要があることです。作業範囲から外して、この最小限のハンドオフすら自動化できます。開発サイクルを自動化すれば、物事がシームレスに進行します。次のステップが自動テストやメインへのマージなどのアクションであるか、実際の人間であるかに関わらずです。

以下の条件を満たす場合はボーナス ポイント...
チームは時間を設けてコード品質の変化 (別名「技術的負債」) に対処して、変更が安全かつ簡便になるようにしているか?
成熟したチームは、コードベースを維持するためにトランクベース開発と CI/CD プラクティスを利用しています。キャパシティ プランニングでは、技術的負債への対処のみに費やす時間を設ける必要があります。さらに、基盤となるインフラストラクチャやプラットフォームの問題に対処する大規模なプロジェクトは、機能開発と同じくらい注目に値します。

チームは適切な指標で評価されていますか?
チームのリリース速度とは別に、成功の尺度としてチームヘルスと技術的な品質指標も考慮する必要があります。

測定に関する最後の質問に関して、DevOps チームでは従来、「成功」の定義において DevOps Research and Assessment (DORA) に関する次の 4 つの主要指標を考慮しています。

  • デプロイ頻度 - 組織が本番環境に正常にリリースする頻度
  • 変更のリード タイム - コミットが本番環境に到達するまでの所要時間
  • 変更エラー率 - 本番環境で障害を引き起こしたデプロイの割合
  • サービスの復旧時間 - 組織が本番環境の障害を復旧するまでの所要時間

アトラシアンの調査によると、パフォーマンスの高いストリーム基準のチームは、DORA で指定されたこれらの指標に加えて、次の属性も監視しています。

  • バランスの取れたチーム - チームに多様なスキルと視点があること
  • フルタイム オーナー - フルタイム オーナーが核となるチームと部門横断型の参加者が問い合わせ先を把握して、チームが所有するプロジェクトに関連する決定をどのように行うべきかを確認できること
  • 理解の共有 - 成功のための価値と指標の定義に加えて、要件に関する共通の理解があること
  • 価値と指標の重視 - プロジェクトをリリースに移すまでに、チームが取り組むべきタスクをガイドする指標があること
  • 概念実証 - 仮定をスパーリングしてテストするための実際のアーティファクトが存在して、チームが何度も反復して改善できること
  • 管理された依存関係に基づくベロシティの維持 - 管理された依存関係を理解してブロッカーの侵入を防ぎ、チームのベロシティを維持できること

結論


DevOps は最終目的地ではなく、ツール、チームの文化、プラクティスを常に改善し続けるジャーニーのことです。DevOps に初めて取り組む場合は、顧客に価値を提供するための目標の方向付けから始めます。成熟するにつれて、ツールとプロセスに自動化を追加します。最後に、チームが上級実践者になったら、可観測性を取り入れて、正しい物事を監視、測定、改善できるようにします。

Ian Buchanan
Ian Buchanan

Ian Buchanan はアトラシアンの DevOps のプリンシパル ソリューション エンジニアです。継続的なインテグレーションとデリバリーの向上を目的とした新しい DevOps コミュニティと、Jira、Bitbucket、Bamboo アプリケーションの適用に重点的に取り組んでいます。Java と .NET の両方について広範で豊富な経験を持つ Ian Buchanan は、大企業におけるリーンとアジャイルの各プラクティスの推進者として最もよく知られています。

キャリアにおいて、企業のソフトウェア開発ツールのライフサイクルを、最初から最後まですべての段階で適切に管理してきました。組織全体のプロセス改善を推進して、生産性、品質、顧客満足度を向上させました。自己主導性と自己組織化を尊重する多国籍アジャイル チームを構築しました。会話やコーディングをしていないときには、Ian はパーサー、メタ プログラミング、ドメイン特化言語にその情熱を傾けています。


この記事を共有する
次のトピック

おすすめコンテンツ

次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。

DevOps のイラスト

DevOps コミュニティ

DevOps のイラスト

DevOps ラーニング パス

マップのイラスト

無料で始める

DevOps ニュースレター購読

Thank you for signing up