ソフトウェア開発
DORAメトリクスを導入する実用ガイド
「どのようにソフトウェアエンジニアリングにおける業績を計算するのか？」という問いに対して、いくつかのチームは「コード」か「ストーリーポイント」で評価すると答えるでしょう。しかし、それは物語の半分しか語っていません。プログラマーの団体は数百のコードを書けますが、それ自体はこのアウトプットの迫力が全く伝えられません。
テクノロジリーダにとっては、直面する挑戦が「正確に計算できなかったらどうすれば業績が促進できるようになるのか？」ということです。
GoogleのDORA（DevOps Research and Assessment）チームが定めた「DORAメトリクス」は、実証済みのソリューションを提供します。DORAメトリクスをなす5つの指標は※、「速度」と「安定性」の釣り合いによりソフトウェア開発ライフサイクルの全体像を把握できます。
本記事では、有意義かつ持続可能な改善を推進するためにDORAメトリクスを導入することを実用的に解説します。まずはDORAの指標を定義し、そして導入プロセスの明確な計画を発表し、導入中に発生する一般的な課題を特定します。これにより、チームリーダ層は期待するものおよび導入プロセスに摩擦を最小限に抑える方法がより深く理解します。
※4つの指標から修正されました。
DORAメトリクスの5つの重要な指標
さて、DORAメトリクスの5つの指標について解説します。
これらの指標の力とは、「連動性」のことです。速度の改良は、品質を犠牲にしないようにするため、DORAの指標がシステムとして機能しています。
また、DORAメトリクスは、2種類の主なメトリクスに分かれています。それは、スループットメトリクス（Throughput Metrics）と安定メトリクス（Stability Metrics）と呼ばれるものです。
スループットメトリクス（速度）
1．デプロイ頻度（Deployment Frequency）：組織では、どのくらいの頻度でコードが正常に本番環境にリリースしますか？
高い頻度の場合は、成熟度の高いおよび自動化されたCI/CDパイプラインを示します。
2．変更リードタイム（Lead Time for Changes）：コミットされたコードを正常にデプロイするにはどのくらいかかりますか？
短いリードタイムは、効率的な低摩擦の開発プロセスを反映します。
3．デプロイ復旧時間（Failed Deployment Recovery Time）：旧称は平均修復時間（Mean Time to Recovery）です。失敗したデプロイメントが起こった場合、復旧する時間はどのくらいかかりますか？
短い時間が、チームの回復性とインシデント対応の能力についての重要な指標です。
安定メトリクス（品質・信頼性）
４．変更失敗率（Change Failure Rate）：本番環境へのデプロイメントにより品質低下のサービスが起こる、あるいはホットフィックスなどの修正が必要とするのは何割ですか？
低率の場合は、高品質なレビューとテスト、デプロイを示します。
５．デプロイの手戻り率（Deployment Rework Rate）：手戻りともよばれる本番環境インシデントによりデプロイメントが起こり、事後対応が必要とするのは何割ですか？ 手戻りの低率は、チームのシッピングの前のインシデント指定・修正が有能を意味します。
実用的な導入フレームワーク
DORAメトリクスを導入する際に、チームはデータ収集の自動化、シグナル集中、そしてフィードバック主導のカルチャー構築を含む戦略的評価を確約します。要するに、導入はただ計算に始まって終わるわけではありません。
具体的なDORAメトリクスの導入フレームワークについては以下の通りです。
１．シグナルソースよりデータ収集の自動化
正確かつリアルタイムなデータは、成功したDORAメトリクスの導入のための基盤となります。まずはキーシグナル（重要なシグナル）が既存のツールチェーンにどこで発生するか特定し、収集を自動化させるべきです。
ソースコード管理（例：GitHub、GitLab）：コミット、マージ、プルのソースであり、変更リードタイムの計算に不可欠です。
CI/CDパイプライン（例：Jenkins、CircleCI）：デプロイイベント、テストの失敗、そしてロールバックのデータを提供し、デプロイ頻度と変更失敗率の測定に必要です。
インシデント追跡・可観測性（例：PagerDuty、DataDog）：これらのシステムは、インシデントの開始時刻、解決、およびサービスステータス全体を記録するため、デプロイ復旧時間を計算する際の真実のソースです。
２．指標の集約・計算
シグナルの収集が完了した後、それらを一元化させ、処理する必要があります。
データの一元化：さまざまなツールからのイベントデータを、BigQueryなどのデータウェアハウス、またはElasticsearchなどのログ集計システムのような中央プラットフォームに統合します。
自動計算：毎日この生データを処理するために自動化されたタスクまたはスクリプトを実装します。そうすると、デプロイ頻度（デプロイ回数÷期間）と変更失敗率（失敗したデプロイ回数÷デプロイ総数）などの指標は、いつも標準化されたロジックを用いて計算させるようになるのを保証できます。
３．業績の可視化・フィードバックループの確立
文脈なしの生データは有用ではありません。データは、チームにとって実用的な洞察を変換しなければなりません。
ダッシュボード：GrafanaやTableauなどの可視化ツールを使用して、指標の長期的な傾向を追跡するダッシュボードを構築します。
文脈に応じた見方：トップレベルのデータを表示するだけでなく、指標の変化（例：変更失敗率の急増）を、引き起こした特定のコミット、デプロイ、またはインシデントに接続して追跡できるドリルダウン機能を提供する必要があります。
共同レビュー：これらのダッシュボードを、チームの振り返りミーティングや計画会議に統合します。何が稼働しているかどこにボトルネックが存在するかについての会話においては、客観的な出発点としてデータを使用します。
４．「非難なしに改善するカルチャー」の醸成
最後の、そして最も重要なステップは、文化的なものです。DORAメトリクスの成功はどのように使用されるかにかかっています。
評価対象は個人でなくシステム：DORAメトリクスで収集されたデータは、システムやプロセスのレベルで問題や結果を評価するものです。従って、これらの指標を個人の評価または処罰に用いるわけではありません。例えば、変更失敗率が高い場合は、プロセス上の問題をほのめかします。
改善に焦点を当てる：「目標数値の達成」でなく、目標はこの数値を使用して継続的な改善を推進することです。「共同問題解決」を中心に議論を組み立てます。
リーダーシップの支持：リーダー層は、これらの指標が学習・成長するためのツールであることをチーム全体に協調するように積極的に繰り返し伝えなければなりません。
避けるべき一般的な落とし穴
DORAメトリクスの導入中に、以下のような予想可能な課題が発生する場合があります。
単一の指標に注力：DORAメトリクスの5つの指標は、バランスの取れた相互接続システムを構成しています。変更失敗率を軽視しつつデプロイ頻度に向上させると、不安定を高めるリスクが発生します。
文脈を無視：DORAメトリクスは、「何が起きているか」を示しますが、「なぜ起きているか」までは示しません。デベロッパー心理調査といった定性的なフィードバックと組み合わせて活用するように全体像を把握できます。
指標の悪用：指標が業績評価と連動している場合、チームが指標を悪用しようと考えるおそれがあります。例えば、デプロイ頻度を増やすために、大きな機能を些細なデプロイに分割する策略が行うでしょう。その結果、システム全体に形骸化されてしまいます。
重要なポイント：測定から改善へ
DORAメトリクスの導入は、単純な測定からデータ主導の継続的な改善へと進化していくプロセスです。また、その原則は普遍的ですが、各組織によって具体的なツールやプロセスは異なります。
自動化されたデータ収集、計算方法の標準化、そして「避難せずに分析するカルチャー」の醸成は出発点として、テクノロジリーダの方は上記のフレームワークを活用し、より効率的で回復性および業績の高いエンジニアリング組織を構築することができます。
高業績チームと共にお客様のロードマップの実現を追加させませんか？ekino Vietnamは、ただエンジニアを提供するだけでなく、卓越したエンジニアリング能力をご提供します。
ekino Vietnamの専任チームがどのようにDORAメトリクスを活用し、お客様のプロジェクト一流のデリバリー速度とコード品質を保証するかについての詳細は、ぜひコンサルテーションをご予約ください。