GitHub Copilot のロールアウトで成功を収めるためのヒント

GitHub Copilot を開発チームにロールアウトする方法の詳細は、最終的に組織と組織のニーズにより異なりますが、ロールアウトの成功にはいくつかの共通する要素があります。GitHub Copilot を使い始めたばかりでも、組織全体で既にチームが使用している場合でも、慎重にロールアウトを行い、これらの要素を念頭に置くことで、投資対効果の向上を実現できます。

このガイドの学習内容

• ロールアウトを計画する際の考慮事項

• セルフサービス ライセンシング モデルによる導入の合理化

• 社内トレーニングを実施する際の留意点

最初のロールアウトの規模を慎重に検討する

GitHub Copilot を全ての人が一度に利用できるようにするのは素晴らしいことですが、予期せぬ影響が出る可能性もあります。GitHub Copilot の需要が多く、エンジニアリングに重点を置いている組織であれば、このアプローチを採用することも理に適っているかもしれません。しかし、そうした組織以外は、潜在的な阻害要因を発見し、成功事例を共有するために、最初は小規模で慎重にロールアウトする方が良いでしょう。

最初のロールアウトの規模をどうするかは組織の規模と性質により異なります。自分が管理しやすい規模を選択してください。組織全体で数百人、数千人の開発者がいる場合よりも、十数人の開発者と作業する方が、導入状況の測定やフィードバックの取得が簡単です。また、立ち上げ時に少人数で集中的に取り組むことで、社内のチャンピオン、つまり、導入の促進を支援してくれる組織内の影響力のある開発者を見つけやすくなります。

どのチームが GitHub Copilot の使用を最も熱望し、最も恩恵を受けそうかを考えてみてください。そのチームから開始して、広範囲に展開する準備が整うまで、一度に 1 チームずつアクセス権を付与すると良いでしょう。

セルフサービスを採用し、リマインダーを送信する

GitHub Copilot の使用を希望する人が簡単に使えるようにします。特に成功している組織の中には、開発者が承認なしで GitHub Copilot ライセンスを請求できる、完全なセルフサービス モデルを提供しているところもあります。GitHub Copilot のロールアウト準備が整う頃には、開発者はアクセスを切望しているでしょう。ライセンスの使いすぎを心配されるかもしれませんが、多くの組織は最初は逆の問題を抱えています。つまり、ライセンスを使おうとする開発者はそれほど多くありません。開発者がライセンスを取得するために完了しなければならない承認の数を合理化することで、開発者はアクセスできるようになるまでの時間を短縮できます。組織のライセンシング プランを作成するためのヒントについては、GitHub のユーザー管理の戦略ガイドを参照してください。

開発者が GitHub Copilot に初めてアクセスすると、歓迎の旨と開始手順が記載されたメールが届きます。開発者はメールを読んだきり実行に移さず、メールについて完全に忘れてしまうことがよくあります。リマインドのメールやメッセージを共通のチャネルに送信することで、開発者に GitHub Copilot のインストールと利用を促すことができます。なお、この作業はセルフサービスを導入することでさらに簡素化できます。チームの GitHub Copilot の使用例を紹介するのも利用を促す良い方法です。

技術的な障害になりそうなものを特定して文書化する

新しいツール導入の場合と同様に、GitHub Copilot を特定のテクノロジー スタックと統合するには、特定の考慮事項があります。たとえば、IT チームが GitHub Copilot をファイアウォールの許可リストに追加したり、ネットワーク プロキシの設定を必要とする場合があります。稼働を開始するためにユーザーが行う必要がある環境固有の作業を特定し、これらの情報を全て文書化して、最新の状態に保ちます。 

これらの潜在的な問題を見つけて解決するには、全社的なロールアウトではなく、小規模で慎重なフォーカス グループから始めることをお勧めします。利用時のフィードバックを提供できるユーザーを最初にオンボーディングすることで、これらの課題を事前に特定して解決できます。

経営陣との連携を重視する

GitHub Copilot で規模を拡大することに成功した組織は、一般的に経営陣の強い賛同を得ています。ツールの使用が経営陣から奨励される場合、開発者がそのツールを使用できるかどうか、またはどのように使用できるかについて疑問の余地はありません。

経営陣と話し合い、GitHub Copilot のロールアウトに賛同してもらえるようにすることが重要です。経営陣に懸念事項があれば対処し、GitHub Copilot の戦略について組織全体でステートメントを発表することを依頼します。経営陣からのよくある質問や懸念に対する回答は、GitHub Copilot Trust Center や、このラーニングパスの他のガイドに記載されています。選ばれた開発者グループとのトライアルや概念実証を既に実施している場合は、GitHub Copilot の効果を測定したデータを会話に取り上げる良い機会です。

インフルエンサーに力を与える

日常生活でもそうですが、他者の影響で、製品の導入が進むことはよくあることです。これを利用して、早い段階で影響力のある開発者や管理者を選ぶことで、導入を推進することができます。彼らの熱意と働きかけにより、他の人たちが進んで GitHub Copilot を導入して使用するようになります。たとえば、Shopify の副社長兼エンジニアリング責任者である Farhan Thawar 氏は、GitHub Copilot を愛用している主任技師にビデオインタビューを行い、そのビデオを社内で共有して導入を促進しました。

トレーニングを開催する

開発者は、GitHub Copilot のベスト プラクティスや、いつ、どこで使用できるかについて疑問を持つでしょう。GitHub Copilot に関する「ランチミーティング」を開催して、自社の導入戦略やベストプラクティスを共有したり、質問に答えたりすることで、成功を収めているお客様もいます。これは、既に GitHub Copilot を使っている人がさらに GitHub Copilot を活用できるようにするだけでなく、導入を促進する社内マーケティングにもなります。社内のインフルエンサーにサポートを求める良い機会です。

質問に回答したり、トレーニング セッションを設計したりする際に参考になるリソースをいくつか紹介します。

• GitHub Copilot がデータを処理する方法

• GitHub Copilot Trust Center

• プロンプト エンジニアリングと LLM に関する開発者向けガイド

• GitHub Copilot の使い方: プロンプト、ヒント、ユース ケース

GitHub Copilot を Cisco のビジネス グループに所属する 6,000 人の開発者にロール アウトしたとき、熱意と興奮を持って受け入れられましたが、多くの疑問も残っていました。GitHub プレミアム サポート チームと協力して GitHub Copilot の使用方法を説明し、便利なプロンプトを書くためのベスト プラクティスを提供し、GitHub Copilot のユニークな機能を実演する一連のトレーニング セッションを開催して質疑応答の場を設けました。その後すぐに、開発者は日々の開発で GitHub Copilot を自信を持って使用できるようになりました。本当に役に立ったのは、開発者の質問や懸念を事前に把握し、質疑応答セッションで初期の懸念に対処できるよう、セッションの内容を概要的なものに保つことができたことです。

Brian Keith // Cisco Secure、エンジニアリング ツール部門責任者 // Cisco

シートのプロビジョニングを計画するまで、ロールアウト戦略は完了しません。次に、この点について説明します。