トップ > Copilot > GitHub Copilotの本当の効果とは何か

GitHub Copilotの本当の効果とは何か

Copilot Developer Experience 開発者体験

はじめに

初めまして、システム本部デベロッパーエクスペリエンス室の室長、加藤真史です。

デベロッパーエクスペリエンス室は、開発者体験（Developer eXperience）を向上させることを目的としたシステム本部横断組織で、2023年4月、新設された組織になります。

GitHub Copilotの登場を受けシステム本部全体への適用を活動の1つとしておりました。
GitHub Copilotのような新規技術を組織全体で導入する際にはハードルがいくつもあります。そのなかでもこの組織で「効果が本当にあるのか」の点がもっとも重要でかつ悩ましいところになります。

今回は、GitHub Copilotをシステム本部での導入にあたり、どのように検証、評価したかをご説明します。

評価を進めていくなかで、世間で話題となっている時間削減以外の重要な効果について、気づかされることがありましたので、こちらもご紹介いたします。

また、効果検証トライアル実施にあたり、先行して情報公開されているZOZO社さまの取り組みを参考にさせていただいております。 非常に勉強になりましたのでぜひ、結果を当社と見比べてみてください。

GitHub Copilot効果検証トライアルの前提と実施状況

新規技術の導入は少なからずコストがかかります。

そのため導入を進める際、自組織にとってどのような効果があることが見込めるか、ということを具体的に証明しないと組織としての承認は下りないのが一般的です。
そこでGitHub Copilot効果検証のトライアルを実施することで具体的な効果の実績を確認し、その上で、システム本部組織全体に適用の承認をもらうプロセスで進めることとしました。

また、GitHub Copilotの情報セキュリティ面、法務面での懸念事項については、当該担当部門と効果検証のプロセスに先んじて進めており、最終的に問題ないことを確認しています。
この点については、いくつも公開事例があるため、今回は、効果検証の内容とその結果について述べさせていただきます。

トライアル参加メンバーの選定

トライアルの参加メンバーの選定については、少なからず参加メンバーの業務のワークロードに影響がある点と、興味本位による参加にすると「やってみたいけど、忙しくてろくに触れなかった」「何がどれくらい、どういいのか説明するのが手間」などの理由で意図するフィードバックが得られない可能性がある点があります。

そのため、システム本部の各部門長に協力を仰ぎ会社施策として協力できる人材を選定することにしました。また、その条件として以下の2点を設定しました。

  • きちんとトライアルのフィードバックをすること
  • トライアルの感想をテックブログで記事にすること

また、特定の部門に偏ったトライアルにしてしまうとその部門特有の使い方の効果となってしまい、全体としての効果を確認できません。
そのためまんべんなく参加してもらい全８部門、計２２名でトライアルの実施となりました。

利用した開発言語

トライアル実施時の開発言語の分布となります。
占有率の高い順に、C#、PHP、Ruby、Javaとなっています。その他として、JavaScript、Kotlin、SQL、ShellScriptなどでも利用があったことがわかりました。

また、期間は「２か月」としました。
理由として実際の開発案件でGitHub Copilotを利用してもらい実態にそった効果を測定したいためです。 短期間ですと検証のためのトライアルになってしまいがちなので、比較的長めの期間を設定し、なるべく開発案件での利用とすることをトライアルのメンバーには推奨しました。

参加メンバーのコーディング時間割合

一日の仕事のなかでコーディングに費やす時間はどれくらいかを確認しました。
コーディング時間＝GitHub Copilotを触る時間と考えているため、長く触っている時間が多いほど検証できていると考えたためです。

結果として一日のうち３０％以上をコーディングに費やす割合は６４％と多数を占めているため、利用シーンとしては充分な時間を費やしていると判断しました。

どのようなシーンで利用したか

どのような業務で利用したかを調査しました。あまり実際の業務とかけ離れた使い方になってしまうと、トライアルの意味合いが薄れてしまうと考えたためです。

その結果、実際の開発作業とそのテストでの利用が８６％にのぼり、実際の業務利用シーンに非常に近い状況でのトライアルができたことを確認できました。

