Slide 1

Slide 1 text

俺的 Four Keys 解釈

Slide 2

Slide 2 text

Four Keys とは 開発における要素のカテゴリ分けを行い、その要素がどのように開発者に影響し ているかを整理した中で Software Delivery Performance* に影響するものを 定量的に測ったもの ※ Software delivery performance とは、どれだけ performance ( 定義については後述 ) 高くソフトウェアを届けられるかの指標であり、実際 の企業の利益に結びつくものではない 開発における要素のカテゴリ DORA Capability Catalog どのように開発者に影響しているか DORA Core

Slide 3

Slide 3 text

Four Keys とは ❏ DORA Capability Catalog ❏ 開発に関わる分野を Technical / Process / Cultural の 3 つの軸を元 に、コードの保守性・ CI/CD・カスタマーフィードバック・ドキュメン トの質・組織文化の形成など 29 個のカテゴリに分けたもの DevOps capabilities

Slide 4

Slide 4 text

Four Keys とは ❏ DORA Core ❏ Capability Catalog の要素を、最終的な成果である組織成果への因果関係を整理したもの DORA's Research Program

Slide 5

Slide 5 text

再掲

Slide 6

Slide 6 text

Four Keys とは 開発における要素のカテゴリ分けを行い、その要素がどのように開発者に影響し ているかを整理した中で Software Delivery Performance* に影響するものを 定量的に測ったもの ※ Software delivery performance とは、どれだけ performance ( 定義については後述 ) 高くソフトウェアを届けられるかの指標であり、実際 の企業の利益に結びつくものではない 開発における要素のカテゴリ DORA Capability Catalog どのように開発者に影響しているか DORA Core

Slide 7

Slide 7 text

DORA Core における Software Delivery Performance の立ち位置 Four Keys とは

Slide 8

Slide 8 text

Four Keys の指標 Software Delivery Performance を計測するために当時 DORA が定義した実際 の定量的指標を 2020 年 9 月 23 日の Google Cloud のブログから抜粋 ❏ デプロイの頻度 - 組織による正常な本番環境へのリリース頻度 ❏ 変更のリードタイム - commit から本番環境稼働までの所要時間 ❏ 変更障害率 - デプロイが原因で本番環境で障害が発生する割合 ❏ サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間

Slide 9

Slide 9 text

Four Keys の指標 ( 最新版 ) 最新版である State of DevOps Report 2023 での Four Keys の表記 ❏ デプロイの頻度 - 組織による正常な本番環境へのリリース頻度 ❏ 変更のリードタイム - commit から本番環境稼働までの所要時間 ❏ 変更障害率 - デプロイが原因で本番環境で障害が発生する割合 ❏ デプロイ失敗時の復旧時間 - ソフトウェアの変更失敗から回復するのにかか る時間 ❏ インフラ・ネットワークなどの制御できない障害と、ソフトウェアの変更による障害を切り 離して考える

Slide 10

Slide 10 text

Software Delivery Performance への指標の追加 ❏ 2021 年に Software Delivery Performance に信頼性が追加されている ❏ これにより Software Delivery Performance = Four Keys + 信頼性となっている ❏ 原文では Reliability ❏ 信頼性は SLO を以下の軸で判断材料として用いている ❏ Coverage : 全体のうち何 % のシステムが SLO を設定しているか ❏ Fit : SLO はユーザ体験に紐付いているか ❏ Balance : 適切な値が設定されているか ❏ Compliance : SLO が日常的に運用されているか ❏ どのように上記を判断するかはまだ定義されていない

Slide 11

Slide 11 text

開発者生産性に対する考え方のアップデート 開発生産性は 1 つの指標では測れない 定量的な指標だけでは測れない 複数の指標を目的に合わせて多面的に分析する必要がある

Slide 12

Slide 12 text

