DevOps メトリクスに対するアプローチ方法

DevOps メトリクスは、 ソフトウェア開発と IT 運用に関連する DevOps プラクティスの有効性を測定するための指標です。DevOps の目的は、ソフトウェア提供のスピード、信頼性、安定性を向上させることです。セルフサービスツール、自動化、コミュニケーションを優先し、開発者の生産性と満足度を重視します。

DevOps を導入している企業には、進捗状況を監視するための整合性のあるメトリクス群が必要になります。組織にとって何が重要かによって、最適なアプローチは異なります。ソフトウェアの出力を測定したいですか？チームの健全性を測定したいですか？この記事では、ソフトウェアに焦点を当てた DORA と、チームの状態を重視する SPACE の、2 つの代表的なフレームワークについて説明します。

DevOps の核となるのは、継続的な改善の文化です。何を改善しようとしているのか、そしてそれをどのように測定するのかを決めることは、重要な戦略的ステップです。DevOps メトリクスにおいて、影響力を持つ 2 つのフレームワークが、DORA と SPACE です。 

DevOps の主な目的は動作するソフトウェアのリリースを迅速化することであるため、この目標に関連する指標が優先されることが多くあります。このケースに適合するのが DORA (DevOps Research and Assessment の略) メトリクスです。

しかし、DevOps で重要なのは、動作するソフトウェアの出荷量だけではありません。チームの満足度やコラボレーションなどの品質に焦点を当てることが必要な場合もあります。SPACE は、Satisfaction (満足度)、Performance (パフォーマンス)、Activity (アクティビティ)、Communication and Collaboration (コミュニケーションとコラボレーション)、Efficiency (効率性) の頭文字をとったもので、チームに関連するこうした指標を重視します。

DevOps を測定するこれらの異なるアプローチは、「何を測定すべきか」に関する異なる考え方を反映しています。しかし、それらは二者択一を反映しているわけではありません。どちらのフレームワークも互いに補完しつつ、DevOps の目標の異なる側面をそれぞれ測定することができます。 

DORA

DORA メトリクスは、Google Cloud がサポートする DORA 調査プログラムから生まれたものです。DORA プログラムは 2020 年、ソフトウェア開発チームのパフォーマンスを測定するための「4 つの指標」を確立しました。

• デプロイ頻度：組織がプロダクション環境へのソフトウェアリリースを正常に完了させる頻度。これを判断するには、デプロイの成功とは何かを定義する必要があります。定義が定まると、「少なくとも 1 回の正常なデプロイが行われた週あたりの日数の中央値」などの計算が可能になります。
• 変更のリードタイム：コミットからプロダクション環境への反映までにかかる時間。これを判断するには、コミットが発生した時刻と、デプロイが完了した時刻の両方を追跡する必要があります。
• 変更失敗率：プロダクション環境で障害を引き起こしたデプロイの割合。これを計算するには、問題管理システムなどで、実施したデプロイの総数と報告されたバグやインシデントの数を把握する必要があります。
• サービス復元時間：プロダクション環境で発生した障害から回復するまでにかかる時間。これを測定するには、各インシデントが作成された日と解決した日を追跡する必要があります。これは、インシデント管理システムから取得できます。

そして、5 つ目の主要なメトリクスが翌年に追加されました。

• 信頼性：可用性、レイテンシー、パフォーマンス、スケーラビリティを包含する指標。DORA フレームワークでは、組織が信頼性の目標を達成または上回る成果を出しているかを測定します。

この調査と一連のメトリクスの焦点は、ビジネス成果の向上です。チームは、ソフトウェア・パイプラインからダッシュボードにデータを取り込み、経時的に進捗状況を監視することで、ソフトウェアのパフォーマンスを追跡できます。DORA フレームワークでは、各メトリクスのレベルに基づいて、パフォーマンスを「エリート」、「高」、「中」、「低」で評価します。

DORA フレームワークの主な利点は、GitHub、GitLab、インシデント管理システムなど、ソフトウェアチームがすでに使用しているツールからすぐに取得できる測定値に基づいていることです。メトリクスをダッシュボードに取り込む必要はありますが、データはすでに存在しています。

SPACE

DevOps メトリクスにおける SPACE フレームワークは、生産性のさまざまな側面を捉えようとするものです。2021 年の論文で SPACE を紹介した研究者チームは、その論文の中で「エンジニアリング作業はあまりに複雑で、単一の側面やメトリクスでは捉えることができない」と提唱しました。ソフトウェア開発にはトレードオフが伴うため、チームには業務のより多くの要素を包含する包括的なアプローチが必要です。

SPACE フレームワークには、次の明確な 5 つの指標が測定対象に含まれます。

• 満足度と幸福度：開発者が自分の仕事についてどう感じているか、また、どれくらい健康で幸福であるかを測定します。これには、アンケート調査を通じて、「従業員の満足度」、「開発者が必要なツールやリソースにアクセスできているか」、「職場のストレスによる燃え尽き症候群の度合い」などに関するデータを収集する必要があります。
• パフォーマンス：システムやプロセスの「成果（アウトカム）」(「アウトプット」とは区別される) 。これは単なるコードの量やそれがビジネスに及ぼす影響だけではありません。パフォーマンスは、品質 (コードの信頼性や継続的なサービスの健全性など) と影響 (顧客満足度や、顧客の獲得率と定着率など) によって測定されます。
• アクティビティ：業務の過程で完了したアクションまたは出力を追跡します。コミットの量やリリース数など、さまざまな方法で開発者のアクティビティレベルを把握できますが、SPACE フレームワークではこれらを単独で使用しないことを強調しています。
• コミュニケーションとコラボレーション：個人やチームがどのように情報を共有し、協力し合うかを捉えます。コミュニケーション、コラボレーション、調整の測定に役立つメトリクスには、ドキュメントや専門知識の見つけやすさ、作業が統合される速さ、作業レビューの品質、接続しているユーザーを示すネットワークメトリクス、新しいメンバーのオンボーディング時間などがあります。
• 効率性とフロー：中断や遅延を最小限に抑えつつ、作業を完了したり進めたりする能力を測定します。SPACE では、プロセス内のハンドオフの数、フロー状態を維持して業務を遂行できているかという主観的な実感、中断の数、システムを通過する時間などのメトリクスで評価することが推奨されています。

