📗

開発の生産性を計測するためにFour Keysを学習する

2024/10/15に公開

はじめに

ここ数年、私が所属している開発組織では開発の生産性向上をテーマに開発体制のアップデートを行ってきました。感覚としては生産性向上しているように思いますが、指標を明確に持って活動方針を考えていきたいと思い、生産性を測る指標としてFour Keysを学習しました。
 本記事では、学習の過程で得られた知見を共有します。

こういう人におすすめ

  • 開発の生産性を計測する指標に悩んでいる方
  • Four Keysについて調査中の方

Four Keysとは

Four Keysとは、DORAメトリクスとも呼ばれ、DevOpsチームがソフトウェアの開発・デリバリー・保守の有用性を計測するためのフレームワークです。

Four Keysはその名の通り、4つの指標で開発生産性を測ります。

大きく二つの能力を測る指標になっていて、上二つはサービスのデリバリースピードを、下二つはサービスの安定性を測るための指標になっています。

デプロイ頻度とは

新しいコードがプロダクション環境にリリースされる頻度を指します。
 これは開発チームの効率性と、変更を迅速に提供する能力を測定します。

変更のリードタイムとは

コードの変更が行われてからプロダクション環境にデプロイされるまでの時間を指します。
 これは、開発チームの敏捷性と、価値を素早く提供する能力を計測します。

変更失敗率とは

プロダクション環境へのデプロイ後に、障害や問題が発生する割合を指します。
 これは、リリースプロセスの質と変更管理の効果を測定します。

平均修復時間とは

システム障害が発生してから、サービスが復旧するまでの平均時間を指します。
 これは、システムの回復力と問題解決の能力を測定します。

なぜFour Keysで生産性を測るのか

これは上げた生産性を継続させるためだと私は考えています。

Four Keysの指標はどれも「組織の能力」に着目して設定されています。

「能力の高いエンジニアが在籍しているから開発スピードが速い」とか「品質保証のスペシャリストがいるから不具合が漏れ出しづらい」とか、そういった個々の熟練度ではなく、「デプロイ工程が自動化されているから事故も起きづらく一定の時間でデプロイできる」とか「E2EテストやUnitテストが整備されているから担当者が意識しなくても不具合が検出される」とか、そういった仕組みが整っていたほうが、生産性が安定して向上していくという考え方だそうです。

Four Keysで計測する前に知っておきたいこと

バッチサイズの代わりにデプロイ頻度

実際に計測するのはデプロイ頻度ですが、リーン手法によると、本来の計測尺度はバッチサイズ(一度に進める作業のサイズ)です。
 バッチサイズを削減することによって得られる効果は、サイクルタイムの短縮とフローにおける変動の低減、フィードバックの高速化、リスクと諸経費の低減、効率・モチベーション・緊急性の認識の向上、コストとスケジュールの膨張の抑制だと言われています。
 ただし、ソフトウェアの場合は目に見える商品が存在しないことがあるため、バッチサイズを測定してその結果を伝えるということが難しい。そのため、計測も容易で変動も小さいデプロイ頻度を計測指標としているそうです。

変更のリードタイムには開発工程以前の時間を含まない

変更のリードタイムに要件定義の時間は含まれません。「リードタイム」と聞くと、顧客のリクエストからそのリクエストが満たされるまでの所要時間を思い浮かべがちですが、一口に「リードタイム」といっても二つの部分に分けられます。

  1. 製品や機能の設計と検証にかかる時間
  2. その製品や機能を顧客に納品するための時間

1に関しては、多くの場合、所要時間の計測開始地点が明確でない上に、似たような製品開発でも工程の変動が非常に大きいという問題があります。
 2に関しては、実装、テスト、デリバリの所要時間、は計測が比較的容易で変動も比較的小さい傾向があります。

だから2だけ計測するようです。

変更失敗率の「失敗」の定義

「失敗」の定義は、製品ごとに定義する必要があります。

変更によってシステムがダウンした場合は明らかに失敗ですよね。

しかし、一時的なパフォーマンスの低下は失敗でしょうか?ユーザーからの問い問い合わせが増えれば失敗でしょうか?ちょっとしたレイアウトのズレは失敗でしょうか?

自分たちが開発している製品にとって何が「失敗」にあたるのか、失敗のパターンを列挙しつつ、定義を決めていく必要があります。

おわりに

Four Keysを学習する際、「LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する」と「エンジニア組織を強くする 開発生産性の教科書 ~事例から学ぶ、生産性向上への取り組み方~」の2冊を参考にしました。
 どちらも興味深かったですが、個人的には前者の本が開発組織の在り方に関する考え方が書かれていたので面白いと感じました。

Thinkingsテックブログ

Discussion