米国ベイエリアレポート（第 9 回）GitHubとソーシャルコーディング

Google, Apple, Facebook等、IT業界を牽引するグローバルカンパニーが集積するシリコンバレー。それら先進企業においても、オープンソースソフトウェアの存在は不可欠なものとなっています。

ここではシリコンバレーにおけるIT、オープンソースの動向について、紹介させて頂きます。今回は、第8回目として、GitHubのヴァイスプレジデントとして、事業戦略の策定に携われているブライアン・ドールさん(Mr. Brian Doll) にお伺いした内容を以下ご紹介いたします。

ブライアン・ドールさんのご紹介

ブライアン・ドールさん

(過去のご経歴をご紹介いただけますか。)

私は現在、GitHub社 (GitHub, Inc) において、ヴァイスプレジデントとして事業戦略立案を担当しております。私はこれまでテクノロジー業界に身を置いてきましたが、1999年にカリフォルニアの方へ移ってきました。ソフトウェアエンジニアとしてキャリアをスタートし、かれこれ15年程、エンジニアとして業界に携わってきましたが、そんな中、クライアントに何かしらのインパクトをもたらすことに、仕事としてのやりがいを感じ、マーケティングの方面へキャリアをシフトさせました。よって、私のスキルセットは常にクライアント向けの製品開発のためのものであり、クライアントとの対話を大切にするようにしています。

(GitHub社の前は、New Relic社で勤務されてきたとのことですよね?)

はい、GitHub社の前は、New Relic社　(New Relic, Inc) に勤務していました。

New Relic社には、かなり早いタイミングで参画しており、当時はまだエンジニアも35名しかおらず、当時はRuby向けのみのビジネスでした。実はそれまで、私はNew Relicのユーザーで、当時、私がエンジニアリングチームと共に、どのようにNew Relicのシステムを利用しているのか、等々をお話していたのですが、あるとき、New Relic社の創業者であるルー・サーン (Lew Cirne) とお会いする機会があり、それをきっかけにNew Relic社で働くこととなりました。

最終的にはNew Relic社は4つの開発言語をサポートするサービスを提供するようになり、彼らのツールをどのようにマーケティングしていくか、という議論が必要とされるようになりました。New Relic社のサービスはRubyのコミュニティではよく知られていましたが、PythonやJava、PHPのコミュニティでは、当時まだあまり認知されておらず、同時に、いくつかのソフトウェアのコンセプトやパフォーマンスモニタリングに関する技術についても、Javaの分野では確立されていても、RubyやPHP、Pythonではまだ確立されていない場合もあり、彼らの製品をマーケッティングしていくことはとても貴重で楽しい経験でもありました。

(最近はどのようなことを中心に従事されているのですか。)

私の現在の担当はクライアントもしくは、潜在的なクライアントとの対話であり、ソフトウェアの短期間でのリリースに向けた方法を模索している経営陣との対話に多くの時間を費やしています。

そこでの対話のトピックは大きく二つの分野に分けられます。

一つはよりモダンなツール、継続的開発 (Continuous Integration / Delivery)、クラウドプラットフォームといった技術的観点でのトピックが挙げられ、そういった比較的新しい技術は、大企業においはまだ全社的な導入に至っていないとケースが少なくありません。そこで私達はGitHubといったプラットフォームのみならず、関連するツールと合わせた導入をサポートしています。

また、今日におけるソフトウェア開発は、コーディング以外にも様々な作業が必要となります。ソフトウェア技術の周りには様々な人々が関わりを持っており、具体的にはカスタマーサポート、マーケティング、セールス、コミュニケーション及びドキュメンテーションと言った作業に携わる人々が挙げられます。そこでもう一つのトピックとしては、そういった今日のソフトウェア開発におけるチーム内、チーム間でのコラボレーションの必要性が高まっており、そういうテーマが挙げられます。

GitHubの歴史と提供サービス

GitHubのPull Requestの開発に用いられたノートパソコン

(GitHubの歴史について、簡単にご紹介いただけますでしょうか。)

