理想的なDevOpsチーム構造を作成する

堅実な[DevOpsプラットフォーム](topics/devops- platform/)が最大限の効率を実現するには、堅実なDevOpsチーム構造が必要です。

堅牢なDevOpsチーム構造を構築することは、単に技術的なスキルを持つ個人を集めることではなく、製品ライフサイクル全体にわたってコラボレーション、継続的な改善、効率を重視するDevOps文化を育むことでもあります。

組織がソフトウェア開発プロセスを合理化しようとしている場合、DevOpsエンジニア、開発チームの役割、自動化ツールが生産性を向上させる方法を理解することが不可欠です。全体像を把握することで、信頼性のあるソフトウェアデリバリーと生産的な作業環境という包括的な目標に沿ったDevOps構造を形成するのに役立ちます。

チーム構成に関しては、いくつかの要因が影響します。

• 既存のサイロ：独立して作業を行う製品セットやチームはありますか？
• 技術的なリーダーシップ：グループマネージャーはDevOpsの目標を達成するように設定されていますか？
• 役割の変更：Opsのタスクは開発の役割に溶け込んでおり、セキュリティチームはすべての関係者と協力し、テクノロジーは変化し続けています。すべての要素を定期的に再評価するようにしましょう。
• 継続的な改善：DevOpsチームが最適な状態として「完了」することは決してありません。イテレーションが必要になります。

DevとOpsを別々のチームに分割すると、多くの場合デプロイプロセスに課題が発生します。それでも、一般的なツールが統合されたDevOpsカルチャーを採用することでこうしたギャップを埋めることができます。

経営コンサルタントのMatthew Skelton氏はさまざまなDevOpsのシナリオに関する詳細な文章を発表していますが、ここでは、特にサイロについて、そしてそれが組織にどのような影響を与えるかについてご紹介します。

Skelton氏はこれをお役所仕事的チーム構造と呼んでおり、その名からも分かる通りこれは効果的なDevOps戦略ではありません。どちらのチームもそれぞれのバブルの中で働いており、他のチームのワークフローを把握できていません。完全に分離されている状態で、効果的なDevOpsの重要な要素であるコラボレーション、可視性、理解の要素が欠けています。そこで発生しがちなのは、「あちらのチームが何をしているのかこちらは知らない、私たちのチームは役割を果たしている」などといった責任転嫁です。

このチーム構造でも開発チームとオペレーションチームは分離されていますが、ある種の仲介人的役割として「DevOps」チームが存在します。これは必ずしも悪いことではなく、Skelton氏はこの形式にも特定の役割があると強調しています。たとえば、これが将来的に開発とオペレーションをより凝集させることを目標とした一時的なソリューションであれば、一時的戦略として有効であるかもしれません。

このシナリオでは開発とDevOpsは融合している一方、オペレーションはサイロ化されたままです。このような組織はオペレーションをソフトウェア開発のイニシアチブを支援するものと見なしており、それ自体の価値を認めていません。このような組織は基本的なオペレーションミスが多く発生しがちです。オペレーションがもたらす価値を理解することで、はるかに成功率を向上させられる可能性があります。

DevOpsチームのサイロ化を解消するには、あらゆるレベルにおいてリーダーシップが必要となります。まず各グループに摩擦が発生している主なエリアを明らかにしてもらい、各グループのリーダー（開発、オペレーション、セキュリティ、テスト）を特定します。各リーダーは、すべての摩擦点について個別および協力して取り組む必要があります。

コミュニケーションの重要性は強調してもしすぎることはありません。チームは各役割のあらゆる側面に関するフィードバックを定期的に聞く必要があります。

うまくいっていないグループには、コミュニケーションとコラボレーションを促進する行動や言葉をモデルとして見せる「チャンピオン」を投入することで状況を改善できる可能性があります。

マルチクラウドからマイクロサービスやコンテナへと移行する技術の進歩は、適切なDevOpsチーム構造を定義する際にも役立ちます。2020年グローバルDevSecOps調査](/developer-survey/)では、回答者の83%がチームがより迅速にコードをリリースしていると回答しています。

現代のデベロッパーは、従来はオペレーションのプロが担当していた役割であるインフラストラクチャの作成、モニタリング、メンテナンスを担っています。オペレーションチームはクラウドサービスの管理に多くの時間を費やしていますが、セキュリティチームのメンバーはこれまで以上に開発チームとオペレーションチームの機能横断型チームと協力しています。

今日のソフトウェア開発ライフサイクルは明らかに変動部分が多くなっているため、DevOpsチームの適切な構造を定義は流動的であり、定期的な再評価が必要となります。

GitLabでは、イテレーションがコアバリューの1つであり、それは当社のDevOpsチーム体制でも実践されています。GitLabは単一のアプリケーションとして提供される完全なDevOpsプラットフォームであるため、開発チームは異なるステージ（例Verifyなど）で編成されています。これは、こうしたものが他企業では別々の製品として扱われ、独自の自律性が必要になるためです。製品の他の側面を管理する「Dev」以外にも、機能的なDevOpsグループがあります。

GitLab.comの稼働時間と信頼性を管理する信頼性グループ、品質部門、ディストリビューションチームが存在します。こうしたすべての要素の組み合わせは、SDLC全体にわたって透明性と可視性が実現するための取り組みの一環です。同時にすべてがうまく機能するよう、この構造を定期的に調整（イテレーション）しています。

まとめ：DevOpsチームを構築したらその内容を再考し、その後も定期的に再考を続けましょう。そうすることでコードリリースはより迅速になり、チームメンバーの幸福度向上も見込めます。

DevOpsチーム構造を最適化するプロセスは反復的であり、DevOpsプロセスとツールの継続的な進歩を反映するものです。各要素は、チームの成功に重要な役割を果たします。従来のサイロ化を解消し、DevOpsチーム内の役割を統合することで、組織はより一貫性のある効率的な環境を育むことができます。

持続的な改善の鍵は、ソフトウェアの生産とデプロイの急速に進化する需要に合わせてDevOps構造を定期的に再評価し、改良することにあります。そうすることでソフトウェア開発プロセスのスピードを上げるだけでなく、よりレジリエンスに優れたレスポンスの高い組織を構築できます。