改めて「four keys」をきちんと理解する

2024年11月20日 16:18

はじめに

開発生産性というと「four keys」を計測してそれが高くなるようにすれば良いと考えがちな人がいます。
「four keys」はFindy Team+やGitHub・Google Cloud・Datadogなど計測ダッシュボードや計測のためのAPIが使えるのでそれを使えば良さそうです。
以上の話は間違ってはいませんが、そもそも「four keys」が何をねらいにして作られたかをきちんと解釈する方が良いと思うのでその話をします。

「four keys」は誰が作った？

DORA (DevOps Research and Assessment) という研究組織です。
DORAは、ソフトウェア開発とデリバリーの状況改善のための能力を調査・検証している研究組織です。2018年にGoogle Cloudが買収したためいまはGoogle Cloudの一部となっています。

「four keys」の定義

ここで説明するまでもないと思うのですが、こちらです。
最近は「Elite」というPerformance levelの項目が追加されています。「High」のままで止まっている組織も一部みられますね。

Change lead time (変更のリードタイム)
- commit から本番環境稼働までの所要時間
Deployment frequency (デプロイの頻度)
- 組織による正常な本番環境へのリリースの頻度
Change fail rate (変更障害率)
- デプロイが原因で本番環境で障害が発生する割合 (%)
Failed deployment recovery time (サービス復元時間)
- 組織が本番環境での障害から回復するのにかかる時間

わかりました。では「four keys」を上げていけばいいですか？

間違っていませんがもう少し前段の背景を知る方が良いです。
DORAは毎年レポートを作成しており、そこでさまざまな研究結果の共有・仮説の検証をしています。
そもそもこれら「four keys」はどのように導き出されたのかというと、ソフトウェア開発とデリバリーの状況を改善するのに効きそうである各変数 (=指標・要因と言い換えてもよさそうです) をいくつか設定したうえ、それらがどう作用するのかモデルを作成しながら(=モデリングによる仮説)、統計的分析によりそれが正しいかを検証しています。
つまり、元のモデルが何であり、そのモデルで設定した各変数がどう作用しているのかを理解することではじめて「four keys」の意図がわかると思います。

DORAモデルv1

上述したモデルというのがDORAモデルというものです。
わかりやすくするためあえて古いほうのDORAモデルv1から話します。
DORAのモデルは最近v2にアップデートされています。後ほどv2に関しても説明します。

現在公式ページではv2の表記になってしまっているため。こちらの記事からありがたく引用させていただきます。

「four keys」はどう使うのか

様々な変数があるなか、技術だけでなくプロセスや文化も含めた「Technical Capabilities」を図の一番左の通りに設定されました。
それらの変数は結局のところ、「Shift left on security」と「Continuous delivery」に相関があります。

「Shift left on security」とはセキュリティレビューやテストを開発の早期に組み込むことです。セキュリティ上の欠陥を早期に特定し、より早く適切な修正ができます。その結果、ポストプロダクションでの欠陥が少なくなり、修正作業やアーキテクチャの変更を減らすことができます。

「Continuous delivery」は継続的デプロイメントに加えて継続的にリリースを行うためのプロセスも含みます。これは後述する「Generative organizational culture」にも密接に関係します。

「Generative organizational culture」とは、「生産的組織文化」といい、Westrum博士が提唱する3つの組織モデルのうち、創造的なパフォーマンス志向の組織のことを指します。下図の一番右の項目が該当します。

この「Generative」を目指すことで「four keys」をはじめとした「Software Delivery Performance」にも「Well-being」にも効いてくることになります。
これらの項目について調査することは、アンケートによる回答が有効だと述べられています。

「Streamlined change approval」とは、「変更承認の効率化」といい、変更承認を開発のプロセスの中で行い、良くない変更は早期に発見・修正されるべきということです。効率化を進めていくことで「Software Delivery Performance」にも「Well-being」にも効いてくることになります。

以上の「Shift left on security」・「Continuous delivery」・「Generative organizational culture」・「Streamlined change approval」が「four keys」のもとなのです。つまり、この4つのケイパビリティを定量的なパフォーマンスとして予測することができるのが「four keys」なわけです。
そのため、「four keys」をただ計測して評価するためのベンチマークではなく、パフォーマンスを計測し改善するためにどのケイパビリティを改善・向上させるかのアクションにつなげるために利用するのです。

もちろん職種によってこの「four keys」の解釈を少し変えなければならないこともあるでしょうし、そもそも対象となるkeyに該当するものが存在しないこともあるでしょう。
その時は、もともとのケイパビリティを見つめながらチームや組織に必要な指標を設定するべきです。

各ケイパビリティの定義はこちらから参照できます。

outcomeについて

