GitHub Universe 2023、GitHubのCOO、Kyle Daigle氏にインタビュー

GitHub Universe 2023から、GitHubのCOOであるKyle Daigle氏のインタビューをお届けする。Daigle氏とは毎回のGitHub Universeで必ず顔を合わせる間柄だが、2017年、つまり6年前に行ったインタビューとあまり変わらずに今回も真摯に回答をしてくれた。以下の6年前に行ったインタビュー記事も参考にして頂きたい。

●参考：GitHubにとってAPIとは？　GraphQLが提供する価値とは？

GitHubのCOO、Kyle Daigle氏

今回のキーノートではCopilotが主題となっていましたが、これまでのデベロッパーがコードを書くための支援だけではなくドキュメントやテスト、そして書いたコードの概要も生成するなど包括的にAIを使えるようになることが大きなテーマでした。しかし世の中には賢いが悪い人間も存在します。Copilotをハッカーが悪用するという可能性はあるのでしょうか？

Copilotは生成型AIのパワーでよりシンプルで脆弱性のないコードを生成します。人間がコードを書いて結果的に脆弱性がコードに含まれてしまうという可能性を低くすることができます。Code scanning autofixで自動的に脆弱性を修正する機能もありますから、悪意を持ったハッカーがCopilotを使って意図的に脆弱性のあるコードをコミットするということ自体が難しくなりますし、すでに存在するコードの脆弱性を使うことも難しいでしょうね。結果としてCopilotによってよりセキュアなコードを作ることが可能になるわけです。

キーノートのデモなどを見て感じたのは、Copilotはペアプログラミングの相手としてデベロッパー個人を支援する形ですよね。でもソフトウェア開発は複数の人間がチームとして目標に向かっていくというグループワークだと思います。その部分に対する支援は？ またHashiCorpのMitchell Hashimoto氏や元ChefのAdam Jacob氏などのベテランが「これはやり過ぎだ。デベロッパーのクリエイティビティが抑えられてしまう」という懸念を表明しています。それについてのコメントは？

確かにCopilotはペアプログラミングの相手として個人を支援するものですが、実際に約500名のデベロッパーに対するリサーチでわかったのは、デベロッパーが使う時間のうちコーディングに費やす時間というのはそんなに多くはないということなんですね。それよりももっと多くの時間を使っているのは、その他のチームメンバーとのコミュニケーションなどであることがわかっています。

つまりコーディングにかかる時間を減らせばもっとチームとしての作業が捗るということなんです。実際に社内のリサーチでもコーディングの時間が減り、レビューやコミュニケーションの時間が増えたという結果も出ています。また今回のデモでは見せなかった使い方として、デベロッパーがコードを書いてそれをGitHub.comにコミットするとします。その時にそのPull Requestをレビューする人はCopilotを使ってこのPRの内容が良いものであるかどうかを検証できます。つまりコードを書くだけではなく、内容を検証して他の書き方があるかどうかを調べるという使い方もあるんです。そうするとPRを送った人、それをレビューする人の双方を支援することができる。つまりグループとしてのタスクを支援することができるわけです。

Copilotについてやりすぎだという声があるのは知っていますが、それについては例え話で説明します。Copilotはバターをスーパーマーケットで買うのと同じことなんじゃないかということです。

私の祖母は東ヨーロッパの出身で彼女にとってバターは家で作るものだったので、母がバターを買ってくると文句を言っていました。でも今は多くの人がスーパーマーケットでバターを買うのが当たり前だと思っていますよね？ もちろん、今でも自分でバターを作る人はいるでしょうが、大多数はスーパーマーケットで買うバターに満足しています。Copilotはスーパーマーケットで買うバターのような存在になると思います。

GitHub Actionsが最初に登場した時はCI/CDのツールではない、GitHub上でデベロッパーが行うことの自動化のためのツールと言っていました。でも今やGitHub Actionsは世界最大のCI/CDツールだと言っています。結果としてベンダーロックインになってしまうのでは？

