DORAメトリクスとは。

GoogleのDevOps研究&アセスメント（DORA）チームによって開発されたDORAメトリクスは、ソフトウェアの提供とDevOpsの成熟度に関する業種・業務標準のベンチマークを提供します。

DORAメトリクスは、その中核として、次の2つの側面に焦点を当てています。

1. スループット：DevOpsチームがどれだけ早くソフトウェアをリリースできるか。
   
   
2. 安定性：DevOpsチームがどれだけ信頼性と安全にソフトウェアを提供できるか。

スループット重視のメトリクスは、コードの変更がソフトウェア開発ライフサイクル（構想段階から本番稼働まで）をどれだけ迅速に動き進むかを示し、安定性重視のメトリクスは、デプロイメントがどれだけの頻度で失敗するか、そしてチームがどれだけ迅速に復旧できるかを示します。一緒に、ビジネスリーダーとDevOpsチームに、DevOpsの性能に関するエビデンスに基づいた再現可能な洞察を提供します。企業は、「書かれたコード行数」や「作業時間」などの主観的な性能指標や値に頼る必要はありません。

DORAメトリクスを追跡することで、DevOpsチームは、業界で認められた性能階層（低、中、高、エリート）と比較してそれがどの程度なのか、また企業全体の目標と整合しているかどうかを確認できます。継続的インテグレーション/継続的デリバリー（CI/CD）パイプライン、ソフトウェア・テスト、インシデント管理におけるボトルネックを客観的に特定するのに役立ちます。

DORAメトリクスはまた、リーダーシップがエンジニアリング部門の健全性をビジネス上の利害関係者に伝えやすくし、DevOpsの実践を最適化する高度なオートメーション、オブザーバビリティー、サイト信頼性エンジニアリング（SRE）ツールへの投資を正当化しやすくします。

DevOpsにおいて、DORAとはソフトウェア開発チーム向けに組織のパフォーマンス・メトリクスを普及させたDevOpsリサーチ・アセスメント・チームを指します。

DORA（現在はGoogleクラウドの一部）は、ソフトウェア・デリバリー・プロセスがビジネス成果にどのように影響するかを調査する独立した研究プロジェクトとして始まりました。DORAチームは、「パフォーマンスの高いソフトウェア・チームはパフォーマンスの低いソフトウェア・チームと異なる理由は何か」という重要な質問に答えたいと考えていました。

彼らは数千のチームから調査やテレメトリー・データを収集し、少数の納品および運用関連のメトリクスが全体的な性能を確実に予測できることを発見しました。具体的には、これらのメトリクスとは、デプロイメント頻度、変更のリードタイム、変更失敗率、失敗したデプロイメントの回復時間です。成果として、リリースのスピードとソフトウェアの安定性は密接に関連していることも証明されたため、チームはどちらかを優先する必要はありません。

最終的に、4つの指標が標準的なDORAメトリクスとなり、ソフトウェア配信のパフォーマンスに関する業界のベンチマークとなりました。2024年、DORAの研究チームはフレームワークに5番目のメトリクスであるデプロイメントの再作業率を追加しました。

5つのDORAメトリクスは、「スループット」と「安定性」という2つの包括的なカテゴリーに分類できます。

スループット・メトリクスには、デプロイメント頻度、変更のリードタイム、デプロイメント失敗時の復旧時間などがあり、これらを総合すると、アプリケーションが処理できる変更の数と、変更が本番環境に反映される速度がわかります。

安定性メトリクスには、変更失敗率とデプロイメント再作業率が含まれます。これらは、失敗を引き起こしたデプロイメントの割合と、計画外または本番環境のインシデントによって引き起こされたデプロイメントの割合を測定します。

デプロイメントの頻度は、チームが一定期間（1日あたり、1週間あたり、1か月あたり）に本番環境へコードを正常にデプロイした頻度を測定します。

デプロイメント頻度は、ソフトウェアチームが納品プロセスにおいてどれだけアジャイルで自信を持っているかを示す最も目に見えるシグナルの一つです。チームが1日に何度もコードを本番環境にデプロイする場合、それは通常、自動化されたビルド、テスト、デプロイメントのプロセスがスムーズに実行され、健全なオブザーバビリティー・メカニズムが整備されていることを意味します。このような状態により、開発チームはシステムの故障を心配することなくソフトウェアをリリースできます。

対照的に、月に1回しかデプロイしない（あるいはそれより低い）チームは、長く続くコード・ブランチ、手動テスト、複雑な承認プロトコル、大規模なリリース日に依存していることが多くあります。これらすべての要因により、ユーザーからのフィードバック・サイクルが遅くなり、欠陥の修正コストが増加します。

