State of DevOps Reportとは？
良いDevOpsとは何か？をアンケート結果から何か見えないか？というのを調査したレポートが話題になった。そのレポートが"State of DevOps Report" である。
State of DevOps Reportで有名になったのは、以下の4つの指標で、クラスター分析をかけると、いくつかのクラスターが見つかったことである。
- デプロイ頻度
- 変更のリードタイム
- サービスの回復時間
- 変更への失敗率
以下は2019年の結果表で、良い結果のクラスター(Elite/Highパフォーマー)は全ての指標において、よい結果になっている。このレポートでは各クラスター群をElite/High/Medium/Lowパフォーマーに分けている。
そう、この4つの指標が良い結果の企業は、非常にITが進んでいるということを表している。
2019年のレポートにはもうひとつ興味深い図もある。2018年と2019年の各パフォーマーの割合の推移で、HighパフォーマーはEliteパフォーマーに向上している傾向があるが、Midium/Lowパフォーマーの合計は、ほぼ変化していない。つまり、Midium/Lowパフォーマーに陥ると、Elite/Highパフォーマーになかなか向上できないということを意味している。
なお、この2017年までのレポートを、書籍にしたものがLeanとDevOpsの科学である。日本語で読めるので興味があるひとは読んでほしい。
2020年のレポートで語られているもの
2020 State of DevOps Reportはこちらよりダウンロードできる。
毎年、レポートには先ほどの章で載せた4つの指標の表が掲載されていたが、今年はそれは掲載されていないのがまず目に引く。
また、今年は大きく以下の2つのテーマに関して語られている。
- 社内プラットフォーム・チームとともにスケールするDevOpsプラクティス (Scaling DevOps practices with internal platform teams)
- DevOps時代の変更管理 (Change management in the DevOps era)
社内プラットフォーム・チームとともにスケールするDevOpsプラクティス
社内で活用できるプラットフォームがある会社がよいDevOpsの提供する傾向にある、特に自動化されたインフラストラクチャー・デリバリーや、更に進んで、セルフサービスでリソースが使用できるようになる環境があるのがよりよい傾向にある、としている。
皆さんの社内でも社内標準のプラットフォームが何らか存在するとは思うが、このレポートはプラットフォーム提供に関しても以下のアドバイスを含んでいる。
- プロダクトとしてのプラットフォーム (Platform as product)
プラットフォームはすべてのアーキテクチャ、機能性、ツールなどを規定する象牙の塔のような集団となっては行けない、と明確に書いている。プラットフォームはチームを円滑に仕事をさせ、ゴールを達成させ、そしてビジネスを向上させるための、コア・ケーパビリティを提供する必要がある。そのためにはチーム(顧客としての社員)のニーズに耳を傾ける必要がある。
以下のプラクティスが書かれている。
- セルフサービスとAPIファーストを考える (Think self-service and API first)
- ローカルでスタートし、グローバルで構築する (Start locally but build globally) → Agileなアプローチのようにフィードバックを重視して、プロダクトを作っていこう、という意味だと思われる。
- 開発者の経験とフローにフォーカスする (Focus on developer experience and flow)
- 布教する (Evangelize) → 「俺が作ったから、絶対使えよ」みたいなのは失敗しがち。プラットフォームのケイパビリティをデモンストレーションする。
- プロダクトに継続的に投資する (Continuously invest in the product)
それ以外に興味深いのは、社内プラットフォームの構築への課題は、高度に進んでいるところ(High evolution)では、時間や標準化の欠如が1, 2位だが、その割合はLow/Medium evolutionに比べると著しく低い(significantly lower percentage)と記載されている点である。(具体的にどれくらいかの記載はなし)
DevOps時代の変更管理
State of DevOps Reportでは、過去にも変更管理に関する言及はあったが、今年のレポートは大きく取り上げている。
変更管理は以下の4つに分けて語られている。
- 運用上の成熟 (Operationally mature)
- エンジニアリング駆動 (Engineering driven)
- ガバナンス重視 (Governance focused)
- アドホック (Ad hoc)
これらは、自動化に支えられた適応型変更承認(Adaptive change approval)とコミッティーや多段階の手動によるオーソドックスな変更承認(Orthodox change approval)の2つの軸で語られている。
この4つの中で最もよい傾向があるのはエンジニアリング駆動な変更管理で下記のグラフの通り、変更管理(CM = Change Management)の効率性も最も良い成績を示している。
他にも様々な調査結果のグラフが資料にはあるが、ポイントは、以下に手動で行っていた変更プロセスを自動化するかに力点が置かれているように思われる。
また、それぞれに対して以下の傾向があるそうだ。
- 運用上の成熟: リスク許容度が低い
- ガバナンス重視: 機能チーム(functional teams)間の信頼性が低い
- アドホック: スキルの不足
さらに興味深いのは、変更内容も文書(prose, 散文)で記述するのではなく、コードで記述するほうが良いともされている。
改善のために以下の提言も書かれている。
- サイロを打破し、共感を構築する (Break down silos and build empathy)
- フィードバック・ループを作る (Create feedback loops)
- 新しいアプローチの効果を測定する (Measure the impact of your new approach)
DXとDevOps
さて、ここはState of DevOps Reportとは直接関係ない話を。
昨今、DX (Digital Transformation)が様々なエンタープライズ企業で語られている。
DXはいまだ何なのかは人により語られることが異なる。ただただ、デジタル化することやモダン化をすることではないことはなんとなく理解されつつあるのではないかと思われる。
本レポートではDXというキーワードは語られていないが、DXを推進するためには指標となりそうなことはこのレポートでは書かれていると思う。
リスク許容の文化の醸成/エンジニアリング・カルチャー/自動化など多くは過去のレポートにも取り上げられていて、是非とも過去のレポートも含め読んでいただきたい。
最後に
今年のDevOpsレポートは例年と異なり、包括的なものより、プラットフォームと変更管理というトピックを定めて語られていることに興味をもった。
ぜひ、もっと包括的なものをという場合は2019年や2018年のものを読むことをお勧めする。
是非、IT後進国とされる日本もこういうデータに基づくレポートを元に改善をしていってほしい。