DevOpsトポロジー

みなさんこんにちは。@ryuzeeです。

2021年12月1日に発売した『チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計』ですが、おかげさまで多くの方に読んでいただき感謝しています。

チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計

著者／訳者：マシュー・スケルトン、マニュエル・パイス、原田騎郎、永瀬美穂、吉羽龍太郎
出版社：日本能率協会マネジメントセンター
発売日：2021-12-01
単行本：280ページ
ISBN-13：9784820729631
ASIN：4820729632

今日はこの「チームトポロジー」の元となったDevOpsトポロジーについて紹介します。このアイデアは2013年に著者の1人であるマシュー・スケルトンが自身のブログに書いた記事をまとめたものです。

2013年頃といえばDevOpsが流行しはじめた時期だと思いますが、このような時期から組織構造やチーム間のコミュニケーションモデルをロジカルに定義しようとしていたのは驚きです。

チームトポロジーでは、このDevOpsトポロジーやその他の考え方を元にして、4つのチームタイプと3つのインタラクションモードという分かりやすいモデルを作りましたが、その根底にある考え方が理解できるのではないかと思います。

なお、日本語訳はエイヤですので、何かお気づきの点があれば、@ryuzeeまでお知らせください。

以下は、マシュー・スケルトン氏とマニュエル・パイス氏がdevopstopologies.comにて公開しているコンテンツを日本語訳したものです。原文のライセンスに従って、Creative Commons Attribution-ShareAlike 4.0 International Licenseにて公開します。

イントロダクション

組織におけるDevOpsの取り組みの主な目標は、顧客とビジネスに対する価値の提供を改善することです。コスト削減や自動化の推進が目標でもなければ、構成管理を起点としてすべてを進めることが目標なわけでもありません。これは、効果的なDevとOpsのコラボレーションを行うには、組織ごとに異なるチーム構造が必要になることを意味します。

サマリー

どのDevOpsチーム構造やトポロジーが組織に適しているかは、いくつかのことに依存します。

組織のプロダクト群: コンウェイの法則から予測できるとおり、プロダクトの数が少なければ自然にサイロが少なくなり、コラボレーションが容易になります
技術リーダーシップの度合い、強さ、有効性: 開発と運用が目標を共有しているかどうか
運用部門を「ハードウェアのラッキング」や「サーバーの設定」から、価値の流れに本当の意味で沿うようにし、ソフトウェアチームは運用関連の機能を重要視するように変える意欲や能力を組織が持っているかどうか
運用上の懸念事項を率先して解決する能力やスキルが組織にあるかどうか

もちろん、ここで説明しているテーマにはさまざまなバリエーションがあります。トポロジーとタイプは、どのパターンが適切かを評価するためのリファレンスガイドや発見的手法となることを意図したものです。実際には、複数のパターンを組み合わせたり、あるパターンが別のパターンに変化したりすることが、最適なアプローチになることが多いでしょう。

では、DevOpsを成功させるためには、どのようなチーム構成が適切なのでしょうか？すべての組織に適合する魔法のような形態やチームのトポロジーが存在しないのは明らかです。しかし、チーム構造を少数の異なるモデルに分類すれば役に立ちますし、特定の組織によくあてはまるものもあるでしょう。これらのチーム構造（もしくは「トポロジー」）の長所と短所を調べることで、コンウェイの法則を考慮しつつ、自分たちの組織でDevOpsを実践する上で最適なチーム構造を決定できます。

こういったDevOpsトポロジーは、以前から色々なところで書かれてきました。特に、CollabNetのローレンス・スウィーニー氏は、ベン・ケペス氏のブログのコメントで、私がここで分類したアンチタイプB DevOpsチームサイロ、タイプ3 IaaS（Platform）としてのOps、タイプ1 DevとOpsのコラボレーションについて詳細に説明していて、役に立ちます。 DevOpsGuysでは12種類のDevOpsアンチパターンのリストを紹介しており、ジェズ・ハンブル氏やジーン・キム氏、ダモン・エドワーズ氏を始めとして、多くの人が同じように述べています。ここではさらに、私が今まで明文化されてこなかった3つの「トポロジー」を追加しました（タイプ2 Opsの責任を完全に共有、タイプ4 外部サービスとしてのDevOps）。

