DevOps チーム構造: タイプ、役割、責任

ソフトウェア チームが DevOps 実践への道を歩む際には、企業の幅広い状況と変化への欲求に応じて、チームごとに異なる構造が必要になることを理解することが重要です。

DevOps チームの台頭

あなたの会社に DevOps チームは存在しますか?「はい」と答える方が多いと思います。DevOps Trends の調査で、調査対象の 3 分の 2 を超える組織に、ある程度のキャパシティを持つ「DevOps」というタイトルのチームまたは個人が存在することがわかりました。

DevOps の普及が進むにつれて、ソフトウェア チームが DevOps チームになったとよく耳にします。ただし、新しいツールを追加したり、チームを DevOps として指名したりするだけでは、DevOps のメリットを十分に実現するには不十分です。

DevOps とその適切な実装方法を明確に理解していないと、DevOps 変革は再編成や最新のツールに限定されがちです。DevOps を適切に導入するためには、チームが新しい構造と新しい管理原則を持って、特定のテクノロジー ツールを採用するという文化的変化を伴います。

DevOps チーム構造のタイプ

実装する DevOps チーム構造の決定は、組織が取り組む製品の数、技術的なリーダーシップ、開発チームと運用チームのプロセス連携の能力の有無など、さまざまな要素によって決まります。

すべてのチームが同じ目標を共有したり、同じプラクティスやツールを使用したりするわけではないことを理解することが重要です。チーム構成の方法すら標準化すべきではありません。企業の幅広い状況と変化への欲求に応じて、チームごとに異なる構造が必要になります。2 つの企業の DevOps チームは、根本的に異なるものを指すことも考えられます。

市場投入までの時間の短縮、デプロイ頻度の改善、チーム文化の向上、チーム/部門全体のコラボレーションの向上など、DevOps のメリットを享受するには、各チームが果たす役割を理解することが重要です。それでも、多くの組織ではさまざまなチーム タイトルがあり、各チームが複数の役割を担っています (たとえば、インフラストラクチャ チームがツールの選択と保守の両方を担当するなど)。この無秩序な増加によって、リーダーは組織全体の状況を可視化して重要な質問に答えることが困難になりつつあります。その質問とは、適切なチームが配置されているか、担当チームのいない分野に対する能力の欠落があるか チームの自律性と他のチームからのサポートの間で必要なバランスが取れているか、といったものです。

『Team Topologies』という優れた書籍があり、さまざまな DevOps チーム アプローチに対するアトラシアンの考え方の出発点となっています。以下のチーム構造は、企業の規模と成熟度に応じて異なる形態を取ることにご注意ください。実際には、複数の構造を組み合わせたり構造を別の構造に転換させたりすることが、多くの場合に最良のアプローチとなります。

開発と運用のコラボレーション

多くの人は、DevOps のことを単に開発と運用の団結とコラボレーションであると考えています。これは DevOps の基盤であり、ソフトウェア チームがより迅速かつ確実に構築、テスト、リリースできるようになるなど、明確なメリットが提供されます。

このチーム構造を成功に導く鍵となるのは、運用チームに対して課せられる稼働時間の維持と解決時間の最小化というプレッシャーを、開発者が理解することです。同様に重要なのは、デプロイ時間と市場投入までの時間を短縮したいという開発チームの要望を運用チームが理解することです。

開発と運用の統合

このチーム構造は、開発と運用が一緒になって単一チームで活動し、共通の目標を持つ共同戦線として機能することを前提としています。これは「NoOps」と呼ばれることもあり、Facebook や Netflix などの単一の主要デジタル製品を扱うテクノロジー企業でよく見られます。アプリケーションの開発者と運用者が同じである、いわゆる「構築した者が運用する」形態さえも採用できます。

DevOps/SRE

Google によって普及したこのチーム構造では、開発チームはソフトウェアを実際に実行するサイト信頼性エンジニアリング (SRE) チームに製品を引き渡します。このモデルでは、開発チームはログやその他の成果物を SRE チームに提供して、ソフトウェアが SRE チームのサポートを受けるのに十分な基準を満たしていることを証明します。開発チームと SRE チームは運用基準に基づいてコラボレーションして、SRE チームには本番前にコードを改善するように開発者に依頼する権限が与えられています。

