導入1ヵ月で、35,000行分のコーディング時間を削減　定量面・定性面から評価する「GitHub Copilot」

登壇者の自己紹介

黒瀧悠太氏：よろしくお願いします。GMOペパボの黒瀧です。今日は「GitHub Copilotで開発生産性はどのように変わるのか」というタイトルで発表します。

私は、今GMOペパボ株式会社の「SUZURI」というサービスの技術責任者、シニアエンジニアリングリードというのをやっていて、GMOインターネットグループとしては「デベロッパーエキスパート」専門分野のエキスパートとして活動しています。

SNSアカウントは「@kurotaky」というのでやっています。趣味はドラムを叩くこと。音楽が好きで、Rubyコミュニティで活動することが多かったです。

今、社会人博士課程にいて、ざっくり書いているのですが、ウェアラブルデバイスの研究、回路の設計、基盤の実装、材料の研究などをやっています。

「YouTube」のCMに出ているので、たまにこのことを突っ込まれます。僕がなんかしゃべっているだけなんですけど（笑）、興味がある人は見てください。

GMOペパボにおけるGitHub利用の歴史

GMOペパボは、2023年でちょうど20周年を迎えました。ずっとクリエイターさんの表現活動を支援して、その人たちのアウトプットを増やすということを行っていて、その中でいろいろなサービスを提供しています。

ホスティング事業、EC支援事業、ハンドメイド事業、金融支援事業というのがあるのですが、私はEC支援事業の「SUZURI」というところにいます。

「SUZURI」というサービスでは、Ruby、JavaScript、TypeScriptが言語として多いかなと思っています。

GMOペパボと「GitHub」の関わり方の歴史ですが、「GitHub Enterpriseで仕事をもっとおもしろくできる」という発表やスライドが公開されています。

ざっくりGitHubとペパボの関係をまとめると、私は今の会社はちょうど11年目で、2012年4月に新卒エンジニアとして入社しました。当時「github.comを利用しよう」みたいな流れが出てきていて、2012年はGitHubにちょっとずつ移行していく時期でした。

その後、2014年からGitHub Enterpriseを利用し始めて、2016年にはGitHub Enterpriseとgithub.com/pepaboというところを利用するようになりました。

今は主にサービス開発にはGitHub Enterpriseを使っていて、業務でオープンソース化したものなどは、github.com/pepaboのほうに置く感じになっています。

GMOインターネットグループ全体として“AIの活用”を推進

「GitHub Copilot」導入に至った背景としては、GMOインターネットグループ全体として「AIを活用しようぜ」という流れがありました。そんな中、「ChatGPT」が出てきて、「生成系AIだ」と言われた時に、その「生成AI」を活用して機能開発したり、開発プロセスへどんどん活用していこうといった流れが社内で起きました。

例えば「slack-gpt」は「Slack」のボットで、それに質問を投げると結果を返してくる。ChatGPTをSlackのボットとして扱えるようにしたオープンソースを作って公開している人がいたり、SUZURIに関しては「スリスリAIラボ」というので、テキストを入れるとそこから画像を生成してTシャツを作るとか。

ほかにはアイテムの説明文。アイテムというのはSUZURIで販売しているTシャツやマグカップですね。アイテムを作った時に、自分でその商品の説明文を書くのが大変だったり、とりあえず作ったけれど説明文を入れていない人がいた時に、AIがアシストしてくれる機能。

あとは今見ているTシャツの画像に似たTシャツを画像で検索して推薦してくれる機能など、自然言語生成モデルをいろいろ活用しているので、法的な面で問題はないか、ガイドラインを社内で作成することも進めていました。

SUZURIでの事例が多いのですが、ほかのサービスでもAI活用をやっていきました。

「GitHub Copilot」導入1ヵ月で、35,000行のコードを書く時間を削減できた

その中でGitHub Copilotを導入したのですが、「GitHub Copilotを導入してどうなったか」という記事をテックブログに公開しています。弊社の技術責任者がブログを書いているので、こちらを読んでいただけると詳細がわかります。

セキュリティ的に問題がないのか、ライセンスの問題はどうなのか、どうやって解決するのかも書かれています。

GitHub Copilotを1ヶ月ちょっと使った中で、定量的なデータを見てみました。これ、GitHubのCopilotの利用状況みたいなものが見られるようになっているんですね。

GitHub Copilotがコードを提案してくれます。「こういうの、どうですか？」みたいなのをパパッと出してくれて、それを承認するか、違うのにするかを人間が選択する。その採用率です。GitHub Copilotが提案してくれて、それをアクセプトした数が今30.1パーセントで、行数で言うと3万5,000行ということですね。

1ヶ月で見た時にこの状態なので、ざっくり定量的に言うと、1ヶ月で3万5,000行、人間がコードを書くというところを削減できたことがまず見えてきました。

言語ごとの利用率がわかる

もう1個、言語ごとの利用、Acceptance Ratesも見ることができます。ペパボだとPHP、Ruby、Go、TypeScriptがメイン。機械学習やデータ基盤関連だとPythonが多いです。

（スライドを示して）まずここ、PHPをけっこう使っているのですが、PHPはRateが低いんですよね。低いんですが、実際にはけっこう「PhpStorm」を使って開発している人が多いです。

確か、言語ごとのAcceptance Ratesは、「VSCode」を使っているものの中での統計データだったと思うので、PHPのRateが低くても実際はけっこう使っています。

Rubyに関しても、Acceptsは多いはずなのですが、Rateが低い。このあたりは、テックブログに考察が書いてありました。

