クロスプラットフォーム開発で苦労し、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なんだよ」と説明したという。
「慣れてもらうのが一番」ということで、テキストファイルだけの練習用リポジトリを作った。修正したらプルリク、コードレビュー、修正、マージといった、一通りの開発フローを体験してもらうことで使い方を覚えてもらった。
開発現場の雰囲気が向上し、コードの質も向上、ストレスも軽減
GitHub Enterpriseを導入すると、開発現場にさまざまな変化が生まれた。かつてのコードレビューは対面が基本で、開発者がどこを修正したのかを説明する必要があった。WinMergeなどのツールを使いつつも、それなりの手間が生じており、また議事録をExcelに記録する必要があった。
GitHub Enterprise導入後はレビューを対面でする必要がなくなり、レビュアーはブラウザ上で自分のスケジュールに合わせてレビューできるようになった。開発者はプルリクを送信した後は次の開発に作業を移ることができる。時間を効率的に使えるようになった。
修正履歴の議事録については少し工夫した。プルリクを見れば修正履歴は分かるものの、社内要件に合わせる必要があった。同社では品質の可視化のため、コードを修正する時には「致命欠陥」、「重欠陥」、「軽欠陥」などカテゴリを追記する必要があった。そこで必要な機能をいくつか自作して追加した。レビューで定型文を追加することや、GitHub APIからデータを集計するなどだ。
導入前にカオスと化していたソースコードのマージは、GitHubだけではなく各種ツールとの連携も加わり格段に効率化した。今ではプロジェクト管理の「Redmine」、チャットツール「Mattermost」、継続的インテグレーションツール「Jenkins」などを活用しているという。同社ではモダンな開発環境へと徐々に移行しており、大島氏は「デプロイ自動化が次の課題です」と話す。
たまにプルリクが埋もれてしまいレビューされないことがあったが、クローズしていないプルリクを抽出するツールを自作することで問題は解決した。これは開発現場の若手が自発的に機能開発したそうだ。
開発現場の風土も変わったという。先述したように、以前のコードレビューでは対面で議事録を出すなど当事者にはストレスがかかっていた。しかしブラウザ上で静的解析や自動テストなどのツールを活用することにより、「効率化と精神的安定を手に入れました」と大島氏は笑顔で話す。レビューアーと開発者は対立する関係ではなくなり、「解決しなくてはならない課題をチーム全員で共有する」と意識が変わっていった。
それだけではない。良いコードを称賛する文化も芽生えた。GitHubではSNSのように手軽に「いいね」ができて、称賛や激励を示すことができる。サンプルコードを提示し、アドバイスをすることも気軽にできるようになり、開発現場の雰囲気が良くなった。大島氏は「良い雰囲気は良いコードを生みます」と話す。
自動テストや静的解析のチェック機構により、小規模な改善もやりやすくなった。あるとき、チームで「早朝プチリファクタリングマラソン」を実施してみたという。これは毎朝15分だけ、小規模（50ステップ以内）の改修を行うというもの。その日のうちにプルリクし、レビュアーはその日のうちにレビューするというルールにした。少しだけでも改修を進め、ためないことを重視した。
すると、これまで後回しとなっていた細かな修正が次々となされ、内部品質が日ごとに高まっていった。GitHub Enterprise導入後は市場からのソフトウェアに対する問い合わせが半減、不具合密度は1/5に激減したという。
大島氏は「GitHub Enterpriseは使えることがメリットではなく、もはや、使えないことがデメリットになるのだと実感しています。これからも私たちはGitHubを愛しながら開発していきます」と熱く語った。
なお富士フイルムソフトウエアのGitHub Enterprise導入をサポートしたのはマクニカネットワークス。同社 AI＆ソフトウェアビジネス部 第2課 課長の根本竜也氏も登壇し、サポート体制の詳細を紹介した。
マクニカネットワークスは、GitHub EnterpriseだけではなくCircleCIの国内一次代理店で、モダンな開発ツールに詳しく、日本語のテクニカルサポートも行っている。GitHub社のビジョンでもある「他ツールとの連携」をソリューションとしてクライアントに提供する。
「GitHubは周辺ツールとのインテグレーションがやりやすい。CI/CDツールやチケット管理の機能など、すべてをGitHubだけでまかなおうとはせず、GitHub社のビジョンとしても『いかに周辺のイケてるツールと連携しやすくしていくか』を掲げています」（根本氏）
マクニカネットワークスは、開発元で新機能の発表やバグ情報などが発表されたら、いち早く日本語で顧客に案内するなど、技術情報提供の役割も担う。定期的に「GitHub Enterpriseまるわかりセミナー」を実施しており、直近では9月6日に東京で「モダンな開発環境を実現する GitHub EnterpriseとCircleCIまるわかりセミナー」開催する。
「GitHub Enterpriseでどんな効果があるかもう少し詳しく知りたい方は、デモなども交えた本セミナーにぜひご参加いただければと思います」
根本氏はこう話し、セッションを締めくくった。
お問い合わせ
マクニカネットワークス株式会社
富士フイルムソフトウエア株式会社
