用語集: GitHub Copilot の影響を測定する

GitHub Copilot の影響に関する用語集

この用語集には、組織が Copilot の影響を評価するために使用できるいくつかの基準が記載されています。以下について説明します。

• 基準に関する定義と注意事項
• 基準を使用するタイミング (段階)
• 基準へのアクセス方法 (ソース データの場所)

Copilot の影響を測定する GitHub のアプローチについては、GitHub Copilot ラーニング パスをご覧ください。

重要 😀: スピードと品質に関するシステムレベルの基準の妥当性と有用性は、組織によって異なります。Copilot の影響はコーディング以外では間接的なものになりますが、下流工程に影響を及ぼす可能性は無限にあります。したがって、スピードと品質に関する基準に因果関係を求める際には注意が必要です。

以下に示す測定基準は、Copilot によって改善されることが多いプロセスを表していますが、影響の度合いはさまざまです。組織の強みと弱みに応じて、影響は大きくなることも小さくなることもあります。ベンチマークを達成することよりも、ニュートラルからプラスの改善を観察することの方が重要です。エンジニアリング リーダーが懸念すべきなのは、測定基準が後退した場合だけです。その場合は、先に進む前に一度立ち止まって根本的な原因を究明してください。

ヒント:

• GitHub では、固定的な目標を設定するのではなく、各基準の経時的な改善を模索することを推奨しています。
• 測定頻度を開発サイクル (スプリント サイクルなど) に合わせて調整することをお勧めします。
• 簡単に分析できるように既存の BI ツールやレポート ツールでデータ ポイントを照合し、時系列で傾向を確認することを選択できます。あるいは、スプレッドシートを使って、時系列で基準を追跡することもできます。
• 開発者を Copilot に追加すると、その開発者は日常業務の一環として Copilot を使いこなす能力と自信を身につけることができるため、いくつかの基準が減少する場合があります。オンボーディング グループ (Copilot シートが提供される開発者のグループ) に応じて測定値を分析することを検討してください。
• システムに影響を与える可能性のある領域の初期指標を得るために、評価段階と導入段階で一部の DevOps メトリックを監視することを選択できます。ただし、特に評価段階と導入段階では、満足度とエンゲージメントの基準に重点を置くことをお勧めします。開発者が Copilot を効果的に使用するようになれば、システムレベルの基準が改善される可能性が高くなります。

カテゴリの凡例:

開発者の満足度 - 😃
開発者のエンゲージメント - 👩‍💻
スピード - 🏎️
品質 - ✨

