DORAソフトウェアデリバリ指標の歴史と進化 A history of DORA’s software delivery metrics

For more than a decade, the DevOps Research and Assessment (DORA) program has been quantifying what makes software delivery effective. This retrospective post walks through how its now-famous metrics came into being and how they have been refined over time.

The four key metrics that DORA popularized — deployment frequency, lead time for changes, change fail rate, and time to restore service — emerged from years of survey-based research published in the State of DevOps Reports and synthesized in the book Accelerate. Their lasting contribution was statistical evidence that throughput and stability are not opposing forces: elite teams achieve both simultaneously. That insight challenged a long-held assumption that moving faster necessarily meant breaking more things, and it gave engineering leaders a defensible framework for investment decisions.

The metrics have not been static. Definitions have been clarified — for instance, change fail rate has been reworded over the years to reduce ambiguity for survey respondents — and a fifth metric focused on operational reliability was eventually added. The reasoning, as reported by the DORA team, is that some organizations improved delivery speed and stability without correspondingly improving the user-perceived reliability of their services, suggesting that the original four metrics did not fully capture the operational dimension.

The broader ecosystem reflects how influential these measurements have become. Google maintains an open-source project called Four Keys that automates collection from CI/CD pipelines, and commercial vendors including GitHub, GitLab, Jellyfish, LinearB, and Sleuth ship DORA dashboards out of the box. The metrics have effectively become an industry lingua franca for engineering productivity discussions at the executive level.

That ubiquity has prompted healthy debate. Critics warn of a Goodhart's law dynamic — when a measure becomes a target, it ceases to be a good measure — and point out that gaming deployment frequency or batching failures into single incidents is trivially easy. The DORA team itself has consistently emphasized that the metrics are most useful when paired with the program's broader capability model, which examines technical, process, and cultural practices that drive the outcomes. Looking ahead, it seems likely that future iterations will continue to expand beyond pure delivery, possibly incorporating developer experience and AI-assisted development signals as those areas mature.