GitHubは常に「デベロッパーが何を必要としているのか？」を考えています。そのために足らない部分を埋めようとしている結果として自動化も必要でしたし、CI/CDもその過程で実現しています。でもデベロッパーがアプリケーションの特性に合わせてCI/CDのツールを選ぶ必要がある場合には、それも可能になっています。例えば自動運転のためのアプリケーションであれば、特殊なビルドツールも必要になるかもしれません。その時にデベロッパーが別のツールを使ってアプリケーションをビルドするプロセスやツールを組み合わせることも可能になっています。CopilotもVisual Studio CodeだけではなくJetBrainsのツールにも対応しているのは、デベロッパーの選択の自由を実現したいという思いからです。

今回Red HatがGitHub Universeに参加しているのを見て驚きました。Red Hatはどちらかと言えばインフラストラクチャーの会社でLinuxやサポートをOps側に提供するのが仕事だったと思います。Kyleさんに訊くべき質問ではないとは思いますが、どうしてRed Hatが参加しているんでしょう？

GitHub Universeはスポンサーの費用を払えば誰でも出展できるので彼らの意図を私が答えるのもどうかとは思いますが、Red HatはOuter Loop、つまりビルドからテスト、そしてデプロイというOuter Loopの部分からデベロッパーがローカルのマシンで実行するInner Loopの部分に焦点を合わせてきたからではないかと思います。その場合「デベロッパーが何を必要としているのか？」を考えた時にCopilotのようなツールに注目した、その結果としてGitHubのターゲット層と重なってきたことが今回、Red HatがCopilot Partner Programに参加している背景なのではないでしょうか。

●参考：Kubernetes-native inner loop development with Quarkus

実際に今回はRed HatだけではなくDatadogなどのモニタリングの会社も出展していますし、デベロッパーがコードを書くだけではない部分にも用途が拡大をしていくのを感じます。

我々が数年前にCopilotを考えていた時に戻って考えてみると、コードを書いたデベロッパーがアプリケーションを実行して、そのフィードバックをアプリケーションの改善に活かそうとした時にいろいろな種類のモニタリングツールやダッシュボードを使い分ける必要があったわけです。でもその部分にCopilotを使ってチャットの形で「どこを改善すれば良い？」というような質問で回答を得られたらベストだと考えたわけです。つまりCopilotがモニタリングツールなどにもアクセスしてデータを取得して「このデータによるとここを直せばもっと速くなります」ということを可能にするためにはCopilotが外部のツールと連係できることが必要なんですね。なのでCopilot Partner Programというエコシステムは重要なんです。それによってデベロッパーエクスペリエンスを改善する、デベロッパーファーストを実現すると思っています。

Copilotは英語に特化しているように見えます。プログラムのコード自体は英語に近いので日本のプログラマーも困っていないと思いますが、コメントやドキュメントは日本語であって欲しいというのが願いだと思います。CEOのThomasはGPT-4に依存しているのでGPT-4が可能なら日本語でも可能だと言っていました。Copilotがその部分に対応する予定は？

ご存じのようにGitHubはユーザーインターフェースを含めて多くのリソースを翻訳して多言語で提供しています。機械翻訳なども使いながら努力は継続していますが、まだ期待するレベルには達していないかもしれません。GitHubは機械翻訳と人間によるチェックを交えて多言語化を行っていますが、問題は「100万人を超えるデベロッパーに対応してスケールアウトできるようなアーキテクチャーを構築できるのか？」という部分なんです。単純にコンピュータと人間を組み合わてその規模のスケーラブルなシステムを可能にするのは非常に難しいので、これに関してはまだ取り組んでいるという段階ですね。

30分弱という時間の中で多くの回答を行ってくれたKyle Daigle氏のインタビューだった。先行ユーザーであるアクセンチュアの例も示しながら、コード生成だけではなくデベロッパーがチームで仕事をする部分においても意識をしてシステムの改良に取り組んでいる姿勢が強く感じられた内容となった。