ソースコード管理の進化：Excel管理からGitHubまで、エンジニアの戦いを振り返る！

プロローグ

先日、弊社のとある案件内での会話です。

• 熟練エンジニア（以降「熟練」と表記）：GitHubのプルリクが来てたからコードレビューしておいたよ。

• 若手エンジニア（以降「若手」と表記）：ありがとうございます。助かります。

• 熟練：他の人のコードにも指摘した内容がキミのコードにもあったので指摘しておいた。他の人のプルリクは見ていないの？

• 若手：いや、他の人のプルリクは見てないですね。。 必要ですかね・・？

• 熟練：必要だよ。昔はそういうのやりたくてもできなかったんだから！

• 若手：（はじまった、熟練さんの昔語り・・。長いんだよなぁ。。）なるほど！そうなんですね。他の人のコード読んで勉強します！

はじめに

皆さん、こんにちは。エンジニア歴約20年目の立脇です。今日は、エンジニアにとって切っても切り離せない「ソースコード管理」の歴史について、ちょっとだけ書いてみようと思います。

プロローグにあるような熟練エンジニアと若手エンジニアのやり取りは、皆さんのプロジェクトでも発生しているのではないでしょうか。

それこそ昔は、

• ローカルでプログラミング後、ファイルサーバーにソースコードをコピー。（「切り取り→貼り付け」は禁止。もし、コピー中に失敗したら、この世からソースコードが消えてしまう可能性があるから。（私はこれをやらかしました・・。）
• ソースコード管理台帳なるExcelに変更日と変更内容を記載。（このソースコード管理台帳Excelが今みたいな共同編集なんてできないので、誰かが記載していたら待たないといけなかった。）

という感じで管理していました。懐かしいなぁ…（遠い目）。当時は、チームメンバー複数人が同じファイルを編集し、後から「あれ、私の変更上書きされてる・・。誰だ！」ってなることもしばしば発生していました。

当時の悲劇をまとめてみました。

バージョン管理システム革命（笑）

「あー、もう！バージョン管理がめんどくさい！」「マージしかしてない！開発者にソースコードを書かせてくれ！」

・・・。そう何度も夜中に叫んだことがあります。

そして、ついに革命が起こりました！それが、バージョン管理システムの導入です。これは私にとっても、世のエンジニアにとってのかなりの衝撃だったんではないでしょうか。

バージョン管理システムと一言でいっても、歴史があります。バージョン管理システムそのものの歴史は調べてもらったらわかるので、以下に私が経験してきた歴史を図示してみました。（なかなかチームに導入が進まなかったです・・。スッと導入されているチームの方々がうらやましかったです。（泣））

1. CVS：バージョン管理の夜明け

最初に現れたのが、CVS（Concurrent Versions System） です。ファイルの変更履歴を記録してくれるので、誰がいつどんな変更を加えたのかが一目瞭然！Excelで管理していた頃と比べれば、格段に効率がアップしました。

「使い方がわからんよ」という当時の熟練エンジニアの人達に、当時は若手だった自分が使い方をレクチャーしたところ「こりゃすげえわ」と感動いただいたことを今でも鮮明に覚えています。

しかし、CVSには課題も。

• 集中管理型： 中央サーバーにソースコードが集まるので、サーバーがダウンすると全員がお手上げ状態に。夜中にサーバーが落ちて、メンバーの気持ちも落ちるという事件が多発しました。
• ブランチ機能が貧弱： 新機能開発やバグ修正を同時に進めるのが難しく、開発が停滞してしまうことも。

それでも、CVSは当時のエンジニアたちにとって、まさに救世主のような存在でした。

2. SVN：CVSの進化形！

CVSの後継として登場したのが、SVN（Subversion） です。CVSの課題を克服し、より使いやすく進化したバージョン管理システムです。CVSに慣れていたエンジニアにとってとっつきやすくスムーズに移行できた記憶があります。