これは想定を大きくうわまったため、トライアルメンバーがかなり意図して実際の業務で取り入れてくれていたことによるものと考えております、感謝。

評価方法について

何をもって開発者生産性をはかるか

GitHub Copilotの効果としての開発者生産性を何をもって測るかという点は、今回の効果測定でも重要な課題でした。ものさしとしての基準を決めておかないと測定する項目があいまいになり、また結果も比較できないものとなりがちです。

そのため、世の中にある開発生産性の指標を調査した上で、今回の効果測定の基準を選定することにしました。

基準とする指標としての方法論は多数あり、どれを基準にするかについてはまず先行公開されているZOZO社の事例でも観点として採用されているSPACEフレームワークの観点を当社も採用することにしました。

その背景として、基準をそろえることで比較しやすくし当社の特徴を洗い出したい点と、SPACEフレームワークの観点である「満足度と幸福（well-being）」「効率とフロー」のカテゴリーは、pull-request数や、d/d/dなどの指標や、Four Keysの指標とは別の視点での生産性評価となる点を大きく考慮しました。

GitHub Copilot効果測定結果と考察

採用指標による結果

「満足度と幸福」カテゴリーで、ポジティブな反応（「とてもそう思う」「そう思う」）は、５０％～７３％と非常に高く① 「効率とフロー」カテゴリーでも、６０％～８７％とさらに高い②結果となったため、開発者生産性に良い影響を与えると評価できます。

※「作業に没頭し集中できる状態に入りやすい」設問が３７％と低い数値③となっているのは、GitHub Copilotからの回答を全面的に信頼するわけにはいかず確認する必要があるため、没頭するレベルには至らなかったと推察しています。

eNPS評価について

開発生産性としての評価指標以外に、まったく別の視点での満足度を測る方法も検討することにしました。ひとつのものさしだけで物事を測るよりも 複数のものさしで測ることで、より多面的に実態をつかむことができると考えたからです。

そこで、主に会社の満足度評価に使用されているeNPSの観点を採用することにしました。


その結果GitHub CopilotのeNPSスコアは、「-14」となりました。

マイナス表記のため、一見低く見えますが、日本のeNPS平均スコアは-61.1のため、かなり高い結果になります。（eNPSスコアは中間層も批判者として判定するためマイナス数値になりやすい指標）

よって、eNPSの観点でもGitHub Copilotは良い評価であることがわかり、先述のSPACEフレームワークも加え２つのものさしで良い満足度となることを確認できました。

GitHub Copilot利用による削減時間の結果と考察

効果結果として最も重要である定量的な時間削減について確認をしました。GitHub Copilot利用により削減される時間をヒアリングしています。

まず、削減効果ありと答えた割合は８６％になり、非常に高いことがわかります。

削減時間の回答から、トライアルメンバーの削減時間の平均を求めました。時間レンジでの回答のため、低いレンジを採用し１日平均の削減時間を算出したことろ、１日平均２７分の削減ができることがわかりました。

これは、単純に１か月を２０営業日とした場合、２７分×２０営業日＝月平均９時間の削減が見込めるという結果になります。この結果は想定以上の結果であり、単純に２０営業日として換算することに関して過大に効果が出ているのではないか、といった議論になりました。

そのため、いくつかのバリエーションを立てて月の削減時間を算出していく形にしましたが、これは後述いたします。

削減時間量との相関要素について

つづいて削減時間に影響をあたえる要素がわかれば、その要素を拡大することで削減時間を最大化することができます。

そのため、影響を与える要素としてコーディング時間に着目し、削減時間との相関関係を確認しました。

コーディング時間が多い＝削減時間も多いと想定しましたが、トライアルの段階でははっきりとした相関はみられませんでした。（特異点①を除くとうっすら傾向②があるように見えるレベル）

これは、対象者がまだ少ないため、相関傾向を見つける状態ではないと判断し、システム本部全体適用後に継続して検証していくこととしました。今後の効果の最大化を図るアクションにつなげていきます。

定性的な効果を分類してみる

数値化しづらい定性的な効果も多数レポートされているので、大きく６分類してみました。

