目次
はじめに
State of DevOps ReportはDevOpsの成熟度についてアンケート形式で調査しているレポート資料です。毎年アップデートされているので、直近の動向などを理解し、かつ課題解決の活路を見出すのに良いレポートです。2021版が先日リリースされていました(もとのレポートはこちら)。
デジタルトランスフォーメーションの文脈の中で、ソフトウェア開発がますます増えてきていますが、単に一発作っておしまいではなく、継続的に進化させることが求められます。継続的にサービスを進化させていくことがビジネス力の根源となるということをアンケート調査から証明したのが、このレポートで、調査内容については、『LeanとDevOpsの科学』をご一読いただくと良いかと思います。
今回はState of DevOps Reportの内容をいくつかピックアップして、グローバルのDevOpsの動向にキャッチアップしたいと思います。
レポートは以下のウェブサイトよりダウンロードいただけます。
https://puppet.com/resources/report/2021-state-of-devops-report/
DevOpsの成熟度別の傾向
冒頭のイントロダクションでは、DevOpsには元々、自動化、プログラム可能なインフラ、様々なプログラミング言語とAPIへのアクセスのような主要な要素があるが、基本的には人間中心のムーブメントであると説明し、DevOpsを導入する上で文化は根源的な問題であるとしています。また、DevOpsをうまく実践している企業はDevOpsとは呼ばずに単純に彼らの仕事のスタイルとして実践している企業も多くでてきており、DevOpsはバズワードから仕事そのものに変化してきている。ただ、DevOpsの主要な要素をうまく実践している組織でさえ、中レベルで立ち往生しているケースもあるという。
以下のグラフにあるように、過去4年の傾向をみると、Highly Evolved（高く進化した組織）は増加傾向にあります。一方で、Midと定義される集団が、なかなか減らない状況を課題視している。そのため、今回のレポートでは、Midの集団を、3つのカテゴリに分類して、Midの中でもどのような違いがあるかを明確にしたということです。Mid状態の組織の67％が繰り返されるタスクの自動化は導入されているが、組織のサイロ化やインセンティブ提供の誤りなどが多い傾向にあるというデータが取れているようです。つまり、文化的な要素がHighにあがるためのキーファクターであることがわかります。
DevOpsの成熟度レベルについて
前述した、High・Mid・Lowの違いについて改めてレポートでも触れられていますが、この指標は、このState of DevOps Reportを過去に何度も調査する中で、事業パフォーマンスの良い企業が、サービス開発においてどのようなパフォーマンスを挙げているかをベースにしたものです。
デプロイメント頻度、変更へのリードタイム、平均修復時間、変更失敗率の4つのポイントで、DevOpsの成熟度を評価している。以下の図を見て分かるように、Highになればリリース頻度が高くなり、システムに問題が起きたときの修正や修復などの時間も短いことが分かります。
これらのシステム的なパフォーマンスは、昨今デジタルなサービスを顧客に提供し関係性を構築し、売上向上を狙っていくような場合には非常に重要な要素であるといえます。
今回のレポートのポイントはTeam Topologies
前述の通り、今回のレポートではMidに位置する組織がなぜHighに上がれないかを分析しています。また、2020年のState of DevOps Reportでは、「プラットフォームモデル」が紹介されました（参考記事：こちら）。このプラットフォームチームについて、Team Topologiesモデル（https://teamtopologies.com/book）の考え方も引用しつつ、今回のレポートが作成されています。このため、Team Topologiesの著者であるMatthew SkeltonとManuel Paisが参画したとのことです。
クラウドの利用や自動化を導入するだけでは、DevOpsの成熟度Highにはなれない
本レポートの調査対象の3分の2がパブリッククラウドを利用していると回答したが、20％のみがその最大の可能性を活かしきれていないということが明らかになったようです。また他のアンケート結果でも分かったこととして、クラウド、自動化の導入に加えて、組織・チームの要素が重要であるということです。具体的には、以下が挙げられています。
- ミッションが明確化
- 主要顧客となる接点／他社との健全なインタラクションができているか
チームのアイデンティティと明確なコミュニケーションの枠組みが重要
また、Team Topologiesで説明されている、Stream-aligned TeamとPlatform Teamを組み合わせている組織ほど、DevOpsの成熟度が高くなっているということです。これにより、チームの認知負荷がスケールできるように管理できると説明されています。
Stream-aligned TeamとPlatform Teamについては後述しますが、「認知負荷がスケールできる状態にできる」とは、それぞれのミッションに応じてフォーカスができる、という意味だと理解しました。
また、チームの責任の明確化に関しても成熟度がHighであるほど、他部門や隣接部門の責任について理解ができていることが今回のレポートで分かったようです。
91％のHighly Evloved Teamは、他のチームの責任に関する明確な理解を持っている。一方で、Low-evolution teamは46％しか回答していない
77％のHighly Evolved Teamが隣接するチームの責任について明確であると回答した。それに対して、Low-evolution teamは約30％しかそのように回答していない
Team Topologies モデル
上述したTeam Topologiesモデルについての概要が本レポートで説明されおり、簡単に抜粋すると以下のような要素になります。これらのモデルをうまく組み込んでいる組織ほどDevOpsの成熟度がHighになっているといことのようです。
各種サービスの開発チームはStream-aligned Teamとして事業の価値を届けるための活動を進める中で、それをスピーディに実現するプラットフォームをPlatform Teamが提供する、そのようなイメージとして理解ができるかと思います。それ以外にも、Enabling TeamやComplicated Subsyste teamなどがあることもしっかり意識しておきたいところです。
◆4つのトポロジーの基礎◆
- Stream-aligned team：ビジネスドメインの価値の流れに沿って仕事をするチーム
- Enabling Team：Stream-aligned teamが障害を乗り越えることや、何か不足していることがないかを発見するチーム
- Complicated subsystem team：数学的・演算が必要となる領域や、ニッチなテクノロジー専門性が必要とされる領域をフルタイムで仕事するチーム
- Platform Team：Stream-aligned Teamがデリバリ速度をあげるために、社内向けプロダクトを提供するチーム
◆3つの相互作用◆
- Collaboration：特定の期間協業し、新しいことをみつける（API、実践方法、技術、など）
- X-as-a-Service：あるチームが提供し、別のチームが as a Service として利用する
- Facilitation：あるチームが、別のチームを支援する、メンターする
社内プラットフォーム
「社内プラットフォームの利用レベル」のアンケートを見ると、DevOps成熟度Highの上位3つがTeam Topologiesを採用していることが分かるかと思います。以下に上位3つのラフな翻訳をご紹介します。
- 部門を超えたチームが、機能を開発し、顧客向けに独立してその機能を提供できる
- 特定のチームが、多くの機能開発チーム向けに、セルフサービスAPIを経由したソフトウェア配備のソリューションを提供している （例：インフラ、データ、CI/CDツールなど）
- 特定のチームが、インフラを準備・維持し、他のチームが機能のデザイン・開発・配備を行っている
また、社内プラットフォームに関しては、インフラの提供をオンデマンドで提供するだけではなく、開発者が必要とする機能を提供することで、より一層活用が広まるという言及もありました。このように、プラットフォームをしっかり準備し、機能開発チームのスピードをあげていくことが重要なことかと理解できるかと思います。
NIST Cloud Capability Metricsへの適用は重要な要素
冒頭の方でご紹介したように、自動化の実践やクラウドの活用は根本的な要素ではあるが、DevOpsの成熟度をHighにもっていくためにはあまり影響がないということが今回のレポートで何度も言われています。明確な差が出たのは、NISTのcloud capability metrics への適用であると紹介されており、NIST Cloud Capability Metricsの5つすべてを適用していると回答した成熟度Highの組織がMidやLowと比較しても倍以上の適用度になっています。
NIST Cloud Capability Metricsは、米国標準技術研究所（NIST）が定めたクラウド適用するうえでのガイドラインのようなものです。詳細のドキュメントはこちらから確認ができますが、5つのCloud Capabilityは以下の通りです。
- オンデマンドなセルフサービス
- 幅広いネットワークへのアクセス
- リソースのプール
- 迅速な弾力性
- サービスの計測
運用の未来
また、本レポートでは運用（Ops）の未来についても言及がある。パブリッククラウドの登場によって、運用担当者の仕事はなくなるのではないかと言われたこともあったかと思いますが、本レポートでは以下のようなスキルを身につけることで、運用担当者としての市場価値が高められると述べられています。
- Vendor Engineering：ベンダー管理
- Product Engineering：社内向けPlatformをプロダクト開発の発想で扱う
- Sociotechnical System Engineering：フィードバックループを回すことで効果的・効率的にしていく
- Managing the portfolio of Technical investments：技術的投資や技術的負債のポートフォリオ管理
上記の4つのポイントの詳細については、A Cloud Guruのブログ記事で紹介されているものを採用しているようですので、気になる方はこの記事を読んでみると良いかと思います。
おわりに
上記でかなりの部分を紹介してしまいましたが、これ以外にも多くの示唆が本レポートから得ることができます。DevOpsは元々2009年のVelocityというイベントで、Flickr社に所属していた方が、「10+ Deploys Per Day」というプレゼンテーションで、Dev（開発）とOps（運用）の協業により、スピーディなソフトウェアのデプロイができているという紹介されたことを起源としています。その後DevOpsという言葉はバズワードのように広まりましたが、現在ではこのレポートでもあるように、DevOpsという言葉はもう使わずに自然体になってきているようです。
アジャイルも同様ですが、DevOpsは一日にしてならず。このようなレポートの示唆などを参考にしつつ、少しずつできることから進めていくのが良いのではないでしょうか。
ーーー
デジタルサービス開発のポイント＆事例の紹介資料をご確認ください！
顧客向けのサービス開発をアジャイル開発の手法を活用してご支援しています。また、今回ご紹介したDevOpsの要素も技術的に取り入れながら継続的に改善ができるサービスとして開発をしていきます。顧客向けのデジタルサービスを開発する上でのポイントとあわせて、事例をご紹介している資料は以下からダウンロードいただけます。
『デジタル顧客接点トータルサービス』のご紹介資料を含めたウェビナー資料（事例も掲載しています）以下のフォームからご確認いただけます。（フォームが表示されない場合には、こちらからご確認ください）
資料ダウンロードは以下のフォームにご記入ください。
キャッチ画像は İrfan Simsar on Unsplashを活用させていただきました
