Zenn
サイボウズ 生産性向上チーム 💪Publicationへの投稿
💪

State of DevOps Report 2023 のまとめ

r4mimu
2023/10/23に公開
#
DevOps
#
生産性向上
#
開発生産性
idea

2023 年版の State of DevOps Report が公開されました。
State of DevOps Report とは Google の DevOps Research and Assessment（DORA）チームが毎年公開している DevOps や開発生産性にまつわる年次レポートです。

本記事で、今年のレポートの概要を簡単に見ていきたいと思います。

主な調査結果

Goodhart の法則を理解し、パフォーマンス向上の落とし穴を避ける

開発組織のパフォーマンスを評価する際、メトリクスの設定や評価の方法には注意が必要であり、特に「Goodhartの法則」という考え方を知っておくことが大切であると述べられています。

Goodhartの法則とは、簡単に言うと「測定が目標となると、それは良い測定基準でなくなる」という法則です。
この法則を踏まえた、パフォーマンスの評価や向上のためのヒントと注意点が纏められています。

  • 基準の設定:
    パフォーマンスを向上させるための最初のステップは、現状の性能を明確に把握すること。これを基に、チームがどのように進化しているのかを定期的に評価することが大切
  • 継続的な改善:
    単なる数字や目標に囚われることなく、継続的な改善を目指す姿勢を持つことが重要。それには、チーム全体での協力や実験の推進、そしてその結果の再評価が不可欠

さらに、以下のような落とし穴にも注意が必要です。

  • 単純な比較を避ける:
    異なる環境や背景を持つプロジェクトを単純に比較するのは適切ではない
  • メトリクスの悪用:
    すべてのアプリケーションやプロジェクトが同じ基準を満たす必要はなく、目標を設定する際は現実的なものを選ぶことが大切
  • 適切なメトリクスの選択:
    複雑なシステムに対して一つのメトリクスだけに依存するのは避ける
  • 意義あるメトリクスの重視:
    測定しやすさだけでなく、そのメトリクスが持つ意味や価値に注目することが重要

このように、メトリクスを設定する際やチームのパフォーマンスを評価する際には、多角的な視点や柔軟な思考が求められるとあります。

メトリクスを良くすることを目的にするのではなく、メトリクスを良くすることでチームのパフォーマンスを向上させることを目的にすることを忘れないようにしましょう。

ソフトウェアデリバリーパフォーマンス

今年も Four Keys を用いたソフトウェアデリバリーパフォーマンスの調査結果が公開されています。
Four Keysは DORA が定義するソフトウェア開発チームのパフォーマンスを示す、以下の 4 つの指標のことです。

  • 変更リードタイム
  • デプロイ頻度
  • 変更障害率
  • サービス復元時間

詳しくは Google のブログを参照してください。

以下の画像が今年のソフトウェアデリバリーパフォーマンスに関する調査結果です。

デリバリーパフォーマンス結果2023年の調査結果 (レポート P.12 より引用)

気になる点としては、2022 年のレポートでは Elite はいませんでしたが、2023 年は全体の18%が Elite となっています。
この原因は、レポートでは明言されていませんが、Appendix P.92 辺りの内容を踏まえると以下のような理由が考えられます。

  • 変更失敗率の報告方法の変更
    • 昨年までは回答者には6つのオプション (0-15%, 16-30% など) が提供されていた
    • 2023 年 のアンケートでは回答者は 0% から 100% の間で任意の値を選択できるスライダーに変更された
  • 障害復旧に関しての質問文の変更(原文ママ、レポート P.92 より引用)
    • 昨年までの質問:
      “For the primary application or service you work on, how long does it generally take to restore service when a service incident or a defect that impacts users occurs (for example, unplanned outage, service impairment)?”
    • 2023 年 の質問:
      “For the primary application or service you work on, how long does it generally take to restore service after a change to production or release to users results in degraded service (for example, lead to service impairment or service outage) and subsequently require remediation (for example, require a hotfix, rollback, fix forward, or patch)?”

2023 年の質問には、具体的なシナリオ（変更やリリースに関連するサービスの劣化）が追加され、その結果としての修正アクション（ホットフィックス、ロールバック、フォワード修正、パッチなど）に関する情報が求められるようになっていました。

また、お気づきでしょうか、「復元時間(Time to restore)」が「失敗したデプロイメントの回復時間(Failed deployment recovery time)」に変更されています。