DevOpsアンチタイプ

私たちが「アンチタイプ」（アンチパターン）と呼んでいる悪いやり方を見ておくと役に立ちます。

アンチタイプA DevとOpsのサイロ
アンチタイプB DevOpsチームサイロ
アンチタイプC DevがOpsを必要としない
アンチタイプD DevOps as Toolsチーム
アンチタイプE システム管理者のリブランド
アンチタイプF DevチームでOpsを包含
アンチタイプG DevとDBAのサイロ
アンチタイプH フェイクSRE

アンチタイプA: DevとOpsのサイロ

アンチタイプA

これは、壁越しに投げつけるという、古典的な開発と運用の分離です。開発側はストーリーポイントを早期に計上できるかもしれませんが、Doneは「機能が完成している」ことを意味するだけで本番環境では動作しません。また、開発者は運用関連の機能については十分にコンテキストを理解しておらず、運用担当者はソフトウェアが本番で稼働する前に問題を修正するために開発者と関わる時間や意欲がないため、ソフトウェアの運用性が損なわれます。

このトポロジーが良くないことは誰もが知っていると思いますが、実際にはさらに悪いトポロジーもあります。ただ、少なくとも、アンチタイプA DevとOpsのサイロが問題であることは間違いありません。

アンチタイプB: DevOpsチームサイロ

アンチタイプB

アンチタイプB DevOpsチームサイロは、マネージャーや幹部が「DevOpsなるものが少々必要だ」と判断し、「DevOpsチーム」（おそらく「DevOp」と呼ばれる人たちでいっぱい）を立ち上げることから生じるのが典型的です。 DevOpsチームのメンバーはすぐに別のサイロを形成し、「無知な開発者」と「時代遅れの運用担当者」は自分たちの領域やスキル、ツールセットを守ろうとして、これまで以上にお互いが離れることになります。

独立したDevOpsサイロが本当に意味を持つ唯一の状況は、開発者と運用担当者をより緊密に連携させるという明確な目的を持ち、その後にDevOpsチームを不要なものにするという明確な期限（たとえば12か月やとか18か月）がある場合です。これは、私がタイプ5 期限付きDevOpsチームと呼ぶものに該当します。

アンチタイプC: DevがOpsを必要としない

アンチタイプC

このトポロジーは、特に新しいプロジェクトやシステムへの取り組みを始めるときの、開発者や開発マネージャーの単純さと傲慢さが相まって生まれています。開発者は運用を過去のものと考えて（「今はクラウドを使ってるんだし」）、運用のスキルや活動の複雑性と重要性を過小評価します。そして、運用のスキルはなくても大丈夫とか、余った時間でカバーできると考えてしまうのです。

アンチタイプC DevがOpsを必要としないのDevOpsトポロジーは、ソフトウェアが複雑になって、運用の活動が「開発」（コーディング）の時間を圧迫し始めると、おそらくタイプ3 IaaS（Platform）としてのOpsまたはタイプ4 外部サービスとしてのDevOpsのトポロジーを必要とするようになります。運用をソフトウェア開発と同じくらい重要で価値のある規律として認識しているチームだけが、多くの苦痛と余計な（そして極めて基本的な）運用上のミスを避けることができるはずです。

アンチタイプD: DevOps as Toolsチーム

アンチタイプD

現在の開発チームのベロシティ（機能系のストーリーのデリバリー）を減らすことなく「DevOps化」するために、デプロイメントパイプライン、構成管理、環境管理などに必要なツールに取り組むDevOpsチームが作られます。その一方で、運用担当者は孤立したまま作業を続けて、開発チームはアプリケーションを「壁ごし」に投げ続けます。

この専門チームの成果は、ツールチェーンの改善という点では有益ですが、そのインパクトは限定的です。アプリケーション開発ライフサイクルにおいて、運用が早期から関与することもなければコラボレーションも欠如しているという根本的な問題は、そのまま変わっていません。

アンチタイプE: システム管理者のリブランド

アンチタイプE

このアンチタイプは、エンジニアリングの成熟度が低い組織で典型的です。このような組織では、業務改善とコスト削減を望んでいますが、ITがビジネスのコアドライバーであることを理解していません。 DevOpsによる業界の成功が明らかになったので、自分たちも「DevOpsをやりたい」と考えます。でも残念なことに、現在の構造や関係性のギャップをふりかえるかわりに、運用チームに「DevOpsエンジニア」を採用するという理解しがたい道を歩んでいます。

