CI/CD Conference 2021からCircleCIによる調査レポートの解説を紹介

CI/CD Conference 2021から、CircleCIのエンジニアがDevOpsに関するアンケート調査を解説するセッションを紹介する。これは「State of DevOps Report 2020/2021から見るCI/CDの始め方」と題されたセッションで、プレゼンテーションを担当したのはCircleCIのシニアソリューションエンジニア、車井登氏だ。

セッションを行う車井氏

車井氏はこのセッションで紹介されるState of DevOps Reportについて、2011年からPuppetによって開始されたアンケートベースの調査であること、CircleCIとして2019年から参加していることなどを語った。

State of DevOps Reportとは何かを説明

2013年からDevOpsを評価するための指針となる4つの指標を作ったこと、2018年から組織のDevOpsへの取り組みの成熟度のモデルを取り入れたことなどを解説した。

4つの指標とは何か

4つの指標について、デベロッパーにおいてはスループットという観点からデプロイの頻度、そしてデプロイを実施するために必要なリードタイムを紹介した。また運用チームにおいては安定性という観点からトラブルやバグなどの失敗から復旧に要する時間、そして失敗の頻度を挙げた。

ここではDevOpsがデベロッパーとOps（運用）を連携させる発想であることから、デベロッパー側の指標と運用側の指標がそれぞれ選ばれていることに注目したい。

4つの指標の程度によってランク付けする発想

ここからはその4つの指標のレベルによって、組織をエリート、高、中、低に分けて、どの程度の数値を出しているのか？ によってランク付けする発想を紹介した。運用側の指針であるトラブルからの復旧時間に関しては、どのようなトラブルなのかによって変わるだろうし、頻度についても変更をデプロイする機会自体が少なければそもそも内部的要因による失敗はあまり起こらないと思われるので、その点だけで運用側のDevOpsらしさを評価するのは難しいだろう。しかしデベロッパーが書いたコードが頻繁に本番環境に反映され、そのための準備も少なくて済むという状況において、バグに対応するための復旧時間が短く、しかも復旧を要するようなバグがあまり発生しないというという限定された状況を想定していると考えれば、ある程度は納得できるかもしれない。

State of DevOps Report：The 2020 State of DevOps Report is here!

そしてこの4つの指標について、車井氏が所属するCircleCIのサービスではダッシュボードから確認できるという宣伝を挟んで、ここからはDevOpsを組織に取り入れていくにはどのようにすべきか？という説明に移った。

CircleCIのダッシュボードから4つの指標を確認できる

ここで注意したいのが、ここでの主体はあくまでもデベロッパーから見たDevOpsであるという点だろう。デベロッパーは常に新しい機能、サービスを開発するのが仕事で、運用チームはそれを安定的に稼働させるのが仕事だ。2020年度版のレポートではアンケートに参加した2400社のうち27％がデベロッパーチーム、20％がDevOpsチームであるのに比べて、インフラストラクチャー／Opsチームと称しているのが15％しかいないという点からすれば、視点がデベロッパー中心になるのは仕方ないのかもしれない。その視点を理解した上で、次のスライドに説明を移そう。

DevOpsジャーニーとは

このスライドはDevOpsを実現するための段階を解説したものだが、正規化、標準化、範囲の拡大、インフラデリバリの自動化、セルフサービスという段階の見出しを見れば、デベロッパーが最終的にすべてのアプリケーションの実装までを自動化するための段階であることがわかる。ここでのインフラチームは、あくまでも黒子として扱われている。

「開発チームと運用チームが協力して連携する」とは言うものの

この中間のまとめのスライドには「DevOpsの基本は開発チームと運用チームが協力して連携する」として、ツールやプロセスが必要ではあるものの、同時に組織の構造的な問題を解決する必要があるとも書かれている。また「DevOpsが企業内で広まらない理由は、構造的に組織の調整がなされていないからだ」とも書かれている。つまりツールやプロセスを導入しても組織がそれを支援する形に変わらない限りは、DevOpsとして開発と運用を素早く安定的に回すことは難しいことがわかっていると言える。しかし組織をどのように変えるべきか？ については言及せずに「DevOpsの手法を社内基盤チームに広げよう」とだけ推奨している。

「DevOpsの手法を社内基盤チームに広げる」とは

ここでの社内基盤は、開発者が開発からデプロイ、リリースまでを行えるような基盤を指すと思われる。つまりいわゆるインフラストラクチャーとしての基盤ではなく、PaaSのようなモノを想定しているようだ。ここでも組織をどのように変えるべきかについては深く掘り下げていない。

そして次に、社内基盤を作ることはプロジェクトではなく永続的に続く製品化として取り組めというスライドが現れる。

社内基盤は一過性のプロジェクトではなく製品として取り組め

特徴的なのは、予算を決めるなという部分だろう。これはつまり社内基盤は特定期間だけ発生するプロジェクトではなく、永続的に人的なコストが発生するものとみなして取り組もうという発想だ。しかし運用側はコストセンターとして常にコストと効果の最適化を命じられる部門だし、開発チームにおいても開発したコードがビジネスにどれだけ貢献したのか、もしくはコストや時間をどれだけ削減したのかを常に求められる部門のはずだ。特にパブリッククラウドを使うことによって、オンプレミスと比較してコスト意識をさらに鋭敏にしなければいけない昨今の企業においては、なかなか受け入れが難しい発想かもしれない。

