変更要約: AZ-400 第1章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
1.2DevOps メトリクスとフロー
DevOps の改善指標——DORA メトリクス（デプロイ頻度／変更のリードタイム／変更失敗率／MTTR）、サイクルタイム、ダッシュボード——を理解します。データで継続的に改善します。
改善は計測から。DORA の 4 指標でデリバリーのスピードと安定性を測り、ボトルネックを見つけます。
1.2.1DORA メトリクス
- デプロイ頻度：本番へどれだけ頻繁にリリースするか（スピード）。
- 変更のリードタイム：コミットから本番稼働までの時間（スピード）。
- 変更失敗率：デプロイのうち障害/ロールバックを招いた割合（安定性）。
- MTTR：障害からの平均復旧時間（安定性）。ダッシュボードで継続的に可視化する。
「速さ＝デプロイ頻度・変更のリードタイム」「安定性＝変更失敗率・MTTR」 の DORA 4 指標は AZ-400 で頻出です。スピードと安定性はトレードオフではなく、優れた DevOps では両立します。サイクルタイムやフロー効率もダッシュボードで追跡します。
AZ-400 は「データで継続的に改善する」姿勢を問います。DORA 4 指標は研究に基づくデリバリーパフォーマンスの標準で、スピード＝デプロイ頻度（本番リリースの頻度）と変更のリードタイム（コミット→本番の所要時間）、安定性＝変更失敗率（デプロイのうち障害/ロールバックを招いた割合）と MTTR/失敗からの復旧時間。エリート組織はこの 4 つを同時に高めており、速さと安定性は二者択一ではありません（小さく頻繁なデプロイ＋自動テスト＋自動ロールバックが両者を底上げします）。これらは Azure Pipelines の分析、Boards の Analytics（OData）、ダッシュボードウィジェット、Application Insights/Azure Monitor から算出・可視化します。改善のループは「計測→ボトルネック特定→小さな実験→再計測」で回し、リードタイムが長ければパイプラインの並列化やテスト高速化、変更失敗率が高ければレビュー/テスト/段階的デプロイ（カナリア）を強化、MTTR が長ければ監視/アラートと自動ロールバック/Runbook を整えます。バリューストリームマッピングで工程ごとの待ち時間（フロー効率）を可視化するのも有効です。設計の要は、4 指標をベースラインとして継続計測し、ボトルネックに的を絞った改善を回すことです。
| DORA 指標 | カテゴリ | 改善の打ち手の例 |
|---|---|---|
| デプロイ頻度 | スピード | 小口デプロイ・自動化パイプライン |
| 変更のリードタイム | スピード | テスト高速化・並列化・承認簡素化 |
| 変更失敗率 | 安定性 | 自動テスト・カナリア・品質ゲート |
| MTTR | 安定性 | 監視/アラート・自動ロールバック |
シナリオ：デプロイ頻度は高いが、変更失敗率が高く本番障害が頻発している。→ DORA で「速いが不安定」と判明。安定性側の打ち手として、パイプラインに自動テスト/品質ゲートを強化し、カナリア/段階的デプロイ＋自動ロールバック（Azure Monitor アラート連動）を導入。再計測で変更失敗率と MTTR が下がるか確認し、速さを犠牲にせず安定性を引き上げます。
FAQ：スピードと安定性はトレードオフではないの？ DORA 研究では、エリート組織は 4 指標すべてで高い水準を達成しており、両者は両立します。鍵は「小さく頻繁に・自動テストで守りながら・素早く復旧できる」仕組み。大きく稀なデプロイはむしろリスクが高く、小口・自動化・段階的デプロイがスピードと安定性を同時に押し上げます。
ひっかけ：コードカバレッジや行数（LOC）を DORA 指標と混同しないこと。DORA はデプロイ頻度・リードタイム・変更失敗率・MTTRの 4 つで、カバレッジは品質の補助指標にすぎません。また「デプロイ頻度を上げれば良い」だけでも不十分で、変更失敗率/MTTR（安定性）と併せて見ないと、速いが壊れやすいデリバリーになります。
1.2.2この節のまとめ
- スピード＝デプロイ頻度／リードタイム
- 安定性＝変更失敗率／MTTR（ダッシュボードで可視化）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. コミットから本番稼働までにかかる時間を短縮できているか測りたい。どの DORA 指標ですか？
Q2. 障害発生から復旧までの平均時間を改善できているか測りたい。どの指標ですか？
Q3. DORA メトリクスのうち、デリバリーの「安定性」を表す指標の組み合わせはどれですか？