DevOpsは、従来システム管理者と呼ばれていた役割を単にリブランドしたものになってしまい、文化的、組織的な意味での本当の変革は起こりません。このアンチタイプは、たちの悪いリクルーターがこの流れに乗って、自動化やツールのスキルを持つ候補者を探すことで、ますます広まっています。残念ながら、DevOpsを組織で成功させることができるのは、人間的なコミュニケーションスキルなのです。

アンチタイプF: DevチームでOpsを包含

アンチタイプF

組織として運用チームを分離したくないと考えると、開発チームがインフラ、環境管理、監視などの責任を負うことになります。しかし、プロジェクトやプロダクト主導でこれを行うと、これらの項目はリソースの制約や再優先順位付けの対象となり、不十分なアプローチや中途半端なソリューションにつながります。

このアンチタイプが見られる組織では、効果的なIT運用の重要性やスキルに対する認識が不足しています。特に、運用は開発にとって厄介なものとして扱われて、運用の価値がないがしろにされます（他の優先事項を持つ開発チームのマネージャーが運用を管理しているためです）。

アンチタイプFとタイプ2の明確な違いについて示唆を与えてくれたスコット・プルー氏に感謝します。

アンチタイプG: DevとDBAのサイロ

アンチタイプG

これはアンチタイプA DevとOpsのサイロの一種で、複数のレガシーシステムが同じコアデータに依存している中〜大企業で多く見られます。これらのデータベースがビジネスにとって非常に重要なため、専門のDBAチーム（運用部門内であることが多い）が、メンテナンスやパフォーマンスチューニング、ディザスタリカバリに責任を負います。ここまでは理解できます。問題は、このチームがあらゆるデータベース変更のゲートキーパーになり、頻繁に小さな変更をデプロイ（DevOpsと継続的デリバリーの中心にある考え方）するときの障害になる場合です。

さらに、アンチタイプA DevとOpsのサイロにおけるOps（運用）と同じように、DBAチームはアプリケーション開発の初期に関与せず、データの問題（移行、パフォーマンスなど）はデリバリーサイクルの後半に見つかります。複数のアプリケーションのデータベースをサポートすることで過剰に負荷がかかり、常に消火活動を行い、デリバリーについて強いプレッシャーを受けることになります。

アンチタイプH: フェイクSRE

アンチタイプH

これはアンチタイプA DevとOpsのサイロの一形態で、その10年後の姿です。運用エンジニアはSREと名乗れるようになりましたが、他はほとんど変わっていません。開発者は相変わらず「機能的に完成している」だけのソフトウェアをSREに投げつけています。開発者は自分たちが作ったソフトウェアを実際に動かしている環境からは離れていて、ソフトウェアの運用性は犠牲になっています。また、SREは、問題が発生したときにそれを解決するために開発者と関わる時間はないままです。

DevOps チームトポロジー

アンチタイプとは反対に、DevOpsを機能させるいくつかのトポロジーを見てみましょう。

タイプ1 DevとOpsのコラボレーション
タイプ2 Opsの責任を完全に共有
タイプ3 IaaS（Platform）としてのOps
タイプ4 外部サービスとしてのDevOps
タイプ5 期限付きDevOpsチーム
タイプ6 DevOpsアドボケイトチーム
タイプ7 SREチーム（Googleモデル）
タイプ8 コンテナ駆動のコラボレーション
タイプ9 DevとDBAのコラボレーション

タイプ1: DevとOpsのコラボレーション

タイプ1

これはDevOpsの「約束の地」です。開発チームと運用チームがスムーズにコラボレーションし、それぞれが必要なところに特化し、必要なところを共有します。多くの独立した開発チームが存在し、それぞれが別々（もしくはほぼ別）のプロダクトスタックに取り組みます。

私の感覚では、このタイプ1のモデルを確立するにはかなりの組織改革が必要で、技術管理チームの上層部にはそれなりの能力が必要です。開発と運用は、明確に表現されていて、効果が明確な共通の目標（「信頼性の高い頻繁な変更を実現する」といったもの）を持つ必要があります。運用担当者は開発者とペアを組み、テスト駆動のコーディングやGitを使いこなさなければいけません。また、開発担当者は運用機能を真剣に考え、ログ出力の実装について運用担当者に意見を求めるといったことが必要です。これらはすべて、従来と異なる文化の変化が必要です。