outcomeとして設定しているのは、「Organization performance」と「Well-being」です。

「Organization performance」については「commercial」と「non-commercial」の分類がされています。

前者に関しては営利上のパフォーマンスを指し、DORAでは「Profitability, Productivity, Market share, Number of customers, Quantity of products or services」が含まれるとしています。会社によって何を営利上のパフォーマンスとするかは異なると思いますので、自分の会社が追っている売上に関する指標やKPIを参考にすると良いかもしれません。

後者に関しては非営利上のパフォーマンスを指し、「Operating efficiency, Customer satisfaction, Quality of products or services provided, Achieving organization or mission goals」が含まれるとしています。

「Well-being」については「Less deployment pain, Less rework, Less burnout」としています。

「Less deployment pain」の「deployment pain」とは、エンジニアがコードを本番環境にプッシュする際に感じる恐怖や不安の尺度です。デプロイが苦痛になってしまうと組織上のパフォーマンスを落としてしまいます。図を通して、逆を言えば、継続的デリバリー体制がしっかりしており、組織文化や変更承認も効率化されているとこの「Less deployment pain」は減少し、組織上のパフォーマンスを上げることにつながります。

「Less rework」の「rework」とは手戻りや計画外の作業のことを指します。緊急のデプロイやパッチ修正、監査対応など多岐にわたります。こちらも同様にこのような計画外の作業が増えると組織上のパフォーマンスを落としてしまいます。図を通して、逆を言えば、継続的デリバリー体制がしっかりしており、組織文化や変更承認も効率化されていると計画外の作業量は減少し、組織上のパフォーマンスを上げることにつながります。

「Less burnout」の「burnout」とは燃え尽き症候群といい、過労やストレスによって引き起こされる肉体的、精神的、感情的疲労を指します。この燃え尽き症候群のレベルが下がることでも組織上のパフォーマンスが上がっていきます。

ここまでのまとめ (結局それぞれがどう関係しているの)

・「Software delivery performance」を示す定量的な指標である「four keys」は「Shift left on security」・「Continuous delivery」・「Generative organizational culture」・「Streamlined change approval」の4つから設定されたものである
・その4つは複数の技術的なケイパビリティから構成されている
・「four keys」は「Organization performance」に影響を与えるが、「Well-being」には影響を与えない
・「Continuous delivery」・「Generative organizational culture」・「Streamlined change approval」は「Well-being」に影響を与える
・「Well-being」は「Organization performance」に影響を与える

ということです。念を押して伝えておきたいことは、「four keys」をあげたからといって「Well-being」は改善しないということです。「four keys」の前段にある継続的デプロイメントや組織文化を変えていくことで「Well-being」は向上します。
組織のパフォーマンスを開発者の目線から定量的に判断するうえでは「four kyes」は有用ですが、組織の「Well-being」を判断するなら継続的デプロイメントや組織文化を見ていく必要があるということです。

私たちはヒトです。組織のパフォーマンスも大事ですが、働く上での満足度や幸福度合いも大事だと思います。「four keys」だけにとらわれず開発者体験がよくなるように何ができるか考えることも大事です。

新たな指標、「信頼性」について

2022年からソフトウェアデリバリーのパフォーマンスである「four keys」に加えて運用パフォーマンスである「信頼性」の重要性が示唆されました。
「信頼性」自体は広い意味を持つ用語であり、ユーザーの期待に応えるチームの能力を指します。ソフトウェアサービスの場合、可用性、レイテンシ、正確性の側面、またはユーザーエクスペリエンスの整合性と品質に影響を与えるその他の特性の側面を指す場合があります。
DORAは信頼性を、可用性、パフォーマンス、正確性などの尺度に関し、定められた目標をサービスが達成している程度と定義しています。

DORA2021の調査では、以下の項目について付け加えられたうえ評価がされました。
・ユーザーへの対応に関して信頼性を定義する
・SLI/SLO指標フレームワークを採用して、エラーバジェットにより作業に優先順位を付ける
・自動化を利用して、手作業と、仕事の妨げになるアラートを削減する
・インシデント対応のプロトコルと、対応準備をテストするための演習を定義する
・ソフトウェアデリバリーのライフサイクル全体にわたり、信頼性に関する原則を取り入れる（「信頼性のシフトレフト」）
これにより、可用性・レイテンシ・パフォーマンス・スケーラビリティがより広く反映されるようになりました。
調査の結果、ソフトウェアデリバリーのパフォーマンスだけでなく、この「信頼性」も重視する場合、より組織上のパフォーマンスにおいて優れた結果が得られたということです。

逆を言えば、「four keys」だけではなくてベースとなる「信頼性」がないとソフトウェアデリバリーパフォーマンスひいては組織上のパフォーマンスに結びつきづらいということが述べられたわけです。