SPACE メトリクスはどれも、個人、チーム、またはシステムレベルで測定および追跡できます。

SPACE フレームワークは、DevOps に対する考え方を「単純なアウトプットの測定」から「生産性に対する包括的な視点」へと拡張させようとするものです。開発者の満足度レベルなど、まだ存在していないメトリクスを収集するには、アンケートなどの新しいプロセスの導入が必要になる場合もあります。

使用する DevOps メトリクスは、組織独自の優先順位を反映し、現実的に測定できるデータに基づいて選択する必要があります。DevOps の成功を測るメトリクスには、DORA フレームワークのように、リリースの速度やソフトウェアの品質などのアウトプットに焦点を当てるものも、SPACE フレームワークのように、生産性を高めるためにソフトウェア開発者が行う必要のある複雑なトレードオフに焦点を当てるものもあります。

測定対象を選定する際は、以下の質問が役に立ちます。

• 組織の目標は何か？スピードアップを目指すのか、信頼性と回復力の向上を目指すのか。あるいは、開発者の満足度、コラボレーションのしやすさ、効率性などを含めた包括的な開発者エクスペリエンスを重視するのかを確認しましょう。
• どのようなデータを収集できるか？ソフトウェア変更の提供に関するデータは、継続的インテグレーション/継続的デプロイメント (CI/CD) パイプラインが最良のソースとなります。また、定性的なデータを収集するためにアンケートを実施する必要もあるかもしれません。
• 自動化とコミュニケーションのシステムは効果的に機能しているか？DevOps メトリクスを取得するには、ボトルネック、チーム間のコミュニケーション、意思決定の方法が可視化されている必要があります。測定したい要素に関する信頼できるデータを取得するために、DevOps システムが設計どおりに動作しているかを確認することが、最初のステップになる場合もあります。

DevOps は、DevOps ワークフローをサポートする内部プラットフォームとツールを扱う、プラットフォーム・エンジニアリングに関連しています。DevOps のパフォーマンスを評価するいくつかのメトリクスは、プラットフォーム・エンジニアリング・ツールから取得されます。開発者エクスペリエンス (DevEx) の概念も DevOps メトリクスに反映されます。 

プラットフォーム・エンジニアリングは、開発チームの負担を軽減することで開発者のエクスペリエンスを向上させることを目指しています。これには、開発者が使用する共通の再利用可能なツールや機能を一元化する、内部開発者向けプラットフォーム (IDP) の提供が含まれます。プラットフォームエンジニアには、ゴールデンパスを設計および維持する責任があります。ゴールデンパスとは、組織の標準に従ってソフトウェアを構築およびデプロイするための、適切に文書化され、サポートされている方法です。

IDP、ゴールデンパス、およびその他の関連アーティファクトを構成する際の選択は、DevOps メトリクスと密接に関連します。DevOps を効果的なものにするためのプロセスを確立することは、何が重要で、何を現実的に測定できるかについて決定することにもなります。たとえば、CI/CD パイプラインは、ソフトウェアのコミットとリリースを可視化するソースとなります。

Red Hat には、DevOps の生産性を測定するのに役立つプラットフォーム、ツール、そしてコンサルティング・サービスがあります。

Red Hat OpenShift

アプリケーションを実行するプラットフォームは、DevOps メトリクス戦略が成功するかどうかに影響します。 Red Hat® OpenShift® は、クラウド、オンプレミス、エッジのあらゆる環境にわたって一貫したプラットフォームを提供し、Red Hat OpenShift GitOps および Red Hat OpenShift Pipelines Operator を通じて CI/CD ワークフローをサポートします。また、Red Hat OpenShift Observability により、アプリケーションのパフォーマンスと健全性を把握できます。

Red Hat Advanced Developer Suite

DevOps が重視する「生産性向上」と整合するかたちで、Red Hat Advanced Developer Suite は、開発者の生産性の向上、ソフトウェア・サプライチェーンのセキュリティの強化、および AI を活用した開発のサポートに不可欠なコンポーネントを提供し、Red Hat OpenShift の機能を拡張します。

Red Hat Developer Hub

Red Hat Advanced Developer Suite に含まれる Red Hat Developer Hub は、内部開発者ポータルです。このポータルは、サービスカタログやドキュメントから CI/CD パイプラインに至るまで、開発者ツールとサービスを単一の操作可能なハブに視覚的に統合しており、これを使用することで開発者エクスペリエンスと組織の生産性が大幅に向上します。

Red Hat コンサルティング

Red Hat コンサルティングの技術エキスパートが、実践的なコラボレーションを通じて DevOps プログラムをサポートします。コンサルタントは、サービスブループリントやメトリクスベースのプロセスマッピング (MBPM) などの手法を使用して、ワークフローをより適切に理解し、測定できるよう支援します。