「GitHub Copilotのおかげで“とりあえず書き切る”ができるようになった」　開発プロジェクトへの活用で感じたメリット

登壇者の自己紹介

服部佑樹氏（以下、服部）：準備ができたようなので、続いてパネルディスカッションを進めていきたいと思います。

ファシリテーターを務めるのは、GitHubの服部です。よろしくお願いします。では、左から自己紹介をしていただいてよいでしょうか？

黒瀧悠太氏（以下、黒瀧）：よろしくお願いします。GMOペパボ株式会社の黒瀧と言います。GMOペパボでちょうど10年ぐらい働いて、今は11年目になります。2012年に入社していろいろなWebサービスを開発したあとに、「SUZURI」というオリジナルグッズを作成するサービスの技術の責任者をしています。

最近、GMOインターネットグループの中で技術的な新しい取り組みや、先進的な活動をしていることを認められて、今はデベロッパーエキスパートもやっています。

業務はWebシステムがメインですが、趣味ではIoTデバイスやハードウェアを作ったり、いろいろな領域でエンジニアリングをやっています。「GitHub」はもう10年ぐらいの付き合いで、「GitHub Copilot」は最近は毎日使っていて、欠かせないツールとなっています。よろしくお願いします。

服部：お願いします！

髙橋健一氏（以下、髙橋）：同じくGMOペパボから来ました、髙橋と申します。インターネットでは@kenchanというIDでやっています。よろしくお願いします。私は今はEC事業部でシニアエンジニアリングリードという、黒瀧と同じ技術の責任者と、あとは全社のエンジニア組織の責任者をやっています。

今回のGitHub Copilotの導入に関しても、いろいろと各所と調整をしたりした経緯があります。あとは先日サイバーエージェントさんと同様にメトリクスを公開したので、みなさんに見てもらえていたらうれしいなと思います。ペパボでも生産性の向上やAIの活用を推進しているところです。本日はみなさんよろしくお願いします。

黒崎優太氏（以下、黒崎）：黒崎と申します。先ほど発表をしたのでアレですが。登壇者のお名前を見ていて、黒瀧さんが……。

黒瀧：（笑）。

黒崎：僕は黒崎優太というんですが、黒瀧悠太さん、アルファベットで表しても1文字しか変わらないのですごい……。あとで名刺交換をさせてください（笑）。

（一同笑）

黒瀧：ぜひよろしくお願いします（笑）。

黒崎：楽しみにしていました。

服部：ありがとうございます。本日は日本でGitHub Copilotを使っていただいているトップランナーの方々に登壇していただいています。あれ!?　みなさん良いTシャツを着ていますね。

これは「The GitHub Shop」と調べてもらうと、みなさんもお買い求めいただけます。ぜひチェックしてもらって、GitHubで買ってもらえればなと思います。

本ディスカッションのテーマ

本日（のディスカッション）は30分なので、テーマが3つあります。まずはベーシックなところから「GitHub Copilotの活用実践」です。続いてもう少し個人的なところで、例えば「エンジニアとAIはどうやって関わっていけばいいのかな」と。

今後のキャリアみたいなところも含めて……。マネージャーとしての立場だと『どうやって育成していくのか』みたいなことになっていきます。

最後に組織文化とこういう（AIの）活用、AIの融合について聞きたいと思います。

（スライドを示して）ちょっと字が小さいかもしれないですが、こちらの質問を用意してきました。全部はたぶんいけないので、登壇者の方にも読んでもらって「あ、これは答えられるかな」みたいなところも探してもらいたいです。

GMOペパボのGitHub Copilotの活用実践

ではどうしましょうかね。黒崎さんには「どうやって開発プロジェクトで活用されているのか」はもううかがったので、そこに関して髙橋さんからお願いできますか。

髙橋：これは黒瀧が（回答するほうが）いいのかな？

服部：どちらでも。

髙橋：じゃあお願いします。

黒瀧：そうですね。実際の開発プロジェクトでは、弊社の場合はエンジニアもデザイナーもけっこうみんな使っています。日々の業務で常に使っている感じです。

プログラムを書いたり、何かを作り出した時に、コメントとかをしっかり書くとコードを作ってくれるので、ああいうのをどんどん出してもらって、とにかく動かして進めていくようなことはみんなやっていますね。

髙橋：私たちの会社だと、バックエンドとフロントエンドのエンジニアリングがきれいには分かれていなかったり、バックエンドの方がけっこう片手間でフロントエンドを書いたりすることが多くなっているのですが、そういう時にすごくうまく機能する機能だなと思っています。

今のコードがある程度しっかりしたものがあれば、バックエンドの方でもフロントエンドのコードを「今あるものからとりあえず書き切る」みたいなところができるようになってきたということは、メンバーから実際に声が上がっていていて、そこはすごく良いところだなと思っています。

出てきたコードは100パーセント良いコードではもちろんないと思うので、そこから専門性の高い人のレビューを通すようにはしていますが、とりあえず書き始めるとか、プルリクエストを出すみたいなところまでがすごく速くなったなと感じています。

黒瀧：確かにそうですね。社内でいろいろなエンジニアに話を聞いたら、ふだんはバックエンドをメインで開発していてRubyやGoを使うことが多いのですが、「フロントエンドはあまりやったことがないけど、自分でちょっと作りたい」という人が「経験のないTypeScriptとかVue.jsとかをやった」と言っていました。その開発をGitHub Copilotに助けてもらって、「プルリクを出すところまですぐにできました」みたいな人がいて、すごいなと思いました。

服部：ありがとうございます。

GitHub Copilotの活用でまだうまくできていないところ