この「信頼性」の定義は会社によってまちまちだと思われます。上記の内容を踏まえてソフトウェアの「信頼性」をどう定義し、それに対してどういうプロセスで改善していくか検討するのがよいでしょう。

DORAモデルv2

いよいよv2モデルの話です。
これまでのv1モデルの内容と、新たな指標である「信頼性」もふまえたうえで新たなモデルが作成されました。

v1と比較すると、大まかには以下の点が違います。

技術的ケイパビリティがグルーピングされた

「Climate for learning」・「Fast flow」・「Fast feedback」の3つで構成されるようになりました。
・Climate for learning: 学習風土とは、継続的な改善と知識共有の文化を育む組織内の雰囲気であり、学習が成長と成功に不可欠な戦略的投資と見なされるということ
・Fast flow: 開発チームが「flow」の状態、つまり成果をあげることに集中できている状態で、スピーディーに高品質なソフトウェアを提供できること
・Fast feedback: ソフトウェアデリバリライフサイクル全体を通じて、チームが迅速かつ実用的な洞察を得られるようにする包括的なアプローチのこと。チームが行っている変更に自信を持つことで、より迅速なイテレーションと高品質なソフトウェアを実現する

この3つの項目の中に各ケイパビリティが分類されるようになりました。

信頼性に関する項目が追加された

前述した通り、新たな指標として「信頼性」がモデルに反映されるようになりました。
パフォーマンス部分にて既存の「Software delivery performance」である「four keys」はそのままで、「Reliability」が追加されています。

Reliabilityを表す指標としてSLI/SLOに焦点を当て、以下の4つが設定されました。
・Measurement coverage: どれほどの重要なサービスがSLIをもっているか、どれほどフルカバレッジに近づいているか
・Measurement focus: SLIの定義がどれほどユーザーが経験するシステムの挙動を反映できているか、ユーザー中心であると言えるか
・Target optimization: SLOがユーザーのケイパビリティを反映した適切な数値になっているか
・Targer compliance: SLOが一貫して達成されているかどうか、加えて組織の人々がそれを確認できるかどうか

前半の2つは「Measurement」としてSLIに着目し、後半の2つは「Target」としてSLOに着目しています。
Code Modelのページ上ではこれらが定量的な指標として示されているわけではありませんでしたが、まだこのモデルはアップデートされていくものなので今後更新があるかもしれません。
会社でSLO/SLIの定義はそれぞれ違うと思うので、改めて「信頼性」に関する理解と上記項目について考えてみるとよいでしょう。

各ケイパビリティ・パフォーマンス・アウトカムへの矢印がなくなった

この点がv1とは違う大事なところだと感じています。v1の図では個々に矢印があることで、

・図が読みづらくなる
・個々のチームの強みやチャンスといった事情が考慮されず、有用性が限定的である指摘
・この矢印の位置関係や影響の大きさが、年ごとに異なることがわかってきており、標準的なものと解釈するのが難しくなった

といった問題があったそうです。そのためもう少し粗い粒度にし、ケイパビリティからパフォーマンスを予測でき、パフォーマンスからアウトカムを予測するといった解釈に変更されました。

そのため、パフォーマンスの部分でよくないところがあれば、前段となるケイパビリティの項目を参照してどこに問題があるか特定し改善するプロセスを作っていきましょう。
もちろん、(v2モデルでは「限定的」ということで扱わなくなりましたが) v1モデルの各ケイパビリティとの相関関係を参考にすることが有用である組織もあると思います。

今後のアップデートについて

このv2モデルはDORA2024のレポートがなされる前に決定したものです。今年のレポートを受け、また来年以降はこのモデルが変わるかもしれません。引き続き動向を追っておきたいですね。

おわりに

「four keys」が高くなるように行動することはとても良いことです。
しかし、「four keys」自体をハックして高くなるようにしたり、ただそれだけを追求することは違います。手段と目的が逆転しています。まさにグッドハートの法則 (計測結果が目標になると、その計測自体が役に立たなくなる)の話です。

モデルの内容を参照しながら、ケイパビリティや文化で改善できるところがないかを考え、継続的な改善プロセスとして使うべきであり、「four keys」だけでなくチームや組織に合った指標を色々と検討すべきです。
また、それに必要なコミュニケーションも部署・チームを跨いで積極的になされると良いと思います。

また、組織やチームは常に一定ではありません。変わります。もちろん「four keys」を出しているDORAの思想も常にユーザーの意見を取り入れながら変わっています。最新のレポートは英語ですが面倒くさがらずに一次情報からきちんと理解するのがよいでしょう。