GitHub Universe開催、ActionsとPackagesの背景にある思想をCTOに訊いた

GitHub Universe 2019では、ActionsとPackagesがともに正式版としてアナウンスされるという華々しい幕開けとなった。今回はGitHubのCTOで過去のUniverseでも何度もインタビューを行っているJason Warner氏にインタビューを行った。昨年のUniverseの時の肩書はまだVPであったが、今回は2019年11月にCTOという新たな肩書になったばかりという時点でのインタビューとなった。

今回はActionsとPackagesがベータ版から正式版になりました。Actionsは昨年のUniverseに発表され、大きな反響を呼びましたが、今回Packagesが一緒にアナウンスされた意味を教えてください。

GitHubのCTO、Jason Warner氏

GitHubにとってActionsというのは、ソフトウェア開発を行う際のワークフローとして重要な意味を持っています。昨年「ActionsはCI/CDツールなのか？」という質問を多くいただきました。あなたからもそういう質問をしていた記憶があります。当時私は「ActionsはCI/CDツールでもあり、そうでもない」という回答をしたことを覚えていますが、それは変わっていません。ActionsはCI/CDのツールであるよりも、もっと大きな意味を持っていると言いたいと思います。

参考：2018年のGitHub UniverseにおけるJason Warner氏のインタビュー

その意味を教えてください。

Actionsは、デベロッパーを中心に考えるGitHubのさまざまな機能を繋げる役割を担っています。つまりソースコードを書いてソフトウェアを開発するという仕事の中でActionsは、いろいろな機能を繋げる糊の役割を果たすのです。そう考えているから、ActionsはCI/CDツールか？　という質問には「Actionsはそれよりももっと大きなモノです」という回答になるわけです。CI/CDはActionsが果たす機能のうち、バーティカルなソリューションに過ぎません。Actionsはもっと大きな部分をカバーすると言えます。

もう一つ別の言い方をすれば、ActionsはGitHubが造る宇宙船なのです。宇宙船の中の椅子や部屋というパーツはそれぞれが別々のものですが、それらの個別のパーツを徐々に良くすることで宇宙船自体が快適なものになります。でも宇宙船ですから、他の椅子やパーツを使いたいという人もいるでしょう。そういう人のために、TravisやJenkinsなどを組み込むことができるようになっています。

ちょっと前にCircleCIのユーザーにどうしてJenkinsではなくてCircleCIを使うようになったのか？ という質問をしたことがあります。そのユーザーはArtifactのキャッシングが基本機能として備わっていることがCircleCIを使う大きな理由であると言っていました。そして今回のActionsにもArtifactのキャッシング機能が付いています。

そうですね。すでにキャッシング機能は実装されています。これはCI/CDのツールベンダーと競争しているというよりも、ユーザーが欲しいと思う機能を順に実装している、というようにとらえてください。我々はユーザーが必要としているツールを提供したいと思っています。そのために、常にユーザーの声を聞いています。同じジャンルのツールを作っているベンダーが持つすべての機能を実装するというのではなく、ユーザーの欲しいものを開発する、そしてユーザーに選択肢を与えているということです。

いずれにせよ、同じ目的を果たすツールはある程度は共通の機能を持つようになります。また新しいベンチャーや野心的なデベロッパーがまったく新しい独創的な機能を実装することがあるかもしれませんが、GitHubがそういうことをするとは思えません。

ActionsはCI/CDに限らず他のツールとの連携を実現するものであるというのはわかりました。ソースコードのリポジトリーではなくイメージのリポジトリーであるPackagesは、JFrogと直接競合するものでは？

ショーケースで大きな面積を占めていたCircleCIのブース

PackagesもGitHubが考えるデベロッパー中心のワークフローを実現するという発想から出てきた製品になりますが、ソースコードを書く、そこからイメージのビルド、テスト、そして配置という流れの中でイメージのリポジトリーが必要であるということから開発が進みました。大きな視点でソフトウェア開発を眺めてみれば、最初のプランニングか始まってソースコードを書く段階、そしてビルド、テストと進んでいくわけです。その際にCI/CDは必要なプロセスですし、その成果物を収めるリポジトリーも必要なわけです。そしてPackagesもGitHubの発想ではGitHubが開発して用意することは当然ですが、もちろんユーザーは選択の自由があります。我々のイメージリポジトリーはまだ最初のバージョンですから、すべての機能で同様のツールを作っているベンダーと並んでいるとは言えないでしょう。そこで、ユーザーがすでに使っているツールをActionsに組み込んでワークフローを利用することは可能ですし、それはこれまでと同じです。

でも実際には多くの機能がActionsやPackagesに実装されることで、CircleCIやJFrogのビジネスを殺すことになりませんか？