基準	定義	段階	ソース データの場所
Copilot の使用満足度 - 😃	ワークフローにおいて Copilot を重視している Copilot ユーザーの数。	すべて	Copilot の影響調査: • Copilot が使えなくなったらどう思いますか?
Copilot を使用するメリット - 👩‍💻	ユーザーが Copilot を活用する領域の範囲と、得られるメリットの範囲/程度。	すべて	Copilot の影響調査: • Copilot を使うと、私は… • Copilot を使うと、チームは… • この 1 週間、Copilot を使ってみて… • GitHub Copilot を使って…
Copilot を使用する上での課題 - 👩‍💻	潜在的な導入障壁の影響を受けるユーザーの数。	すべて	Copilot の影響調査: • Copilot のトライアル中にどのような課題に直面しましたか?
提供されたイネーブルメント - 👩‍💻	シートを持ち、リソース/トレーニングのイネーブルメント セッションを受講したユーザーの数。	すべて	Copilot の影響調査: • 次の GitHub Copilot イネーブルメント資料のうちどれを受け取りましたか?
1 ヶ月あたりの 1 日平均アクティブ ユーザー数 - アクションの完了数 - 👩‍💻	特定の日に 1 件以上の提案を受け取ったユーザー数。	すべて	Copilot メトリック API: • API でアクティブ ユーザー数 (アクションの完了数) の 28 日間の平均を取得する
1 日平均アクティブ ユーザー数 - チャット数 - 👩‍💻	特定の日に 1 回以上のチャットを行ったユーザー数。	すべて	Copilot メトリック API: • API でアクティブ ユーザー数 (チャット数) の 28 日間の平均を取得する
1 日平均アクティブ ユーザー数 - 合計 - 👩‍💻	特定の日に 1 件以上の提案を受け取って受け入れた、または 1 回以上のチャットに参加した一意のユーザー数。	すべて	Copilot メトリック API: • API でアクティブ ユーザー数 (合計) の 28 日間の平均を取得する
配信された提案数 - アクションの完了数 - 👩‍💻	IDE で Copilot のアクションを完了した場合にコード エディタに表示される 1 日あたりの提案数。	すべて	Copilot メトリック API: • 提案の数
受け入れ数 - アクションの完了数 - 👩‍💻	1 日あたりの受け入れられた提案の数 (部分的に受け入れられた提案とそのまま受け入れられた提案の合計)。	すべて	Copilot メトリック API: • チャット/コードの受け入れ数
受け入れられたコード行数 - アクションの完了数 - 👩‍💻	1 日あたりの受け入れられたコード行数 (部分的に受け入れられたコード行とそのまま受け入れられたコード行の合計)	すべて	Copilot メトリック API: • 受け入れられたコード行数 - アクションの完了数
受け入れ率の合計 - アクションの完了数 - 👩‍💻	受け入れられた提案 (そのまま受け入れられた提案と部分的に受け入れられた提案の合計)/提案の合計数	すべて	手動による計算 (Copilot メトリック API に基づく): • 提案の数 • 受け入れの数
支払いサイクルに追加された新しいシート数 - 👩‍💻	この支払いサイクル中に組織メンバー用に購入された追加のシート数	導入、最適化、維持	支払いと計画 (Copilot) (組織用の設定) • この支払いサイクル中に追加された新しいシート数
休止中のユーザー - 👩‍💻	最後に Copilot を使用したのが ʺnʺ 日以上前のユーザー数	導入、最適化、維持	Copilot アクセス管理 (組織用の設定): • 最後に使用した順に並べ替える
完了したプルリクエストの合計数 - 🏎️	特定の週に完了したプルリクエストの合計数	導入、最適化、維持	GitHub PR リスト (リポジトリ内) は、ある期間のクローズ済み PR でフィルター適用できます
開発者あたりのプルリクエスト数 - 🏎️	プルリクエストの数/コード コントリビュータ数	導入、最適化、維持	手動による計算: • GitHub PR リスト (リポジトリ内) は、ある期間のクローズ済み PR でフィルター適用できます • リポジトリにコントリビュートしている開発者に関する組織のデータ
マージにかかる時間 - 🏎️	PR のオープンからマージまでの平均時間	導入、最適化、維持	GitHub: 計算では組織の GitHub 設定を考慮する必要があります
PR のリード タイム - 🏎️	PR のオープンから展開までの平均時間	導入、最適化、維持	GitHub Actions: 計算では組織の GitHub 設定を考慮する必要があります
コード レビューにかかる時間 - 🏎️	プルリクエストあたりの平均コード レビュー時間 (PR のオープンから PR のクローズまでの時間)	導入、最適化、維持	GitHub: 計算では組織の GitHub 設定を考慮する必要があります
プルリクエストのマージ率 - ✨	特定の週に完了したビルド成功の合計数	導入、最適化、維持	GitHub: GitHub PR リスト (リポジトリ内): マージされた PR の数/送信された PR の数
ビルド成功の合計数 - ✨	正常にマージされたプルリクエストの割合	導入、最適化、維持	GitHub Actions: 計算では組織の GitHub 設定を考慮する必要があります
障害率の変更 - ✨	本番環境で障害を引き起こしたコード展開の割合	導入、最適化、維持	計算では、組織の GitHub 設定とサードパーティ アプリケーションとの統合を考慮する必要があります
未解決のセキュリティ脆弱性の数 - ✨	GHAS によって特定された未解決の脆弱性の数	導入、最適化、維持	組織レベルのセキュリティに関するインサイトの数
継続的インテグレーションの成功率 - ✨	テスト自動化を含む成功した継続的インテグレーション実行の回数/試行された継続的インテグレーション実行の回数	導入、最適化、維持	計算では、組織の GitHub 設定とサードパーティ アプリケーションとの統合を考慮する必要があります