このガイドは、エンジニアリング システムの改善を推進するための戦略とメトリックを推奨する GitHub の「Engineering System Success Playbook (エンジニアリング システム サクセス プレイブック)」(ESSP) からヒントを得ています。
Copilot のロールアウトを開始する場合は、目標を定義し、それに応じてロールアウトを計画し、スタッフに目標を明確に伝えることをお勧めします。 「GitHub Copilot を使って会社のエンジニアリング目標を達成する」をご覧ください。
1. 成功への障壁を特定する
ESSP が推奨する最初の手順は、会社の改善を妨げている障害を明確に理解することです。 現在のベースライン、目的とする将来の状態、進歩を妨げる障壁を理解することで、的を絞った効果的な変更を行うことができます。
Teams では、レビュー サイクルが長引いために pull request のマージが遅れることがよくあります。 多くの場合、このような遅延の原因は次のようなものです:
- 理解するのが難しい複雑なコード変更
- レビューを困難にする一貫性のないコードの書式設定
- 変更に関して提供されるコンテキストの一般的な欠如
- レビューを遅くしたりレビューへの対処を難しくしたりする社会的要因
レビュー担当者は、運用時の問題につながる可能性がある小さなエラーを簡単に見逃す可能性もあります。
そのために、開発プロセスでボトルネックが発生し、機能の全体的なデリバリーが遅れ、品質が低下します。
2. オプションを評価する
次の手順では、手順 1 で特定した障壁に対処するための解決策を評価し、同意します。 このガイドでは、特定した目標に対して GitHub Copilot がどのような影響を与え得るかに焦点を当てます。 新しいツールのロールアウトを成功させるには、カルチャとプロセスを変更する必要もあります。
パイロット グループを使用して新しいツールとプロセスの試用版を実行し、フィードバックを収集し、成功を測定します。 試用中に使用するトレーニング リソースとメトリックについては、3 を参照してください。セクションを監視するための変更とメトリックを実装します。
<a href="https://github.com/enterprise/contact?ref_product=copilot&ref_type=engagement&ref_style=button" target="_blank" class="btn btn-primary mt-3 mr-3 no-underline">
<span>営業に問い合わせる</span><svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-link-external" aria-label="link external icon" role="img"><path d="M3.75 2h3.5a.75.75 0 0 1 0 1.5h-3.5a.25.25 0 0 0-.25.25v8.5c0 .138.112.25.25.25h8.5a.25.25 0 0 0 .25-.25v-3.5a.75.75 0 0 1 1.5 0v3.5A1.75 1.75 0 0 1 12.25 14h-8.5A1.75 1.75 0 0 1 2 12.25v-8.5C2 2.784 2.784 2 3.75 2Zm6.854-1h4.146a.25.25 0 0 1 .25.25v4.146a.25.25 0 0 1-.427.177L13.03 4.03 9.28 7.78a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042l3.75-3.75-1.543-1.543A.25.25 0 0 1 10.604 1Z"></path></svg></a>
Copilotがどのように役立つか
GitHub Copilot には、pull request レビュー プロセスを高速化し、コードの品質を強化し、コラボレーションを向上させ、最終的にマージ時間を短縮するように設計された一連の機能が用意されています。
Copilotの機能を活用することで、チームはワークフローを合理化し、摩擦を減らし、一貫性のある高品質のコードを確保できます。
完全で役立つ PR の概要を生成する
Copilot は、明確で簡潔な PR の概要を自動的に生成し、開発者の時間を節約し、PR の目的と変更をレビュー担当者が簡単に理解できるようにします。 これにより、誤解の可能性が減り、レビュー プロセスの速度が上がります。
レビュー プロセスの間にレビュー担当者を支援する
GitHub Copilot は、強力な PR レビュー コンパニオンとして使用できます。
- Copilot は、PR が何を提供しているのかを校閲者がより迅速に理解できるように、複雑なコード変更を説明するのに役立ちます。
- Copilot では、リポジトリ全体にわたるコンテキストに対応した提案と潜在的なコード改善を、 GitHubの pull request レビュー インターフェイス内で直接提供でき、レビュー担当者が潜在的な問題をキャッチし、建設的なフィードバックをより効率的に提供するのに役立ちます。
- Copilot は、レビュー担当者が明確で一貫性があり、効果的なレビュー コメントを下書きし、書き込むのに役立ちます。
Organization のガイドラインに基づいてレビューする
- Copilot では、プル要求を開く前に IDE のコード変更を確認したり、pull request にレビュー担当者として割り当てたりすることができます。
- ルールセットを使用すると、カスタム条件に基づいてプル要求を体系的に確認する Copilot を設定できます。
- レビュー用のカスタム手順により、 Copilot は組織のコーディング標準とベスト プラクティスを適用し、潜在的な違反に自動的にフラグを付け、修正プログラムを提案することができます。
これらの機能は、コードベース全体の一貫性を保証し、開発プロセスの早期にエラーを把握するのに役立つので、手作業でのコード レビューの必要性が減り、開発者とレビュー担当者の時間が節約されます。
コードの修正を提案する
pull request レビュー コメントに基づいて、 Copilot は、pull request 作成者がレビューを解決するために必要なコード変更をすばやく実装するのに役立ちます。
文化に関する考慮事項
GitHub Copilot のロールアウトに加えて、自分の目的の達成を妨げる可能性がある社会的な要因や文化的な要因に対処します。
次の例は、ESSP の "アンチパターン" セクションから抜粋したものです。
- チームは、リリースまでの待ち時間が長すぎるために大量のコードを一度に配置することがあります。 これは、頻繁なリリースでの不安定化への恐れ、CI/CD パイプラインの成熟度の欠如、または厳格なコンプライアンス要件が原因で発生する可能性があります。
- 開発者は、コードを完全なものにするために時間をかけすぎたり、不要な機能の追加で時間を無駄にしたりすることがあります。 これは、完璧主義の文化や効果的な優先順位付けの欠如が原因である可能性があります。
- 開発者は、単純な問題のために過度に複雑な解決策を構築する場合があります。 これは、不必要な将来的保証の願望や、複雑さを通じて価値を高める圧力が原因である可能性があります。
3. 変更を実装する
障壁を克服するための適切なアプローチを特定したら、特定したソリューションをスケーリングします。 新しいツールまたはプロセスのロールアウトを成功させるには、ロールアウトの各部分に所有権を割り当て、目標について透過的に伝え、効果的なトレーニングを提供し、結果を測定します。
このセクションでは、開発者向けのシナリオ例、ベスト プラクティス、リソースについて説明します。 このセクションでは、従業員が Copilot を目標に沿った方法で使用できるように 、コミュニケーションとトレーニング セッションを計画 します。
- 役に立つ pull request の概要を作成する
- Copilotをレビュー アシスタントとして使用する
- レビュー担当者として Copilot を追加する
- レビュー コメントの実装で支援を受ける
- 開発者向けのベスト プラクティス
- リソース
役に立つ pull request の概要を作成する
- pull request を作成するときに、[説明の追加] フィールドの Copilot アイコンをクリックし、[ 概要] をクリックします。
-
Copilot は、プル要求をスキャンし、散文で行われた変更の概要と、影響を受けるファイルの変更の箇条書きリストを提供します。 -
Copilotの説明に満足していることを確認します。 - レビュー担当者が pull request の作業を行うときは、レビューを残すために必要なすべてのコンテキストが揃っています。
Copilotをレビュー アシスタントとして使用する
レビュー担当者として pull request にジャンプするときは、 Copilot を使用してレビューを高速化できます。
-
Copilotするには、**** を使用します。-
ファイルに加えられた変更を要約するように Copilot に依頼します。特に、差分が長くなる場合に役立ちます。 ファイルの右上にある をクリックすると、差分内の特定のファイルを選択できます。
![Pull request の [変更されたファイル] タブのスクリーンショット。[この差分について Copilot に尋ねる] オプションが赤で強調されています。](/assets/cb-114020/images/help/copilot/ask-to-explain.png)
-
特定の行の変更については、理解を深めたい行を強調表示し、 Copilot に変更内容を説明するよう依頼します。 一連の行を強調表示にするには、最初に一番上の行番号をクリックし、Shift キーを押しながら、差分の一番下の行をクリックします。
![Pull request の [変更されたファイル] タブのスクリーンショット。複数行の選択が強調表示され、ドロップダウンに [説明] オプションが表示されています。](/assets/cb-77888/images/help/copilot/highlight-lines.png)
-
-
**PR レビューをCopilotと共同で行います**。 Copilot に指示を出す前に、特定のファイルの差分を会話に添付することを忘れないでください。-
PR の変更に関する独自の意見を Copilot に尋ねるには、次の質問を行います:
Provide your judgement as a PR Reviewer, both for functional and non-functional aspects that these changes bring。 このプロンプトで、コードの機能面と非機能面の両方を考慮するように Copilot に求める点に注意してください。 -
独自の PR レビュー コメントについては、 Copilot に第 2 の意見を求めます。
As my peer reviewer on this pull request, give me your feedback on my own review: YOUR-REVIEW-COMMENT. Do you think it's pertinent? Am I missing something?
-
-
Copilotと共同作業して、レビューコメントを下書きし、洗練させる。- Copilotを使用してレビューを計画した後、指定する必要があるコメントの一覧を表示するように求めることができます:
Make a list of review comments to add to the PR and tell me exactly in which file diff and lines each comment should be added。 - Copilotにレビューコメントの最初の下書きを作成してもらったり、投稿前にコメントを絞り込んだりすることもできます:
Help me draft review comments as discussedまたはRefine this review comment to make it clear, concise, and actionable。
- Copilotを使用してレビューを計画した後、指定する必要があるコメントの一覧を表示するように求めることができます:
レビュー担当者として Copilot を追加する
レビュー時間を短縮し、pull request をマージするには、 Copilot コード レビューを体系的に使用します。最初に IDE でプル要求を開き、次に GitHubの PR を使用します。
コード レビュー Copilot 使用しても、人間によるコード レビューの必要性に代わるものではありません。 ただし、上記の手順のようにすると、人間によるレビューをより速く完了するのに役立ちます。
- 開発者は 、pull request を開く前に、 Copilot コード レビューを使用して、すべての変更のレビューを要求する必要があります。
- 管理者は、 保護されたブランチを対象とするプル要求に Copilot をレビュー担当者として自動的に追加するように、リポジトリまたは組織のルールセットを設定する必要があります。
- チーム リーダー は、チームの標準的なスタイルとルールをキャプチャし、 Copilot がレビューでそれらを活用できるように、組織のカスタム指示として設定する必要があります。
- カスタム指示には、コードを読みやすくするスタイル設定に関する最小限の推奨事項のセットが盛り込まれるようにします。これは、pull request のレビュー プロセスの間に役立ちます。
- スタイルの問題による PR レビュー コメントの量を減らすには、リポジトリレベルと組織レベルでの手順にCopilot同じ推奨事項を設定します。 これにより、 Copilot によって生成されるコードは、これらのガイドラインに準拠します。
レビュー コメントの実装で支援を受ける
pull request 作成者は、 Copilotの支援を受けて修正プログラムを迅速に実装することで、PR レビュー コメントの解決を高速化できます。
- Copilot自体によって残されたレビューコメントについては、提案された修正を直接コミットするか、コミットする前にCopilotワークスペースで編集します。
- 同僚が残したレビュー コメントについては、その PR レビュー コメントに関連するファイルの差分に移動し、その差分を コパイロットチャット の会話に添付します。 その後、次のようなプロンプトを使ってレビュー コメントをコピーして貼り付けます:
Suggest a fix for this review comment: - VS Code を使用している場合は、エージェント モードで GitHub Copilot にレビュー コメントから必要な変更を実装するように依頼します。
開発者向けのベスト プラクティス
開発者がすべきこと:
- 問題を早期にキャッチして解決するようにプッシュする前に、IDE で Copilotのレビューを要求します。
- Copilotを使用して、PR 作成者が問題を理解して解決できるように、独自の PR レビュー コメントを計画および調整します。
- Copilotを使用して、特定のコード行を含む関連する差分コンテキストを会話にアタッチします。
開発者がすべきでないこと:
- テストせずに Copilotの提案を適用します。
- レビューはCopilotのみに頼ってください。
- コードの読みやすさを無視します。
リソース
- GitHub Copilotを使用した pull request の概要の作成
- GitHub Copilot を使ったコードレビュー
- GitHub Copilot用のリポジトリカスタム命令の追加
- GitHub Copilotによる自動コード レビューの構成
- GitHub Copilot の組織のカスタム手順を追加する
監視対象のメトリック
新しいツールの評価版を評価し、完全なロールアウトで一貫した改善が提供されていることを確認するには、結果を監視し、必要に応じ調整を行います。 品質、速度、開発者の幸福度の重要なゾーンと、これらのゾーンを組み合わせてビジネス成果に貢献する方法を検討することをお勧めします。
この特定の目標に対するCopilotの影響を評価するための指標を以下に示します。
- 開発者の満足度: 開発者アンケートを使って、エンジニアリング ツールに対する満足度を測定します。
- 開発者ごとにマージされた pull request:
pull requestWebhook を使って、actionがclosedであり、mergedオブジェクト内のpull requestプロパティがtrueであることを確認できます。 - Pull request のリード タイム: PR の作成とマージの間の平均時間を測定します。
- Pull request の欠陥のエスケープ率: 適切にレビューされていない PR によって発生したデプロイ問題の発生率を測定します。
- Pull request レビュー コメントの種類: PR レビュー コメントをダウンロードし、AI ベースのトピック分類を使って分類し、設計、スケーラビリティ、戦略に関する人間のレビュー担当者によるコメントを追跡します。