今回のゲストは、分散バージョン管理システムGitのメンテナで『入門Git』（注1）の著者、濱野純さんです。Linuxカーネルの開発者、Linus Torvaldsさんから引き継いでGitのメンテナになった経緯から、対談スタートです。
（撮影：武田康宏）
Gitに関わった経緯
弾：Gitに関わったきっかけは？
濱：2005年の4月にLinuxカーネルのバージョン管理システムとして使われていたBitKeeperが使えなくなる[2]からということで、Linus君がいろいろありものを探したんだけど、使えるものがなくて、誰かがいいのを作ってくれるまでのつなぎというつもりで、とりあえず自分でもコードを書いた、というアナウンスをしました。それをカーネルメーリングリスト（ML）で見ていたんですが、たまたまボクの本業がプロジェクトとプロジェクトの合間だったんです。なんかおもしろそうなこと始まってるじゃん、ということで、彼が書いたコードをダウンロードしてみたら、1,244行しかなくて。
弾：全部Cですか？
濱：そうですね。そのくらいだったら、2時間で読めるでしょ。隅から隅まで読んでみると、すごくきれいに書けてるので感心して。ボクは基本的にカーネルの開発者でもなんでもなくて、カーネルMLもちょっと眺めてただけっていう感じでした。でも、何十万行もあるカーネルのソースに関わるのはたいへんかもしれないけど、1,200行くらいから始まるこのプロジェクトなら今から入ってもおもしろいことができるかな、っていうのがGitに関わった動機の1つ。当時、1週間くらいの間にいろんなことが起こったんですけど、Linuxのカーネル開発者はLinusがわけのわからないものを使うと言ってるから、俺たちも使わせられるんだろう、あんまりひどいものを使わせられたんじゃかなわないって言うんで、力を貸して良くしようとしていました。それで自分も、全体のプロジェクトの流れを俯瞰（ふかん） して、本当に必要なものは何かと考えてみると、とりあえずコミットはできるようになって、前の版からの差分も見られるようになった。でも、マージがなかったんです。Linus君がもともとマージはこんな形でやりたいというアウトラインを何回かポストしていたんですが。
弾：Linusが一番文句付けてたところですよね、既存のバージョン管理システムで。
濱：彼はCとシェルでしか書かないものですから、このマージのロジックくらいになるとさすがにかなり複雑だからスクリプト言語かなんかで誰かさらっと書いてくれたほうがいいんだけどな、みたいなことを、何回もMLに投げてたんです。でも誰も食いつかなかったんですよ。それで1週間くらい、ずーっとMLを見て勉強して、Linus君がやろうとしているマージのアルゴリズムをちょっとPerlで書いてみたっていうのを投稿した。それがボクの一番初めのある程度の規模のコントリビューションです。けど、そのときに丁寧にテストケースを、こういうときにはこうって場合分けのテーブルを30個くらい書いたんですけど、それから6時間くらいして、Linus君が自分のツリーにコミットしたマージのやり方は全然違うものだったんですよ。もっとすごい別のやり方考えたから、これで行くよって。見ると確かにコロンブスの卵で、ボクは今までMLでこんな形でやるよってLinus君が説明していたのに従って、丁寧にコードを書いたわけだけど、確かにそれを全部捨ててしまうくらいすっきりした、おもしろいやり方だったんです。誰かやってくれないかって言うからやってあげたのにってカチンときそうなものなんだけど（笑）、そのときに全然そうではなかったのは、もちろんボクが聖人君子だからじゃなくて、それだけすごいものがあったんです。
コロンブスの卵
弾：どうコロンブスの卵だったんですか？
濱：ボクはBitKeeper使ったことないんですけど、BitKeeperのやり方は基本的にワークツリーに自分のファイルがあるとすると、その中ではマージしないそうなんです。テンポラリディレクトリみたいなものを作って、そこにマージした結果を開いて、コンフリクトがあるものはそっちで解消して、その結果をコミットしたものが自分が普段使っているワークツリーに開かれて、それでマージ完了になる。そういう形だったらしくて、もともとそれを踏襲したような形にするつもりだったらしいんだけど、結局そうしても最後にマージコンフリクトを解消した結果を、実際にコミットしてしまう前に、一度テストしたいよね。そうするとワークツリーの中で直接、テンポラリディレクトリを使わずにマージできたほうがいいよね、っていうことになって…。Gitでコミットする前に、次のコミットに入れるファイルの内容を登録しておくインデックスがあるんですけど、そのインデックスは当初、1対1だったのをやめにして、ステージという概念を導入すると言い出したんです。どういうことかというと、もともと3ウェイマージをするものだから、最初のバージョンから私はこんな変更をしました。あなたはこんな変更をしました。という差分を持ってきてマージする。じゃあ、この3つをステージ1、2、3っていうふうにインデックスに登録して、それでマージすればいいじゃん、とLinus君がいきなり言いだしたんです。確かにそうするといろいろおもしろいことができる。一番単純な例としては、私もあなたも何もしなかった場合。そしたら結果はもとのまま。それから私は何かしたけど、あなたは何もしなかった場合。そしたら私の結果をとればいいし、その反対も同様です。で、1つおもしろいと思ったのが、実は私もあなたも同じことをしたっていうケースなんです。
濱野純 氏
弾：結構あります（笑）。
濱：使ってみると実は確かにそうなんだけど、特にLinuxカーネルのプロジェクトは、MLベースでしょ。だから同じパッチを見て、これはうちのサブシステムもフィックスだからって拾った、だけど、実は別の人も拾ってたとかいうことがある。そういう場合分けというのはインデックスの中で全部できてしまうので、効率もいいし、非常に見通しがいい。
Linusのマネージャとしての資質
濱：それと彼は、よくメンテナの仕事の半分はNoって言うことだっていう言い方をするんですけど、人のパッチを捨てるっていうときにも、パッチというか、この変更はペケなんだけど、でもそれはお前がペケなんじゃないよって、すごく人を大事にした捨て方をするんですよね。それがすごいなと思って。ボクのときも、コードは捨てるけど、君のテストケースはそのまま使えるはずだから、こういう形でマージを作ってみたんだけど、やってみてって言われて。
弾：それ、いいなあ。
濱：人がしたことを無駄にしてないんだよというのを相手に知らしめると、コントリビュータのモチベーションを下げないで済むんですよね。新しいマージのやり方っていう発想もすごかったんだけど、コミュニティマネージャとして、人を使うマネージャとしての資質もすごい人だなと。それではまっちゃいましたね（笑）。
GitHub
弾：GitHub[3]ってありますよね。あれはGitと組織的なつながりはあるんですか？Gitコミュニティがエンドース（支持、承認）してやってるのではなくて、Git好きの人がやってる？
濱：あれはちょっと複雑な立場なんです。もともとGitHubを始めた人たちは、Gitコミュニティの人が知らなかったような人たち。あの人たちって基本的にRubyの人ですよね。RubyコミュニティでGitを使っていたのはRailsがGitを採用したとかの流れがあったんだろうけども、GitHubは最初、あれだけ流行る前にインビテーションベースでテスト運用をしていたらしいんですが、そのときにもGitコミュニティの主要メンバーに誰にもインビテーションが来なかった。ボクはあんまり気にしないんだけど、中にはそれでコマーシャルベースにのせてなんかやってるっていうのでカチンときた人もいたみたいで、結構長いことあんまり仲良くなかったんです。
弾：そうだったんだ、GitとGitHub（笑）。あんまり相手のことを見てなくて。
濱：見ないで走ってたというところがあって、たとえばもともとのGitとGitHubが動かしているGitデーモンとではちょっとバージョンが違うのかな。手を入れてなんかやってるとか。あまり隠れたところで非公式なものを作られると困るから。
弾：それは大いに困りますね。
濱：で、去年、第1回のGit togetherっていうイベントがありまして、Googleが場所を提供してくれて、3日くらいやったんですけど、そのときGitHubの人たちもGitコミュニティの主要メンバーということでやってきて、これからどんなふうにしていこうかねって話をしたりして、今はそんなに悪い感じではなくなってます。実際、GitHubのヘルプコンテンツとかって結構いいでしょ。そうやって、ドキュメンテーションとかユーザサポートとか、自分たちの得意分野でやってくれる人たちがいるんだったらいいことじゃない。
弾：何の過去もない人たちがいきなりGitHubから始められるわけですよね。確かにあれは世界が変わると思いますよ。最初から世界に向けてソースコードを単に公開するんではなくて…。
濱：みんなでなんかやっている、マージし合っているという、あの構造はすごくいいですね。
弾：僕もあれがなければGit何それ？ のままずーっときてたと思います。
濱：あれは非常に斬新だった。細かいところで注文はつけたい部分はあるけれど、GitHubがGitの普及に果たした功績ってすごく大きかったですね。
弾：あれを見てやっと、なんでLinusが今までのバージョン管理システムにケチを付けているのかも実感できた。マージできねえじゃんと。結局、Linuxカーネルほどばかでかいプロジェクトだと確かに、どっちのコードを入れてどっちを捨てるというのも大問題になるけど、普通は入れるか入れないかですし、メンテナは各プロジェクトで1人で済んでいて、1人では間に合わなくなったらプロジェクトをサブプロジェクトに分割してっていうやり方を今までしてきて、それでほとんどのものは間に合ってきたじゃないですか。確かにありがたみがわかりませんよね。GitHubだと使っている人たちが、こりゃあちょっとマージしないとやばいよなというのは嫌でもわかるようになりますよね。あれはすばらしいですよ。
優れたエンジニアの資質
弾：「優れたエンジニア」とはどんな人だと思いますか？
濱：Gitのメンテナを引き継ぐときにLinus君に、スターエンジニアには3つの資質があるって言われたんです。一番重要なのは、何か1つのことをずっと続けていけること。そういう意味ではアルファギークではいけないわけ。尖鋭（せんえい）的で、新しいものにすぐ飛びつく、までは構わないけど、すぐ飽きちゃダメ。ちなみにボクは尖鋭的でも新しもの好きでも飽きっぽくもないので、およそアルファギークではありません。
弾：なるほど。すぐ飽きちゃダメ。続ける力。
濱：2つめは審美眼というのかな。センスがいい、いいテイストを持っているっていう言い方をLinus君はするんだけど、これは確かにそう思うんですよね。センスがいいっていうのはどういうことかっていうと、何か1つ問題があったときに、実際に全部解いてみなくてもだいたいこういう方向に行ったら最終的にうまい解決に導けそうだなっていうのを最初になんとなく見て感じ取れる能力。3つめはコミュニケーション能力。それも、ただ自分がこうしますということを言うためにコミュニケーションするんじゃなくて、その1つ先の、私はこういう目標にたどりつきたい、この目標がいいことだと思うでしょ？ って聞いてる人を納得させることができて、それに至る道筋として私は今はこれをやるんだよっていうのを説明できる。自分の目標を明確に相手に伝えられる人。それはすごく重要だと思います。Gitのプロジェクトを見ていても、すごく良くできる子が7、8人はいるんだけど、その中で3つともそろっている人っていうのはすごく少ない。
弾：僕も審美眼に対してはLinusに言いたいこといっぱいある（笑）。ただ、Linusにこう言ったらこう言い返すだろうっていうのもわかるので。でもその3つのうち、2つでもあれば本当に食いっぱぐれないような気がしますよね。1つでもあれば仕事は成り立ちますし、2つあればでかい顔ができますよね。
濱：そうかもしれませんね。彼はそういう順番で言ったんだけど、今までGitのコミュニティを見ていて、3つのうち1つしかない人でもコミュニケーション能力を磨いたら、きっと自分のしたいことができるようになるだろうなと思いますね。コミュニケーション能力は、自分ができなくてもこれが目標って言えばオープンソースの世界ではほかの人が手伝ってくれますから。目標を明確に示すことができたら自分がやらなくてもいいわけ。
弾：僕はオープンソースという言葉がないころから、オープンソース的というと誤解されちゃうかな、要はフリーソフトウェアの世界にいたんですけど、コミュニケーション能力という点では、ベースラインがものすごい上がっていますね。たとえば10年前と今と比べると、今の若い人たちのコミュニケーション能力ってすごいですよ、ライトニングトークってあるじゃないですか、5分でプレゼンするっていう。昔だったら30分くらいかけてだらだら話してたことがちゃんと5分に収まるというのを彼らは証明しちゃいましたからね。実際にコミュニケートする場も、昔はオープンにする前にワーキングプロダクトを持ってきて、これでどうよだったんだけど、今は逆に実装がなくても、こんなふうがいい、あんなふうがいいってやっていけるようになったじゃないですか。ツールが良くなったっていうのはすごい大きなことだと思うんですよね。ネットが速くなった、ネットで動くプラットフォームも良くなったっていうのはすごい大きなことだと思うんです。「近ごろの若いものは」、っていうセリフがあるじゃないですか。僕は「すごい」、なんですよ。むしろ連中についていける俺のほうを褒めてあげたいみたいな感じがしますもんね（笑）。今は半年そのプロジェクト見てないとついていけないってなっちゃうもん。Gitが難しいと思うのも、僕が老化したせいなのかもしれないって（笑）。
40代以降のエンジニアに伝えたいこと
弾：40代以降のエンジニアに伝えたいことはありますか？40代のエンジニアが、そろそろ若人たちについて行くのがたいへんだなと思ったときにどう振る舞うか。20代の若いころはコード書いてりゃいいじゃんみたいなところがありますが。
濱：どんなふうに若い人のお手本になれるかってのを考え出すと、かなりたいへんだと思いますよ。
弾：とりあえず1つだけ、これは答えでいいんじゃないかなって思うのは、自らが楽しく仕事をしていることだと思います。苦虫を噛み潰したような顔だったらそんなのうまくいくわけないじゃんって。苦労話もおもしろいものはおもしろいんだけど、自分や自分の先輩がすごかったという証拠にしてほしくないんですよね。なんだ、しょぼい道具しかなかったじゃん、あんたらって言い切っていいと思うんです。そういう中にあって、実はGitのメンテナというのは…。あ、そうだおいくつなんですか？
濱：内緒です（笑）。
弾：少なくとも20代、30代ではないですよね。なかなかいけてるなって思いますよ。バージョン管理システムの中ではGitは一番若くて、メインのシステムになってるわけじゃないですか。
濱：そうですね。
弾：若いプロダクトを若い人がやっているとは限らないというのがすごくよいことだと思います。