特に、デプロイ頻度が高くても、頻繁な停止やロールバックが発生する場合は、健全性の兆候ではありません。パフォーマンスの高いチームは、高いデプロイメント頻度と堅固な品質保証手法（マルチレベルの自動テスト、段階的デプロイメント、機能フラグ、リアルタイム監視手法）を組み合わせ、ユーザーへのリスクを最小限に抑えながら頻繁なリリースを可能にします。

リーダーシップの観点からは、デプロイメント頻度を時間軸で追跡することで、ソフトウェアのDelivery Pipelineのボトルネックを明らかにできます。例えば、新しい承認委員会を導入した後にデプロイメントの頻度が低下した場合、プロセスの負担が大きすぎることを示している可能性があります。逆に、デプロイメントの頻度が着実に増加し、信頼性メトリクスが向上していることは、CI/CDパイプラインとDevOpsプラクティスへの投資が成果を上げていることを示す強力な指標です。

変更のリードタイム（変更リードタイムとも呼ばれる）は、変更がバージョン管理システムのメイン・コード・ブランチにコミットされた後、そのコード変更が本番環境にデプロイされ、正常に実行されるまでに要する時間を指します。

このエンドツーエンドのウィンドウには、ビルド時間、テスト実行、コード・レビュー、承認、パイプラインの段階、実際のデプロイメントなど、すべてが記録されます。これにより、システムがいかに迅速に意思決定をエンドユーザーの目に見える変化に変換できるかが明らかになります。

リードタイムが短い場合（1時間未満）、組織はほぼリアルタイムでインシデントに対応できます。例えば、セキュリティー・チームが脆弱性にフラグを立てた場合、エンジニアリングチームは修正プログラムを実装し、自動チェックによって検証し、非常に短期間で公開することができます。この迅速なフィードバック・ループにより、チームは変更の影響を迅速に測定し、それに応じて調整することができるため、開発作業がビジネス成果に直結します。

変更のリードタイムを短縮するには、ほとんどの場合、DevOpsチームがDelivery Pipelineを自動化および簡素化する必要があります。このプロセスには、すべてのコミットを迅速に構築・テストするための継続的統合（CI）ツールへの投資や、承認プロセスの効率化を含み、承認が開発ワークフローと統合されるようにします。

失敗した展開復旧時間は、平均復旧時間（MTTR）またはサービス復旧平均時間とも呼ばれ、展開関連の障害後にサービスを正常に戻すまでの時間を評価します。

サービスの修復では、開発者は不良変更をロールバックしたり、ホットフィックス（通常のリリース・サイクル外にリリースされる小規模な緊急コード変更）をデプロイしたり、ユーザーがシステムを再び正常に使用できるように、問題の影響を軽減したりする必要がある場合があります。

回復時間が短い（数分）場合、通常、複数のDevOpsコンポーネントがうまく連携していることを意味します。

オブザーバビリティーは強力です。リアルタイムのテレメトリー・データ（メトリクス、ログ、トレース）は完全に集約され、ダッシュボードに一元化されます。インシデントは迅速に（多くの場合自動的に）検出され、ユーザーからの苦情を待つ必要はありません。

アラートは、エンジニアが迅速に通知を受け取る一方で、不要な通知に煩わされることはありません。

DevOpsチームは、ランブック（技術的タスクを実行するためのステップバイステップの戦術ガイド）、プレイブック（チームが状況にどのように対応すべきかを説明する、より高レベルの戦略ガイド）、および文書化されたロールバック手順に依存しています。これらのフレームワークでは、障害の発生時に何をすべきかを推測する作業を必要とします。

リカバリー時間が数時間または数日と長い場合、運用方法が不十分であることを示していることがよくあります。検知が不十分な場合もあるため、顧客から報告されるまで生産障害が残ります。診断は、データ収集が分散しているか、エラー・メッセージが不明瞭か、または障害モードでのシステムの動作についてチーム間で共通の理解が欠如しているため、時間がかかるプロセスです。このような環境では、各インシデントは、明確な解決プロトコルを備えた単純な問題解決作業ではなく、高ストレスで高リスクのイベントになります。

他のDORAメトリクスと組み合わせることで、デプロイメントの回復時間が短いため、デプロイメントが時折失敗した場合でも、障害を封じ込め、応答時間を短くすることができます。

変更失敗率（CFR）は、ライブ運用環境でデプロイメントが失敗する頻度をDevOpsチームに示す「配信品質」メトリクスです。問題のある本番デプロイメントで、問題に対処するために次のリリースまで待つのではなく、チームがすぐに介入しなければならない場合は、「失敗した」デプロイメントとみなされます。

CFRを長期にわたって追跡することは、チームがどの程度確実に変更を提供しているかを理解するのに役立ち、速度を優先するスループット・メトリクス（デプロイメント頻度、変更のリードタイム）に対するカウンターバランスとして機能します。

