5分でわかる State of DevOps Report 2023 Engineering Productivity Meetup #1 in Tokyo(2023/11/28) サイボウズ株式会社 ⽣産性向上チーム 三村 遼(@r4mimu)

⾃⼰紹介 ▌Ryo Mimura (𝕏: @r4mimu) ▌2022年 サイボウズ新卒⼊社 l 2022年 7⽉ ⽣産性向上チームジョイン l GitHub Actions Self hosted runner 基盤の運⽤ l CircleCI Server の構築・運⽤ l Four Keys 計測基盤構築 l Garoon リリース改善チームに体験⼊部中 ▌開発組織の⽣産性 や DevOps に興味があります 2 ⽣産性向上チームの紹介資料 アイコンのねこ

発表内容 ▌ Zenn に投稿した State of DevOps Report 2023 のまとめ に基づいて作成しています ▌発表内容には個⼈の感想やお気持ちも含まれます 3 Zenn へのリンク

発表内容 ▌話すこと l State of DevOps Report とは l 2023 State of DevOps Report の概要 l 注⽬トピック ▌話さないこと l レポート内で⾏われた実験の詳細 l レポートの結果に基づいたプラクティス 4

State of DevOps Report とは ▌Google の DevOps Research and Assessment（DORA）チームが毎年公開している DevOps や開発⽣産性にまつわる年次レポート ▌規模、業界、地域を問わず世界中の組織からアンケートを募り DevOps のパフォーマンスに ついて分析 l 2023 年度レポートは 10 ⽉に公開 l 36,000 ⼈以上からアンケートが集まった l昨年⽐で 3.6 倍︕ 5

2023 State of DevOps Report の概要 個⼈的に⼤きく 3 つのトピックがあった ▌Goodhart の法則を理解する ▌ソフトウェアデリバリーパフォーマンス ▌Key findings l ユーザーを重視する l コードレビューの⾼速化でソフトウェア・デリバリーのパフォーマンスを向上 l質の⾼い⽂書化で技術⼒を増幅する letc … 6

2023 State of DevOps Report の概要 個⼈的に⼤きく 3 つのトピックがあった ▌Goodhart の法則を理解する ▌ソフトウェアデリバリーパフォーマンス ▌Key findings l ユーザーを重視する l コードレビューの⾼速化でソフトウェア・デリバリーのパフォーマンスを向上 l質の⾼い⽂書化で技術⼒を増幅する letc … Key findings は Zenn の⽅で紹介しています 7 👈 今回話すのはこの2トピック

Goodhart の法則を理解する ▌Goodhartの法則 : 測定が⽬標となると、それは良い測定基準でなくなる l メトリクスを良くすることを⽬的にしない l メトリクスを良くすることでチームのパフォーマンスを向上させることを⽬的にする ▌後述する Four Keys 指標の計測・利⽤にも当てはまる l リードタイム削減のために PR を作り直す、インシデントや不具合を報告しない など… 測定が⽬標となるとメトリクスハックが横⾏しかねない メトリクスは⼿段であり⽬的ではない︕ 8

Goodhart の法則を理解する ▌正しく指標を⽤いるための気をつけるべき落とし⽳ l 単純な⽐較を避ける l メトリクスの悪⽤ l 適切なメトリクスの選択 l 意義あるメトリクスの重視 9

Goodhart の法則を理解する ▌正しく指標を⽤いるための気をつけるべき落とし⽳ l 単純な⽐較を避ける 異なる環境や背景を持つプロジェクトを単純に⽐較するのは適切ではない ➜ Web と Mobile︖ クラウド と オンプレ︖ エンタープライズ向け︖ 提供すべき(したい)価値も多種多様 10

Goodhart の法則を理解する ▌正しく指標を⽤いるための気をつけるべき落とし⽳ l メトリクスの悪⽤・ハック メトリクスが良くなるように恣意的に⾏動 ex. PR を開いてから時間が経ったので⼀旦クローズして再び PR 作成 ➜メトリクスをよくすることが⽬的ではない 11

Goodhart の法則を理解する ▌正しく指標を⽤いるための気をつけるべき落とし⽳ l 適切なメトリクスの選択 ⼀つのメトリクスだけに依存するのは避ける ある指標が良くても他の指標は悪いこともある、逆も然り 12

