クロスプラットフォーム開発で苦労し、GitHub Enterpriseを導入
オープンソースコミュニティでソースを共有し、共同開発で効率化が進んだのはGitHubの貢献が大きい。今ではすっかり定着した「プルリク（Pull Request）」（コードレビューを要請すること）の文化は、GitHubで育まれたものだ。新しいソースコードを書いたら「プルリク」し、他の誰かがレビューし、コードをマージする。こうしたソースコードを共同で改良する仕組みは、開発作業効率だけではなくソースコードの質を高めることにも寄与している。
GitHubの良さは理解されつつも、これまで多くの企業ではためらいがあった。知的財産保護の観点から「ソースコードをクラウドに置くわけにはいかない」からだ。しかしこの懸念は企業内だけで使えるGitHub Enterprise（いわばオンプレミス版のGitHub）で、払拭できつつある。近年、企業で急速にGitHub Enterpriseの導入が進んでいる。
富士フイルムソフトウエアも、GitHub Enterpriseを導入してコードレビュー文化を実体験した企業の1つ。同社は写真プリントに関連したソフトウェア開発などを行っている。代表的なものが写真店や家電量販店に設置されている店頭受付端末のソフトウェアだ。同じ機能を提供するスマートフォン向けアプリも開発している。
プリント受付は店頭だとパソコン、アプリだとスマートフォンを使う。同じ機能を提供するとなると、ソフトウェアを搭載する端末の違いだけではなく、開発環境の違いも乗り越えなくてはならない。富士フイルムソフトウエアでは極力部品を共通化し、並行して開発することにした。
とはいえ、クロスプラットフォーム開発におけるソースコードのマージ作業で生じるコストは想像を超えていた。同社の大島一輝氏は「異なるプラットフォーム間の進捗が見えづらくなり、開発効率の低下につながりました」と話す。当時の開発現場では、ソースコードの本流を示すはずの「trunk」ディレクトリが同時多発的に増えていた。「trunk2」や「trunk3」など、もうどれが本当の本流だか分からなくなりそうで「このままでは進めない！」と現場は危機感を強めた。そこで大島氏らが立ち上がった。
「並行開発の末に悪魔合体を繰り返したソースコードに秩序を取り戻すため、大規模リファクタリングを敢行しました。同時に開発環境もリファクタリングできるチャンスであり、現場からはGitHubを導入したいという声がありました」（大島氏）。
大島氏が言うように、開発現場がGitHubを待望していた。開発者らはGitHubの導入によって、マージコストの低下だけではなく、コードレビュー文化の繁栄やCIツールとの連携にも期待を寄せた。率直に言うと「なにより、GitHub、面白そうじゃん？」とノリノリだった。
GitHubを開発現場に導入するにはいくつかの壁があった。「GitHub.com」では不可だったという。まず、開発中のソースコードをインターネットに置くのは社内ルール的にNG。またサイトメンテナンスの影響を受けてしまうことが考えられ、開発が中断してしまいかねない。また無料版だと足りない機能もあった。
しかし「GitHub Enterprise」ならセキュリティの懸念が払拭できて、サポートが充実していることも安心感につながった。GitHub Enterpriseは社内環境で運用するため、ソースコードを保護できて、メンテナンスは自社でコントロールできる。運用については「サポートツールが充実しており、運用の負担はそこまで高くありません。マクニカさんのサポートのおかげです」と大島氏は言う。
トレーニングも必要になる。同社では大島氏が「GitHubおじさん」となり、布教とサポートに努めたという。未経験のメンバーにはトレーニングを実施し、基本的な使い方や運用をまとめたドキュメントも整備した。大島氏は初心者には「GitHubはシステムエンジニアにとってのSNSなんだよ」と説明したという。
「慣れてもらうのが一番」ということで、テキストファイルだけの練習用リポジトリを作った。修正したらプルリク、コードレビュー、修正、マージといった、一通りの開発フローを体験してもらうことで使い方を覚えてもらった。
