こんにちは！
ourly株式会社 執行役員CTO(@tigers_loveng)の相澤です。
最近では「開発生産性」という概念は様々な会社に広く浸透してきているのではないかと感じています。
開発生産性を語る上で避けては通れないのが「Four Keys」ではないでしょうか？
でも、Four Keysを改善すると、開発プロセス全体にどんな変化が起きるのでしょうか？
「リードタイムやデプロイ頻度を上げるだけじゃ、単に “高速ゴミ製造機” になるだけだ」という声もSNSなどで過去に見たことがあります。確かに数字だけを追い求めれば、見かけ倒しのバニティ指標（虚栄の指標）になりかねません。
しかし、この2年間にわたる取り組みで僕が得た実感はむしろ逆です。Four Keysの向上を真剣に目指すことで、開発フローからアーキテクチャ、プロダクトマネジメントに至るまで広範囲に改善が波及しました。その様子はまさに「逆割れ窓理論」とも呼ぶべき好循環でした。
この記事では、その気づきと具体例を僕の視点で語ります。
Four Keys指標と「高速ゴミ製造機」論争
Four Keysと現場の不安
Four Keysとは、DevOps Research and Assessment (DORA)で定義されたソフトウェアデリバリーパフォーマンスを示す4つの指標です。具体的には以下の4項目で、開発チームのパフォーマンスを測定します。
- デプロイ頻度: 本番リリースの頻度
- 変更リードタイム: コード変更をコミットしてから本番にデプロイされるまでの所要時間
- サービス復元時間（MTTR）: 障害発生から復旧までの時間
- 変更失敗率: デプロイ後にバグやロールバックが発生する割合
どれも開発のスピードと安定性に直結する重要な指標ですが、特にデプロイ頻度とリードタイムはビジネスへの価値提供スピードを測る上で目に見えて効いてきます。
とはいえ、現場では「そんな指標の数字を追って意味あるの？」「無理に上げても結局“見せかけの成果”になるんじゃ？」という不安の声が上がることも事実です。
たとえばデプロイ頻度を上げようとしてリリースを細切れにしすぎれば品質が下がるかもしれませんし、リードタイム短縮を意識するあまりレビューを疎かにすればバグを生み出すリスクもあります。
こうした懸念から、Four Keys改善の取り組みに対し「それって結局虚栄の指標に過ぎないのでは？」とか「スピードばかり重視して高速ゴミ製造機になるだけでは？」といった議論が生まれてきました。
Vanity Metricsではなく、システム改善の起爆剤に
結論から言えば、Four Keysは使い方次第で“ただの数字”にも“改善の起爆剤”にもなり得ると感じます。
ポイントは、指標の数字そのものではなく、その裏にある原因に目を向けることです。
Four Keysはあくまでパフォーマンスの高い開発組織の結果指標なので、その結果が出るようなプロセス自体に価値があります。
僕たちのチームでも当初はリードタイムやデプロイ頻度の低さに課題を感じていましたが、「どう数字を良く見せるか」ではなく「なぜ低迷しているのか」を掘り下げました。その結果見えてきたのは、プロセス上のムダやボトルネックです。
例えば2023年5月時点、変更リードタイムは平均360時間（約15日） にも達していました。つまりコードをcommitしてからmergeされ本番反映されるまでに2週間もかかっていたわけです。
当然この間にはレビュー待ちやリリース待ちの停滞が含まれ、放置されたPRも多数ありました。当時は新機能開発に注力するあまり、既存のプルリクエストが後回しにされて長期間放置されるケースもあったのです。
緊急度の高い修正には対応できても、通常の機能改善は滞りがちで、その結果初期のPRが古くなって手戻りが増えるという悪循環も起きていました。
こうした状況にメスを入れるためにFindy Team+を導入し、Four Keysの指標を可視化し、データに基づいて課題を洗い出しました。
数字を上げること自体を目的にするのではなく、数字が悪い原因を潰していく。この方針に切り替えてから、チームの姿勢も変わりました。「どうすればデプロイをもっと頻繁に、安全に行えるか？」「なぜレビューにこんなに時間がかかっているのか？」といった問いを皆で共有し始めたのです。
その結果、Four Keysの数値改善は手段であり目的ではないという認識が生まれました。指標はあくまで開発システムの健康診断であり、異常値が出たらその根本原因を探って治療（改善）する――まさにそんなシステム思考で取り組んだのです。
数値そのものではなく、その先のプロセスに焦点を当てたことで、Four Keysは決してバニティには終わらず開発組織を進化させるドライバーになりました。
Four Keys指標改善が引き出した「逆割れ窓」効果
開発プロセスへの連鎖的な改善
Four Keysを起点に見えてきた課題に対して、僕たちは様々なプロセス改善策を講じました。ここでいくつか具体例をご紹介します。
プロセス細分化とボトルネック特定
まず開発フローを細かく分解し、どの工程に時間がかかっているかを可視化しました。
コードを書いてからPRをオープンするまで、レビュー開始まで、承認まで、マージまでといった各段階に区切り、それぞれに目標を設定したのです。
例えば「commitからレビュー開始までを平均X時間以内に短縮」といった具合に具体化することで、漠然と「リードタイムを縮めよう」と言うよりも遥かに実行策が見えました。
実際、このプロセス細分化により 「レビュー待ち時間」がボトルネック だと判明し、そこに集中して対策を打つことができました。
WIP制限（仕掛かり制限）の導入
ボトルネックだったレビュー待ちを解消するために、各自が抱えるプルリクエストの数を制限することにしました。
具体的には、自分の出したPRがレビュー完了してマージされるまでは新たな実装に着手しすぎないようにするルールです。これによって「前のPRが放置されているのに次の実装に集中してしまい、先行PRの修正対応が遅れる」という悪循環を断ち切りました。
結果、フロー効率が飛躍的に向上し、2024年3Qには“commitからmergeまで平均34時間”という目標に対し実績15.7時間と、大幅に目標を上回る成果を出せました。
WIP制限は劇的な効果を生みましたが、一方で「なぜそのルールが必要か」をチーム全員に腹落ちさせることも重視しました。ただ機械的に制限するだけでなく、目的を共有し合い、メンバーの定性的な声にも耳を傾けフィードバックループを回すことで、継続的な改善文化を根付かせています。
コードレビューの高速化と明確化
次に着手したのがコードレビューのプロセス改善です。以前は「なんとなく全員がapproveしないとマージしない」という曖昧なルールで、レビューに時間がかかりがちでした。
そこで承認プロセスを明確に簡略化しました。テックリードもしくは僕(CTO)の1名の承認でマージ可能とし、他のメンバーは必要に応じてレビュー参加する形に変更。加えて、プルリクを出した人が待ち時間に暇になることがないようペアレビュー・相互レビューを推進しました。
メンバー同士で先にレビューし合い、問題点を洗い出してから最終承認者に回すことで、レビュー待ちによる停滞とリーダーへの負荷を減らしたのです。この取り組みでレビューリードタイムが短縮されるとともに、レビューの質も向上しました。
「早くマージするために粗くレビューする」のではなく、「早く確実にレビューを終えるにはどうするか」を皆が考えるようになり、結果として相互学習やコード品質向上にもつながりました。
権限移譲と意思決定の見える化
開発スピードを上げつつ品質を保つためには、EMやテックリードだけに負荷が集中しないようにする必要があります。そこで開発タスク以外の仕事をメンバーに移譲し、自己組織的な動きを促しました。
たとえばカスタマーサポート対応や一部のプロジェクトマネジメント的なタスクをメンバーに任せ、僕は進捗確認や助言に徹するようにシフトしました。
これによりマネージャー層の工数に余裕が生まれ、ボトルネックだった意思決定待ちの時間が短縮されています。
また、マネジメント層だけで意思決定を完結させず、Why（なぜそれをするか）や判断プロセスをチームに可視化しました。意思決定の背景が共有されることで、各自が目的を理解して動けるようになり、いちいち上長の判断待ちで停滞することが減りました。
プロダクトレビューの効率化
プロダクトマネジメント側との調整も見直しました。本来ユーザー体験に直接影響しないリファクタリングやテスト拡充などは、開発チームの裁量で進められるはずです。
そこでPO（プロダクトオーナー）と事前に合意を取り、技術的変更は原則開発チーム判断で進める方針に切り替えました。
これにより、仕様調整を待つことなく必要な内部改善をどんどん実施できるようになりました。結果としてアーキテクチャの健全性やテストカバレッジも向上し、将来的な開発スピードの底上げにも貢献しています。
これらの施策はすべて、Four Keysの数値を良くしようとして始めた取り組みですが、発揮した効果はそれ以上のものでした。
ひとつ改善が進むと、その成功体験が次の改善への意欲を生みます。例えばWIP制限でレビュー待ちが劇的に減ると、「じゃあもっと小さい単位でデプロイできるようにしよう」と自発的に議論が始まり、CI/CDパイプラインの整備やリリース手順の簡略化といった次の一手に繋がっていきました。
まさに小さな改善が次の改善を呼ぶ正のスパイラルが生まれたのです。
これらの施策のより詳細な内容や背景や内容、結果は以下の記事にまとめていますのでよければご覧ください。
アーキテクチャとプロダクトマネジメントへの波及
興味深いのは、Four Keys改善の波がソフトウェアの設計やプロダクトマネジメントの領域にまで及んだことです。当初は「リードタイムを縮めよう」「リリース頻度を上げよう」という開発プロセス上の目標でしたが、それを達成するために自然とプロダクト開発に関わる全体の最適化に目が向きました。
リリースの小分けとフィーチャーフラグ
アーキテクチャ面では、フィーチャーフラグの活用を推進しました。大きな機能でもフラグで切り替え可能に実装し、本番環境にコード自体はデプロイしておき、切り替えタイミングをコントロールするアプローチです。
これによってデプロイ頻度を高めつつリスクを抑制でき、マーケティング的なリリース日調整とも両立がしやすくなりました。エンジニアは本番反映を待たずに次の開発に進めますし、万一問題が起きてもフラグOFFで即座に影響を遮断できます。
結果としてフィーチャーフラグの活用により、デプロイ頻度だけでなく、リリース頻度※の向上も実現できました！
Re:「開発」チームから「プロダクト」チームへのシンカ（3期振り返り） より
スクラムの改善
デプロイ頻度を上げるためには、開発フローの健全性を保つことが不可欠です。最初に取り組んだのが、スクラムサイクル自体の見直しでした。当初、スプリント期間を1週間にしていましたが、十分な作業時間を確保できず、スプリントゴールを達成することが難しくなっていました。
特にスタートアップの環境では、開発業務以外のタスクが多く、作業工数が圧迫されることがありました。そこでスプリント期間を2週間に変更し、毎スプリントでリリース可能な単位を確保できるようになりました。
さらに、スプリントレビューにCSメンバーも参加してもらうようにし、実際にプロダクトを使う顧客に近い立場からフィードバックを得る機会を作りました。これにより、チーム全体でプロダクトの解像度を高め、リリース時に期待される価値を明確にすることができました。
加えて、スプリントゴールを消化するチケットの羅列のようなタスクベースではなく、提供価値ベースで設定することで、予期せぬ事態が発生した場合にも柔軟に対応できるようになりました。ストーリー単位で目標を設定し、進行中の変更に対しても適切な判断がしやすくなりました。
この変更が、より迅速に価値を提供するための基盤となり、結果として開発のフローがスムーズに回るようになりました。
プロダクトバックログの見直し
開発サイクルを高速化したことで、プロダクトマネジメント側にも変化が生まれました。
リリースが数週間おきから日次あるいは随時になったことで、企画の優先順位付けや要件定義の進め方もアップデートが必要になったのです。プロダクトオーナーやビジネスサイドと協議し、バックログアイテムをこれまで以上に小さく切り出して定義するようにしました。
大きな機能を一度に出すのではなく、価値のスライスを細かく刻んで連続的に提供する考え方です。
これにより開発側の無理な詰め込みが減り、常にデプロイ可能な状態を維持できます。ビジネス側もユーザーの反応を小さく早く確認できるため、フィードバックループが短縮されプロダクトの方向修正も柔軟に行えるようになりました。
こうしたアーキテクチャやプロダクトマネジメントの変化は、一見するとFour Keysとは直接関係ないように思えるかもしれません。しかし 「指標を良くするにはどうすれば？」 と突き詰めていく過程で、組織やシステムの構造的な改善にまで踏み込む必要性に気付かされたのです。
結果として開発チームは単なる"機能実装部隊"から、プロダクト全体の継続的改善/進化をリードする存在へと変わっていきました。
ここまで来ると、もはやFour Keysの数字は単なる結果に過ぎず、チームのカルチャーそのものが継続的デリバリーの文化へとシフトしたと言えます。
「逆割れ窓理論」が示すFour Keysの真価
最後に、今回のテーマである 「逆割れ窓理論」 について触れたいと思います。元々の割れ窓理論は「小さなほころび（割れた窓）を放置すると環境全体の悪化を招く」というものでしたが、僕が体験したのはその逆です。つまり、小さな改善から始めることで、次第に良い影響が全体に波及していくという実感です。
Four Keys改善を軸に据えた取り組みは、まさにこの「逆割れ窓」の効果をもたらしました。一つひとつは地味に見えるプロセス変更やルール策定でしたが、「一箇所に着目して改善することで、その根本の原因に辿り着き、改善が周辺領域に及んで全体として良くなる」 という正のスパイラルが確かに存在しました。
リードタイム短縮に成功するとメンバーの意識が変わり、さらにデプロイ頻度向上へのモチベーションが高まる。デプロイが頻繁になると品質維持の重要性が再認識され、自主的にテストを拡充する。テストが充実すれば安心してリファクタリングに取り組め、将来の開発がさらに効率化する――このように、良い変化が次の変化を誘発する連鎖を肌で感じました。
重要なのは、Four Keysの価値は数字そのものではなく、そこから得られる洞察と行動にあるということです。数値はチームへのフィードバックであり、対話のきっかけです。Four Keysを改善しようと真剣に取り組むことで、必然的に「どうすればもっと良くできるか？」という建設的な問いが生まれます。その問いに向き合い続ける限り、チームは決して“高速ゴミ製造機”にはなりません。むしろ高速かつ高品質なものづくりを支える学習機械へと進化していくのです。
まとめ
Four Keysの数値は魔法の尺度ではありません。しかし、正しく使えば魔法のようにチームを進化させる触媒になります。僕自身、この2年間でその威力を思い知りました。指標の改善を追い求めた結果、得られたのは数字以上に価値ある開発文化の変化と継続的改善のマインドセットでした。これこそがFour Keysの真価であり、逆割れ窓理論的な好循環の本質だと思います。
CTO, EMやテックリードの皆さんも、「指標なんて所詮数字」と敬遠せずに、その先にある可能性に目を向けてみてはいかがでしょうか。きっとチームやプロダクトをより良くするヒントが見つかるはずです。
そして小さな成功体験を積み重ねていけば、いつの間にか組織全体がポジティブな変化で満たされている――それが高速ゴミ製造機を超えた“高速価値創造機” とも言うべき理想の姿なのだと、今では確信しています。
それでは今回はこのへんで。最後まで読んでいただき、ありがとうございました！
Discussion