Rubyは言語の表現力が高いと言われているので、Copilotが提案してくれるのですが、プロダクトの規約があったり、個人の好みでけっこう書き直したり、提案ではないものを採用したりすることが多いのかもしれません。これは社内で、実際にRubyを書いてCopilotを使っている人にもう少し深堀りして聞いてみるとおもしろいかなと思っています。

利用している開発環境は「VSCode」が8割を占める

（スライドを示して）開発環境も統計が、見えるんですね。この左から、真ん中端まで出ている紺色、青っぽい大きな四角がVSCodeです。120人ぐらいの開発者がいろいろなエディタを使ってコードを書いて、Copilotを使っているのですが、そのうちの8割がVSCodeという感じです。

これは他社さんのブログを見ても同じ感じで、VSCodeを使っているところが多かったですね。そのほかは、いろいろなIDEとか「Vim」「Emacs」とか、そういうものを使っている人もいます。

生産性を測るメトリクス「Four Keys」で定点観測をしている

あと、デプロイ数はどうなったかというところで、GMOペパボでは全サービスにおいてFour Keysという生産性を測るメトリクスを常に計測して定点観測しています。デプロイ数に関して変化があったのかというと、Copilot導入前と導入後で、全サービスが上がったわけではなかったのですが、2つのサービスにおいては、導入前と導入後で、1日におけるデプロイ数が1.6とか、0.5とか上がったという定量的なデータを、ここ1ヶ月で見ることができました。

（スライドを示して）このFour Keysというのは、今回はデプロイの頻度だけを見ましたが、変更へのリードタイムで、これも計測しています。変更した時の障害率と、サービスの復元時間と合わせて、この4つの軸で生産性を測るというのは、いろいろなところでやられていることかなと思います。定点観測している中で、今のところデプロイ回数が2つのサービスにおいては上がったので、これももう少し見ていきたいなと思っているところです。

「テストコードを書いてもらえて便利」「時間が短縮された」　定性面における評価

定性面において、どうだったかをエンジニアの人にちょっとヒアリングしてみました。「Copilot使ってどうですか？」というようなことをいろいろ聞いてみました。

そうしたら、「Rubyで書く時に、AutocompletionのところをCopilotがやってくれて便利です」とか「VSCodeで10行ぐらい一気にバッと出してくれるので便利」とか、いろいろな意見が聞けました。

「Copilot Chat」は、エラーが出た時に英語で提案してくれるのですが、「日本語に直して」と言うとそれを日本語に直して、エラーについて解説してくれます。なにか動かして、エラーになって、修正して、といったところがすごく早くなりました。

あとは、使っていくうちに変数名などの命名をしっかりしようという意識になってきました。変数名をしっかりと一貫したものにすると、人間にも優しいコードが提案される。「あっ、これいいじゃん」となる割合が多いというのが、うちの会社のエンジニアの経験からわかってきています。

そういうふうに書いていくと、結果としてコード自体もすごく見やすく、人間に優しいコードになっていくというのがありました。

あとは、OSSのライブラリのコードを解説してもらうのにも便利です。たくさんOSSを使っていく。Rubyだったらgemをいっぱい使っていて、npmだったらパッケージを使っているのですが、1人だとそれを1個1個深堀りしていくのは時間が足りないけれど、ある程度解説をもらえるので便利という話がありました。

ほかには、実際に途中まで入力して待つと補完してくれるので便利という話が、開発者のインタビューで出ています。今まではガッと自分で書いていった感じでも、いったん補完を待つと、けっこういいコードをパッと出してくるので、補完を待つようになった。そのくらい便利になったという話もあります。

あとは、「列挙する時の型スイッチとかはかなり強いよね」というので、ASTなどが触りやすくなったと。

ほかにも、テストコードを書く時間が短縮されたという話だったり、（スライドを示して）この最後に書かれているのも先ほどと同じ感じなのですが、やはり一貫したコードを書くという話につながるのかなと思っています。

人間にとっても理解しやすいコードを書くと、Copilotが生成するコードも採用したくなるものになりますが、理解しにくいコードを書くと生成されるコードは採用したくないものが多くなる感じがあります。

（スライドを示して）このあたりは、先ほどの補完の話と同じですが、「右クリックでrubocopの修正をしてくれるのはありがたいよね」とか「テストの説明を書いたら内容全部考えてくれる」などいろいろありますね。

あとは、そうですね、実際に自分が触ったことがない言語を実装する機会があった時に、それをCopilotと一緒にやることで、知見がぜんぜんない言語でもすぐプルリクエスト出せたといった話もあります。

インタビューデータはたくさんあるので、この後の懇親会やチャット欄で聞かれたら答えようかなと思います。

GitHub Copilotの導入により生産性は向上した

「GitHub Copilotを使って開発生産性がどのように上がったか」というと、まず2つのサービスにおいてデプロイ数が上がりました。今後は、このデプロイ数と合わせて、変更のリードタイムでの比較も定点観測したいなと思います。

Acceptance Ratesに関しては、全部の言語で約30パーセント、3万5,000行のコードを書くのを削減できました。

インタビューをして定性面のデータをまとめましたが、そこからも生産性が上がったことがわかりました。主観的なものになりますが、「生産性が上がった」という意見が大多数です。

ということで、現状、GitHub Copilotを導入して生産性は上がっていると思いますので、今後も計測と評価を続けて活用していきます。本日はありがとうございました。

（会場拍手）