Git Hubは、8年ほど前に立ち上げられました。2007年の10月にGit Hubの開発が開始され、2008年4月にサービスがリリースされました。つまり、かなり短期間で構築がなされたというわけです。分散型バージョンコントロールシステムであるGitは、Subversionといった中央管理型システムに対して、非常に画期的なものであり、多くの人がすぐに、中央から独立して、ブランチを管理できるリポジトリの価値を理解しましたが、皮肉にも分散型リポジトリは皆がフルセットのリポジトリを保有することとなり、新たな問題も浮上しました。

Gitのリポジトリーをシェアするための一種のハブを作る、というアイディアを最初にシェアしたのは、サンフランシスコで開催されたRubyのミートアップでした。それはまさにソフト開発現場での必要性から生まれたモノと言えます。私達は比較的早い時期にすでに、オープンソースプロジェクトにおいては無料での利用とし、プライベートリポジトリーに課金するというビジネスモデルを考えついたわけですが、よい選択だったと思います。

また、GitHubのオンプレミスバージョンである、GitHubエンタープライズの立ち上げも行いました。それはあなたの会社の社内においてGitHubを運用できるようにするものであり、今や何万人といった開発者が社内のGitHubで開発を行っています。最近のGitHubエンタープライズに関する主だった動きとしては、昨年11月に実施されたAWS対応です。GitHubエンタープライズは、会社が所有するサーバーにインストールすることも可能ですが、今日においては大手企業ですら、開発環境をクラウドに移行するケースが増えてきています。しかし、彼らの多くはプライバシーおよび他者からの独立性を同時に希望します。彼らは彼らの会社のためだけのGitHubを必要としますが、彼ら独自のハードウェアは持ちたくない、という実情があり、AWSにてプライベートなGitHubを持つことができるようになった、ということです。

これらの二つがGitHub社が提供する主要な製品となります。

(クライアントはGitHubのプライベートリポジトリではなく、GitHub Enterpriseを選択される主な理由としては何が挙げられるのでしょうか。)

大きく二つの理由が挙げられます。

一つはID管理です。もし会社に何万人もの開発者がいる場合に、私だったら、その何万人といった開発者のユーザー情報を一般公開されているウェブサービスに登録したいとは思いません。その点において、GitHubエンタープライズは社内だけの利用となるため、とてもメリットがあると思います。GitHubエンタープライズの導入により、社内でのみ参照可能なLDAPサーバーと連携させることもできるためです。

二点目としては、自分の持ち物は他の人のものと、切り離して管理したい、というビジネス上の要望が挙げられます。GitHubのプライベートリポジトリを利用するとしても、GitHubを利用する限り、それはGitHubで公開されるプロジェクトの一部、と言う位置づけになります。GitHubエンタープライズを利用することで、それは会社だけのものであり、完全に秘匿することができます。もし多くの開発者と共に作業を行う場合には、GitHubエンタープライズが選択肢の一つとなるでしょう。

(GitHubとその他のソーシャルコーディングプラットフォームとの主な違いとしては何が挙げられますか。)

この2,3年、市場においてとても興味深い変化を示しています。

GitHubは6年ほど前からすでに世界最大規模のソースコードリポジトリですが、今年の1月(*1)、GitHub.comへのアクセス数は、世界のウェブサイトのトップ100に入りました。検索エンジンや、facebookといったソーシャルネットワークサービスが占めるトップ100にGitHubが入ったと言うことは驚きに値することではないでしょうか。GitHubには2,000万のプロジェクト、3,000万のユーザーがアクセスしています。私達は世界中の大学と協働し、クラスではGitHubを用いて授業が行われています。つまり、リクルーターが探し求める技術者および、従業員の大半はすでにGitHubの使い方を理解している、ということであり、ソフトウェアに関する仕事でのデファクトスタンダード (de-facto standard) になっている、といえるでしょう。もし、私自身がオープンソースのプロジェクトを運営する場合にも、間違いなくGitHubを利用します。