• 集中管理型： CVSと同じく、中央サーバーにソースコードが集まります。サーバー設置環境が良くなったこともあり、いきなりサーバーが落ちることは少なくなりましたがそれでも落ちることはありました。
• ブランチ機能が強化： CVSよりもブランチ機能が充実し、複数人で同時に開発を進めることが容易になりました。

SVNは、現在でも多くの企業で採用されている定番のバージョン管理システムです。バイナリの差分管理ができるのも特徴的だと思います。

3. Git：分散型の革命児！

そして、ついに現れたのが、エンジニア界の革命児Gitです。

Gitは、分散型バージョン管理システムと呼ばれる新しいタイプのシステムです。CVS、SVNに慣れていたエンジニアだった私は最初は「？？？」でした。

• 分散型： 各開発者のマシンにソースコードの完全なコピーが保存されるため、中央サーバーに依存せず、オフラインでも作業できます。
• 強力なブランチ機能： 複雑なブランチ操作も可能で、開発の柔軟性が大幅に向上しました。
• 高速な処理： ローカルで操作するため、サーバーとのやり取りが少なく、高速な処理が可能です。

Gitの私の理解は「これまでのバージョン管理界隈で出たウラミツラミの解決をすべて実装したもの」です。

Gitはその柔軟性と高速性から、多くのエンジニアに愛され、現在では事実上の標準となっています。

4. GitHub：Gitのホームグラウンド！

Gitの登場によって、ソースコード管理は大きく進化しました。そして、Gitをさらに便利にするサービスとして登場したのが、GitHubです。（ここではGitLabも同義として考えます。）

GitHubは、Gitリポジトリをホスティングするサービスです。最近ではさらに機能が充実し、SNSといっても過言ではない、もはやコミュニティ化していると思います。

• Gitリポジトリの共有： プログラムのソースコードを公開したり、共同開発したりできます。
• チーム開発の効率化： チームメンバーとのコミュニケーションツールとしても活用できます。
• オープンソースコミュニティ： 世界中の開発者と交流し、コードを共有できます。

GitHubは、エンジニアにとってもはや欠かせない存在となっています。大規模なシステム開発や継続的なプロダクト開発において、GitHub無しでの進行は不可能といっても過言ではないかも知れません。

まとめ：エンジニアは情報のアンテナを張るのが大事！

ソースコード管理は、エンジニアにとって永遠のテーマです。Excel管理からCVS、SVN、Git、GitHubと、時代とともに進化し続けてきました。これからも、より便利で効率的なソースコード管理システムが登場するでしょう。

そのメリットを最大限享受できるようになるためにも、常に情報のアンテナを張っておき、最新の技術動向を押さえるようにしたいですね！

なお、私はCVSを見つけた当時（確か今は休刊してしまった「WEB+DB PRESS」の記事だったと思います）の興奮は今でも忘れもしません。皆さんも是非同じような興奮を体験してください！

エピローグ

「ソースコード管理、もうExcelに戻りたくないなぁ…。」

これは、私の本心から来るものです。あんなに生産性の悪い時代を経験したからこそ現代の効率の良さに感激できるのだと思います。

ある程度成熟した時代から入ってきた今の若い人達からすると「なんでこんな面倒くさいソースコード管理をしないといけないのか」「もっとサッとできないのか」と思うこともあるでしょう。でもこれは歴史の積み重ねで今の仕組みになっているんです。日本史・世界史を学んで悪い歴史を繰り返さないようにしよう、と思うことと同様、何事にも歴史があるのです。

ITなんてたかだか数十年の歴史です。若い人達は、その歴史を知ることが大事です。熟練エンジニアの人達に歴史を語らせてください。きっとみなさん、遠い目をして「あの頃には戻りたくないなぁ・・」といって教えてくれながら、表情は「あの頃は良かった・・」ってなってると思いますよ（笑）

（裏腹なんです（笑））