GitHub Copilotの全社導入効果について

ヘッドウォータース(以下、HWS)では2023年4月にGitHub Copilotの全社導入¹を行いました。本記事では、GitHub Copilotの導入効果について紹介します。

※本記事の内容は2023年10月時点での情報をもとに作成しております。

GitHub Copilotとは？

開発者がコードをよりすばやく記述することを可能にする、AIを活用したコード補完ツールです。Microsoft社とOpenAI社により開発され、GitHub社から提供されています。企業向けのGitHub Copilot for Businessでは、1ユーザーあたり19ドル(2023年10月現在)で利用を開始することができ、サポートされているいくつかのコードエディター²で使うことができます。

GitHub Copilotを使うことで、開発者は、断片的なコードからAIによるコード補完を得ることができたり、コメントからコードを自動生成したりすることができます。GitHub Copilotが使用するAIはGitHub上のオープンソースをもとに学習を行っており、GitHub Copilot for BusinessでGitHubに送られる断片的なコードやプライベートリポジトリのソースコードが学習に使われることはありません³。

GitHub Copilotの導入目的について

HWSでは、エンジニアの実装業務効率化による開発スピードの向上とコード品質の向上を主な目的として、GitHub Copilotが導入されました。

より具体的には、以下のような効果を期待していました。
● シンプルなコードを書く時間の短縮
● スペルミスなどのヒューマンエラー低減
● 開発者が初めて実装に利用する開発フレームワークなどの学習補助

GitHub Copilot導入効果検証の方法について

2023年6月~7月にかけて、全社員向けにGitHub Copilot導入についてのオンラインアンケートを実施し、GitHub Copilotが業務の効率化に繋がっているかどうかを調査しました。また、GitHub Copilotを特に積極的に使っている一部の回答者に対しては、追加でインタビューを実施し、具体的なユースケースや使ってみてのリアルな感想などをヒアリングしました。

GitHub Copilotの導入環境について

HWSエンジニアの多くはVisual Studio Codeを利用しており、今回のアンケート回答者は全員がVisual Studio Code上でGitHub Copilotを利用していました。また、今回の調査では使用言語や利用目的は特に制限せず回答を募集したため、エンジニアの開発作業全般における回答結果となっています。

結論

結論としては、基本的には従来のコード補完ツールのように使いつつ、書きたいコードが明確な時はコード提案を採用することで実装効率向上が期待できることがわかりました。ただし、コード提案の利用判断はエンジニア自身が都度判断しないといけない点は注意が必要です。

回答結果から得られた評価サマリー（一部抜粋）はこちら

• エディタの補完機能よりもGitHub Copilotの方が便利である。
• 可読性の向上やチーム開発時の意思疎通に効果的である。
• リファクタリングなど既存コードの改善や修正にはあまり使えないとの意見が多く、その目的にはChat GPTを利用している人が多い。（※今後、Copilot Xに期待）
• 実務経験が浅いエンジニアの方が業務効率の向上を実感していた。（ただし、実務5年以上経験者も56%は向上を実感）
• コード提案にかかる時間が長いと感じている人はほとんどいない。
• コード提案を使うことで自分の実力以上の実装を行えるようになることは少ない。

得意なユースケース例はこちら

• util系の関数定義をする場合や実装頻度の低い処理を書く場合のコード提案。
• 毎回書く必要のあるようなコードの提案。
• チーム開発観点における、新規メンバーが参画した場合のチーム実装ルールのキャッチアップ。
• 得意な言語を持っているエンジニアが知識の少ない言語で実装をする場合のコード提案。
• 経験の浅いエンジニアが静的型付け言語で実装をする場合の型定義に関するコード提案。

あまり得意ではないユースケース例（※2023年7月時点）はこちら

• リファクタリングなど既存コードの改善や修正。
• 外部ライブラリを利用した実装。
• 動的型付け言語のコード提案。
• 実務経験の少ないエンジニアの学習補助観点。

アンケート結果

以下は各アンケート項目の回答結果です。

GitHub Copilotを利用したことで業務効率が向上したと思いますか？

全体の結果としては、63%が向上したと回答した。特に、実務経験5年未満の人で向上したと回答した人は71%となっており、全体の結果よりも高かった。

GitHub Copilotの利用を通して自分自身の実装力が向上したと思いますか？

75%が実装力の向上は感じていないと回答しており、学習補助効果は薄い。

GitHub Copilotを利用したほうが難しい処理の実装ができると感じますか？

75%が効果を実感していないと回答しており、GitHub Copilotを使っても自分の実力以上に高度な実装を行うことの補助効果は薄い。

GitHub Copilotの提案コード採用率はどのくらいですか？

コードの採用率が高い人ほど業務効率の向上を感じている傾向があった。
うまく提案してくれる事が多い利用環境の人ほど効果を感じていると考えられるが、数名のインタビューを通して、「とりあえず提案コードを採用して間違っているところは自分で直す」というスタンスの人ほど結果的にGitHub Copilotの恩恵をより享受できているという可能性も感じた。

GitHub Copilotの提案コードを採用する時・採用しない時の理由

採用する時

・自分が書くよりも分かりやすい。または全てを採用しなくても自分でアレンジを加えることで完成することができる。