服部：我々も、GitHub Copilotをどううまく使っていただくのかみたいなところは非常に注目して見ているところです。なぜかというと、GitHub Copilotのブーストしたコード、開発者がブーストされたとして、何を持ってそれが生産性が上がったのかが直感的にわかりにくいんですよね。

GitHubでは最近Issue Metrics GitHub Actionsという、プルリクエストとかを閉じるまでに要した時間も計測しようという動きもあります。みなさんたぶんいろいろやられていると思いますが、そういった最大限の活用をする中で、これもまたGMOさんになってしまうのですが、みなさんにアドバイスはありますか？サイバーエージェントさんからはテンプレート共有みたいなお話があったので（笑）。

髙橋：先ほどの発表を見て、うまく使っている人を探すのが「あ、できていないな」と思ったんですよね。活用できている人をどうやって探すかと、その人たちのノウハウをどうやって社内に広げていくかというところが、わりとうまく使っていくところのポイントなのかなと先ほどのお話を聞いて思ったので、社内に持って帰って、明日からやってみたいと思っているところです。

服部：ありがとうございます。ではサイバーエージェントの黒崎さんに聞きたいのですが、Copilotでまだうまくできないところはどんなところですか？　いろいろ共有されていたこともあると思いますが、たぶん2点あって、機能としてできないみたいな話と、組織のロールアウトとして結局あまりうまく使ってもらえていない感覚ももしかしたらあるかもしれないと思いました。

そういうところの全体も含めて、「なんかうまくいかないな」みたいなところはどうですか？

黒崎：そうですね。やはり機能的な部分はいくつかあるなと思っています。どうしてもコードにコンテキストが現れないようなもので、例えばインフラでもTerraformで管理されている範囲だったらわりと反映されやすいのですが、そうじゃない部分も混ざっていたりとか。

そうすると、バックグラウンドとしてもCopilotが知りようのないコンテキストが入っていたりすると、いわゆるそこの推薦がうまくいかないなみたいなことはあります。それは何かしらの文脈を入れられたらいいなと思っています。

あとは、弊社の言語別の数字だと、TypeScriptとGoを使うことが多いというのがあったのですが、やはりTypeScriptやGoはすごく推薦が利きやすいです。僕は広告系のプロダクトでScalaを書いていた時期がありますが、関数型言語など、Goに比べて相対的に書いている人が少ないやつとかだと、やはりちょっと推薦の精度が弱いなと思ったりしますね。

僕の推測ですが、関数型言語だとどうしてもコード的にはすごく抽象化されているので、Goみたいにコードの中にコンテキストが近いところに現れていなかったり、抽象化されていたりして、同じコードでも文脈によって効果や何かしようとしている作用がまったく違ったりします。そういう高度に抽象化されているものだと、補完がすごく利きづらいのかなみたいなところはありますね。

服部：それも含めてテンプレートとかプロンプトのところで補給ができないかみたいなところも共有されていますよね。ありがとうございます。

ちなみにテンプレートですが、「OpenGPT」にコードインタプリタというものがあるじゃないですか。あれのデバッグモードでやるとプロンプトが見えるみたいで、これは私もおもしろそうだなと思いました。

やはり誰がどうプロンプトを書いているのかはレビューとかだと見えにくいので、それをどうやって社内で共有して、ちゃんと良いプロンプトが書けるようになるのかも肝かもしれないですね。

GitHub Copilotに欲しい機能

服部：最後の質問をして次にいきたいと思います。今後のGitHub Nextないし……。正直これはNextじゃなくても良くて、「GitHub Copilotにこんなのがあったらいいのにな」みたいなところも含めて期待している機能はありますか？　黒瀧さんからお願いしようかな（笑）。

黒瀧：じゃあ私から。Copilot Voiceというのがあるっぽくて。サイトで見ると、しゃべりかけるとそのとおりにコードを書いてくれるというやつを今作っているんですかね？　Waitlistか何かですよね？

服部：そうですね。

黒瀧：それはすごく楽しみだなと思っています。手を使えない人がいろいろ使えるのも良いです。オンラインでペアプロをする時とかも、しゃべりながらやることが多いと思うのですが、人間と人間でそのコードを書いている中で、Copilotにも「この行に飛んで、こういうことをやって」ということを命令できる。

サンプルが書いてあって、VS Codeで「38行目に着いてきて」みたいな機能がありますが、人と話しながら、「Copilotも一緒に38（行目）にちょっと行って書いて」と言っておきつつ、人と話している内容を「Copilotに渡して」みたいなことを、ペアプロからAIも入った3人、3人というか、AIが1人と人間が2人とか、そういうかたちの共同、コラボレーションみたいなのが今後できるんじゃないかなという面で、Copilot Voiceをすごく期待しています。

髙橋：私は主にプロジェクトの進行を見ることが多いので、GitHub本体のprojectsやissueやプルリクのインテグレーションがこれからどういうふうにされていくのかにすごく興味があって、そのあたりはとても期待しています。

黒崎：確かNextでプルリクエストのレビューの機能がありますよね。あれはすごく良いだろうなと思っています。出した瞬間にひととおり指摘されそうなものを洗い出してくれるみたいな。Linterを入れたりとかもあると思うのですが、それよりももう一段抽象度の高い指摘とかをもらえると捗るんだろうなと思います。

あと最近、他社のツールだったかもしれないですが、コードの実行時のエラーを検知して、それをAPMとかでトレースして、そこに対して修正を提案するみたいなものもあったりして。単に書くだけじゃなくて、実行時の情報などを拾って、そこからパフォーマンスチューニングとかかもしれないですが、能動的にコードの提案をしてくれることがより加速すると、開発サイクルが上がって良いだろうなと期待しています。

服部：ありがとうございます。

（次回に続く）