タイプ1の適合性: 強力な技術リーダーシップを持つ組織
潜在的な効果: 高

タイプ2: Opsの責任を完全に共有

タイプ2

プロダクト開発チームに運用担当者が含まれている場合は、タイプ2のトポロジーとみなせます。開発と運用担当者の別け隔てはほとんどなく、全員が共通の目標にとても集中しています。これはタイプ1 DevとOpsのコラボレーションの一形態であることは間違いありませんが、いくつかの特別な特徴があります。

NetflixやFacebookなど、実質的に単一のWebベースのプロダクトを持つ組織は、このタイプ2のトポロジーを実現しています。しかし、一部のプロダクトを除いては当てはまらないのではないかと考えています。というのも、複数のプロダクトストリームを持つ組織には、通常予算の制約とコンテキストの切り替えがあり、それによって開発者と運用担当者がさらに離れることになる（たとえば、タイプ1 DevとOpsのコラボレーションに戻る）ためです。このトポロジーは、明示的なオペレーションチームは存在しないので、「NoOps」と呼ばれることもあります（NetflixのNoOpsは、タイプ3 IaaS（Platform）としてのOpsかもしれません）。

タイプ2の適合性: 単一のウェブベースのプロダクトまたはサービスを持つ組織
潜在的な効果: 高

タイプ3: IaaS（Platform）としてのOps

タイプ3

伝統的なIT運用部門があり、十分な速度で変化することができない場合や、すべてのアプリケーションをパブリッククラウド（Amazon EC2、Rackspace、Azureなど）で実行している組織の場合は、アプリケーションをデプロイして実行するための弾力性のあるインフラストラクチャーを提供するだけのチームとして運用チームを扱うことが有効です。

開発のあるチーム（おそらく仮想チーム）が、運用機能、メトリクス、監視、サーバープロビジョニングなどに関する専門知識の源として機能し、おそらくIaaSチームとのコミュニケーションのほとんどを行います。このチームは開発チームのままですが、テスト駆動開発、継続的インテグレーション、反復開発、コーチングなどの標準的なプラクティスに従います。

IaaSトポロジーでは、実装を簡単にするために潜在的な効果を犠牲にします（運用担当者との直接的なコラボレーションがなくなります）。しかし、これによってタイプ1 DevとOpsのコラボレーションよりも素早く価値を届けられるようになります。

タイプ3の適合性: 従来の運用部門を持ち複数の異なるプロダクトやサービスを持つ組織、またはアプリケーションが完全にパブリッククラウドで実行されている組織
潜在的な効果: 中

タイプ4: 外部サービスとしてのDevOps

タイプ4

特に小規模な組織では、自分たちが作ったソフトウェアの運用を行うだけの資金や経験がなかったり、スタッフがいなかったりする場合もあります。その場合、開発チームは、テスト環境の構築やインフラストラクチャーや監視の自動化をRackspaceのようなサービスプロバイダーに依頼したり、ソフトウェア開発サイクルで実装すべき運用機能のようなものに対してアドバイスを受けたりできます。

DevOps-as-a-Serviceと呼ばれるものは、小規模な組織やチームが自動化や監視、構成管理について学ぶのに便利で実践的な方法です。そして、自分たちが成長して、運用に注力するスタッフが増えたら、タイプ3 IaaS（Platform）としてのOpsやタイプ1 DevとOpsのコラボレーションモデルに向かっていきます。

タイプ4の適合性: 業務上の問題の経験が少ない小規模なチームや組織
潜在的な効果: 中

タイプ5: 期限付きDevOpsチーム

タイプ5

タイプ5 期限付きDevOpsチームは、実質的にはアンチタイプB DevOpsチームサイロのように見えますが、その意図と寿命はまったく違います。このチームは一時的であり、開発者と運用担当者の距離を縮め、理想的にはタイプ1 DevとOpsのコラボレーションもしくはタイプ2 Opsの責任を完全に共有のモデルに向けて、最後は自分自身を無くす使命を持っています。

