# DORAメトリクスとは、
ソフトウェア開発のパフォーマンスの測定ができるメトリクス。
４つのメトリクス:
- デプロイメントの頻度
ソフトウェアチームが変更を本番環境にプッシュする頻度 - 変更リードタイム
コミットされたコードを本番環境で実行するのに要する時間 - 変更失敗率
すべての展開におけるインシデント、ロールバック、失敗の割合 - サービス復旧時間
インシデント発生後に本番環境でサービスを復旧するまでにかかる時間
この４つの指標により、組織で優れたビジネス成果を達成する能力を予測できることが示されました。
DORAのチームは、よく知られているDevOpsのベストプラクティスがビジネス成果にどのように関係するかを評価するために、科学的な厳密さを適用しました。
展開頻度
デプロイメント頻度は、チームが変更を本番環境にプッシュする頻度を測定します。高パフォーマンスのソフトウェア チームは、頻繁に、小さな増分単位で出荷します。
頻繁に小ロットで出荷することには、2 つの利点があります。1 つ目は、ソフトウェア チームが顧客価値をより早く生み出せるようになることです。2 つ目は、本番環境で起こり得る問題を簡単に特定して修正できるため、リスクが軽減されることです。
デプロイメントの頻度は、次のようなさまざまな要因によって影響を受けます。
自動テストを信頼できますか?テスト スイートが合格すれば、本番環境にデプロイしても安全であることを示し、テスト スイートが不合格であれば、何かを修正する必要があることを示します。問題は、自動テストのカバレッジ不足とテストの不備から生じます。
デプロイメントは自動化されていますか?自動化されたデプロイメントへの投資は、すぐに回収できます。
少しずつ増分して出荷することは可能ですか?最適な方法は、開発者が短期間のブランチで作業することです。構築中の機能は、機能ゲートによってエンドユーザーから隠されます。
作業を小さな増分に分割する方法を知っていますか?作業の計画と分割には、ある程度の練習とコードベースの十分な理解が必要です。
優れたチームは、変更のたびに 1 日に複数回、本番環境にデプロイします。デプロイが苦痛であったりストレスを感じたりする場合は、より頻繁にデプロイする必要があります。
リードタイムの変更
変更リードタイム (変更のリードタイムまたはサイクルタイムとも呼ばれます) は、コミットされたコードを本番環境で実行するのに要する時間を表します。
このメトリックの目的は、開発プロセスにおける待機時間を明らかにすることです。コードは、誰かがレビューするまで待機する必要があり、デプロイされる必要があります。手動の品質保証プロセスや信頼性の低い CI/CD パイプラインによって、さらに遅延されることもあります。
開発プロセスにおけるこれらの追加ステップには理由がありますが、迅速に反復処理できると、他のすべてがよりスムーズに実行されます。俊敏性を高めるために多少のリスクを負う価値はあるかもしれません。多くの場合、バッチ サイズを小さくすると実際にリスクが軽減されます。
State of DevOps レポートによると、平均すると、エリート チームは数時間以内に変更を本番環境に反映します。ただし、このレポートは調査に基づいているため、基準値は平均よりも良好な状態を示すものであると確信しています。24 時間以内であれば、素晴らしい結果です。
変更のリードタイムの改善に関心のあるチームにとって、一般的な議論のトピックは次のとおりです。
プロセスに何か本質的に速度を低下させるものはありませんか?すべての変更を手動でテストしている場合、外部の QA チームにテストを依頼すると時間がかかります。チームにテスターを組み込むことはできますか?機能フラグを使用して、作業中の機能を非表示にし、ほとんどの機能を全体としてテストすることはできますか?
コードレビューはどのくらい速いですか? プルリクエストのレビューは遅くする必要はありません。
一度に多くのことに取り組んでいませんか?マルチタスクは、ブロックされているタスクから別のタスクに移ることができるときは効率的であるように思えるかもしれませんが、そのブロックに対処する可能性が低くなることも意味します。
失敗率の変更
最初の 2 つのメトリクスは、主に、迅速に反復する能力に関するものです。これらは、健全な運用が継続していることを保証する次の 2 つのメトリクスによってバランスが取られます。SPACEフレームワークは、互いにバランスを取るために異なるグループからメトリクスを選択するという同じパターンに従います。速度を測定するメトリクスを選択するときは、速度が速すぎる場合に警告するメトリクスも選択します。
変更失敗率は、クラウド プロバイダーのダウンタイムなどの外部要因ではなく、自分で行った変更によって発生したインシデントに焦点を当てています。これは、最初の 2 つのメトリックを制御するための優れた変数になります。
インシデントまたは障害の定義はあなた次第です。変更によって生じた生産停止は明らかに障害です。変更をロールバックしなければならないことも、おそらく良い兆候です。それでも、バグは新しく構築されたソフトウェアの通常の副産物であり、必ずしもすべての回帰をカウントする必要はありません。
優れたインフラストラクチャは、これらの問題の影響範囲を制限するのに役立ちます。たとえば、Kubernetes クラスターは、インスタンスが準備状態と生存状態のチェックに応答した場合にのみトラフィックを送信し、アプリ全体がダウンしてしまうようなデプロイメントをブロックします。
サービスを復旧する時間
平均復旧時間 (MTTR) は、インシデント発生後に本番環境でサービスを復旧するまでにかかる時間を表します。
傾向を理解することは有用ですが、最も重要なことは、組織がインシデント対応のための確固たるプロセスを備え、エンジニアリング チームがこれらのインシデントの根本原因を解決するために時間を費やせるようにすることです。
より複雑なマイクロサービス環境では、MTTR の代わりにサービス レベル目標を推進することも検討できます。
DORA メトリクスのよくある落とし穴
4 つの DORA メトリックの優れた点は、速度 (展開頻度と変更リードタイム) と安定性 (変更障害率とサービス復旧時間) という 2 つの変数にわたってエンジニアリング パフォーマンスを測定およびベンチマークするためのシンプルなフレームワークを提供していることです。
しかし、ソフトウェア エンジニアリングに携わったことがある人なら誰でも証言するように、数字、特に集計された数字は必ずしも真実をすべて伝えるわけではありません。DORA メトリクスを導入し始めたソフトウェア組織で見られた主な問題は次のとおりです。
1. 文字通りに受け止めすぎる
カーゴ カルトは、アジャイルの初期の導入では一般的でした。人々はスクラムに関する本を読み、その根底にある原則を理解せずに「正しい方法」について議論していました。
本といえば、『Accelerate』は素晴らしい本です。そして、この本は実際に、組織文化や開発者の幸福など、エンジニアリングのパフォーマンスに影響を与えるさまざまな要因を取り上げています。しかし、本全体が 4 つの DORA メトリックに縮小されると、このコンテキストの多くが失われます。
DevOps の実践だけが、気にする必要があるものではありません。優れた製品管理と製品設計の実践も重要です。心理的安全性も重要です。優れた製品開発組織を運営するには、4 つの指標だけでは不十分です。
2. 集計指標の背後に隠れる
DORA メトリックの集計値は、長期的な傾向を追跡することと、組織の初期ベンチマークを取得することという 2 つの主な理由で役立ちます。
ただし、改善を推進するには、チームに合計数値以上のものが必要です。個々のデータ ポイントは何ですか? これらの数値の要因は何ですか? それらを既存の毎日および毎週のワークフローにどのように統合する必要がありますか?
3. 組織の賛同の欠如
ソフトウェア開発の生産性の測定はデリケートな問題であり、そのためトップダウンの決定は簡単に論争を引き起こす可能性があります。一方、エンジニアリング リーダーからの指示がなければ、簡単に諦めてしまうこともよくあります。
リーダーシップの役割は、チームと個人が成功できる環境を構築することです。フィードバック ループを確実に確立することが、この役割の完璧な例です。したがって、この議論に積極的に参加することは理にかなっています。
開発者は、有害なメトリクスや個人のパフォーマンスを追跡することについて懸念することがよくあります。この問題を積極的に取り上げ、DORA メトリクスがほとんどの開発者の考え方と哲学的にどのように一致しているかを説明することをお勧めします。
4.十分に良いものに執着する
コードを 24 時間以内に一貫して本番環境にリリースし、すべての変更を大きな問題なくデプロイしている場合は、DORA メトリックについてあまり心配する必要はありません。複雑さが増しても状況が悪化しないよう、これらの数値を把握しておくことは重要ですが、常に念頭に置く必要はありません。
幸いなことに、継続的な改善の取り組みはそこで止まる必要はありません。
DORA 指標を超えて
Accelerate の作者は最近、SPACE フレームワークを使用して開発生産性のトピックに関する考えを広げました。これは自然な次のステップであり、まだ検討していない場合は今がよいタイミングです。