GitHub SatelliteでSVPに聞いたシステムインテグレーターへのアドバイスとは

連載 :

2018年7月12日(木)

都内で行われたGitHubのカンファレンスで語られたDMM.comの事例と、SVPへのインタビューをお届けする。

ソースコードリポジトリーのGitHubが、2018年6月12日と13日に都内でプライベートカンファレンス「GitHub Satellite」を開催した。2回目の記事では、GitHub Enterpriseの事例であるDMM.comのエンジニア、唐澤陽介氏によるセッション、そしてSVP of TechnologyのJason Warner氏とMicrosoft、GoogleなどでProduct Managerを務めた経験を持つ及川卓也氏との対談を取りまとめてお届けする。

DMM.comによるGitHub Enterpriseの事例

GitHub EnterpriseはGitHubの商用バージョンであり、オンプレミスにGitHub環境を構築するための製品としてGitHubの売り上げを支える主力製品ということになる。もっともDMM.comは全てのサービスをAWS上で運用しているということなので、オンプレミスというよりは「AWSの上に構築された占有環境」というのが正しい理解だろう。DMM.comがすでに自社保有のサーバー上でGitサーバーを稼働させていたにも関わらずGitHub Enterpriseを選んだという辺りは、非常に興味深い。この辺りは、エンジニアがすでにGitHubを使っていて、ある程度知見があること、同じ操作方法などで開発からCI/CDまでが回せるといって点にヒントがありそうだ。

登壇するDMMの唐澤氏

DMM.comでのGitHub Enterpriseの導入は、全体の約4割といったところだろうか。各々のチームがそれぞれ言語やツールを選択しているということで、チームごとに事情が異なるのであろう。

DMM.com全体からみたGitHub Enterpriseの導入例

実際の導入までの経緯としては、Gitサーバーが稼働しているという段階から社内の環境改善チームによるGitHubの試用、そして他のチームを巻き込んでGitHub Enterpriseの導入というステップを踏んだと思われる。この手法は、他のエンタープライズ企業においても参考になるステップではないだろうか。

IT環境は全てAWS上に構築

またCI/CDについても開発環境、検証環境そして本番環境のフローを紹介し、テストおよびデプロイが自動的に回る仕組みを解説した。

DMM.comのCI/CDパイプラインの例

ここまではいわゆる「パイプライン」の解説だが、いかにも現場で苦労したことを伺わせるのは、ビルド時に処理速度を上げるために、イメージをキャッシュする構成ファイルの例を公開した点だろう。

CircleCIの構成ファイルの例。キャッシュの設定がされていることがわかる

最後に、GitHub Enterpriseを導入して約1年という時点での感想として、今後、多くのプロジェクトがGitHub Enterpriseを使うであろうということを語って、締めくくった。

Jason Warner×及川卓也

続いてJason Warner氏と及川卓也氏の会談をお届けする。

SVP of TechnologyのJason Warner氏

及川：まずMicrosoftによる買収発表、おめでとうございます。私もインタビュワーの松下さんも以前Microsoftにいたことがあるので、今回の発表を喜んでいるところです。

Warner：ありがとうございます。期待してもらって良いと思いますよ（笑）。

及川：まず「これから未来のソフトウェア開発がどうなるのか？」というポイントについて意見を聞かせてください。去年のGitHub UniverseでGitHubのCEOが、「将来のソフトウェアはNo Codingになる」と語ったと聞いています。自動プログラミング、自律的プログラミングには大きな期待を掛けている一人として、今後それはどうなっていくと思いますか？

Warner：Autonomous Codingは、まず「ソフトウェアを書くというプロセスを自動化する」というところから始めると考えています。そしてGitHubのゴールは、「エディターで書いたものが実際にデプロイされるというところまでのループを限りなく自動化する」というものです。実際にそれが可能になれば、そのプロセスの中で大量のデータが発生します。今はまだこれをログという形でしか見られませんが、今後は機械学習を通じて利用することで、さらにループを短くする、速くするというのが目標になるでしょう。GitHubはそれをインサイトとして利用することを計画しています。