地味なブースのJFrog

私はそうは見ていません。どのツールもある程度の共通部分があるのは仕方ないことでしょう。それはユーザーが求めている機能ということでもあります。なのでActionsもPackagesも、ある程度は既存のツールと共通の機能を持つことになると思います。そしてユーザーは、ツールを選ぶ自由があるということになります。

Sonatypeのブース

GitHubには機械学習チームがありますが、そのチームを使ってもっとインテリジェントな機能をCI/CDに組み込むことで差別化を行おうという計画は？

我々の機械学習チームは、さまざまなソフトウェアの中に機械学習の機能を追加しています。コードサーチにもセキュリティの機能にも組み込まれています。多くの機能の中に組み込まれているために、ある機能だけを機械学習だからといって強調することがないくらいには利用されていますよ。

クラウドネイティブなシステムが拡がっていくなかでコンテナ化、マイクロサービス、そしてKubernetesがモダンなプラットフォームとして注目されています。GitHubとしてはそこにもっと注力するべきでは？

マイクロサービスもKubernetesも大きな流れとしては理解しています。しかしソフトウェア開発をもっと大きな視点で見れば、マイクロサービスだけがデザインパターンではないのです。当然ですが、まだモノリシックなソフトウェアを開発しているデベロッパーもいますし、すべてがマイクロサービスになる必要もないのです。

GitHubとしてはデザインだけに注目するのではなく、もっと多くの人にどうやったらGitHubを使ってもらえるのか？　に注目しています。もうひとつ言えば、GitHubのソフトウェアの将来について考える際に、私は常に未来を見てそこから逆算するというやり方をしています。すべての人がGitHubを使う、それが当たり前になるという未来を想定して、何が起こればそういうことが可能になるのか？　これを考えるのです。そうするとソースコードリポジトリーだけではなく、Packagesのようなイメージリポジトリーも必要ですし、セキュリティも重要になります。他にもテレメトリーやログ、トレーシングも重要になるでしょう。なので2019年9月に発表したSemmle（コード分析プラットフォーム）の買収も、これからの製品の将来を考えると理に適っています。

昨年のUniverseの時にビッグデータのようなソースコード以外を管理する機能を実装する予定は？　という質問をしました。それの回答の一部がPackagesだと思いますが、他にも拡張の予定は？

昨年のインタビューでも、「デベロッパー以外の職業の人たちにもGitHubを使ってもらいたい。そのための何をするべきか？」という話をしましたね。すべての人がGitHub上で仕事を進められるようになるために何をするべきか？　これも逆算の発想ですね。GitHubにはそうなるポテンシャルがあると信じていますし、この世の中で最もクールなソフトウェアカンパニーになれると思っています。ただそうなるためには、信念とそれに沿った製品が必要です。

最悪のパターンはソースコード用の製品とソースコード以外のための製品、つまりデベロッパー以外の人が使う製品があって、それぞれにコネクターがあって接続する、というような方法ですね。これは最悪のパターンです。

そうではなくて、すべての人が一つのプラットフォームの上で仕事をする、コラボレーションする、というやり方が大切です。そのためには何が必要か？　これを考えています。そのためにはまだ多くのことを実装する必要があります。今のところ思いつくのは、ソフトウェア開発で言えば最も初期の部分、つまりソフトウェアを企画する部分の機能と、最終的にソフトウェアをデプロイした後の運用の部分ですね。そこをカバーするべきだと思っています。

プランニングの部分はソフトウェアのデザインのフェーズだと思いますので、そのところからアイデアの共有やコラボレーションが生まれるのは必要だと思います。しかし最後の運用の部分はもうデベロッパーの領域を超えてインフラストラクチャーの部分では？

しかしそれも含めてソフトウェアが成り立っているのであれば、そこはカバーするべきでしょう。Infrastructure as Codeとも関係していきますが。

そうするとカオスエンジニアリングなども視野に入ってくるのでしょうか？

カオスエンジニアリングについても重要な領域だと思いますが、製品として成り立つにははまだ少し早いかなと思います。

昨年のGitHub Universeでは「ActionsはCI/CDか？」という質問が多くのメディアから出されて多少辟易としていた風のWarner氏であったが、今年はActionsとイメージリポジトリーのPackagesが正式版となったこともあって多分にリラックスしていたように見られたインタビューとなった。

しかしActionsが実際にCI/CDの機能として紹介され、パートナーブースにはCircleCIやTravis CI、JenkinsのCloudBees、JFrog、Sonatypeなどが出展していた。GitHubから見ると、彼らは競合でもありエコシステムのパートナーでもあるという微妙な関係性であり、これらの競合他社に対して、GitHubが気を遣う場面を何度も見かけたことが印象的であった。