2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
服部佑樹氏(以下、服部):準備ができたようなので、続いてパネルディスカッションを進めていきたいと思います。
ファシリテーターを務めるのは、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の融合について聞きたいと思います。
(スライドを示して)ちょっと字が小さいかもしれないですが、こちらの質問を用意してきました。全部はたぶんいけないので、登壇者の方にも読んでもらって「あ、これは答えられるかな」みたいなところも探してもらいたいです。
ではどうしましょうかね。黒崎さんには「どうやって開発プロジェクトで活用されているのか」はもううかがったので、そこに関して髙橋さんからお願いできますか。
髙橋:これは黒瀧が(回答するほうが)いいのかな?
服部:どちらでも。
髙橋:じゃあお願いします。
黒瀧:そうですね。実際の開発プロジェクトでは、弊社の場合はエンジニアもデザイナーもけっこうみんな使っています。日々の業務で常に使っている感じです。
プログラムを書いたり、何かを作り出した時に、コメントとかをしっかり書くとコードを作ってくれるので、ああいうのをどんどん出してもらって、とにかく動かして進めていくようなことはみんなやっていますね。
髙橋:私たちの会社だと、バックエンドとフロントエンドのエンジニアリングがきれいには分かれていなかったり、バックエンドの方がけっこう片手間でフロントエンドを書いたりすることが多くなっているのですが、そういう時にすごくうまく機能する機能だなと思っています。
今のコードがある程度しっかりしたものがあれば、バックエンドの方でもフロントエンドのコードを「今あるものからとりあえず書き切る」みたいなところができるようになってきたということは、メンバーから実際に声が上がっていていて、そこはすごく良いところだなと思っています。
出てきたコードは100パーセント良いコードではもちろんないと思うので、そこから専門性の高い人のレビューを通すようにはしていますが、とりあえず書き始めるとか、プルリクエストを出すみたいなところまでがすごく速くなったなと感じています。
黒瀧:確かにそうですね。社内でいろいろなエンジニアに話を聞いたら、ふだんはバックエンドをメインで開発していてRubyやGoを使うことが多いのですが、「フロントエンドはあまりやったことがないけど、自分でちょっと作りたい」という人が「経験のないTypeScriptとかVue.jsとかをやった」と言っていました。その開発を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 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とかでトレースして、そこに対して修正を提案するみたいなものもあったりして。単に書くだけじゃなくて、実行時の情報などを拾って、そこからパフォーマンスチューニングとかかもしれないですが、能動的にコードの提案をしてくれることがより加速すると、開発サイクルが上がって良いだろうなと期待しています。
服部:ありがとうございます。
(次回に続く)
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには