GitHub Copilot の影響を測定する
GitHub Copilot は、開発者がより良いコードをより速く、より楽しく書くのに役立ちます。私たちは、お客様やパートナーと共に、その影響を測定する方法を継続的に学習しています。たとえば、GitHub および外部リサーチャーは両者とも GitHub Copilot が提供した制御実験やフィールド調査でプラスの効果を確認しました。
予測テキストの使用により、タスクの完了が 55% 高速化
8 つの要素で品質が向上 (読みやすさ、エラーの少なさ、保守性など)
多くの企業が「GitHub Copilot がチームにこうしたメリットをもたらしていることを把握するにはどうすればよいか」という疑問を持つのは当然のことです。この疑問にお答えするため、このガイドでは 4 つのステージで影響を評価するためのフレームワークを紹介します。
このガイドの学習内容
初期導入から持続的な効率化まで、4 つのステージで GitHub Copilot の影響を評価する方法。
システムレベルの指標における GitHub Copilot の影響の先行指標として、開発者調査とテレメトリ データを使用する方法。
GitHub Copilot がもたらす可能性のあるシステムレベルの改善を計画し測定する方法。
GitHub Copilot の導入ステージ
最初の 2 つのステージ (評価と導入) ではコーディング作業にできる限り近い先行指標に焦点を当てます。開発者の自己申告データと、GitHub の既存のテレメトリを組み合わせて活用します。この戦略を採用すると、(a) 今後の影響を確実に予測できるとともに、(b) 可観測性への追加投資を比較的少なく抑えて評価を実施できます。
開発生産性の客観的な測定は、不可能ではないものの難しい作業です。当社では、どのように時間を使っているのか、何が障害になっているのか、どのようなツールが役に立っているのかを開発者に尋ねるのが一番であろうと考えました。GitHub Copilot を使用している開発者の圧倒的大多数が、少なくとも週に 1 度は使用する有益なツールであると言っていることから、投資を正当化するに十分であることは間違いありません。
3 番目と 4 番目のステージ (最適化と持続的な効率化) に進むにあたり、エンジニアリング リーダーは組織の具体的な目標を評価基準に組み込んでください。これらのステージでは効率性の向上 (例: コスト/労力、市場投入までの時間、リスクの測定に基づく) と、志向性の向上 (例: もたらされた価値の測定に基づく) に焦点を移します。
全てのステージにおいて、組織レベルまたはチーム レベルで測定することをお勧めします。同じサービスまたはアプリケーションにコードをコミットするワークグループの境界に沿って測定するのが理想的です。これにより、チームは同様の作業を実行する開発者の影響を評価できます。
では、4 つの各ステージについて、具体的な目標、手法、関連するメトリクス、次の測定ステージに進むための基準を見ていきましょう。
評価
目標: GitHub Copilot を大規模に導入/却下するためのテクニカル ケースとビジネス ケースを作成する。
手法: 開発者調査やユーザー エンゲージメント測定を使用して、(コーディング作業に近い) 影響の先行指標を評価する。
関連するメトリクス (用語集を参照): Satisfaction using Copilot, Benefits of using Copilot, Challenges of using Copilot, Enablement provided, Average daily active users per month - completions, Average daily active users - chat, Average daily active users - total, Suggestions delivered - completions, Number of acceptances - completions, Lines of code accepted - completions, Total acceptance rate - completions
終了基準: アクティブなトライアル参加者の 40% 超が GitHub Copilot にアクセスできなくなることを「非常に残念である」と回答する (調査を参照)。
評価中、ほとんどの組織は単に次の点についての判断を望んでいる: GitHub Copilot は大規模に導入する価値があるか?
結局のところ、ほとんどのチームが望んでいるのは質の高いソフトウェアを迅速かつ安全にリリースすることです。とはいえ、市場投入までの時間、デリバリーにかかるコスト、セキュリティ態勢、人材定着率などは評価に時間がかかる遅行指標です。さらに、このような遅行指標は人員配置の変更、ビジネスの優先事項、技術的課題などの外的要因に影響される可能性があります。
このため、投資収益率やエンジニアリング スコアカードに新しいメトリクスを追加する前に、先行指標を検討することをお勧めします。先行指標にはエンジニアリング調査による自己申告データと、GitHub の既存テレメトリの両方の組み合わせを含めてください。
ツールとリソース
開発者調査: 開発者が自身のツールチェイン内で有益か有害かを評価できる、当該分野のエキスパートであることを示す十分な調査があります。GitHub は開発者が自身の仕事に対する GitHub Copilot の影響を批判的に評価できると信じています。調査は比較的簡単に実施できるため、今後の影響を迅速かつ確実に予測する手段としても効果的です。開発者を対象とした GitHub Copilot 調査の質問では、GitHub Copilot のメリットやデメリット、用途についてのデータを得ることができます。
ユーザー エンゲージメント データ: 調査の回答に加え、Copilot Metrics API と Copilot User Management API を使用して、開発者の GitHub Copilot 使用状況に関する測定結果を得ることができます。Average Daily Active Users などの指標により、
Average Daily Active UsersTotal Acceptance RateTotal Acceptance Rateでさらなる取り組みが必要な箇所を特定できます。
導入
目標: 対象とするチームが GitHub Copilot を有効にして積極的に利用する。
手法: 引き続き、先行指標と有効化指標に焦点を当てる。より広範なシステムへの影響の初期兆候が見られる可能性があります。
関連するメトリクス (用語集を参照): 評価ステージの全ての指標に加え、次のような指標が該当。New seats added in billing cycle, Dormant users, Total completed pull requests, Pull requests per developer, Time to merge, PR lead time, Average code review time in hours, Pull request merge rate, Total successful builds, Change failure rate, CI success rate, Open security vulnerabilities
終了基準: コミットされたライセンスの 80% 超が割り当てられてアクティブになっている状態。かつ、システムレベルのメトリクスに中立的以上の影響がある場合。
組織全体で GitHub Copilot の使用を拡大する場合は、評価中に使用する指標をモニタリングするほか、GitHub Copilot 請求とプランダッシュボードを使用して、さらなる取り組みが必要な箇所を把握することを検討しましょう。
インサイト: Microsoft research によると、ユーザーが AI ツールの使用による満足度と生産性の向上を十分に実感するまでに 11 週間かかります。
2022-2023 年に実施した、GitHub Copilot の影響に関するランダム化比較試験 (RCT) では、処置を受けたグループ (GitHub Copilot にアクセスできる開発者) が有効化のリマインダー メールを受け取った場合、2 週間のうちに 26.4% の導入者増が見られました。
ツールとリソース
次のツールとリソースは導入ステージでの有効化と評価ステージでのエンジニアのトライアル参加を後押しする際に役立ちます。
Microsoft Learn: GitHub Copilot : GitHub Copilot の使用についてのコース (無料)
GitHub Copilot の使用を開始する: VS コードの使用を始めるユーザー向けの動画チュートリアル
GitHub コミュニティ Copilot Discussions: 管理者および開発者向けの優れたリソース。貴重な情報やヒントが満載
GitHub Copilot のドキュメント: 使用開始からトラブルシューティングや機能拡張まで、全てを網羅するドキュメント
調査の回答や API による測定で、高いレベルの製品適合性が見られない場合、エンジニアが抱えている可能性のある課題を理解してさらなる取り組みを実現できるよう、フォローアップ インタビューの活用をお勧めします。
独自に開発者アンケートを実施すれば、エンジニアリングの取り組みについて学び、改善できますが、何よりも先にその動機付けについて考えなければなりません。例えば、当社では、開発者ツールの全体的な満足度を評価すること、どの問題に対処すべきかを優先順位付けすること、それらの問題への対処がどの程度うまくいったかをグラフ化することの 3 つの主要な目標を掲げています。これらの目標は質問する際の指針となります。
同様に、質問の作成にはさまざまな利害関係者に手伝ってもらうことをお勧めします。当社では、Shopify の人材調査とインサイト チームのデータ サイエンティスト、さまざまな部署のディレクターや副社長、さまざまな分野の専門家と協力し、質問を作成して改良しています。
アンケート疲れは実際の業務に支障をきたすことがあるため、アンケートは簡潔なものになるよう心がけています。年に 2 回実施する大規模な開発者アンケートの所要時間は 15-20 分程度ですが、一度にアンケートを送信するのは会社の半分に対してのみであり、再度アンケートを受ける必要もありません。また、アンケートは比較的シンプルなものにするよう心がけており、参加者が文章を 1-5 の 5 段階で評価する「5 ポイント リッカート」を多く採用しています。
ほとんどの組織は開発生産性と開発有効性の向上を常に追求しています。既にチームのエンジニアリング スコアカードに含まれている指標 (PR リードタイム、ストーリー ポイント、変更失敗率など) の改善が見られている可能性もありますが、このステージではその改善に焦点を当てるべきではありません。代わりに、チームが日常業務に新しいツール (ここでは GitHub Copilot) を取り入れる際の変化に対応することに注力しましょう。GitHub Copilot のデプロイ中に、エンジニアリング スコアカードのいずれかの指標で低下が見られた場合、一度立ち止まって根本原因を突き止めましょう。GitHub Copilot がその一因となっている場合は、必要に応じて有効化戦略やデプロイ戦略を変更します。開発者が適切なトレーニングを受け、サポートが必要なときにリソースを利用できるよう徹底します。チームの日常的なエンジニアリング業務に GitHub Copilot を完全に取り入れたら、組織の目標 (市場投入までの時間の短縮、デリバリーにかかるコストの削減、リスクの低減など) に特化したシステムレベルの改善実現に集中できます。
最適化
目標: 組織固有の目標に良い影響をもたらす。
手法: 効率の向上を実現し、プラスのビジネス成果 (市場投入までの時間の短縮やデリバリーにかかるコストの削減など) に導く。
関連するメトリクス (用語集を参照): 導入ステージと評価ステージのあらゆる指標に加え、組織の目標に応じた指標。
終了基準: コミットされたライセンスの 80% 未満が割り当てられてアクティブになっている状態。かつ、組織の目標とするシステムレベルの指標でプラスの影響をもたらすことが文書化されている。
チームが GitHub Copilot を導入したら、組織にとって最も重要なシステムレベルの改善に集中できるようになります。組織はそれぞれ異なります。組織によっては、品質目標は達成しているものの、速度向上を希望している場合もあります。コード スメルや技術的負債という問題を抱えている場合もあります。
GitHub Copilot の影響を最適化して長期的に持続させる包括的な 3 段階のプロセスをお勧めします。
1. システムレベルの目標を設定する
組織にとって最も重要な、システムレベルの目標を決めます。複数の指標を考慮して持続可能な改善策を講じる全体的な視点をお勧めします。品質とスピードの両方の指標をモニタリングし (一方が主な視点であったとしても)、意図しない結果にできる限り早く気づくようにします。開発者の満足度とエンゲージメントに関する先行指標はシステムレベルの改善を支えるため、これらの指標に引き続き焦点を当てます。価値を正当化し最大化するために、組織によってはビジネス バリュー エンジニアリングの指標を選択する場合があります。
システムレベルの目標 (以下のステップ 3 を参照) に向けた進捗状況を測定するにつれ、目標を変更したり、GitHub Copilot の実装だけでなく有効化を実現したりする必要が生じる場合もあります。
ヒント: 目標にあった戦略計画を立てましょう。チームのクリティカル マス (通常は 80% 超) が GitHub Copilot を導入したら、下流のエンジニアリング指標で目に見える影響を期待できるのはもっともです。ただし、これはエンジニアリング リーダーが余剰能力を有意義な目標に充てる場合に限ります。開発者が適切な指示を受けなければ、余剰能力はさまざまな取り組みに散らばってしまい、影響が目立たなくなる可能性があります。
組織がチームに多大な自主性を与えている場合、状況によっては、(a) どの程度の余剰能力を (b) どこに充てているかを記録しておく必要があります。これにより、システムレベルの指標への影響を最大限に測定できるようになります。
2. 目標を測定できるツールを設定し利用可能にする
組織によってはエンジニアリング システムが GitHub プラットフォームの枠を超えて拡張されている場合があります。システムレベルの目標を測定できるようにするために、追加のデータ ソースを活用する必要があるかどうかを検討しましょう。SPACE フレームワークには目標に向けた進捗状況の測定に役立つ、システムレベルの指標の例が示されています。
3. 指標をモニタリングする
システムレベルの指標をモニタリングする頻度を決めます。多くの場合、この頻度はエンジニアリングの頻度に合わせます。お勧めは週に 1 回または 2 週間に 1 回までです。多くのチームでは月次の「エンジニアリング基礎」レビュー ミーティングでエンジニアリング スコアカードを調べることにしています。同時に、GitHub Copilot のエンゲージメントに関連する定量的指標 (Copilot Metrics API と組織とプランダッシュボード) も継続的に観察します。また、少なくとも 6 か月単位で GitHub Copilot 調査を継続的に使用することもお勧めします。使用状況に関する潜在的な懸念を早い段階で把握するためです。または、GitHub Copilot に関する質問を組織の開発者向けの調査に組み込んだり、GitHub Copilot エクスペリエンスを確認するために同期的なフィードバックの機会を設けたりします。
ヒント: 多くのリーダーは GitHub Copilot からの投資収益率 (ROI) の数値化を希望しています。コーディング以外の影響は間接的なものですが、下流の可能性は無限にあります。このため、コード カバレッジ、完了のストーリー ポイント、サイクル タイムのような、システムレベルの指標で因果関係を探る場合は注意が必要です。GitHub Copilot がさまざまなシステムレベルの指標に影響する可能性は高いものの、優先順位の変更、スタッフの変更、ライブサイトの停止、開発段階など、さまざまな要素がシステムレベルの指標に影響する可能性があります。状況ダイナミクスが強力な場合、GitHub Copilot は推進力となるよりも、緩和要因となる可能性が高いといえます。
持続的な効率
目標: 継続的な評価と改善。
手法: チーム構成とビジネス目標の両方が変わった場合に、GitHub Copilot による影響に適応して維持する。
関連するメトリクス (用語集を参照): 導入ステージと評価ステージのあらゆる指標に加え、組織の目標に応じた指標。
組織は時間とともに変わります。最適化ステージでの指標を、エンジニアリング システム内で変更が必要な箇所についてのフィードバックとして活用しましょう。優先順位の変更や目標の変更、システムレベルの代替指標の検討が必要になる可能性のあるビジネス要因に注視しましょう。また、GitHub Copilot の使用を継続する場合でも、調査と定量的エンゲージメント指標の分析を継続して、全ての開発者が GitHub Copilot の影響を実感できるよう徹底します。特定した障壁に対処して、必要となる追加の有効化を提供します。
詳細を確認するには
GitHub Copilot の影響を測定するアプローチは、GitHub が実施した数多くの調査結果に基づくものです。
私たちは GitHub Copilot の有効化に焦点を当てる必要性と、多様でコンテキストに大きく左右されるシステムレベルの影響について一貫して調べてきました。だからこそ、GitHub Copilot がエンジニアの生産性と満足度に与える影響を実感したうえで、システムレベルの目標を決めることをお勧めします。また、エンジニアリングチームに GitHub Copilot による生産性向上の方向性を伝える場合は、明確さと一貫性に留意しましょう。
GitHub は持続可能で安全かつ生産性の高いエンジニアリング システムの一環として AI を活用する方法について、お客様やパートナーとともに学び続けることに尽力しています。今後もさまざまなデータを共有していきます。
では次に、内部の AI ポリシーとガバナンスを形成して、適切かつ効果的な使用を促す方法を見てみましょう。
次の内容: AI ポリシーとガバナンスで開発者を支援するGitHub Copilot の使用を開始する