CFRは通常、パーセンテージとして表され、失敗したデプロイメントの数を同じ期間内のデプロイメントの総数で割り、100倍することで計算されます。

変更失敗率が低いことは、チームが本番環境で期待どおりに動作する変更をリリースしていることを示しています。CFRが低く安定している場合、チームはユーザー・エクスペリエンスを損なうことなく、安全にデプロイメントの頻度を増やし、変更のリードタイムを短縮できます。

ただし、変更の失敗率が高いことは、あまりにも多くの変更がシステムを不安定化させていることを示唆しています。原因としては、不完全または不安定なテスト、本番環境とは異なるステージおよびテスト環境、大規模すぎるデプロイメント、または監視とアラートの遅延などがあります。CFRが高いことは、組織がより小さな、より段階的な変更と、より安全なデプロイメント手法（例：新しいアプリや機能を、広範なリリースを行う前に少人数のユーザーに展開するカナリア・リリースなど）を優先し、より少ない変更を本番環境に導入できるようにすることを示しています。

デプロイメントの再作業率は、チームのデプロイメントのうち再作業率を測定する安定性メトリクスです。「再作業」とは、本番環境でユーザー向けのバグやインシデントによってトリガーされるデプロイメントであり、元の計画されたリリース・トレインの一部ではないものです。

デプロイメントの再作業率は、事後対応的な作業を可視化することで、元の4つのDORAメトリクスを補完します。これは、チームの開発作業が、製品を前進させる代わりに、過去のミスの修正に費やしていることを明らかにします。

再作業率が低いということは、一般的に、DevOpsチームがエンド・ユーザーに届く前にほとんどの問題を発見し、価値を生み出す作業（計画的な最適化やリファクタリング）にほとんどの時間を費やしていることを示しています。再作業率が高いということは、チームがトラブル対応に多くの時間を費やしていることを意味します。

再作業率は、他の主要なメトリクスと組み合わせると特に価値があります。例えば、あるチームのデプロイメント頻度が高く、再作業率が低い場合、そのチームは品質を犠牲にすることなく新しいソフトウェアを迅速にリリースしていることがわかります。しかし、チームがデプロイメント頻度が高く、再作業率も高いことを示している場合、チームは大量のコードをリリースすると同時に、その修正に多くの時間を費やしていることを示唆しています。

重要なのは、ゼロでない再作業率が正常な状態（そして多くの場合健全な状態）であることです。どんなに優秀な開発チームであってもミスを犯す可能性があり、適切に構築されたソフトウェア・アプリケーションであっても時間の経過とともに改善や機能の更新が必要になります。目標は、再作業を0％達成することではなく、全デプロイメントに対する再作業の割合を小さくした予測可能な割合に抑えることです。

各DORAメトリクスに対して、チームは4つの性能層（エリート、高、中、低）のいずれかに分類され、各層はメトリクスに対して確立されたしきい値に基づいています。閾値は以下の通りです。

デプロイメントのリワーク率は新しいメトリクスであるため、しきい値や性能層はまだ設定されていません。ただし、多くの企業やDevOpsチームは、独自の再作業ベースラインを追跡し、時間の経過とともに下降傾向を目指しています。再作業率データと変更失敗率、その他の信頼性メトリクスを併用することで、チームは単一の数値に基づいて過度に修正することなく、デプロイメントの再作業率を向上させることができます。

DORAメトリクスは、アプリ開発機能とオペレーション機能にわたる複数の専門チーム間の継続的なコラボレーションを優先する、ソフトウェア開発に対するより広範なDevOpsアプローチをサポートします。DevOps環境が成功するかどうかは、それを構成するチームの成功にかかっています。

DORAメトリクスを使用すると、企業は、より広範なバリュー・ストリームやビジネス成果と密接に一致した基準に従って、チームの性能を定量化できます。例えば、ハイ・パフォーマーとエリート・パフォーマーは、収益性、市場投入までの時間、顧客満足度の目標を達成できる可能性が高くなります。

DevOps文化は、自由なコミュニケーションとソフトウェア配信の利害関係者間の責任の共有への取り組みによっても特徴的であり、全員が協力して高品質のソフトウェアを構築し、製品イノベーションを加速します。そのため、多くの組織はDORA指標を使用して継続的な改善フィードバックループを構築しています。メトリクスは各チームの性能を測定します。チームは、測定に基づいて改善の機会について話し合い、新しいアプローチを試し、性能を再測定して、どの変更が実際にデリバリー慣行を改善したかを確認できます。

重要なのは、DORAメトリクスは診断であり、懲罰ではないということです。個々の開発者の作業に焦点を当てるのではなく、開発プロセスの体系的なパターンを明らかにするのに役立ちます。