昨年までの調査方法では、「ソフトウェアの変更による障害」とデータセンターでのサービス中断のような「他の要因による障害」とを区別することができませんでした。

また、復元時間 "Time to restore" は時折 "MTTR" として略されていましたが、これは "Mean Time To Recovery" なのか、"Median Time To Recovery" なのかコミュニティ内で混乱を招いていたこと、Resilience Engineering では MTTR 指標の使用を止めている[1]ことから見直されたそうです。

質問文や指標の定義の変更が入っていることを考えると、単純に昨年までと今年の指標を比較することはできないと考えられますが、Elite のチームがかなり増えているのがわかります。

主旨とは逸れますが、MTTR の用語が変わったことは本文中に記載してほしかったです。

チームタイプのクラスタリング

今年のアンケート結果からソフトウェア配信のパフォーマンス、運用のパフォーマンス、およびユーザ重要視性を単位として、チームを比較することで 4 つのチームタイプに分類できたとあります。

  • User-centric (ユーザ中心)
    • このチームは、ユーザのニーズに最も集中している
    • ソフトウェア配信と運用の性能が強いことが、組織の高いパフォーマンスを予想させる
    • しかし、バランスのとれたチームよりも燃え尽きる可能性がやや高い
    • ソフトウェアの配信や運用の性能を向上させることで、これらのチームの燃え尽きを減少させる方法かもしれない
  • Feature-driven (機能駆動)
    • このチームタイプは、機能のリリースに焦点を当てている
    • リリースに対する過度な焦点は、チームがユーザのニーズを満たすことから気を逸らす可能性がある
    • ユーザ中心性と運用のパフォーマンスの数字が低いことからもこれが示されている
    • 燃え尽きや仕事の満足度が非常に高く、組織のパフォーマンスが低いと報告されている
    • 機能駆動のチームは、提供される機能からの価値を最大化するために、ユーザのニーズを反映することで利益を得ることができる
  • Developing (開発中)
    • このチームはアプリケーションのユーザーのニーズに焦点を当てることで良好な組織的パフォーマンスを達成している
    • しかし、彼らはまだ製品-市場の適合性や技術的能力を開発中である可能性が高い
    • このチームは小さな組織で頻繁に見られる
    • ソフトウェアの配信や運用の性能が低く、バランスの取れたまたはユーザ中心のチームタイプよりも燃え尽きるレベルが高いと報告されている
    • これらのチームは、ソフトウェアの配信や運用の性能を向上させる方法として、重いプロセスや自動化できる手間のかかるタスクを持っている可能性がある
  • Balanced
    • このチームタイプは、技術を持続可能な方法で使用して、組織の良好なパフォーマンス、チームの良好なパフォーマンス、および良好な仕事の満足度を達成することを示している
    • これらのチームは燃え尽きのレベルが最も低いとも報告されている
    • ユーザ中心性を高めることで、組織的なパフォーマンスを向上させる可能性がある
      チームタイプとパフォーマンスの関係チームタイプとパフォーマンスの関係 (レポート p.14 より引用)

チームタイプと予測チームタイプと予測 (レポート p.15 より引用)

Key findings

レポートでは Key findings として 7 つのトピックを挙げており、それぞれのトピックについて調査結果をまとめています。

  • ユーザーを重視
  • コードレビューの高速化でソフトウェア・デリバリーのパフォーマンスを向上
  • 質の高い文書化で技術力を増幅する
  • クラウドでインフラの柔軟性を高める
  • ソフトウェアのデリバリー速度と運用パフォーマンスをバランスよく維持し、ユーザーに焦点を当てる
  • 健全な企業文化の確立
  • 仕事を公平に配分する

ユーザーを重視

  • ユーザーを深く理解し、ユーザーからのフィードバックを繰り返し調整し、取り入れている組織は、ユーザーを重視していない組織に比べ、パフォーマンスが 40% 高く、仕事満足度は 20% 高いことが分かった
    • というのは、ユーザーに焦点を当てることで、製品開発チームと運用チームが、ユーザーのために適切なものを作ることができる
    • そのような組織は、ユーザーのニーズに強く焦点を当てながら、デリバリー、オペレーション、組織的パフォーマンスにわたって強みを発揮することができる

ユーザ中心チームタイプがパフォーマンスに優れているといった内容でした。また、今流行の(？) Platform engineering についても触れられていました。

