Four Keysを用いた開発生産性計測 / 改善のアンチパターンと、本質的な改善のために必要な「なぜ？」

Agile Journeyをご覧のみなさん、はじめまして。株式会社リンクアンドモチベーションの川津（@KawatsuYusuke）です。こちらの記事では主に私たちがFour Keys メトリクスを元に、開発生産性向上を目指した活動に関する話題についてお伝えします。

と言っても、『LeanとDevOpsの科学』をはじめ、Four Keysの運用に関するトピックはすでに多く語られています。また、Four Keysは便利なメトリクスであるがゆえに、ときに「Four Keysを改善する」という手段が目的化してしまうことがあります。本稿では主にこれから開発生産性向上に取り組もうとしている方に向けて、私たちの取り組みと、体験したアンチパターンをもとに、「Four Keys改善の取り組みには "なぜ？" が大事」についてお伝えします。

私たちの開発生産性向上のはじまりと、目指すべき状態の設定
Four Keys改善を目的化しないために必要な「なぜ？」
- リードタイム改善が「なぜ必要なのか」を考える
- なぜ、デプロイ頻度が「高いほどいい」と考えてしまったのか
理想的な状態を追求するために必要な「なぜ？」
メトリクスと数値の本当の意味
- デプロイ頻度が低いとなにが問題なのか？
- リードタイムが短いと、チームはなにが嬉しいのか？
4種のメトリクスは連動している
- ビジョンを明確化することから改善が始まる
関連記事

私たちの開発生産性向上のはじまりと、目指すべき状態の設定

組織人事コンサルティングを主業とする弊社が、サービスを内製化するべく、SaaSプロダクト開発の組織を立ち上げたのは、およそ５年前のことです。私が所属する SRE ユニットは３年前に結成され活動を開始しました。

生産性向上に関する活動はこのSREユニットが主導し、以下図のように複数のチーム・プロダクトを跨ぎ横断的に行っています。

さて、Four Keys メトリクスとは『LeanとDevOpsの科学』で示されているように、以下の４つの指標（太字部分）から構成されます。

「速度」に関する指標
- デプロイ頻度
  - 本番環境へのデプロイの頻度
- リードタイム (※正確には “Lead time for changes”)
  - ひとつのPull RequestのFirst commitから本番へデプロイされるまでの所要時間
「安定性」に関する指標
- MTTR（平均復旧時間）
  - 本番環境での障害から回復するのにかかる平均時間
- 変更障害率
  - デプロイが原因で本番環境で障害が発生する割合

これら指標はGitHubなどの開発ソースから計測可能ですが、継続的に観測し、改善活動に活用していくためには自動的に計測＆可視化する仕組みが必要になります。ファインディ社の提供するFindy Team+といったサービスを使用するのも手ですが、私たちは以下の仕組みで計測し、自前でダッシュボードの仕組みを構築しています。

ご覧のとおり、既存のツールを組み合わせたシンプルな仕組みです。「なるべく作り込みをしない」「誰でも触れる技術に限定する」ことに主眼を置き、可能な限り保守性の高い仕組みを目指しました。

計測された指標はこのサンプルのような形でダッシュボードに可視化されます

計測・可視化の仕組みに必要以上のコストを投じないのは、メトリクスを取得することは目的ではなく、改善活動の前提でしかないからです。大事なのはメトリクスをもとに、どのように改善活動をデザインするかです。私たちの場合、改善活動を以下の大きなサイクルで推進しています。

メトリクスを計測する
開発生産性向上に向けての最大のボトルネックである改善対象メトリクスを決める
改善後のメトリクスにおけるゴールを決める
改善後にどのような開発者体験やチーム・現場の姿を目指すか？を決める
改善の具体策を決めて実践する
再度メトリクスを計測し、結果を振り返る

なかでも、私たちがとくに重視したのは（4）です。 Four Keysに基づく改善活動においては、「メトリクスの値を向上させる」が目的化してしまい、本来追求するべき「改善後のチームのあるべき姿」が忘れられがちです。次章では私たちが改善活動のなかで実際に直面したアンチパターンを説明します。

Four Keys改善を目的化しないために必要な「なぜ？」

リードタイム改善が「なぜ必要なのか」を考える

「リードタイム」を改善対象のメトリクスとして生産性向上の活動を行っていた時のことです。当時のリードタイムはおよそ7日程度で、SREが主導し「リードタイム ≦ 3日」を目標に改善施策を講じ、開発チームに実施を「依頼」していました。