・自分の好みやプロジェクト内のコーディングルールを把握して提案してくれるため、違和感なく取り入れることができる。

採用しない時

・コーディングルールに反する時、方向性が違うコードを提案された時。

・明らかに間違っているコードを提案するときもある。

GitHub Copilotを使っていて便利なこと・不便なこと

便利なこと

・基盤作成時などいつも書かないといけないようなソースコードを書く手間が大幅に減った。

・書きたいコードを即座に提案してくれる。型定義や変数名以外にコメントアウトの補完もしてくれる。

不便なこと

・回線状況によって提案まで時間が掛かる時がある。Copilotを導入したことでエディターがもっさり重たくなった。

・補完が明らかに違う時は補完表示が邪魔に感じる。

Appendix ： ファイル認識スコープの検証

※以下はHWSで独自に(そして簡単に)検証した結果であり、公式に発表されている仕様ではないため、内容の正確さは保証されません。参考程度に読んでいただければと思います。

結論

認識ファイルのスコープについて

vscode上で開いているソースコードが提案に利用されます。そのため別プロジェクトのソースコードでもvscode上でファイルを開いていれば提案に利用してくれます。逆に同プロジェクト内でもvscode上で開いていなければ提案には利用されません。

認識ファイル数の上限について

提案に利用するファイル数は20が上限でそれ以上ファイルを開いていると、古いファイルから順に提案へ使われなくなります。ただ提案に使われなくなっても開いているファイルの中から不要なものを閉じて減らすことで再度提案へ利用されるようになります。

ファイル認識スコープの検証方法

・test/test1.pyとtest/test2.pyの二つのファイルを格納しフォルダ外にtest3.pyを作成（図A）
・test1.pyに”2つの引数の合計値を返す関数”を記載（図B）
・別ファイルに同じように計算処理の関数を記載しようとした時、test1.pyを開いている状態と閉じている状態で、プロジェクト内のファイル(test2.py)とプロジェクト外のファイル(test3.py)それぞれで同じフォーマットの提案をしてくれるか検証。

図A

図B

結果

提案してくれた場合は○、してくれなかった場合は×

条件	結果
同ファイル内で似た関数を記載した時	○
test1.pyを開いた状態で、同PJ内の別ファイルに似た関数を記載した時	○
test1.pyを閉じた状態で、同PJ内の別ファイルに似た関数を記載した時	×
test1.pyを開いた状態で、PJ外のファイルに似た関数を記載した時	○
test1.pyを閉じた状態で、PJ外のファイルに似た関数を記載した時	×

→ VSCode上で開いていれば同一プロジェクトかどうかに関わらず提案に使われる。

ファイル認識スコープに関するインタビュー

GitHub Copilotによるファイル認識スコープを意識することはあるか。　また、どの範囲のファイルが認識されていると感じるか

・特に意識はしないが、ソリューションやプロジェクト単位のソースコードまではみている気がする。 外部のモジュールをインストールして使う場合、その使い方まではわかっていない気がする。 開いているファイル上にない情報なのに、なんでこれを提案できたの？と思うことは結構ある。

・体感ですが、少なくともVS Codeで開いているプロジェクト内のファイルは認識されていると思う。 また、同一ファイル内の場合はフォーカス行の前のコードの方が後のコードよりも優先的に認識されているように感じる。

人によっては検証の結果得られた認識スコープ以上に認識されていると感じることもあるようでした。これは大規模言語モデルを使ったコード補完ツールならではの強みで、GitHub Copilotのポテンシャルの高さを表していると思います。

ファイル認識数の検証方法

・開いた状態のファイル全てに適当な汎用的関数を一つ記載しておく
・ファイル認識スコープの検証と同様に、test1.pyに計算処理の関数を記載して、開くファイルの数やファイルの位置を移動させて検証を行った。

結果

検証内容	結果
提案に使うファイル数の上限	20
開いているファイルの位置による提案への影響	なし
使わないファイルを閉じた場合	開いているが上限を超えたことにより提案に使われなくなったファイルが再度提案に使われるようになる

まとめ

GitHub Copilotを導入したことにより過半数のエンジニアが業務効率の向上を実感している事がわかりました。特に自分の書きたいコードが明確に頭の中にあるような場合は、GitHub Copilotの提案によってコーディングの時間を大幅に省略してくれていそうです。また、「GitHub Copilotを使うことの副産物としてコード内のコメントが増えて、結果としてエンジニア間の意思疎通が取りやすくなる」という意見もあり、チーム開発においてさらに効果を発揮するポテンシャルも感じます。一方で、まだ提案内容の精度には課題がありそうなので、そこは今後の改善に期待かなと思います。

本記事が少しでもGitHub Copilot導入検討の参考となれば幸いです。

ヘッドウォータースでは一緒に働くエンジニアを募集しています！

カジュアル面談も歓迎です！
まずは話だけ聞きたいという方も、ぜひご応募いただければと思います！

1. https://www.headwaters.co.jp/news/gptai_github_copilot_for_business.html ↩

2. JetBrains IDEs、Vim/Neovim、Visual Studio、Vidual Studio Code ↩

3. https://docs.github.com/ja/copilot/overview-of-github-copilot/about-github-copilot-for-business ↩