

Aravind Putrevu
January 24, 2025
12 min read
最高水準のエンジニアリングチームは、特に速度、品質、回復力において、適切な指標を達成する効果を理解しています。2024 State of DevOpsレポートによれば、最高のチームはリードタイムを最短1分29秒まで短縮し、インシデントからの復旧時間は平均33.95分です。しかし、どれほどの組織がこの基準へ到達できるのでしょうか。そして、何が必要なのでしょうか。
DORA(DevOps Research and Assessment)指標は、この問いに答えるために存在します。中核となるのは、デプロイ頻度、変更のリードタイム、平均復旧時間(MTTR)、変更失敗率です。
State of DevOpsレポートには、AIが開発者の生産性へ与える影響を扱う専用セクションがあります。AIツールは機能開発を速め、より良いコードレビュー、リアルタイムの診断とフィードバックサイクル、ワークフローへの重要な洞察を提供し、各指標のスコアへ良い影響を与えられます。
本稿ではDORAと4つの主要指標を説明し、AIが各指標におけるチームの性能改善をどう支援できるかを示します。
DORA指標は、ソフトウェアの開発・デプロイサイクルの有効性を定量的に測る方法です。「最高水準のソフトウェアエンジニアリングチームは、なぜうまく機能するのか」という問いへの答えを探します。
DORA共同創設者の一人Jez Humble氏によると、DORAは科学的な測定、ベンチマーク、個別の推奨事項を通じ、企業のソフトウェア提供性能を改善するために設立されました。共同研究として始まり、独立組織となった後、2018年12月にGoogle Cloudが買収しました。
長期にわたり専門家から届いた数千件の調査回答を分析し、デプロイ頻度、変更のリードタイム、変更失敗率、平均復旧時間という4指標を特定しました。

これらが現在DORA指標として知られています。
デプロイ頻度は、一定期間に本番環境へコード変更をデプロイした回数を測ります。期間は日、週、月など、チームに合う単位です。リリースサイクルの俊敏性と、改善、新機能、修正をユーザーへ届ける能力を示します。
頻度が高ければ高速で効率的な開発工程を示し、低ければ継続的インテグレーション・デリバリーの工程やパイプラインにボトルネックがある可能性を示します。
デプロイ回数を測定期間の長さで割ります。例えば一週間に20回デプロイすれば、頻度は週20回です。
$$Deployment\ Frequency = Number\ of\ Deployments\ /\ Time\ Period$$
Time Periodはチームが選んだデプロイ間隔です。
DevOpsを採用しているかにかかわらず、デプロイは工程やパイプラインを通ります。継続的インテグレーション/継続的デプロイ(CI/CD)とInfrastructure as Code(IaC)により、テスト実行、アプリのデプロイ、インフラのプロビジョニングなどを自動化できます。GitOpsではGitリポジトリからこれらを管理します。
GitOpsではコードをGitリポジトリへコミットすると、CI/CDパイプラインが残りの工程を実行します。

ただし、パイプラインが適切に作られていなかったり、設定内の手順に問題があったりすると、更新速度が落ちます。IaC設定は、セキュリティ問題や誤設定を防ぐため、本番環境へ届く前にレビューする必要があります。
現代のAIツールは、コードレビューとインフラ解析を自動化して頻度を大きく高めます。CI/CDプラットフォームと統合し、設定をレビューし、潜在的な問題を検出し、改善方法を提示します。

例えば、開発者がテストケースを更新し、実行するCIパイプラインを作る場合です。
# .github/workflows/ci.yml
name: Node.js CI
on:
push:
branches:
- main
- feat/server
pull_request:
branches:
- main
- feat/server
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: '16' # You can specify your desired Node.js version
- name: Install dependencies
run: npm install
- name: Run tests
run: npm test
この設定はmainまたはfeat/serverブランチへのpushやプルリクエストで実行され、Node.js 16を設定してテストを実行します。
PR作成後、AIは見落とされた可能性のあるエッジケースを発見し、対処方法を提案できます。

別の例として、インフラ設定全体をGitで保存・管理している場合、DevOpsエンジニアがリソースの更新や新規作成用PRを出すと、AIが設定変更を素早くレビューし、安全で効率的なプロビジョニングへの改善を提案します。