Google社 (Google, Inc)は、先週 (*1) 、Google Codeを閉鎖しました。GoogleはGitHubが立ち上げられる前から、類似したソフトウェアの共同開発のためのプラットフォームを運営してきましたが、彼らの目にもGitHubが主流となっていると映ったのでしょう。彼らはGoogle Codeの閉鎖をアナウンスすると同時に、すべてのプロジェクトをGitHubへ移行するため、私達もこの2,3か月ほどはその作業に従事してきました。

Microsoft社 (Microsoft Corporation)も同様です。彼らもまた、CodePlexと呼ばれるコラボレーションプラットフォームを運営してきましたが、2か月前(*1) 、.Netフレームワークを含む数千ものプロジェクトをGitHubに移行しました。そして、昨日、Microsoftの開発ツールのGitHubへの移行を完了しました。

彼らのCEOが代わって以来、彼らのエンジニアの多くがGitHub上で作業をするようになり、今、彼らの中でとても大きな変化が起きていると感じます。また、Microsoft社は、Microsoft社とは独立した組織である、.Net財団 (.Net foundation)を設立しました。Microsoft社は.Net財団のメンバーではありますが、Microsoft社以外にも、.Netフレームワークの未来のために、財団のメンバーになることが可能となっています。

(新しくGitHubでリポジトリを作成するとき、複数のオープンソースライセンスの定義から一つを選択することができますが、今日、ソフトウェアに複数のライセンスを割り当てる、ということもあります。選択したライセンス定義はGitHubでどのように利用されているのですか。)

かれこれ2年前となりますが、当時、私達はGitHubのプロジェクトでライセンス定義をしていないプロジェクトの数を調査していました。もしあなたがコードを所有し、ライセンス条項をそこに含めていない場合、それらコードはあなたの支配下となります。あなたはアメリカの著作権法の元、完全な著作権が保護されます。それはあなたがソフトウェアの権利を他に譲りたくなく、意図的にそうしている場合にはそれでよいでしょう。

しかし、そのようにしている人の多くは、ただ、ライセンス条項の存在を忘れているだけであり、必ずしもソースコードの独占を意図しているわけではないように思いました。そこで、私達は"Choose a license"というウェブサイトの立ち上げを行いました。ソフトウェアライセンスはとても理解が困難です。そこには多数の選択肢があり、あなたの要望に応えるものとして、4つ、もしくは5つ該当するものが見つかるでしょう。私達はそれらライセンスがどのようなものなのかについて示す、説明書きをウェブサイトにしたかったわけではなく、質問にもあるライセンス条項の選択機能を合わせて実装しました。それはユーザーがライセンスというものの存在に気づいてもらえるように意図したものです。

私達がライセンス定義のために必要なものは一つのテキストファイルのみです。ライセンス選択機能はただライセンス定義のテキストファイルを配置するだけであり、複数のファイルを追加配置することも可能です。ライセンス選択機能はただ、ユーザーにライセンスというものについて意識してもらうことを意図したものです。

(GitHubにおいて、"Contributor License Agreement"の管理について、推奨する方法はありますか。)

CLA Hubというサービスがあります。

CLAはシンプルな同意書であり、その同意書に対して明示的に拒否する人々は、リストに名前を記録し、Pull Requestと連動させる、と言うことが行われます。GitHub.com自体はCLAの問題を解決するわけではありませんが、そのようなサービスを活用することで問題を回避できるでしょう。

これらの問題を解決する方法は他にも多くありますが、CLA拒否者のリストを継続的にメンテナンスすることが困難な場合もあるでしょう。私が記憶する中で最も大きなライセンス変更を行ったプロジェクトとしてはTwitterのBootstrapが挙げられます。彼らはライセンスを変更しようとしましたが、CLAを持っていませんでした。それは大変な作業ではありましたが、不可能な作業ではない、ということです。GitHubではたった一行のコミットに対してもe-mailを取得することができるため、本の数秒で貢献者のリストを取得することができるためです。

(Twitterは、Scalaに移行したのに対して、GitHubはRuby On Railsで実装されているとうかがっていますが、どのようにそのスケーラビリティを実現しているのでしょうか。)