この一時的なチームのメンバーは、開発が使っている言葉と運用が使っている言葉の「翻訳」を行い、運用チームにスタンドアップやカンバンなどの素晴らしいアイデアを持ち込み、開発チームにはロードバランサー、管理用NIC、SSLオフロードなどの詳細について考えてもらうようにします。多くの人がDevとOpsを一緒にすることの価値を理解し始めたら、一時チームはその目的を達成する本当のチャンスです。重要なのは、デプロイや本番環境の調査についての長期的な責任を一時チームに与えるべきではないということです。さもなければ、このチームはアンチタイプB DevOpsチームサイロになる可能性が高くなります。

タイプ5の適合性: タイプ1 DevとOpsのコラボレーションの先駆けになりますが、アンチタイプB DevOpsチームサイロの危険性には注意してください
潜在的な効果: 低〜中

タイプ6: DevOpsアドボケイトチーム

タイプ6

開発と運用のあいだに大きな隔たりがある（あるいは隔たりが大きくなりがちな）組織では、開発と運用が話し合いを続けるための「ファシリテーション」役となるDevOpsチームが効果的なこともあります。これは、タイプ5 期限付きDevOpsチームの一種ですが、DevOpsチームは、開発チームと運用チームのあいだのコラボレーションと協力を促進するという具体的な任務を果たすために存在し続けます。このチームのメンバーは、DevOpsプラクティスの認知を広めるのを助けるため、「DevOpsアドボケイト」と呼ばれることもあります。

タイプ6の適合性: 開発と運用が離れてしまう傾向のある組織。アンチタイプBの危険性に注意してください
潜在的な効果: 中～高

タイプ7: SREチーム（Googleモデル）

タイプ7

DevOpsでは、開発チームがオンコールローテーションに参加することを推奨することが多いですが、必須ではありません。実際、Googleを含むいくつかの組織では、違ったモデルを採用していて、開発から、ソフトウェアを実行するチームへと明確に「引き継ぎ」をしています。このチームのことをサイトリライアビリティエンジニアリング（SRE）チームと呼びます。このモデルでは、開発チームは、自分たちのソフトウェアがSREチームのサポートを受けるに十分な水準にあることを示すテストの証拠（ログやメトリクスなど）をSREチームに提供する必要があります。

重要なのは、SREチームは、運用面での標準を満たさないようなソフトウェアを拒否できること、本番稼働前にコードを改善するよう開発者に要求できることです。開発チームとSREのコラボレーションは運用基準を中心に行われますが、SREチームがコードに満足したら、開発チームではなくSREチームが本番稼働をサポートします。

タイプ7の適合性: タイプ7は、エンジニアリングと組織の成熟度が高い組織にのみ適しています。SREや運用チームが「いいからやれ」とデプロイを指示されるような場合は、アンチタイプA DevとOpsのサイロに戻るので注意してください
潜在的な効果: 低〜高

タイプ8: コンテナ駆動のコラボレーション

タイプ8

コンテナによってアプリケーションのデプロイとランタイムの要件をカプセル化することで、開発者と運用担当者のある種のコラボレーションの必要性を無くせます。このように、コンテナは、開発と運用の責任の境界として機能します。健全なエンジニアリング文化があれば、コンテナ駆動のコラボレーションモデルはうまく機能します。しかし、開発者が運用上の考慮事項を無視するようになると、このモデルは敵対的な「ぼくらとあいつら」に逆戻りすることになります。

タイプ8の適合性: コンテナは非常に有効ですが、開発の投げつけるものを何でも実行するように運用チームが期待されてしまうというアンチタイプA DevとOpsのサイロには注意してください
潜在的な効果: 中～高

タイプ9: DevとDBAのコラボレーション

タイプ9

開発とDBAのあいだのギャップを補うために、このタイプ9のような構造を実験している組織もあります。つまり、開発チームのデータベースに関する能力や専門性をDBAチームが補完します。これによって、開発からのデータベースの見方（基本的にアプリケーションのための永続的ストアとしか見ていない）と、DBAからのデータベースの見方（ビジネス価値の素晴らしい源泉）のあいだの変換を助けるのです。

タイプ9の適合性: 1つ以上の大規模な中央データベースを持ち、複数のアプリケーションが接続されている組織向け
潜在的な効果: 中

それでは。