開発者生産性に対する考え方のアップデート ❏ State of DevOps Report 2023 でも Four Keys のみを追いかけるのは意味 がないことを明示した ❏ 組織成果、は開発者の「満足度」と「生産性」と相関がある ❏ 満足度が生産性の先行指標になりうる ❏ ユーザに向き合う組織の方が開発者生産性が高い 2023年版 State of DevOps Reportの内容まとめ State of DevOps Report 2023 のまとめ 『LeanとDevOpsの科学』をきちんと解読する 〜Four Keys だけじゃ絶対もったいなくなる話〜 - Speaker Deck

Slide 13

Slide 13 text

SPACE フレームワーク ❏ 開発者生産性が Four Keys だけでは測れないので多面的に分析するフレーム ワークとして 2021 年に SPACE フレームワークが登場 ❏ 開発者生産性を測るための指標をディメンションで分けて整理したもの ❏ S : Satisfaction and well-being ❏ P : Performance ❏ A : Activity ❏ C : Communication and collaboration ❏ E : Efficiency and flow ❏ 各ディメンションに「個人」「チーム」「システム」の 3 つのデータソース ❏ 各ディメンションに最低 1 つの定性的な指標 The SPACE of Developer Productivity: There's more to it than you think - Microsoft Research

Slide 14

Slide 14 text

SPACE フレームワーク ❏ S : 自分の仕事、チーム、ツール、文化にどれだけ満足しているか ❏ 個人 : 難易度や量的な開発者満足度、必要なツールやリソースがあるか ❏ チーム : 自分のチームを勧めるかどうか ❏ システム : CI/CD などの開発フローへの満足度 ❏ P : 実装された機能やコードがどれほどのアウトカムを出したか ❏ 個人 : バグ消化数 ❏ チーム : 顧客満足度、機能使用率 ❏ システム : サービス稼働率、コスト削減 ❏ A : 業務を遂行する過程で完了した行動やアウトプットの数 ❏ 個人 : ドキュメント作成数、 PR 数、レビュー数 ❏ チーム : 消化したストーリーポイント、デプロイ頻度 ❏ システム : 変更障害率、オンコール対応数

Slide 15

Slide 15 text

SPACE フレームワーク ❏ C : メンバーやチームがどうコミュニケーションをとり、協力し合うか ❏ 個人 : 仕様ドキュメントの発見時間 ❏ チーム : オンボーディング時間・体験 ❏ システム : 仕様ドキュメントの発見時間 ❏ E : 活動がどの程度うまく調整されているか、継続的に進展しているか ❏ 個人 : 中断のない集中時間 ❏ チーム : ミーティング数、コードレビュー時間 ❏ システム : Velocity

Slide 16

Slide 16 text

開発者生産性に対する考え方のアップデート 実際に DORA Survey 2024 では Four Keys ではなく SPACE の指標をとっている ようなアンケート構成になっていた S P A C E

Slide 17

Slide 17 text

今後の Four Keys 界隈 ❏ DORA Core が 1.0 から 2.0 の制定に向けて議論が始まっている ❏ Performance が Software Delivery と Reliability で構成されている ❏ 「トランクベース開発」が廃止され、「小さな単位での作業」に置き換え ❏ Core 3.0 では「 Transformational leadership 」などの要素も入りそう

Slide 18

Slide 18 text

俺的言葉の定義 Software Delivery Performance + 開発者体験 = 開発者生産性 ⇒ 組織成果

Slide 19

Slide 19 text

まとめ ❏ 生産性とは「スループット」と「安定性」と「信頼性」 = Performance ❏ 変更リードタイムとデプロイメントの頻度による「スループット」 ❏ 変更失敗の割合と障害復旧時間による「安定性」 ❏ SLO による「信頼性」 ❏ Four Keys は指標の一つであり、それ単体では意味をなさない ❏ 評価や Four Keys の指標を上げることを目的には置かない ❏ 数値はハック可能な指標である ❏ チームやシステムを跨いで比較しない ❏ GSM フレームワーク* を意識する CI/CD Metrics with GSM Framework | Mercari Engineering