①時間短縮/効率があがった
②楽になった/慣れない言語への抵抗感が軽減
③相談しながら進めることができる/サジェストされた内容から新たな手法を学べる
④単純なミスの減少は多数コメント
⑤テストコードの作成は、「かなり」「非常に」「もっとも」などの強調が多数見られ、特に効果がある
⑥懸念点としては、没頭しているときに邪魔、確認したうえで確定するので自分で書いた方が早い

定性的な観点からは、テストコード作成の領域で大きく効果があることがわかりました。これは単純な時間削減の観点からは得られなかった効果になります。

テストコード作成において精度が高い回答がGitHub Copilotから得られるのは、事前に対象のソースコードを解釈できるためであり、事前情報が少ないコーディング段階での回答とは、前提が異なっていると推察されます。

この結果から、単にコーディング効率UPの観点とは別に、テスト実施/テスト品質の向上の面で大きく貢献できるのではないかと考えています。

費用対効果の見積もり

続いて削減時間から算出される費用対効果にうつります。
ここではGitHub Copilotの利用にかかる費用と削減時間の見積もりを行いました。

1日の削減時間27分というトライアル結果をもとに、単純に月換算（1日削減時間×20営業日）すると過大な効果になる懸念を踏まえ、コーディングする頻度について３パターンを設定することで試算と実際の結果の乖離を防ぐよう考えました。

その結果、最も低く見積もったパターンでも、６か月で、年間費用（GitHub Copilotの年間利用料）と同じになることがわかり、悲観的にみても効果の有用性を確認できました。

外部環境について

世のなかでも、ごく短期間でGitHub Copilot導入が進んでいることがわかり (Github Copilot 採用企業・レポート をまとめてみた) トライアル結果と同様に他社でも生産性が向上すると思われます。

そのため、結果的に未導入企業は相対的に生産性が低くなるため、競争力を保つ意味でも導入をすすめる必要があるということを強く認識しました。
さらにGitHub Copilotの人材獲得面での影響を確認してみました。

GitHub Copilotは、職場の選定基準や離職防止につながるとのポジティブな回答は「７３％」にのぼることがわかりました。

そのため、現在は市場的にエンジニアの人材獲得が困難な状況のため、職場選定や、離職防止につながると判明したこの要素にはコストを積極的に投じるべきと考えることが重要になると考えます。

人間は一旦、便利な道具を使ってしまうと、それまでは平気だったその道具がない状態に対し大きな抵抗を感じるものです。スマートフォンなどその典型的な例だと思います。

GitHub Copilotはエンジニアにとって同様な道具になり得る可能性を大きく秘めており、職場として提供できるかどうかは開発者体験 （Developer　eXperience）に大きくかかわるものだと感じました。

まとめ

  • 開発者生産性（SPACEフレームワーク）は、高い結果をだしている

  • 費用対効果は、GitHub Copilot利用料を大きく上回る（もっとも効果が小さい想定パターンでも）

  • 導入企業は急激に増えつつあり、未導入企業は開発生産性や、人材獲得において相対的に地位が低下すると思われる

よって、GitHub Copilotは、生産性/対費用効果/外部環境の３つの観点で、当社に貢献できるという判断になり、システム本部全体適用を進めることになりました。

また、想定されていた時間削減以外にテストコード生成や、人材獲得面での効果に気づくことができたのは、大変有用な知見になりました。

今後の動き

トライアルをして全体適用となったGitHub Copilotですが、導入して終わりという形にならないよう、以下のように今後の予定を立てています。

特に今回実施した効果の結果が、全体適用後も確認できるのかの観点や、より作業時間削減につながる要素の洗い出し、そして活用していくなかでのナレッジの共有がより効果を促進していくと考えています。

今回の記事を皮切りに、トライアル検証した開発言語別の記事を順次公開していきますので、そちらも見てもらえると嬉しいです。

参考文献

この記事は以下の情報を参考にして執筆しました。

カカクコムでは、ともにサービスをつくる仲間を募集しています！

カカクコムのエンジニアリングにご興味のある方は、ぜひこちらをご覧ください！

カカクコム採用サイト