TwitterとGitHubは多くの点で異なった特徴もありますが、共通する特徴としては、私達はウェブシステムに対するアクセスやAPIリクエストに対するトラフィックを常に考慮する必要がある、ということです。私達はgit接続を管理する必要がありますが、それらのいくつかは、SSLによる接続もあるでしょうし、シンプルなgitプロトコルによる接続など、世界中の端末から様々な接続要求がきます。

その上でシステムのスケーラビリティに対する考え方はある種の文化的な価値観に基づくものであるもと思います。私たちにとってシステムのパフォーマンスは極めて重要です。フィードバックの取得に時間がかかってしまうようなシステムでは、コラボレーションは実現されないでしょうし、そのためにも私達もパフォーマンスについては常に意識しています。そういった問題は技術的改善で克服できる場合もあるでしょうが、場合によっては、私達が対応しきれないような機能の実装を避ける、と言う選択肢で対応することもあります。

GitHub.comはまだRuby On Railsを使っているということは事実ですが、Ruby On Railsで対応しきれない箇所については、C言語を用いています。例としてはコードのハイライト (Syntax High-lightening) があげられます。それは、あなたがコードをGitHubにプッシュしたとき、差分を色を付けて表示する機能です。私達はどのプログラミング言語でそれが記述されたものかを検出し、CSSで装飾する、ということをしているわけですが、日々、何百万ラインと言うコードがプッシュされ、すべての新規コードに対して色を付ける、ということをしなければならず、それは処理のボトルネックであり、他の言語、ツールを用いて改善していくことが求められている分野と言えます。

ソーシャルコーディングとビジネス

GitHub社で行われた取材の様子

(近年のオープンソースプロジェクトにおいて、ライセンスおよび開発言語について、何か新たな動向を感じられることはございますか。)

先週(*1) のブログポストにて、そこに多くの情報を書きだしました。そこにライセンスについても触れていますが、興味深いこととしては、コミュニティの種別やプログラミング言語に応じて、同じライセンスを採用するケースが多い、ということです。たとえば、MatzはRubyにMITを選択しましたが、その結果、世界中のRubyに関係するプロジェクトのほとんどすべてがMITを採用しています。

Ruby on RailsもMITですし、gemもMITであり、MITがこのRubyコミュニティにおける規準になっている、といえるのではないでしょうか。他のコミュニティを見ても同様の傾向を確認できるでしょう。たとえば、Apacheに関するものであれば、Rubyに関係するすべてのテクノロジーでも、今度はApacheライセンスを選択していることでしょう。私にはそれらの中でどのライセンスがいいのか、わかりませんが、オープンソースライセンスを採用する会社に対して、多額のライセンスを払いたくない、というのがユーザー側の共通の関心事項ではないでしょうか。

そして、もしライセンスが定められていない場合には、人々はそれを利用することはできませんし、仮にライセンスが定められていたとしても、そこには次の問題が控えています。それは対象ソフトウェアにバンドルされているすべてのソフトウェアに割り当てられているライセンスはなんなのか、です。ブログポストにおいて、私達は新しいAPIのエンドポイントについて紹介しましたが、GitHub上のプロジェクトのライセンス情報を取得できるようにしているので、もしあなたが興味のあるプロジェクトがある場合には、その関連ライセンスのリストを取得することができます。

(オープンソースの開発において、特に活発に動いている地域などはございますか。)

GitHub.comへのアメリカ全土からのアクセスは全体の27%程度です。私達はすべてのトラフィックデータを取得しており、それは一つの側面を示しているにすぎず、ちょっとしたデータ分析の壁に当たっているとも言えます。毎年、私達はGitHub上でのアクティビティに関する情報を公表していますが、2,3年前にアクティビティを地図データとしてきれいに表示するツールを見たことがあります。それは地図データではありますが、人口が多い国ほど活発な活動がなされている、というように、ほとんど人口分布と似偏った傾向にありました。そして次に一人当たりの活動を見ると、確か、スウェーデン、ノルウェーにおいて、高い貢献が見て取れました。それがなぜかはわかりませんが、どちらにせよ、世界いたるところからのアクセスを見て取れ、その中でも特に中国、イスラム圏やロシアからも活動を見て取ることができました。

