はじめに
この投稿はZOZO アドベントカレンダー２０２２#3 5日目の記事になります。
今回はFourKeysについて考察してみます。
そもそも何？
開発チームのパフォーマンスの測定にFourKeysの指標が使われるようになっています。
ただ、この４つの指標を追っていけば間違いないと流行に乗って何も知らずに、何も調べずに計測に走るのは極めて危険です。
そもそもFourKeysとは何か？
DevOps Research and Assesmentチームが実施し、6年間の調査・研究で確立された、ソフトウェア開発チームのパフォーマンスを示す4つの指標です。(調査は今でも続いています。２０２２年のレポートはこちら)
研究の成果が書籍「LeanとDevOpsの科学 テクノロジーの戦略的活用が組織変革を加速する」にまとめられています。
なので、FourKeysを理解するならこの本を読まなくてはなりません（せめて2章まででも）。なぜこの指標が良いのか、追っていけばチームがどのような状態になるのか？それを知らずに計測しても失敗するだけです。
そもそもチームのパフォーマンスってなんでしょうね？死ぬほど残業して、死ぬほどソース書けばいいんじゃないですかね。または、超スーパーマンになって速攻で素晴らしいソースコードを書けばいいんじゃないですかね。。。そう思っている方はこの本を読みましょう。
FourKeysが上がっていけば素晴らしいチームになれるので、いくらでもいつでも思い描いたサービスが展開できる、明日にでも理想のアプリができるんじゃないですかね。と思っている方もこの本を読みましょう。
ということで、まずはFourKeysが何で「ない」のかを整理します。
FourKeysって何でないか？望ましくない尺度とはなにか
- 「書いたコードの量」・・・当然ながら1,000行で書くより10行で解決するほうが望ましいのだから書いたコードの量を計測しても意味がないですね。
- 「ベロシティ」・・・ベロシティはキャパシティ計画（今週どのくらいできそうか？の計画）には使えるが、チームの生産性を表すものではないです。絶対的な数値ではなく、チーム依存の相対的な尺度になります。よって、ベロシティを尺度としてしまうと、見積もりの水増しや、他チームとの恊働を犠牲にするなどが起こる可能性があります。
- 「リソースの利用率」・・・いつでも開発メンバーが１００％の時間タスクを割り当てられているのが最大の数値になります。リソース利用率を指標にしてしまうと、予想外の仕事や、計画変更、改善作業を入れる隙間がなくなります。
ではなにを基準に計測すればいいのか？を考えるための条件を考えてみます。
FourKeysとは何か（望ましい尺度とはなにか）？
- グローバルな成果にフォーカスを当て、かつチーム同士が競争もしくは対立するような状況を防ぐこと
- 生産量ではなく、成果にフォーカスを当てること
これらを満たす指標を検証・研究していった結果、研究チームが導き出した結論が以下の４つの指標になるわけです。
各項目の意味
１． デリバリのリードタイム
顧客のリクエストからリクエストが満たされるまでの所要時間です。
ただし、設計と検証にかかる時間まで含めてしまうと計測をいつはじめるか？という問題があり、変動が非常に大きく計測できないので、顧客に納品するための時間（実装、テスト、デリバリの所要時間）を計測することになります。
２．デプロイの頻度
バッチサイズ（一度に進める作業のサイズ）を計測したいところですが、ソフトウェアでは計測が難しい。
ソフトウェアのデプロイから本番稼働までなら計測可能なのでそれを指標とします。
３．サービス復旧の所要時間
「パフォーマンスを改善したチームは、安定性を犠牲にして改善したのか？」を研究した結果、安定性も確保されていたことから安定性も指標とします。ただし、失敗しないということは不可能なのでいかに迅速に復旧できるか？というところを指標とします。
４．変更失敗率
調査の結果、パフォーマンスと安定性・品質はトレードオフの関係にはないことがわかったそうです。ハイパフォーマンスな組織はどちらも安定しています。よって失敗率も計測します。
デリバリのリードタイム・デプロイの頻度とサービス復旧の所要時間・変更失敗率の両方を取るということ
この２種の尺度を両取りするということはどういうことか？少なくとも以下のような開発の仕方はNGということになりますよね。
「今が大事な時期だからテストやリファクタリングはリリース後に時間のあるときに。」
「多少ソースが汚くても・・・時間もないし」
「セキュリティ的なものを考えておきたいけど、まだリリース前だから後にしよう」
t_wada さんの「質とスピード」ではこのあたりが超詳細に説明されています。必読です。
テストもリファクタリングもセキュリティも妥協ができません。むしろ妥協しなくてもいい状況に開発チームを持っていく必要があります。
チームメンバーの学習にもコストもかける必要があるでしょう。
できますか？？？？？いや、やるんです。
デプロイのリードタイムと頻度を上げていくならなにを目指すことになるのか？
開発チームのパフォーマンスの計測に「ソースコードの量」でも「リソースの利用率」でも「個人の力量」でもなく、「デプロイのリードタイム」と「デプロイの頻度」が掲げられています。
これを突き詰めるためになにをする必要があるか？
極限、毎日、いや一日に何度もリリースすることになりますよね。開発を朝はじめて遅くても夕方にはリリースしているんです。
この機能は見積もりが2ヶ月だぞ？どうやって？とか思いますよね。
そうなんです。リーダーがメンバーにタスクを割り当てて「じゃあ、見積もり通り2ヶ月後には完成してリリースね」なんてやり方では到底到達できないんですよ。
2ヶ月という問題もそうですが、明日も、明後日も次の日も毎日リリースするなら毎日リーダーがメンバーにタスクを決めて割り当てますか？リーダーもメンバーも疲弊してしまいそうですよね。
なので、FourKeysというのはただ単に開発のパフォーマンスを、開発の速度を上げるだけの話ではないのです。
開発組織の文化からプロダクトの企画、設計、開発、リリース、セキュリティ、リリース後の顧客の反応、運用、リーダー、働き方など全ての側面を変えていかなければならないということです。
それも毎日リリースしていく以上、一回変えればいいわけではない。頻繁に状況によって変えていくサイクルを作っていかなくてはならないのです。
なぜ毎日リリースするのか？
結局、ここの疑問にいきつきますよね。
そこまでして、なぜ毎日リリースするのか？
FourKeysでは生産量ではなく、成果にフォーカスを当てています。
早く顧客に製品を届けるだけではない、早く顧客から反応を得て、顧客から学習し、次の戦略や仮説を立てて、その成果をさらに顧客に届けるのです。
このサイクルをできるだけ早く回すのが目的です。
つまり、リーンの考え方。アジャイルやDevOpsにもつながる考え方ですね。
それもそのはずで、この研究はアメリカの著者たちのものですし、InfoQの記事によると、２０１７年の調査対象の５４％は北アメリカ、ヨーロッパとロシアは27%でアジアで１０％だそうです。
そのアメリカでのアジャイルの普及率は「全面的に取り入れている」「一部取り入れている」が80.8%です。（ちなみに日本は32.7%/DX白書２０２１ P026）
はじめにの章でも「「ウォーターフォール型」の開発手法を使い続け、技術変革には着手したばかりという組織にも、・・・応用できる」とあるので、もう前提として「ウォーターフォール型」の開発手法を使い続けるだけで変わろうとしない組織は問題外としているということです。
そもそも書籍のタイトルが「LeanとDevOpsの科学」ですから。
まとめ
リーンとかアジャイルとかできるチームを目指しますか？
その気がない場合、FourKeysを計測していっても、「今回も数値変わらないねぇ」で時が過ぎていくだけなのでFourKeysで計測することは全くおすすめしません。
リーンとかアジャイルとかできるチームを目指すのであれば、リーンやアジャイル、DevOpsの様々なプラクティスを学び、徐々に取り入れていくことで数値が上がっていくことが、チームが組織が成長していく様子が可視化できると思います。
徐々にでいいんです。チームの進化を計測していくためにFourkeys使っていきましょう！