設定レビューと改善提案を自動化すれば、従来の方法より短時間で工程を進められます。
変更のリードタイムは、コードのコミットから本番環境へのデプロイまでの時間を測るDORA指標です。デプロイ頻度と異なり、DevOps工程の効率を測ります。値が大きい場合、コードレビューやデプロイ工程が遅いことを示します。
この指標から得られるデータに基づき、プロジェクトチームは現実的な期限を設定できます。1日未満なら、新しい変更を一日以内にユーザーへ届けられることを意味します。
特定の変更について、次の式で計算します。
$$Lead\ time\ for\ changes = time\ of\ deployment - time\ of\ code\ commit$$
統計的に有用なデータを得るには、中央値を求めます。
主要な要因の一つはコードレビューです。コードのコミット後に行われ、バグやセキュリティ侵害、コードスメルを見つけ、規約を改善する重要な工程です。
プルリクエストの大きさも影響します。大きいPRはレビューに時間がかかり、小さいPRは短時間で確認できます。レビューが長いほどリードタイムも長くなります。
コードレビューが大きく影響するため、自動化は短縮に有効です。
エンジニアが新機能のプルリクエスト(PR)を提出すると、従来は本番環境へマージする前に、バグやコードスメルを見つけるピアレビューが必要でした。
AIコードレビューツールは提出直後にPRを検出し、変更のレビューを始めることで、従来のピアレビューを補強します。リアルタイムの診断と実行可能な提案を提供し、必要な変更をすぐ行えるようにします。

AIコードレビューがPRの一次レビューを行うことで、変更のリードタイムを短縮する複数の自動化効果が得られます。
平均復旧時間(MTTR)は、アプリケーション障害やシステム停止などの本番インシデントから復旧するまでの平均時間です。エンドユーザーを妨げる問題をチームがどれほど速く解決できるかを理解する重要な指標です。
MTTRが低ければ復旧が速く、ユーザーへの影響と財務・評判リスクを減らせます。State of DevOpsレポートでは、最高水準のチームは一時間以内にサービスを復旧します。MTTRの測定・改善により、インシデント管理のボトルネックを見つけ、システムの回復力を高められます。
$$MTTR = Total\ Downtime / Number\ of\ Incidents$$
例えば一か月に5件のインシデントで合計200分停止した場合は次のとおりです。
$$200 ÷ 5 = 40\text{分}$$
問題発生後にサービスを復旧するまでの時間を示します。継続的に追跡すれば、対応の傾向、機能している点、欠落を把握し、将来の停止時間を減らせます。
現代のオブザーバビリティツールは、AIで問題を素早く発見・修正します。
MLモデルは異常なシステム動作を見つけ、問題を早期に検出します。障害時にはログ、指標、トレースから根本原因を素早く探し、関連する問題をまとめ、ノイズを除いてアラートを有用にします。
過去のインシデントから学び、潜在的な障害を予測し、以前有効だった修正を提案します。チームはログ検索を減らし、実際の修正に時間を使えます。
変更失敗率(CFR)は、ロールバックやホットフィックスなど、本番環境の障害につながったコード変更の割合です。変更の品質と信頼性を理解する重要な指標です。低いCFRは優れたテスト、レビュー、デプロイ手法を示し、高いCFRはレビューやテスト不足を示すことがあります。
失敗した変更数をデプロイした変更総数で割ります。
$$CFR = (Number\ of\ Failed\ Changes / Total\ Changes) × 100$$
50件をデプロイし、2件が失敗した場合は次のとおりです。
$$(2 ÷ 50) × 100 = 4\%$$
コードレビューツールとJiraなどの課題追跡をつなぐと、開発工程を明確に把握できます。コミットから本番環境まで追跡し、ボトルネックや遅延をすぐ見つけられます。レビューを特定の機能や修正へ結び付ければ、各変更で重要な点に集中できます。

依頼された内容とコード変更が一致するか確認できるため、スコープクリープも防げます。本番環境で問題が起きたら、似た変更を振り返って素早く修正し、時間とともに同じ問題を防ぐパターンを見つけられます。
変更の健康診断のように、機能している点、していない点、次に注力する場所が分かります。
DORA指標とAIの役割を理解したら、次を実行できます。
これらの手順で開発工程と成果を改善できます。
DORA指標を理解し、CodeRabbitのような自動コードレビューツールを使うと、チームとユーザーに役立つデータに基づく改善ができます。現在の指標を測り、学んだことを適用し、進捗を追跡しましょう。CodeRabbitの無料トライアルに登録してください。