ソフトウェアエンジニアとして働き始めて以来、ずっとソフトウェアデリバリーのパフォーマンスに興味を持って、さまざまな改善活動をしてきた。当初はスクラムを中心としたプロセスの改善に注力したが、最近はチームの成熟に伴って技術的なプラクティスに興味が移りつつある。より広い視点からデリバリーについて考えるのは非常に楽しい仕事だ。
デリバリーのパフォーマンスを改善していくには、定量指標として確立されたFour Keysを計測し改善するのが業界標準となりつつある。恥ずかしながら、私はこれまでこのFour Keysが腹落ちせず、積極的に計測してこなかった。しかし、多方面に興味が向いて知識や経験が蓄積するにつれて、猛烈にFour Keysの重要性が腹落ちしてきた。この記事では、現時点における自分のFour Keysに関する理解と解釈を整理してみようと思う。
Four Keysとは
Four Keysとは、ソフトウェアデリバリーのパフォーマンスを示す以下の4つの指標のことである。
- デプロイの頻度
- 変更のリードタイム
- commitから本番環境稼働までの所要時間
- 企画立案などを含む製品開発全体のプロセスに関するリードタイムではない
- 変更失敗率（変更障害率）
- これに関しては主要な文献でも定義にブレがある
- LeanとDevOpsの科学では変更失敗率とし、変更起因による本番での障害に加えて、通常のフローによる追加の修正が必要だった場合などを含めている
- 以下に記載するGoogle Cloudに投稿された概説では変更障害率とし、変更起因による本番での障害のみが対象のような書き方をしている
- 本記事ではカバー範囲の広い前者の定義を採用する
- 平均修復時間
5分でわかる解説としては以下の記事が鉄板となる。
エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud Blog
より詳しく知りたい人は以下の書籍を読むと良い。Google Cloudの記事も以下の書籍も由来する研究プロジェクトは同一のものであるはずだ。
LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する - インプレスブックス
Four Keysの妥当性
LeanとDevOpsの科学には、Four Keysがなぜデリバリーのパフォーマンスを示す指標として妥当であるか書かれている。主な論旨は以下のようなものであると理解している。
- Four Keys自体は、LeanとDevOpsの文脈で望ましいとされる像に基づいて、計測しやすい指標をキメ打ちしたものである
- 4指標に関する回答をクラスタリングすることで、意味のある3つの集団（パフォーマンス高・中・低）に分類できた
- 上記の3つの集団においてビジネス的な成功（収益やビジョンの実現）に優位な差が見られた
以上のロジックでFour Keysがソフトウェアデリバリーのパフォーマンスを表す意味のある指標であると読んだ（他にも統計学やアンケート調査の文脈で細かい話題はあるようだが、ここでは割愛する）。さらに、Four Keysの改善効果が高いことが確認された24のケイパビリティ（組織が保持する能力）が紹介されている。本書から何かしら示唆を得ようと考える時は、このケイパビリティの一覧から読み始め、関連する章へ進んでいくと上手く読めるのではないかと思う。
Four Keysを掘り下げる
まずはタイトルの問い「Four Keysはなぜ重要なのか」に簡潔に答えるところから始める。
ひとつには、上に述べた通りビジネス上の成功と関連の高い指標であるからだ。ここに疑いの余地はないだろう。
そしてもうひとつ、これは私の考えだが、現代のソフトウェア開発の様々なプラクティスに対して、広く反応しやすい成果指標であるからだ。ソフトウェア設計、アジャイル、DevOps……どの切り口からチームを改善しようと考えても有力な指標として採用できる。逆にFour Keysから始めることで、現代のソフトウェア開発の幅広いプラクティスに目を向けることもできる。まさに「LeanとDevOpsの科学」ということだ。書籍では統計的な有意性や研究としての成り立ちにフォーカスした議論が多く、最初は煙に巻かれてしまったのだが、Four Keysはこれまでソフトウェア開発を良くするとされてきた様々な議論をうまくまとめ上げているのだと思う。これは、LeanとDevOpsの科学で紹介された24ものケイパビリティがFour Keysをよく改善することからも頷ける。
ここからは、Four Keysの各指標について掘り下げつつ、指標を改善する時にどんな話題と関連するか書き下してみようと思う。自分のチームの課題意識に基づいて話題を列挙するので、ミドルパフォーマーとハイパフォーマーの間くらいの環境が対象になることに注意されたい。LeanとDevOpsの科学ではより一般的な内容がカバーされている。
デプロイ頻度
デプロイ頻度を改善していくためには、以下のような領域と向き合うことになるだろう。
- アジャイルな開発プロセス
- 意味のあるデプロイ回数を増やそうと思うと、ユーザーストーリー単位でタスクを整理し、フロー効率を向上させることが妥当な戦略になる。これは現代的な開発プロセスのプラクティスに他ならない
- デプロイフロー
- デプロイ回数を増やすには、デプロイの負荷が小さいことが欠かせない。作業自体がシンプルで短時間で完了すること、またチームが自律的に実行できることが重要になる。技術と組織の両方を改善しなければいけない。この観点を広げてバリューストリーム全体を分析するのも有効だろう
- フィーチャートグル
- デプロイしたものが必ずユーザーに見えてしまう環境では、プロジェクトの進行やビジネス上の都合によってデプロイを止めざるを得ないケースが頻発する。スタッフフラグやフィーチャートグルを活用して、できたそばからデプロイして本番で確認できる環境になればデプロイ頻度は上昇していく。ビッグバンリリースを避けるインセンティブを与える点でも正しく機能している
- スループット
- デプロイ頻度を増やすためには、デプロイするものがなければどうしようもない。ユーザーストーリー指向で全体のフロー効率を上げていくとは言っても、最後はどれだけ早くコードを書けるかという話になる。以下のような話題が関連するだろう
- 優れたソフトウェア設計
- 障害物を排除しやすい環境
- 各メンバーの成長支援
変更のリードタイム
これはcommitから本番環境稼働までの所要時間のことである。変更のリードタイムについて考えると、デプロイ頻度と似たようなキーワードが思い浮かぶ。先に述べた文献でも、デプロイ頻度と変更のリードタイムは「速さに関する指標」とグルーピングされており、似たようなプラクティスと関連することに違和感はないものの、変更のリードタイムのほうが多少ミクロな効率にフォーカスした概念には見える。特に効果の高いであろう話題としては以下のようなものがある。
- プロセス面でのプラクティス
- 作業の適切な分割
- プルリクエストの単位が小さいければレビューもその修正も素早く完了することができる
- ペア・モブプログラミング
- 設計や実装方法について事前に十分な議論と合意があれば、レビューは格段に容易であるし修正作業も少なくなることが期待できる
- レビューフローの整備
- レビューを依頼してからレビューされるまでの時間が短ければ、当然リードタイムも短くなる
- WIP制限
- チームの全員が3つも4つもタスクを抱えて行き来するようではリードタイムは長くなる。マルチタスクを禁止することで変更のリードタイムは改善するだろう
- CI/CDの高速化
- 一回のテストに30分もかかるようでは修正のイテレーションに長い時間がかかってしまうし、デプロイに何時間もかかるようでは当然そのぶんリードタイムも伸びる。短縮した分がダイレクトにリードタイムに反映される
この指標を突き詰めていくと、コンパクトな変更をコミットしてレビュー依頼、その場でレビューが返ってきて修正してマージ、そのままボタンひとつでデプロイして、本番で動作確認をしてタスク完了！というテンポで仕事ができるようになっていくのだろう。
変更失敗率
このあたりからピンと来なくなる人が多いように思う。少なくとも私はそうだった。以下にLeanとDevOpsの科学から定義をそのまま引用する。
主要なアプリケーションやサービスに施した変更のうち、サービス低下を招いたケースや修正作業が必要となったケース（サービス機能の障害や稼働停止を招いてしまったケースや、ホットフィックス、ロールバック、フィックスフォワード[事態改善のために通常の手順を踏んだ修正]）、パッチが必要となったケースの発生率
この定義を「意図通り動くコードを一発で書けてるか？」と言い換えても、概ね意図は取り違えていないと思う。このくらい噛み砕いてみると変更失敗率から以下のようなキーワードが思い浮かぶ。
- ソフトウェア設計
- 理解しやすく変更しやすいシステムであるほどバグを埋め込む可能性は減る。大きくは、クリーンアーキテクチャ、DDD、マイクロサービスアーキテクチャといったキーワードが想起される。この数行ではとても語りきれない広大な領域である
- テスト
- テストを適切に行えれば開発の段階でバグを発見できる可能性が高い
- 各メンバーの成長支援
- 使用している技術やドメインをよく理解していれば、実装とレビューの段階で正しいコードを生み出せる可能性が高い。広くはパフォーマンスやキャパシティプランニングといった話題もここに含まれるだろう。そうした観点を自律的に盛り込んでシステムを変更できるようになると変更は失敗しづらくなるはずだ
先に述べた文献では、変更失敗率は「安定性に関する指標」であるとされているが、個人的にはこれも「速さに関する指標」と捉えた方が腹落ちしやすいように感じている。例えば、変更のリードタイムがそのままでも、変更失敗率が下がれば価値提供のスピードは上がる。逆に、変更のリードタイムを上げるために適当な計画でコードを書き、変更失敗率が上がった場合、全体としては価値の提供速度が改善していない（なんなら悪化するかもしれない）。難しいことを考えずに、意図通り動くコードを、一発で、素早く書き上げるのが一番早いということだ。この主張は、Four Keysで分類した時のハイパフォーマーが、4つの指標全てにおいて抜きん出ているという事実とも整合するように思う。つまりFour Keysにトレードオフを見出すのではなく、黙って全部改善するという姿勢がハイパフォーマーへの道を切り開くということだ。
平均修復時間
これは本番環境での障害から回復するまでの時間のことである。障害からの回復では以下のようなキーワードを思いつく。他の3指標に比べてOps領域の話題が多い。
- 障害対応の体制
- チームとして障害対応の訓練がよく行われていれば、それだけうまく対応できる可能性は高まる
- オンコール体制や深夜当番などが整備されていれば、早く障害から復旧できる可能性が高まる。一方でサービスに求められる信頼性によっては、こうした体勢まで整える必要はないかもしれない。このあたりを建設的に議論しようとするとSREingに話が広がっていくだろう
- エンジニアリングプラクティス
- Observability（可観測性）
- システムのふるまいが外部から観測しやすいほど、障害の発見と原因の特定が素早く行える。ひとことで片付けてしまったが、ここを掘り下げると、ログ、メトリック、モニタリング、トレーシングといった広大な領域が広がっている
- ロールバック
- 変更に起因する障害であれば原因は明らかなので、ロールバック機構が成熟しているほど修復時間は短くなる。これは単純に可用性や信頼性に寄与する項目だ
- 冪等性
- 障害で処理が失敗した場合に、再送するだけで容易に復旧できるロジックになっていると修復時間は短くなる
変更失敗率と同様に、平均修復時間も「安定性に関する指標」とされているが、これも「速さに関する指標」と捉えた方が腹落ちしやすい印象がある。まず単純に、障害から早く復旧すればそれだけ早く普段の開発に戻ることができる。障害が起こるたびに全員で丸一日対処しているチームと、気づいた人が小一時間で直せるチームだったら、どう考えても後者の方が価値提供に時間を使える。また、これは実際に運用に携わる人なら納得してもらえると思うのだが、障害の復旧は難しいことが多い。直近の変更に起因しない障害は特にだ。そうした状況を素早く解決する能力は、間違いなく他の価値提供も加速する。例えばObservabilityは運用に限らず、日常的な開発におけるデバッグや動作確認においても極めて有用だ。また、そうした技術スキルの習熟が起こる組織文化は、他の指標を含めたデリバリーのパフォーマンス全体に良い影響を与えるだろう。
まとめ
本記事では、ソフトウェアデリバリーのパフォーマンスを表す指標であるFour Keysについて、その定義と重要性を掘り下げた。特に、Four Keysが現代のソフトウェア開発における様々なプラクティスに反応する優れた指標であるという気づきをベースに、各指標の掘り下げを行った。また、一見すると安定性に関する指標に見える「変更失敗率」と「平均修復時間」は、いずれも速度とも強い関連性を見出せる指標であることを議論した。LeanとDevOpsの科学に現れるハイパフォーマーがFour Keys全てで抜きん出ている事実を鑑みて、4つの指標の間にトレードオフを見出さず、全てを改善する姿勢がハイパフォーマーへの道となるだろう。
ここまで言語化をしたなら、あとは計測して改善するだけである。こうした指標を正確に計測するのは悩みの種となるが、幸いにもいくつか選択肢がある。まず冒頭に記載したGoogle Cloudの記事中では、Google Cloud上に構築する「Four Keysパイプライン」が紹介されている。自社で分析基盤をメンテナンスしていく体力があるのなら有力な選択肢となるだろう。また、GitHub等のデータを解析することでエンジニアリング組織の生産性を可視化するFindy Teamsでも、Four Keysへの対応が着実に進んでいる（弊チームでもかなりお世話になっているので宣伝です😉）。他にも、インターネット上には各社が独自に分析基盤を整えたレポートがいくつもあり、それらも参考になるだろう。
Four Keysを計測、改善して、最高のハイパフォーマンスチームを作っていこう。
