誰もが自由にプログラムを変更・公開し、開発元へ還元できる！
大場氏はまず、GitHub導入以前にグリーが抱えていた開発の課題として、「急激な増員」「業種の増加」「国際化」の3つを挙げた。
急成長する企業の宿命ともいえるが、2010年には200人程度だった社員数が毎月50人のペースで増え続け、2012年には約1400人の規模にまで拡大。グリーでは以前から社内でスカイプのチャットなどをよく活用していたが、エンジニアの人数がスカイプの1チャットルームに参加できる最大人数である300人をはるかに上回り、開発時の情報共有に支障をきたすようになったという。
また、以前はWeb系のエンジニアとデザイナーがいればほとんどのプロジェクトがまわったが、スマートフォン対応や3Dなどのリッチコンテンツ開発も増え、1つのプロジェクトに多様な業種のスタッフが関わるようになってきた。さらに、海外9拠点でビジネスを展開するようになり、現地採用のエンジニアはもちろん、日本の開発チーム内にも外国のエンジニアが増えるなど、国際化も進んだ。
こうした背景から、多数のエンジニアが円滑にコミュニケーションを図りながら開発生産性を向上するために、開発環境の見直しが強く求められるようになった。そこでグリーが着目したのがGitおよびGitHubである。
「ちょうどその頃、開発環境の動向としては、ソースコード管理（バージョン管理）の主流がSubversion（SVN）からGitに変わりつつあり、多くのOSSプロジェクトでGitへの移行が進んでいた」（大場氏）
SVNが単一リポジトリで中央集約型のバージョン管理システムであるのに対し、分散型リポジトリのGitは開発者一人一人が自分のPCなどにそれぞれリポジトリを持てるのが大きな特徴だ。そのため、ネットワークに接続していない状態でも、プログラムを変更してリポジトリにコミットすることができる。そして、このGitを使ってプロジェクトをホスティングできるサービスがGitHubだ。
「GitHubとは、ひと言でいえばプロジェクト管理にソーシャル機能をビルトインしたもの」と大場氏は語り、「GitHubの素晴らしいところ」としてforkとpull requestの機能を挙げた。forkは、他人のプロジェクト（リポジトリ）のコピーを自分のリポジトリに作成できる機能で、書き込み権限のないプロジェクトでもforkで自分の手元に持ってくれば自由に変更できるようになる。変更したものはそのまま公開することも可能だ。また、forkで自分が加えた変更を開発元のリポジトリに還元するための機能がpull requestで、pull requestを受け取った開発元はその内容をレビューして必要と判断すれば、merge機能で容易に自分のプロジェクトに統合できる。
「GitHubがなかった時代は、ソースコードを修正してプロジェクトを変更できるコミッターがソフトウェア開発における『特権階級』であり、それ以外の人はメインストリームの変更が行えなかった。それがGitHubの登場により、誰もがソースコードを変更してそれを公開し、さらには開発元へ還元できるという環境が実現した。この変化は非常に画期的なことで、これを『コードの民主革命』と表現する人もいるほど」（大場氏）
例えば、SourceForgeなどの従来のプロジェクトホスティングサービスでは、「プロジェクトに人がぶらさがる」ようなイメージで、あくまでもプロジェクト中心に管理されていた。それに対して、GitHubは「その人がどのプロジェクトに参加したのか」などがひと目で分かるUIとなっており、ソーシャル機能を提供することで、プロジェクト中心ではなく人間中心の管理となっているのも特徴だ。
企業導入ではGitHubをオンプレミスで使うという選択肢も
グリーでは、2004年の立ち上げ時よりソースコード管理にSVNを使ってきたが、開発環境の見直しにより、まず2010年にGit（gitosis）を導入。その後、さらにプロジェクトを超えてコラボレーションするための機能を強化すべく、2012年にGitHubの導入に至った。GitHub導入にあたっては、他にも埋もれているプログラムの発掘や、国際化対応といった狙いもあったという。
検証期間を経て、実際にGitHubを使い始めてからまだ数か月であり、社内のガイドラインなども一部整備中の段階だが、すでにその効果は表れ始めているようだ。
「gitosisで管理していた頃は、リポジトリは一人1つに限られ、作成する場合も事前に申請し、リポジトリメンテナの承認を受ける必要があった。エンジニアにとってはソースコードを公開するプロセスがかなり面倒で、『面倒だから公開しない』という悪循環に陥っていた。今は、それが『簡単に行えるのでどんどん公開する』というよい循環になってきたと思う」（大場氏）
その要因としては、やはりGitHub導入により、リポジトリを好きなときに一人いくつでも作成できるようになったことが挙げられる。また、Gistという機能でコードスニペット（短いコードの断片）も簡単に保管・公開できるため、これまで手元で書き捨てられていたり、埋もれていたようなコードも多数公開され、共有されるようになった。国際化対応についても、ワールドワイドで共通のツールとなり、「ログイン方法さえ各拠点に教えておけば、あとは勝手に使ってくれる」と大場氏がいうほどうまくっている。
そして、もう一つ得られた大きなメリットが、開発にまつわる行動の可視化だ。誰が何を開発しているのか、メンテナ、プロジェクトオーナー、チームメンバーは誰かなどが、GitHub上で容易に分かるようになった。
さらに、「ソフトウェアの寿命を伸ばしてくれるという効果も大きい」と、大場氏は強調する。
「『更新されないプログラム』は、いずれ死んでしまう。GitHubを使うことで、オリジナルの開発者が退職したり、そのプロジェクトに興味がなくなってメンテナンスされなくなったとしても、別の人が更新できるので、以前なら使い捨てられていたようなプログラムも活かせるようになった」
もちろん、GitHubの導入にあたっては、クリアしなければならない課題も存在する。中でも多くの企業に共通していえるのが、自社の貴重なリソースであるソースコードを社外に置けるのかという問題だ。セキュリティ上の理由などで、特に日本の企業では難しい場合が多いのではないだろうか。実は、グリーの場合も最終的にソースコードを社外に出すのはよしとせず、社内にソースコードを置きながらGitHubを使うという方法を選択している。具体的にどういうことなのか、大場氏は次のように説明した。
「GitHubには社内に閉じた範囲で利用できるオンプレミス版の『GitHub Enterprise』というソリューションがあり、これを採用している。GitHubから提供される仮想アプライアンスで社内にGitHubサーバを構築する仕組みで、ソースコードを社外に置く必要がなく社内でセキュアに管理しながら、本家のGitHubと同じようにフルセットの機能を利用することができる」
GitHubは機能の追加・強化なども頻繁に行われるが、それについても本家同様にGitHub Enterpriseに対して最新のアップデートが適用されるという。
ただし、このGitHub Enterpriseの導入判断も慎重に行わなければならない。大場氏は、次のように指摘する。
「GitHubをインターネットから切り離して、会社という閉じた空間に置くことで、最大のメリットであるソーシャル機能を活かせるのかという問題がある。感覚的には、ユーザー数100人程度ではGitHubのソーシャル機能をうまく活かすのは難しいのではないかと思う。（エンジニア400人以上の）グリーの場合は、オンプレミスでも十分なソーシャル機能のメリットが得られると判断し、GitHub Enterpriseを導入したが、組織の規模やコストとの兼ね合い、そしてソーシャル機能とセキュリティのどちらを重視すべきかなどを十分検討したうえで、自社にとって最適な環境を選択することが重要だ」
セッションの最後には質疑応答を実施。時間いっぱいまで来場者からの熱心な質問が続き、あらためてソーシャルコーディングに対する関心の高さがうかがえた。
グリー株式会社