Goodhart の法則を理解する ▌正しく指標を⽤いるための気をつけるべき落とし⽳ l 意義あるメトリクスの重視 ⼈は測定しやすいものを測定しがちで、最も意味のあるものを測定しない 測定しやすさだけでなく、そのメトリクスが持つ意味や価値に注⽬することが重要 l ただし、測定しやすいところから始めるのも⼤事 💪 13

Goodhart の法則を理解する ▌まとめ l 開発組織のパフォーマンスを測定する際に、銀の弾丸となる指標は存在しない l チームに合った複数のメトリクスを⾒定め、それらを多⾓的に評価していくべき 14

ソフトウェアデリバリーパフォーマンス ▌毎年恒例の Four Keys 指標に基づいた組織のパフォーマンス調査結果 ▌Four Keys とは l 変更のリードタイム(Change lead time) l デプロイの頻度 (Deployment frequency) l 変更障害率 (Change failure rate) l 失敗したデプロイメントの回復時間 (Failed deployment recovery time) 15

ソフトウェアデリバリーパフォーマンス ▌毎年恒例の Four Keys 指標に基づいた組織のパフォーマンス調査結果 ▌Four Keys とは l 変更のリードタイム(Change lead time) l デプロイの頻度 (Deployment frequency) l 変更障害率 (Change failure rate) l 失敗したデプロイメントの回復時間 (Failed deployment recovery time) 16 お気づきでしょうか…

ソフトウェアデリバリーパフォーマンス ▌毎年恒例の Four Keys 指標に基づいた組織のパフォーマンス調査結果 ▌Four Keys とは l 変更のリードタイム(Change lead time) l デプロイの頻度 (Deployment frequency) l 変更障害率 (Change failure rate) l 失敗したデプロイメントの回復時間 (Failed deployment recovery time) 17 復元時間(Time to restore) から変更されています…

ソフトウェアデリバリーパフォーマンス ▌なぜ 復元時間 が 失敗したデプロイメントの回復時間 に変更された︖ l 「ソフトウェアの変更による障害」と「他の要因による障害」とを区別することができなかった l 復元時間 "Time to restore" は "MTTR" として略されていた l これは "Mean Time To Recovery" か "Median Time To Recovery" かで混乱を招くため ▌復元時間(Time to restore) を⾒かけたら 「最新のレポートでは失敗したデプロイメントの回復時間だが︖」 と⼼の中でドヤりましょう 😎 18

ソフトウェアデリバリーパフォーマンス ▌Four Keys 指標に基づいた毎年恒例のパフォーマンス調査結果 19 変更リードタイム デプロイ頻度 変更障害率 失敗した デプロイメントの回復時間 2023年の調査結果 (レポート P.12 より引⽤)

ソフトウェアデリバリーパフォーマンス ▌前年、前々年との⽐較 ▌2023年では Elite の組織が増加 l アンケートの回答形式に変化が あったことが要因︖ l 純粋な⽐較はできないので 参考程度に 20 State of DevOps Report 2022 より作成

その他のトピック ▌AI の調査はまだ初期段階 ▌殆どのタスクにおいて 過半数が重要でないと回答 ▌個⼈的には今回の結果は 今後⼤きく変わると感じる 21 AIの重要性についてのアンケート(レポートP.26より引⽤)

まとめ ▌Goodhart の法則を理解しておこう l 指標の測定を⽬標としてはいけない l 複数の指標を多⾓的に分析してアクションを考える ▌ソフトウェアデリバリーパフォーマンス l 「復元時間」 が 「失敗したデプロイメントの回復時間」 に⾒直された l Elite に属する組織が⼤幅に増加したが、アンケート項⽬の変化があったため 純増とはいえない ▌今年は AI について⼤きなトピックは無かった ▌その他のトピックが気になったら原著を読んでみてください︕ 22

Appendix ▌2023 State of DevOps Report ▌State of DevOps Report 2023 のまとめ ▌ 2023 年の State of DevOps Report: 組織⽂化の重要性 ▌エリート DevOps チームであることを Four Keys プロジェクトで確認する 23