ユーザーの重視とは？と思ったのですが Project to Product[2] という本で詳細が書かれていそうです。

コードレビューの高速化でソフトウェア・デリバリーのパフォーマンスを向上

  • コードレビューを高速化することは、ソフトウェアデリバリーのパフォーマンスを向上させる最も効果的な方法の1つです。
  • 効率的なコードレビュープロセスは、コードの改善、知識の伝達、コードの所有権の共有、チームの所有権、透明性につながる。
  • コードレビューが高速化されたチームは、ソフトウェアデリバリーのパフォーマンスが50%向上しています。
  • ペアプログラミングはコードレビューの時間を短縮できるプラクティスである

情報共有やレビューの効率化については、ペア・モブプログラミングが有効とのことです。

質の高い文書化で技術力を増幅する

  • 高品質のドキュメンテーションは、技術的能力が組織のパフォーマンスに与える影響を増幅する
  • たとえば、トランクベースの開発では、質の高い文書が整備されている場合と質の低い文書が整備されている場合とを比較して、組織のパフォーマンスに与える影響が 12.8 倍になると推定されている
  • しかし、ドキュメンテーションの質が高まるにつれて、燃え尽き症候群のレベルが高まると報告する回答者もいる

ドキュメントと燃え尽き症候群の関係性は今後の研究課題として残されています。質の高いドキュメンテーションを作成、メンテナンスすることが負担になっているといったことなのでしょうか。来年以降のレポートに期待です。

クラウドでインフラの柔軟性を高める

  • クラウドコンピューティングが有益なのは、柔軟なインフラを構築できるためである

  • 例えば、パブリッククラウドを使用すると、クラウドを使用しない場合と比較して、インフラの柔軟性が22%向上する

    • 柔軟性の定義はおそらく以下の性能指標かと思われます
      • オンデマンドの自己サービス (On-demand self-service)
      • 広範囲のネットワークアクセス (Broad network access)
      • リソースのプーリング (Resource pooling)
      • 迅速な拡張性 (Rapid elasticity)
      • 測定可能なサービス (Measured service)
    • 正確な定義は The NIST Definition of Cloud Computing [3] を当たってみてください

  • この柔軟性は、柔軟性のないインフラと比較して、組織のパフォーマンスを 30% 向上させる

  • クラウドの価値を最大限に引き出すために重要なのは、クラウドが提供する差別化された特性や能力、すなわちインフラの柔軟性を活用することである

納品スピード、運用パフォーマンス、ユーザー重視のバランス

  • 組織のパフォーマンスを最大限に発揮するためには、強力なソフトウェア・デリバリー・パフォーマンスと強力なオペレーション・パフォーマンスの両方が必要
  • この 2 つをユーザー中心でバランスよく維持することが、従業員の福利厚生を向上させながら、組織として最高の結果をもたらす

ここでもユーザー重視のチームはパフォーマンスが高いことが言及されています。

健全な企業文化の確立

組織文化が成果、技術的能力、従業員幸福度に与える影響を調査しています。

ここでの、組織文化とは以下の 7 つと定義されています。

  • ウェストラムが定義する組織文化
    • このうち、創造的な文化を持つ組織はパフォーマンスが高いということがわかっている
      ウェストラムが定義する組織文化
  • 組織の安定性
    • 従業員にとって安定した環境か、不安定な環境か
  • 雇用の安定
    • 従業員が自分の雇用の安定を心配する頻度
  • 柔軟性
    • どのように働くか、どこで働くか、いつ働くか
  • 知識の共有
    • アイデアや情報がどのように組織全体に広がるか。チームメンバーが質問に答えたら、その情報は他のメンバーも利用できる。回答を待つ必要はない。
  • ユーザー中心主義
    • ソフトウェアを開発する際にエンドユーザーに焦点を当て、ユーザーのニーズや目標を深く理解する
  • 作業配分
    • タスクをメンバー間で公平に分配するための正式なプロセスが存在する

成果に対して

成果とは、

  • チームパフォーマンス
  • 組織パフォーマンス
  • ソフトウェアデリバリーパフォーマンス
  • オペレーションパフォーマンス

と定めており、全体として、健全な組織文化はすべての主要な成果にプラスの影響を与えることがわかりました。
組織文化による成果レポート p.48 より引用