その後、開発チームのあるメンバーにヒアリングをしたところ「自分のPull Request（以下、PR）のリードタイムを3日にした」と言います。しかし、そのメンバーが担う開発は規模が大きく、リードタイムを3日に抑えることはかなり困難です。どのようにしてそこまでのハイパフォーマンスを実現したのか質問すると、「古いPRをクローズして、新しいPRに作り直しました」と答えます。

まるで笑い話のようですが、当時はこの開発者メンバーだけでなく、私自身もなぜこのような本末転倒な問題が生じるのか、根本が理解できていませんでした。

なぜそのような事が起きたのでしょうか。それは開発者の誰もが「リードタイムを改善する事の目的」を見失っていたからに他なりません。

リードタイムとは一体何か？なぜリードタイムを改善すべきなのか？改善したら、チームは(何が嬉しいのか？こうした本質的な問いかけが必要だったのです。

なぜ、デプロイ頻度が「高いほどいい」と考えてしまったのか

また別のプロダクトチームで「デプロイ頻度向上」に取り組んでいたときのことです。

そのチームでは当時、デプロイは2週に1度（0.5 回 / 週）でした。「パフォーマンスが低い」という漠然とした課題感から改善に着手し、「デプロイ頻度1回 / 日（5回 / 週）」を目標としました。この目標は彼らにとって「チームのパフォーマンスが高い状態」のはずです。

その後、チームは精力的に活動し、目標の一歩手前である「デプロイ頻度〜4回 / 週」まで到達します。しかし、チームに改善の手応えを聞いてみると「リリースにまつわるコストが増えて大変……」と答えます。

「デプロイ頻度を上げること」が目的化してしまったがゆえに、こうしたギャップが生じたのです。最終的にこのチームでは、「デプロイ頻度は2回 / 週」が最適である、と目標を修正しています。

理想的な状態を追求するために必要な「なぜ？」

この2つの問題は「メトリクスを上げること」が目的となってしまったことが原因となり生じています。

Four Keys計測において、チームのパフォーマンスが高ければ、メトリクス上の値も良質なものになるでしょう。しかし、その逆「メトリクスが良好ならばパフォーマンスも良好か？」については、必ずしもそうとは限らないのです。先の2例のように、メトリクスはハックできてしまえるし、あるメトリクスを上昇させるためのコストがあまりに過大、などのバグが内包されているからです。

このような事態に陥らないために「目指すべき姿（あるべき理想）」を明確にするための「なぜ？」が大切だと、私たちはアンチパターンから学びました。

ここでいう「なぜ？」は以下の2つ存在します。

なぜ、メトリクス値が低いのか？ (何がメトリクス = 値を悪くしている原因か？)
メトリクス値が低いと、なぜ、いけないのか？ (本当の課題は何か？)

往々にして、（1）はきちんと考えられますが、（2）は見失いがちです。

メトリクス値とは、プログラムコードで言うところの「マジックナンバー」のように、その値が「何を表しているのか？」を理解しなければ、その数値の善し悪しを評価できません。

単純な数値の上下動として捉えるのではなく、開発組織の状態（課題）をイメージし、特定し、どういった開発環境を目指したいのか？を決めるための指標として活用するのが適切だと考えています。

メトリクスと数値の本当の意味

「メトリクス値はマジックナンバー」と表現しましたが、一般的に（※少なくとも弊社では）その値がどのような意味を持っているのか、具体例とともに説明したいと思います。

デプロイ頻度が低いとなにが問題なのか？

2012年のこちらの記事で「Amazonは1時間に1000回ものデプロイをする」というケースが紹介されているように、Four Keys が一般化する以前から「デプロイ頻度」という言葉や概念は見聞きされた印象があります。また、デプロイ頻度の高低≒生産性の高低と捉えてしまいそうになりますが、果たして本当にそう言えるのでしょうか。以降は例を交えて「デプロイ頻度の高低」がどのような意味を持つのか考えてみたいと思います。

まず、「デプロイ頻度が低い」状況を具体的に考えてみます。たとえば、下図のように複数の Feature（PR）をまとめて一度にデプロイをする状態は「デプロイ頻度が低い」と表現できるでしょう。

この状態の問題点は「バグが発生した際にまとめて切り戻さねばならない」ことです。

切り戻しは、直前のデプロイ (リリース) の状態に戻す方法が一般的で、とある commit hash (release tag) に切り戻しすればいいだけであり、作業コストの観点に限れば大した問題でないかもしれません。

しかし、実際には以下のような問題が考えられます。デプロイに含まれるPRの全開発者間（例 : 20 PR => 20 開発者）でコミュニケーションを取る必要があります。

あるFeatureに後方互換性のない変更が含まれる場合、単純な切り戻しでは機能しない可能性がある
Ruby on Railsなど、データベースのマイグレーションが含まれる場合、それ自体を先にロールバックしなければならない

また、これら問題を解決するために発生する開発者間のコミュニケーションも見逃せないコストです。一度のデプロイに複数のFeatureが含まれていれば、そのFeatureの数だけコミュニケーションパスは複雑化し、さらにコストが増加します。

こうした「デプロイ頻度が低い状態」が内包する問題を解決するためにコストを投じた結果、今度はMTTR (平均復旧率) が低下してしまいます。

また、仮に障害原因となったcommitが1件だけだったとしても、まとめて切り戻しされたその他、すべてのcommitも後日再度デプロイし直さなければならず、大変な手間を要します。

リードタイムが短いと、チームはなにが嬉しいのか？

「リードタイム」も、その意味と意義を、チームできちんと捉えるべき言葉です。リードタイムは「ある要求を受けてから機能をお客様に提供するまで」など、「ビジネス上のリードタイム」と錯誤されることがありますが、Four Keysメトリクスにおいては、以下図のように「コードがFirst commitから本番環境で稼働するまで」を意味します。

では、実際の開発において「リードタイム」はなにに影響を受けているでしょうか。下図をご覧下さい。

この図は上下のケース両方とも、同じ機能を「一括でデプロイ（リリース）する」「段階的にデプロイ（リリース）する」という異なる手法で開発しています。同じ機能をリリースしていますが、下のケースは３回デプロイ (リリース) しており、リードタイムは小さいということになります。

つまり、リードタイムを左右する要素は「PR」といえます*1。

こうした前提において、「リードタイムが短い」とは「PRが小さい」と言い換えることができるでしょう。では、リードタイム（≒PR）が短いと、どのような意味があり、チームはなにが嬉しいでしょうか。

すぐに思いつくメリットとして、以下が挙げられます。

PRのレビューが正確にできるようになり、設計・実装の精度が上がる
PRごとのテスト範囲が明確になり、結果的にテスト工数が大幅に減る＆必要なテストを確実に行いやすくなり品質が上がる
開発者間でリリース調整をしなくてよくなる
変更コード間の関連性 / 複雑性を考慮するコストが減る

このように、作業面のコスト低減だけでなく「短いリードタイム」は品質にも好影響を与えます。

「PRが増えるとレビュー回数が多くなるのでは？」という疑問があるかもしれませんが、レビューすべきコードの総量は変わりません。前述の通り変更間の関連性を気にかけるコストが小さくなり、その分、ひとつのPR当たりの設計・実装が明瞭になり、レビュアーは細かいレビュー・指摘が可能になります。

また、テスト範囲も明確になり、「影響範囲が見えないから全部テストしよう……」という、大きなPRにありがちな問題を回避でき、必要最小限のテストに収めることができるようになります。

加えて、PRを小さく分割することで「リリース調整の手間から解放される」メリットもあります。

長い時間をかけて開発された巨大なFeatureは、「テスト → リリース」までの期間も長くなりますが、この間に別の巨大なFeatureも並行して開発されている、以下のようなブランチがあったとします。

この場合、以下のような問題が起きるリスクがあります。

Feature Aがmain（旧master）にマージされる
main（旧master）の変更をFeature Bに取り込む
取り込みの変更影響が見通せず、全テストをやり直しになる

つまり、このブランチング・リリースプロセスではコード間のコンフリクトの懸念から「Feature Aのリリースが完了するまで、Feature Bはテストを開始できない」となり、リリース日調整に大きなコミュニケーションコストが発生してしまいます。組織規模が大きくなり、並行開発が増えるほどに、このコストは増加していきます。

一方で、リードタイムが小さく、頻繁にリリースしている場合はどうでしょうか。以下図はRuby onRailsアップデート開発での例ですが、変更（新旧どちらのRails versionでも動くコード）をファイルの単位で細かくリリースします。