このガイドでは、KPIを確立し、NewRelicを使用してコーディング手法を改善および最適化する方法について説明します。これは、可観測性の成熟度に関するシリーズの一部です。
概要
高品質なコードは、組織がイノベーションを起こし、成長するための鍵です。質の悪いコードは、イノベーションに使えるはずのエンジニアの時間を、トラブルシューティングや修正に浪費してしまいます。また、品質の低いコードは、顧客満足度と収益に強い悪影響を及ぼします。
全体として、ビジネスのデジタルオペレーションは、そのコードの安定性に依存します。安定したコードベースがなければ、エンジニアリングは新機能の基本的な要求に応える時間すらなく、ましてや最先端に到達するために必要なスピードで動くことはできません。
この開発品質（DevQual）ガイドは、コード品質の向上を通じて安定性を促進する特定の主要業績評価指標とプロセスを特定します。 DevQualは、イノベーションと成長のバリューストリームの最初のガイドです。 DevQualの後には、 リリース品質ガイドが続きます。両方のユースケースを順番に実行する必要があります。
次の場合は、このガイドを使用するのに適しています。
- コードの品質を測定しているのではありません。
- あなたのコードの品質が悪いと思われている。
- 開発者がどこで時間を費やしているのか理解できません。
- アプリケーションの不具合による障害が多発している。
望ましい結果
DevQualは、既存の開発ツールチェーンとアジャイルプラクティスを活用して、コードの不具合を減らし、安定性と顧客満足度を向上させるという全体目標に到達します。安定性の向上により、開発者の貴重な時間をイノベーションと成長のために解放することができます。
このユースケースの実装に成功した組織は、次にリリース品質ユースケースによるビジネスインパクトの向上、そしてリリースケイデンスユースケースによるイノベーションの速度の向上に進むことができます。
主要業績評価指標
開発品質プロセスを使用して、次のKPIを収集および測定します。
安定性
- ビルドサクセス
- ユニットテスト成功
- コードカバレッジ
- 欠陥量
ベロシティ
- コードコミット率
- プルリクエスト率
- マージ率
安定性KPIは、送信されたコードの品質を測定します。速度KPIは、新しいコードが記述されてコミットされる速度を測定します。
これらのKPIは、コードの欠陥の原因と、開発者の最も努力が必要な領域を特定するのに役立ちます。これにより、欠陥の削減に注意を集中し、エンジニアリングの才能をより効率的に使用できます。また、開発速度がコード品質に影響を与えるかどうかを理解するのにも役立ちます。
各指標の詳細情報は以下の通りです。
安定性
ベロシティ
前提条件
開始する前に、同等の経験がない場合は、 New Relic University (NRU) Overview Course を修了しておく必要があります。また、以下の基本的な理解も必要です。
KPIの現状を把握する
他の継続的改善プロセスと同様に、開発品質（DevQual）を改善する最初のステップは、KPIの現在の状態を確立することです。これを行うには、次のタスクを実行します。
これらの手順について詳しく説明します。
必要なKPIを収集する
他の品質イニシアチブと同様に、主要業績評価指標を収集することから始める必要があります。これを行うには、ソースコードリポジトリやビルド/テスト自動化プラットフォームなど、開発プロセスをサポートする特定のテクノロジプラットフォームを特定する必要があります。これらのプラットフォームを特定したら、各KPIの属性を抽出してNewRelicにインポートする方法を特定する必要があります。
このユースケースに必要なKPIと最低限必要な属性は、主要業績評価指標のセクションにリストされています。通常、開発ツールチェーンのAPIを使用してKPIとその属性を抽出し、カスタムイベントAPIを使用してそれらをNewRelicプラットフォームに送信します。
カスタム統合作業を開始する前に、既成の統合機能が存在するかどうかを確認する必要があります。
DevQualダッシュボードの実装
DevQual この開発品質改善プロセスの主要な技術的要因です。現在の KPI が表示され、改善が必要な領域を特定するのに役立ちます。
DevQualダッシュボードのサンプルは、GitHubのNew Relic OMAリソースセンター に掲載されています。
ダッシュボードで提示する情報は、開発ツールチェーンに依存するため、ダッシュボードはサンプルからの変更が必要です。
ベースラインを設定する
DevQualプロセスでは、 最初のイネーブルメント を実行する前に、ベースラインを形成するための十分なデータが必要である。ベースラインは、開発活動の代表的なサンプルで構成されるべきである。通常、この期間は最低でも 2 週間であるが、現在の開発ペースに よっては 6 週間までとすることができる。これを行う簡単な方法の1つは、ベースラインの収集と評価のサイクルをアジャイルスプリントと一致させることです。
DevQualのイベントデータが期待通りに蓄積されているか、定期的に確認する必要があります。
イニシャルイネーブルメントの実施
開発チームやその他の利害関係者に、ベースラインのDevQualデータと、フォローする継続的な改善プロセスを紹介します。
このプロセスは、3つの活動で構成されています。
- DevQualのKPIと傾向を確認する。 あなたとステークホルダーはDevQual KPIを見て、トレンドを確認します。
- 成果、課題、および機会を特定します。このフェーズでは、KPIが改善している領域（成果）と改善していない領域（課題）を特定します。次に、KPI（機会）を改善するための戦略と戦術を特定し、それらを実装する方法を決定します。
- 技術的な提言を行う。 ここでは、あなたと関連するステークホルダーが、開発ツールチェーンや観測可能な戦略への変更など、技術的な推奨事項を特定し、検討します。
改善プロセス
これは、継続的改善プロセスの継続的なフェーズです。このフェーズでは、 初期導入ステップ を繰り返し、ベースラインに対する進捗を確認し、戦略や戦術を調整して、必要なプラスのビジネス成果を実現することができるようにします。
改善プロセスの各サイクルは、開発プロセスを数回繰り返した後に行う必要があります。通常、これは約2〜3週間ごとで、すべてのアジャイルスプリントの中間点と終了時に行われます。
この段階では、あなたは
- 毎週上層部にKPIを報告し、ステークホルダーチームが適切に作業の優先順位をつけていることを確認し、約束されたビジネス成果への進捗を示すことができます。
- 数ヶ月から数年にわたり、毎週のKPIを記録・保存し、基準値を設定し、改善率を表示します。
これは継続的な改善プロセスであることを心に留めておく必要があります。長期にわたってKPIを収集し、評価し続けることで、DevQualの目標を達成していることを確認することができます。
価値の実現
DevQualプロセスを確立すると、アプリケーションの安定性が増し、不具合の修正に必要な労力が徐々に減少していきます。やがて、これはフィーチャーバックログの縮小につながるでしょう。
これらの目標への道を進んだら、 リリース品質ガイドの使用を開始する必要があります。