(先日、サンフランシスコ開催のDeveloper Weekの1セッションにて、今オープンソースビジネスのおいて、80年代のpure OSSを用いたコンサルティングビジネス、2000年前後のCommunity Edition / Enterprise Editionといったデュアルライセンスモデルでのビジネスから、今、"Open Standards"や"Open APIs"と言う名の新たなビジネスモデルの波が来ているという表現をされていましたが、そのように思われますか。)

上手い説明ですね。

もしあなたがどんな技術領域の製品開発に取り組んでいるとしても、今、人々がインタラクティブに活動できるようなシステムに対する期待が高まっていると言えるのではないでしょうか。とてもオープンソース的な観点での動きと言えると思います。特にその流れは開発ツールにおいてよく見てとれます。

私達が提供しているビジネスはサービス業であり、PaaS (Platform as a Service) です。私達はサーバー上でサービスおよび、APIを提供しています。もう一つの側面としては、GitHubは開発環境であり、AWS上において、GitHubに接続するRubyクライアント、Javaクライアント、Nodeクライアントなどを利用できます。APIの裏側は有料のサービスとなっているわけですが、もし無料のAPIを利用できない場合には、それらのサービスを利用することはないでしょう。なぜならば、私達はオープンな仕様に基づくAPIを介した相互接続を実現したいと考えるためです。

最後に

GitHubのオフィス

(次のステップとしては、どのようなことを計画されていますか。)

今、いくつか考えていることがあります。

私達の中で最も重要なこととしては、世の中には多くの人が会社に勤めていますが、まだGitHubを利用していない、と言う人が多くいる、ということです。私はそのような会社がどのようにすれば、より良いソフトウェアをリリースできるようになるのか、その方法を見つけだし、サポートしていきたいと考えています。私にとって、クライアントの経営陣と、GitHubの利用価値を紹介し、議論を重ねることは、とても貴重な経験だと感じています。会社において、エンジニアが連携をとって仕事に取り組めるよう、プロジェクトを外部関係者にも公開する場合には、GitHub上での作業に入る前に、まず何より先に、対象とするプロジェクトの発掘、整理から始まります。あなたがその会社でソフトウェア開発にフルタイムで働いているとしても、なかなか、そういう場面に遭遇する機会はないのではないでしょうか。

そして、さらには、世界中のすべての大手企業が、お互い連携を取りながら作業を進められるようにする、というチャレンジが挙げられます。

(ソフトウェアエンジニアにお薦めの本はありますか。)

世の中に出回っている中で、歴史のある名著として、"ピープルウェア"が挙げられます。

"ピープルウェア"は私のキャリア形成に影響をもたらした本です。システムの開発は楽しいですし、とてもエキサイティングですが、危険なこととしては間違ったものを作ってしまう、ということです。私は人々に影響をもたらすことに興味を持っており、ソフトウェアの開発もその一つです。そして、そのソフトウェア開発でもっとも大切なことが人々との会話にあると思っています。"ピープルウェア"は、チームを組んで作業をする上で重要な視座を提供するものであり、人々が一緒に働く上で大切なことは、必ずしもコードに関連したものだけではない、ということです。たとえば、ある議論で反対を受けたときに、どのようにすれば合意にたどり着けるのか、"ピープルウェア"は良いソフトウェアを開発するうえで、キーとなるそのようなトピックを紹介する本であり、私からのおすすめです。

(本日はご協力ありがとうございました。)

*1) 本取材は2015年3月20日に実施されたものです。

【講演資料を公開】11/15【経理部門向け】増え続ける経理業務のExcel問題を、kintoneで解決する～会計業務支援をローコード開発で、経理DXのためのヒントを公開～（2022年12月15日 09:15）

2022-11-15（火）14:00 - 14:55 「【経理部門向け】増え続ける経理業務のExcel問題を、kintoneで解決する～会計業務支援をローコード開発で、経理DXのためのヒントを公開～」と題したウェビナーが開催されました。皆様のご参加、誠にありがとうございました。 **当日の資料は**以下から無料でご覧いただけます。ご興味のある企業さま、ぜひご覧ください。