Close

チーム トポロジ

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

Ian Buchanan

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

寄稿、編集: Shana Vu

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

チーム トポロジの概要


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

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

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

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

ソリューションを見る

チーム全体の DevOps ツール

関連資料

DevOps 文化の構築

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

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

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

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

1. ストリーム基準のチーム


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

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

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

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

2. プラットフォーム チーム


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

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

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

3. 複雑サブシステム チーム


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

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

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

4. イネーブリング チーム


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

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

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

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

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


結論


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

DevOps のジャーニーを開始したばかりでしたら、DevOps の初心者向けガイドでベスト プラクティスをご覧ください。DevOps を実践するには、Open DevOps をお試しいただくことをお勧めします。チームがソフトウェアの開発と運用に必要なものをすべて提供しています。大手ベンダーや Marketplace アプリとの統合によって、チームに必要な 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