及川：GitHubは、Atomというエディターを持っています。それをもっとソフトウェア開発のライフサイクルを高速化するために、他のツールと連携を進めるということですか？　例えば、Microsoftのツールなどと？

Warner：そうですね。我々はプラットフォームを持っています。AtomはGitHubが開発するツールですが、プラットフォームの一部としてさらにほかのツールとの連携も深まっていくでしょう。Microsoftの製品との統合などについては、MicrosoftのCEOであるSatya Nadellaのブログにもあるように、GitHubは独立した組織として運営をしていきます。ですので、MicrosoftのほうからAtomをMicrosoftの持つ他のツールと連携したいということは起こるかもしれません。まぁ、ご存じのようにGitHubがMicrosoftを買ったわけですから（笑）。

ここは今回の来日中、何度も何度もMicrosoftに買収されることが決まったことによる影響や計画などを質問されて、若干うんざりしていた心中が伺える瞬間であった。インタビューをしていた筆者も及川氏も周りのスタッフも、ここでは大爆笑が起こったことはメモしておきたい。

元Googleのエンジニア及川卓也氏

及川：今回のカンファレンスの中で何度も「GitHubの社員の65％はリモートで働いている」ということが語られました。日本でもそれは必要だとは思いますが、ただ、単にリモートワークにするとコミュニケーションがうまく取れないという欠点があります。それについて何かヒントはありませんか？

Warner：私自身も、今はリモートで働いています。過去10年ほど、私はずっとリモートで働いてきた経験を持っていますが、その経験から言えば、コミュニケーションは非常に重要です。つまり、同じことを何度も何度も言わないといけないということになります。それは書いておくこともありますし、ビデオ会議で言わなければいけないこともありますし、フェースツーフェースで会話する時でも同じなのです。その苦労を厭ってはいけません。

あと、これは私の経験からの知見ですが、最もうまくいくリモートワークの組織は、全ての社員がリモートワークをしているという組織ですね。逆に最もうまくいかない組織は、大部分の社員が本社に勤務していてごく一部の社員がリモートワークをしているというものだと思います。多くの企業が、その二つを両極にした中間のどこかにいる感じだと思います。

及川：日本のIT環境の特徴的なことは、ソフトウェアを書くデベロッパーがエンタープライズ企業には存在せず、多くはシステムインテグレーターに存在しているということだと思います。それは理解していると思いますが、システムインテグレーターに対して何か提案はありますか？

Warner：日本のシステムインテグレーターに私が何か提案するというのもちょっと厳しいお願いですが、もしもするとすればソフトウェアを書いているという経験を生かして、よりSpecific、つまり特化したソフトウェアを書く、なんにでも使える一般的なソフトウェアではなく、すぐにある業界の問題を解決できるソフトウェアを書くことに専念することですね。

よくIT業界でみられる現象として、プラットフォームベンダーを目指している企業がパートナーが持ってきたアイデアを自分で横取りしてしまうということがあります。これではエコシステムは拡大しませんし、パートナーも増えません。それを続けることでソフトウェアを書くデベロッパーも増えるでしょうし、経験も積まれていくでしょう。

松下：最後に私からもJasonさんに質問をさせてください。これまでGitHubはソースコードのリポジトリーとして利用が拡がってきました。特にオープンソースソフトウェアにおいては、デ・ファクト・スタンダードのリポジトリーであると思います。

リポジトリーは、ある問題を解決するアルゴリズムをソースコードという形で表現する場合には最適だと思いますが、機械学習のようにデータそのもの、モデルそのものが価値を生むという時代がもう来ていると思います。その時にGitHubの今のリポジトリーの機能では対応できないと思われます。これに関しては何か計画はありますか？

Warner：良い質問です。確かに今の構造は、機械学習に必要なデータを格納することはできないとは言いませんが、最適ではありません。すでにそれに関しては計画していますし、近い将来に何か発表できるかもしれません。11月にGitHub Universeがサンフランシスコでありますので、それにはぜひ参加してください。何かお話しできることがあるかもしれません。