アジャイル／DevOps メトリクス入門
DevOps とアジャイルプロセスを改善する最初のステップは、それらを測定することです。プロセスを測定できれば、より大きな効率化の機会を特定し、それらの機会をビジネス価値と関連付け、組織全体を共通の目標とビジョンでつなぐことができます。アジャイルの旅を始めたばかりでも、既存のアジャイルプロセスを他のグループや事業部門と接続したい場合でも、ここに開始するための 4 つのステップを紹介します。
ステップ 1: DORA メトリクス
DevOps Research and Assessment (DORA) は、わかりやすく、焦点を絞った、実装が簡単な 4 つの指標のリストを作成しました。これらは、メトリクスのイニシアチブのための優れた基盤を形成し、既存の DevSecOps 効率を向上させるとともに、ビジネスステークホルダーへの橋渡しを構築するのに役立ちます。
これら 4 つの「DORA」メトリクスは:
- デプロイメント頻度
- リードタイム
- 平均復旧時間
- 変更失敗率
DORA メトリクスは GitLab のグループレベルのバリューストリーム分析 (VSA) と CI/CD 分析 で利用できます。4 つの DORA メトリクスすべてに対する API も提供されています。詳しくは DORA API ドキュメント をご覧ください。
各メトリクスの概要と、それらが会社全体にどのように関わるかを以下に示します。
デプロイメント頻度
ソフトウェアを本番環境にどれくらいの頻度でデプロイしているかを示します。これは最も基本的な DevOps／アジャイルメトリクスの 1 つです。なぜなら、定期的にデプロイしていなければ、価値を提供することはできないからです。
これは、デプロイしているソフトウェアが実際にどれだけ価値があるかを示すものではない（次のセクションでカバーします）ことに注意する価値はありますが、これがなければ測定するものは何もありません。価値を生み出すためにはデプロイする必要があります。そして、おそらくすでに似たようなメトリクスを持っているでしょう。これは見つけて報告するのが最も簡単な指標です。
変更の平均リードタイム（リードタイム）
これは、コードコミットからそのコードが本番環境で稼働するまでの時間です。一部の企業ではこれは数分の問題ですが、他の企業では数ヶ月です。実際にここで測定しているのはサイクルタイムであり、リードタイムではないという考え方もありますが、重要なのは、名前にかかわらずこれを測定することです。
リードタイムは素晴らしいメトリクスです。これは可能性の優れた直感的な指標だからです。何らかの形で DevOps プロセスを管理している場合、これを全体的なヘルスチェックとして見ることができます。リードタイムが数ヶ月の場合、システムやプロセスを合理化・自動化する機会の領域がおそらくいくつかあります。
リードタイムが長い理由は無数にあります。デプロイメント頻度と同様に、リードタイムは問題を診断するわけではありませんが、答えを探す場所を示すことができます。
これはビジネスにも利益をもたらします。ビジネスプランナーやプロダクトマネージャーが市場需要の変化に反応する機会を見つけたとしましょう —— ユーザーの手に来週金曜日までに何かを届けることができれば。その状況では、10 時間のリードタイムは有望に聞こえます。これは、皆が十分に早くアラインメントできれば、締め切りまでに変更を本番環境に投入できることを示しています。
一方、60 日のリードタイムは、必要な作業に例外的に簡単な部分がない限り、ほとんどの場合この動きを除外するでしょう。しかし、その実行不能性さえ、なぜリードタイムが高いのか、DevOps 投資への対処の価値を見出すのに役立つ生産的なクロスチーム議論を始めることができます。
平均復旧時間 (MTTR)
これは、失敗から立ち直るのにかかる時間の量です。何かをデプロイして失敗した場合、失敗したサービスを再び使用可能にするのにどのくらい時間がかかりますか?
一見、このメトリクスはビジネスに特に関連性がないように見えますが、本質的には変更を加えることによるビジネスリスクの指標です。このメトリクスはまた、DevOps が真にビジネスや収益のイネーブラーとして機能できる方法の 1 つを示しています。MTTR の数値が良いほど（復旧時間が短いほど）、会社は実験やイノベーションをより快適に感じます。
DevOps がこの上に絶対的に乗っていて、数分で失敗から立ち直ることができれば、ビジネスがより多くの（許容できる）リスクを取り始めるよう実際に促し、実験を実行することにより快適に感じ始めるよう促すことができます。最終的にこれはより多くの収益と利益を生み出すことができます。
変更失敗率 (CFR)
CFR は、修復が必要なデプロイメント失敗にどれくらいの頻度で遭遇するかを見ます。物事がどれくらいの頻度で激しく壊れ、ロールバックして MTTR をテストして修正する必要があるか?
これも問題を診断するわけではなく、特定のデプロイメントは何らかの理由でリコールされる可能性があります。それは DevOps パイプラインとは何の関係もないかもしれません。コンテンツの問題や市場の変化のような純粋な外部要因かもしれません。しかし一般的に、時間をかけて追跡すると、CFR は DevOps パイプラインの健全性に役立つビューを提供する傾向があり、それもビジネス主導の会話を駆動できます。
数値が高く、時間をかけても高いままだとしましょう（CFR が 40% だと仮定しましょう）—— それは膨大な量のビジネス価値が無駄になり、決して顧客に届かないということです。その場合、問題の原因を診断できれば、そのパフォーマンスを改善するためにリソースを使うのは非常に合理的です。最終的に提供される全体的な価値を 15% 増加させるなら、3 ヶ月間各サイクルの 20% を技術的負債の返済に使うことは、財務的に非常に良い判断になるかもしれません。
CFR を追跡している場合、文書化されたエンドユーザー価値に結びついているので、インフラストラクチャなどに関するデータ駆動の意思決定を始めることができます。
要約すると、これら 4 つの DORA メトリクスは素晴らしい開始点です。なぜなら:
- 速度とスピードを理解できるだけでなく、全体的な品質と安定性も理解できる。
- DevOps チームが今日利用可能なツールを使って、自分自身でかなり簡単に生成できる。
- すでに行っていることに役立つガイダンスを提供する。
- ビジネスが、価値の共有概念を持って DevOps とビジネスがどのように協働できるかを理解するのに役立つ。
ステップ 2: バリューストリームとフローを測定する
ユーザーへの価値の流れと、その途中の障害を測定するためのフレームワークがいくつかあります。
Lean Six Sigma に詳しい場合は、おそらくバリューストリームマッピングについて多く聞いたことがあるでしょう。また、これらのバリューストリームを測定するためのフレームワークである Flow についてもおそらく多く聞いたことがあるでしょう。
4 つの Flow メトリクスがあります:
Flow Velocity
スループット、すなわち時間に対する速度。
Flow Time
項目が開始から完了まで進むのにかかる時間。
これら両方とも、上で議論したものと類似する伝統的な DevOps メトリクスに非常に似ています。
Flow について独特なのは、次の 2 つです:
Flow Efficiency
Flow Efficiency は無駄を特定します。Flow Time の合計のうち、アクティブ時間と待機時間の比率を測定するため、待機していて価値を失っているかどうかを見ることができます。
Flow Load
現在進行中の Flow Items の数。アクティブか待機中かにかかわらず。
Flow Load はしばしば Work in Progress (WIP) として測定されます。直感的なレベルでは、コンテキストスイッチや火中の栗を多く拾いすぎることのコストがあることを誰もが知っていますが、進行中の項目の数を追跡し、結果と相関付けることで、そのコストを定量化し、どれだけ作業を引き受けるかについてデータ駆動の意思決定を行えます。
ステップ 3: 北極星 (North Star) メトリクス
すべての企業とすべてのイニシアチブには、成功を定義する異なる North Star メトリクスがあります。小売サイトでは年間顧客支出かもしれません。医療機器メーカーでは目標レイテンシかもしれません。ビデオゲーム会社ではプレイ時間かもしれません。
理想的には、会社はエグゼクティブレベルでこのメトリクスを定義する必要があります。OKR のようなものから始めて、カスケードダウンしていきます。
どのように North Star を選ぶか?
正しいメトリクスは 1 つではありません。重要なのは、そのメトリクスをできるだけ頻繁にポーリングし、より頻繁にポーリングできる代理メトリクスを見つけ、これまでに議論してきたすべてをそのレンズを通して見ることであり、ビジネスからデリバリーまで、皆が結果に基づいて一緒にイテレーションすることです。
例として、税務ソフトウェアを作っているとしましょう。あなたの North Star メトリクスは総収益かもしれませんし、ユーザーあたりの収益かもしれません。問題は、税シーズンの終わりまで結果がどうなるかわからないことで、それは数ヶ月先です。これは人々がしばしば 遅行指標 と呼ぶもので、最終状態を測定します。
一方、何かを測定する必要があり、税務シミュレータに費やされた時間が税シーズン中の収益増加と相関しているように観察したとします。これは 先行指標 で、後に続く行動を予測します。これは North Star メトリクスとの完璧な一致ではありませんが、今測定できるものなので、メトリクスを代理として使用し、追跡する他の先行メトリクスを探し続け、遅行メトリクスが利用可能になったときに期待されるパフォーマンスを実際のパフォーマンスと比較できます。
ステップ 4: 相関
実際に何が重要かをマッピングできるようになったので、ビジネス成果の文脈で DORA と Flow メトリクスを評価し、最も価値を加えられる場所を発見し始めることができます。例えば:
- Flow Load を減らすとシミュレータとのエンゲージメントが増えますか? 素晴らしい! 項目を少なくすることに焦点を当てるべきかもしれません。
- 変更失敗率の上昇がそのメトリクスに悪影響を与えていますか? その負債を返済する時かもしれません。
しかしまた、何が重要かを知ることが重要であっても、それはどのレバーを引くかを知るのに十分な可視性をプロセスに持っているときにのみ実行可能になります。だからこそ、計画から開発、Ops、リリース後のユーザーエクスペリエンスまで、チーム全員に共通のメトリクスセットと共通の言語を提供することが重要です。なぜなら、それがビジネスがアジャイルを受け入れる方法だからです。