プラットフォームとしての運用

このチーム構造では、開発チーム内のチームの 1 つがすべての運用面の専門知識ソースとして機能して、サービスとしてのインフラストラクチャ (IaaS) チームとの連絡役のほとんどを果たします。IaaS チームは開発チームが使用するスケーラブルな仮想サービスを作成するため、このチーム構造はパブリック クラウドで実行されるアプリケーションに依存します。

外部パーティとしての DevOps

外部パーティとしての DevOps は、企業が DevOps コンサルタントまたは DevOps チームを期間限定で利用して、開発チームと運用チームが上記の最初の 2 つのチーム構造 (開発と運用のコラボレーションと開発と運用の統合) に移行することをサポートする場です。

DevOps を実践する方法は複数ありますが、実践になっていない現状も多々見られます。チームと DevOps リーダーは、サイロ、コミュニケーションの欠如、コミュニケーションよりもツールを優先するという誤った優先順位を特徴とするアンチパターンに注意する必要があります。

DevOps チームの役割と責任

チーム構造にかかわらず、DevOps を実践しているすべての高機能チームは、開発と運用の間で知識と経験を定期的に共有しています。これは、定例ミーティングを開いたり、メンバーにチームまたは部門をまたいで作業させたりすることによって実現します。高機能チームは、市場投入までの時間の短縮、リード タイムの改善、デプロイ頻度の改善、成果物の品質向上、チーム文化の向上、チーム/部門全体におけるコラボレーションの向上といった、DevOps のメリットを受けています。

通常、DevOps チームは、開発と運用の両方のスキルを持つ人で構成されています。チーム メンバーの中には、コードの記述が得意な人もいれば、インフラストラクチャの運用と管理に熟練している人もいます。しかし、大企業では、CI/CD から IaaS、自動化にいたるまで、DevOps のあらゆる側面に役割が割り当てられている場合があります。これには、開発から本番環境までアプリケーションを調整して管理するリリース マネージャーから、チームの CI/CD パイプラインを保守して自動化する自動化アーキテクトまでが含まれます。

では、DevOps チームに参加するには何が必要でしょうか? DevOps チームに参加するためのジョブ要件は新しいテクノロジーと手法の出現によって変化しますが、優れた DevOps チームの質は常に同じです。優秀な DevOps 実践者のコアとなる特長としては、確かな技術スキル、優れたコミュニケーション、チーム プレイヤーとしての考え方、適応性などが挙げられます。おそらく、これらの組み合わせは、Kubernetes や Git の豊富な知識よりも重要です。ただし、両方あるに越したことはありません。

成功に欠かせないもう 1 つの要素は、DevOps をチーム、共同チーム、そして組織全体に伝道しようとするリーダーです。それは必ずしも「マネージャー」という肩書を持つ人に限りません。懐疑的なチーム メンバーに所属するチームと外部チームの間のギャップを埋めるように説得できる人なら、開発者、運用担当者、プラットフォーム チームの誰であっても構いません。

チームをサポートするソフトウェア

DevOps ツールチェーンはチームが毎日行う実際の作業によって決まりますが、チームと組織の残り部分を結び付けて作業を調整するには、何らかのソフトウェアが必要です。Jira は、ソフトウェア開発プロジェクトの計画、追跡、管理に対応して、直属のチームメイトや広範囲にわたる組織が作業のステータスに関する最新情報を把握できるようにすることを目的とした、強力なツールです。

特にリモートファーストの世界では、チームが迅速かつ効率的にコミュニケーションを取れるように、Zoom、Slack、Microsoft Teams などのアプリケーションも必要です。以前は、開発者が運用チームのところまで歩いていってインシデントのステータスを尋ねられました。今は、同様のコミュニケーションを仮想通信アプリによって瞬時に行えます。

アトラシアンの Open DevOps では、チームにとってソフトウェアの開発と運用に必要となるものがすべて提供されます。チームは、大手ベンダーや Marketplace アプリとの統合によって、DevOps ツールチェーンを自由に構築できます。アトラシアンは、チームとはベンダーが希望する働き方をするのではなく、チーム自体が希望する働き方を行うべきだと考えています。今すぐ試してみましょう。