創造的な文化が組織パフォーマンス、ソフトウェアデリバリパフォーマンス、およびオペレーションパフォーマンスを促進するという例年の調査結果を再現しています。
また、今年の新たなパフォーマンス指標であるチームパフォーマンスも、この文化が後押ししています。

注目すべきで新発見は、ソフトウェア開発に対するユーザー中心のアプローチが、パフォーマンスの有意義な向上につながることです。
ユーザーからのフィードバックは、チームがプロジェクトに優先順位をつけ、ユーザーのニーズを満たす製品やサービスを生み出すのに役立ち、より良いユーザー体験、ユーザー満足度の向上、収益の増加につながるとあります。

技術的能力に対して

技術的能力とは、

  • トランクベースの開発
  • Reliability
  • Continuous Integration
  • Continuous Delivery
  • 疎結合アーキテクチャ

と定めています。
組織文化による技術的能力レポート p.49 より引用

これらの技術的能力を実装することは容易ではなく、人々が協力し合い、オープンマインドを持ち、互いに寄り添い、学び合うことが必要です。
ここでは、ウェストラムの組織文化、ユーザー中心主義、作業配分が効いてくるそうです。

従業員幸福度に対して

従業員幸福度とは、

  • 燃え尽き症候群
  • 仕事満足度
  • 生産性

と定めています。
組織文化による幸福度レポート p.50 より引用

健全な企業文化は、燃え尽き症候群を減らし、仕事への満足度を高め、生産性を向上させることで、従業員のウェルビーイングを高いレベルに導きます。
組織がより良い企業文化に投資しないと、燃え尽き症候群の可能性が高まり、仕事への満足度が低下し、従業員は冷笑的になり、生産性が低下するそうです。恐ろしいですね。

調査の結論として、創造的な文化を持つ組織は、組織パフォーマンスが 30% 高く、従業員のウェルビーイングが高いことがわかりました。

仕事を公平に配分する

  • 昨年のレポートでは、性別を女性や自分が過小評価されていると感じている回答した人は、男性や自分が過小評価されていると感じていない回答した人よりも燃え尽き症候群のレベルが高いことがわかっている
    • 性別を女性である、または自称する回答者は、男性である回答者よりも 6％ 高いレベルの燃え尽き症候群を経験したと報告した
    • また、過小評価されていると感じている回答者は、そうでない回答者よりも24％高いレベルの燃え尽き症候群を経験したと報告した
  • 女性と回答した者、または性別を自称した回答者は、男性であると回答した回答者よりも40％多く反復的な仕事、計画性のない仕事、同僚から見えにくい仕事、自分の専門スキルに直接結びつかない仕事をより多くしていると報告している
  • これらの調査結果は、これらのグループが報告した燃え尽き症候群を部分的に説明している
  • そこで、仕事を公平に分配をすることで、燃え尽き症候群を軽減できるのではないかと考えた
  • その結果、男性であると回答した人、女性であると回答した人、または性別を自称する回答者において、仕事の分配が燃え尽き症候群を軽減していることがわかった
  • また、この燃え尽き症候群を防ぐためには帰属文化を作ることが重要であると述べられている
  • なぜならば、そのような人たちは帰属が不確実なために過小評価されていると感じているからである

反復的な仕事だとやりがいがなく、同僚から見られにくい仕事、自分の専門スキルにならない仕事は評価されないので、燃え尽き症候群になりやすいのは直感的でした。

帰属意識があることにより、居場所がある、必要とされていると感じるので過小評価されていると感じることが少なくなるというのは、自分の経験からも納得できました。

おわりに

いかがだったでしょうか。

今年のレポートではパフォーマンスが Elite だったチームが急増していたのが印象的でした。

また、ChatGPT や Copilot のような AI を交えた開発についての話題は思ったより少なかったと感じました。今後、AI が開発生産性にどのような影響を与えるのかも含めて調査してほしいですね。

本記事では概要程度の紹介になっておりますので、さらに詳細を知りたくなった方はぜひレポートを読んでみてください。

脚注

  1. https://www.infoq.com/articles/incident-metrics-void/ ↩︎

  2. https://itrevolution.com/product/project-to-product/ ↩︎

  3. https://csrc.nist.gov/pubs/sp/800/145/final ↩︎

サイボウズ 生産性向上チーム 💪
サイボウズ 生産性向上チーム 💪Publication

サイボウズ株式会社 開発本部 生産性向上チームです。 サイボウズエンジニアの生産性を上げるために日々活動しています 💪

Discussion