2021年度版のレポートの紹介

ここからは最新のレポートの紹介となった。

DevOpsは自動化ではなくクラウドでもない

ここではレポートのサマリーとして「DevOpsは単なる自動化ではない」「DevOpsはクラウドでもない」「チームのアイデンティティと明確な相互コミュニケーションの枠組みが重要」「大規模な成功の鍵は基盤チーム」などが紹介された。

「自動化でもクラウド化でもない」というのは、DevOpsジャーニーの第4段階に「インフラデリバリの自動化」を挙げているのと矛盾するのではないかと思えるが、そこには言及せずに「チームの存在意義と各チームがお互いに意思疎通をすることが重要」と書いているのも興味深い。ここで「社内基盤チームが重要」というのは、デベロッパーを支援するプラットフォームを永続的に開発するようなチームを作ることが重要であると読み替えても良いだろう。

DevOps成熟度の問題点を紹介

このスライドでは、ランク付けられた企業がDevOps的に成熟するための問題点を紹介している。自動化はされているが文化的、プロセス的、組織的な変化が起こっていないこと、製品サービスのデプロイに複数チームによる引き継ぎが必要であることが問題として挙げられている。ここでも組織的な変化が必要であることが強調され、さらに引き継がずに実装できる仕組み、組織を目指すべきということが暗に示されていると言える。CircleCIの発想では、その引き継ぎ部分を受け持つのが社内基盤チームということだろうか。

提案された組織の例

このスライドでは、DevOpsを実践する上で効果的となる組織の例を紹介している。ここで最下層に描かれているPlatform Teamとは、社内向けの基盤を提供するチームであり、さらにその下にインフラストラクチャーを運用するチームが存在するということになるのだろう。ビジネスを実装するチームと専門的な部分、例えば機械学習などの専門的なドメインの問題を解決するチームなどが描かれている。ここでもあくまでもデベロッパーが主体となってインフラストラクチャーを受け持つ部門は特に言及されていない。

また課題の例として挙げたこのスライドでも、CircleCIの発想はあくまでもデベロッパー目線であることがわかる。

DevOpsやCI/CDの課題の例

「開発会社にすべてを委託していて生産性が上がらない」というのは、開発は外部、運用は内部という企業内のITの状態を部分的に表した課題だと思うが、運用がどこにあるのか？ について言及せずに開発から運用までの一体化を提案するのは無理があるだろう。

そして社内基盤グループが重要であるというポイントを整理するために使われたのが次のスライドだ。ここでは明確に開発基盤グループと書かれており、あくまでもデベロッパーが使うための基盤の成熟度合いを解説するという意味である。

開発基盤を社内に広めるための段階を解説

ステージ2から5までで最終的に生産性の向上が達成できるというのが主旨だ。筆者が違和感を覚えるのはステージ2では個人が社内のツールとは別のモノを使ってDevOpsを実装し、それを個人から公式な命令系統を経ずに別のグループに伝搬させて、それが拡大することで次の段階において公式の開発基盤グループの設立に繋げるという流れだ。

企業に属しているデベロッパーが、業務で使っている以外のツールやプロセスを個人で業務に流用することや、その効果を見た別のチームのデベロッパーがその真似をするなどということは、ITベンチャーでもない限りめったに起きないのではないだろうか。

前のスライドで「組織が変わらないとDevOpsが広まらない」としてボトムアップでDevOpsもCI/CDを実践できるという発想を否定しているにも関わらず、ボトムアップの変革を主張する点には違和感を覚えた。

CI/CDを成熟させる3つのステップを解説

またこのスライドでは導入～改善～拡大という単純な段階でCI/CDを組織に広げることを推奨している。しかしここまで社内基盤チームはプロジェクトではなく製品、プロダクトとして扱うことでコストを決めるなと提言していたにも関わらず、現実的にはトータルコストの見直しが目標として挙げられている。これは現実的とは言えるものの、前段の提案とは矛盾しているように感じた。このスライドでは、すべてのプロジェクトに対してのコスト見直しと書かれていることからも、社内基盤チームはプロジェクトではなくプロダクトだからここでは除外されているということだろうか？

全般的に、英語によるレポートをざっくりと要約したセッションとなったが、組織を変えるべきという問題提起があるにも関わらず、組織の作り方や移行などについて言及がなされてないことが残念である。

筆者は、組織の変革なくして日本にDevOpsを根付かせることはできないと思っている。それは、かつてインタビューした大手ビジネスパッケージベンダーが、開発グループと運用グループの違いについて述べたことを未だに記憶しているからだ。そのベンダーのあるマネージャーは、開発のエンジニアは大卒、運用は高卒で十分、運用マニュアルに書かれていることを忠実に実行してくれるだけで良いということを語ってくれた。しかし、ここまではっきりと区別されているチームが、同じ目標を持って仕事をして評価されるようになるためには、ツールだけではなく採用、評価、そして組織自体の運用まで抜本的に変えないと不可能だろう。そうでなければツールベンダーだけが売り上げをあげるだけで終わってしまう。CircleCIには、その辺りの考え方を含んだ次回のプレゼンテーションを期待したい。