GitHub Copilot を使って会社のエンジニアリング目標を達成する

改善を推進し、測定するための GitHub の推奨アプローチに基づいてロールアウトを計画します。

この記事で

次へ

Copilot影響ダッシュボードの表示

会社が GitHub Copilot などの新しいツールをロールアウトするときは、ツールがエンジニアリング システムに与える影響を測定し、会社の目標に対するツールの貢献度を評価する必要があります。

GitHub's Engineering System Success Playbook (ESSP) は、意味のある測定可能な改善を促進するための戦略とメトリックを提供します。 このプレイブックでは、エンジニアリングの課題を解決するための 3 段階のプロセスを推奨しています。

  1. 成功を妨げる現在の障壁を特定します。
  2. 目標を達成するために必要なことを評価します。
  3. 変更を実装し、結果を監視して調整します。

目標を定義

追跡する Copilot メトリックを決定する前に、エンジニアリングの結果を選択してください。使用状況と導入シグナルは、ユーザーがツール を使用 しているかどうかを示すだけです。 エンジニアリング システムと開発者からのフィードバックからの成果指標は、必要な変更が実際に発生しているかどうかを評価するのに役立ちます。

1 つまたは 2 つの目標から始めて、チームに伝えます。 ロールアウトを変更する前にベースラインを記録します。 各目標の既存のガイダンスを使用して、トレーニングを計画し、成果指標を選択します。

使用シグナルでは、特定の対話によってテストが発生したか、脆弱性が修正されたか、インシデントが防止されたかは識別されません。 それらを使用して、成果指標の代わりとしてではなく、成果指標とあわせて採用状況を理解します。 たとえば、生成されるコードが増えてもテストカバレッジが向上するわけではなく、受け入れ率が高くてもコードの品質や開発者の満足度を示すものではありません。

テスト カバレッジを拡大する

テストのギャップによってリリースが遅れたり、信頼度が低下したりする場合は、継続的インテグレーション レポートからラインとブランチのカバレッジを追跡してください。 また、テストの作成に費やされた時間と開発者の自信も追跡します。 これらの結果を、参加しているチーム間のチャットやエージェントの使用状況の傾向と比較します。 「GitHub Copilotを使用して社内のテスト カバレッジを拡大する」を参照してください。

Pull request を高速化する

レビューの遅延によって提供速度が低下している場合は、プルリクエストのリード タイムとレビュー サイクルを追跡し、デプロイ後に欠陥がないか確認します。 導入コーホート、ユーザーごとのマージ済みプルリクエスト、影響ダッシュボードでマージまでの時間を使って、導入とデリバリーの関係を調べる。 「GitHub Copilotを使用して社内のプル要求を高速化する」を参照してください。

セキュリティ負債を削減する

未解決の脆弱性が蓄積されている場合は、セキュリティ アラートのバックログと、セキュリティの概要で修復までの時間を追跡します。 これらの結果と併せて、修復に取り組むチーム間のエージェントとコード レビューの使用傾向を検討します。 「GitHub Copilotを使用して会社のセキュリティ負債を削減する」を参照してください。

コードの品質を向上させる

保守性や信頼性の問題が増加している場合は、組織レベルのコードの健全性を確認し、Code Qualityで経時的な未解決の検出事項を確認します。 これらを、それらの問題に取り組んでいるチームの導入状況と機能使用の傾向と比較します。 「組織内でGitHubのコード品質結果を探索する」を参照してください。

分析対象のリポジトリのセットの一貫性を保ってください。 未対応の検出結果数は、より多くのリポジトリで分析が有効になっている場合や、コードが改善された場合だけでなく、検出結果が却下されるときにも変化する可能性があります。

本番インシデントの削減

リファクタリングとメンテナンスの作業が安定性の向上を目的としている場合は、インシデント レコードを使用して、リファクタリングされたコードに関連する運用インシデントを追跡します。 その作業に Copilot を使用しているチーム間の使用状況の傾向と併せて、これらの結果を確認します。 「GitHub Copilotを使用して技術的負債を削減する」を参照してください。

開発者エクスペリエンスの向上

ワークフローの摩擦を減らすことが目的の場合は、アンケートや振り返りを通じて、有用性、信頼感、満足度に関するフィードバックを収集します。 継続的な使用、機能の導入、受け入れ率の傾向を使用して、アクティビティだけから満足度を推測するのではなく、開発者と検討・調査すべき問いを特定します。 「GitHub Copilot 試用版の成功を測定する」を参照してください。

責任を持って結果を比較してください

進行状況を確認するたびに、同じ比較方法を使用します。

  1. スコープと期間を揃える。 同じチームと報告日の使用状況と結果を比較します。 含まれているリポジトリとツールを記録し、メトリック定義をベースラインと一致させます。

    影響ダッシュボードでは、導入前後の同じユーザーではなく、異なる導入コーホートのユーザーが比較されます。 コーホート間の違いは、彼ら自身の仕事や経験、およびCopilotの使用を反映できます。 「GitHub Copilot の使用状況と導入メトリックの解釈」を参照してください。

  2. 他に何が変更されたかを確認します。 人員配置、プロジェクトの複雑さ、リリース スケジュール、トレーニング、またはエンジニアリングプラクティスの変更を記録します。 これらは、 Copilotとは無関係に結果に影響を与える可能性があります。

  3. 速度と共に品質を確認します。 pull requests のマージがより速くなった場合は、欠陥、インシデント、開発者のフィードバックも確認します。 出力の増加だけでは、エンジニアリング成果の改善を立証するものではありません。

  4. 結果を帰属させる前に調査します。 複数の期間の傾向を確認し、チームにCopilotをどのように使用したか尋ねます。 因果関係の結論をサポートする追加の証拠がない限り、観察された変更を関連性として記述します。

統合した結果を使用して、次の操作を選択してください。 たとえば、利用が増えているにもかかわらずテスト カバレッジに変化がない場合は、テストの作成に Copilot を使用しているかどうかをチームに確認します。 そのアプローチを拡張する前に、トレーニングまたはワークフローの障壁に対処します。