試したいから、作る。ghq、goreの作者motemenの開発は「自分本位」で駆動する

大坪弘尚さん：2006年、アルバイトとして株式会社はてなに入社。はてなブログ、Mackerelなど同社の手がけるさまざまサービスにアプリケーションエンジニアとして関わる。2012年からはチーフエンジニアとしてエンジニアの採用、後進の育成なども担当。2016年より同社CTOに就任。

──まずは大坪さんのエンジニアとしてのキャリアを聞いてもよろしいでしょうか？

大坪　元々、プログラミングは小さい頃からしていたんですけど、大学に入った2004年くらいから本格的にプログラミングをやるようになりました。もっとも、最初はJavaScript で画面を操作して遊んでいるだけという感じでしたが。

それから、はてなの社員の人と出会ってアルバイトとして参加しました。はてなはPerlの会社なのでPerlでWebサービスを作り始めて、そのまま新卒で入社したんです。

Mackerel（マカレル）はWeb上でサーバ監視ができるSaaS型のサービス。はてなの注力サービスの一つ。

──はてなではどんな仕事をしてきたのですか？

大坪　周りから「ものを作るのが早い」と評価してもらって重宝された部分があって、『うごメモはてな（2013年サービス終了）』や『はてなブログ』、『Mackerel』などいろいろなチームで仕事をしましたね。

Mackerelではサービスディレクターをやらせてもらって、途中からチーフエンジニアという役職にもなり、組織を見る立場に変わっていきました。そのままサービスを作り続けてきたら、いつのまにか CTOになっていたという感じです。

──「作るのが早い」という評価の通り、ghqやgoreなどさまざまなツールをコンスタントに開発されていますが、開発の元にある発想はどこから来るのでしょか？

大坪　特別意識してることはないんですけど、「何か作りたいなー」っていうことを常に考えています。だから 不便を見つけたときは何かを作るチャンスなのかなと思っています。

「こういうものがあったらいいな」っていうニーズが仕事してるといっぱい出てくるし、ニーズに対する回答となる新しいものを作る、というタイミングは新しい技術をインプットするチャンスでもあります。「この問題にはこの新技術が使えるんじゃないか？」とか、課題が見えたときに「この技術をこう活用すれば解決ができるんじゃないか？」というイメージが湧いてくるんです。

逆に、新しい技術を知るとそれを使って何かを作りたいという欲求も生まれます。こうした二つの想いが開発を駆動しているイメージです。

──ghqというツールをなぜ作ろうと思ったのでしょうか？

大坪　OSSのライブラリで気になるものがあったらソースコードを読みたくなりますよね。でも、GitHubの情報をブラウザで読むのは効率が悪いので、手元にクローンするはずです。そのとき、従来は一時的なディレクトリにgit cloneしてたんですけど、もう一度同じソースコードを見ようとしたときに、どこのディレクトリにクローンしたのか分からなくなることが多かったんです。それらを統一するやり方が欲しかったのでghqを作ったんです。

こんな風に、基本的に僕のツールは自分で使うために作ったものを公開している感じなので、あんまり人に使ってもらおうとは考えていません。ただ「良いものができたよ」って周りに自慢したいから公開しているだけかもしれません（笑）。

gheとgoreはどんなツールか

ghqは、GitHubなどにあるソースをローカルにクローンする際に、ディレクトリを指定してリポジトリを管理しやすくなるツール。大坪さんのブログ『詩と創作・思索のひろば』の記事を参照。

ghq: リモートリポジトリのローカルクローンをシンプルに管理する - 詩と創作・思索のひろば

goreは、Go言語で対話的にコードを実行できるREPL環境を実現できるツール。スター数が2000を超え、Go言語の使用者にとって定番となっている。goreのリポジトリにある次の画像が参考になる。

──ghqを作る際に何か参考にしたOSSなどはあるのでしょうか？

大坪　cpanminusというツールに--look というオプションがあって、ダウンロードしたパッケージを展開してインストールする前のディレクトリに cdして移動する挙動があります。それを単純に真似してghq lookコマンドは作りました。

あとはやっぱりGoで書くのでGoのソースコードは読みましたね。go getコマンドのソースコードを読んだときにGit以外のバージョン管理ツールにも対応していて、それを真似しようと考えたんです。Mercurialは僕は全然使わないんですけど、機能としては面白いと思って作りましたね。

──ご自身のブログで「zshからGoに書き換えた」と書いてありましたが、なぜGoを選んだのでしょうか？

大坪　zshだと簡単にcdコマンドが使えるというのがメリットで、最初はzshで書いていたと記憶しています。けれどマシンを変えた際にインストールしていない状態になってしまったんです。改めてインストールするより、Goを試すネタが欲しかったので、Goで書き直してみたわけです。go getで簡単に配布できるし、言語としてシンプルな書き方ができるのがすごく良い。

もうひとつ、誰でも使えるようなツールにしたかった、といのが大きいです。ですから、配布のしやすさはすごく大事だと考えたんです。

昔、htmlcatという標準入力の内容をブラウザ表示させるプログラムをPerlで作ったんですけど、その後、Rubyで作られた似たような機能を持つwebtailというものが公開されて、そっちの方が有名になってしまった（笑）。

一枚スクリプトになっていないPerlのプログラムをインストールするより、RubyGemから一発でインストールできるプログラムの方が、一般的には使いやすいわけです。こうした経験があったから、「使われやすい形で配布しないとダメなんだ」というのは感じました。

htmlcatとは上の画像のようなログをブラウザで表示できるようにするツール。画像出典：大坪さんの旧ブログ

ただ、他の人が似たようなコンセプトでツールを作るのはすごく面白い。他の人が書いたソースを見ると、「こうすると便利なんだ」とか「こういうところがこの人は気になってるところなんだ」と気付けるので。

──zshからgoに書き換えたのは『OSSとしてソースを人に見せるため』という観点もあるのでしょうか？

大坪　人に見せることを第一に書いたことはありませんね。今のghqもいわゆる「オレオレコード」が結構ありますしね（笑）。自分のツールを作るときは新しく覚えた書き方を使っていくということを意識していて、人に見せることを第一に意識していたら何も完成しないと思うんです。

ただ、もちろん他の人でも「最低限使えるようにする」という考えは大事です。作った人の環境でしか使えないっていうのはもちろんダメで、README をちゃんと書く、といった求められる基本的な要素は充実させるよう心がけています。

──では、goreもghqと同じようにまずは「自分用のツール」として作ったのでしょうか？

大坪　goreはそもそもGoでのREPL環境がなかったので、あったら便利だなと思って作りました。すぐに別のツールが出てきて代替されるだろうなと思っていたのですが、意外と長生きしてますね（笑）。

goreもghqにも共通していえますが、「自分がそのツールのユーザーになりたい」と思えるものを作ってるのかなと思います。

──スター数が2000を超えているツールはなかなかないですよね。

大坪　今そんないっています？ 2000超えているのか。すごいですね（笑）。

コツは「小さく作る」、そして「イチから作り直す」こと

──そういったツールを早く作るためのコツやモチベーションの保ち方などあるのでしょうか？

大坪　低レベルな答えで申し訳ないですけど、作って「もうできたの？ 早いね！」と周りに言ってもらえるのは大きいですね（笑）。

ただ、それだけじゃなく早く作ることには意味があると思います。作ってまず形にすると、そこからアイデアが膨らんだり、さらに新しい機能を作ろうという、きっかけになることが多いんです。まず形にしたからこそ、次に進めるわけです。

──「まずは小さく作る」というのが大切なんですね。

大坪　そうですね、僕の中では大切なことかもしれません。例えば、最近社内向けのツールを作って社内で使ってもらっていたんですけど、機能を詰め込みすぎて「motemenさんに聞かないとどういう動作かわからない」とブラックボックス化してしまったことがありました。それで機能をかなり削ぎ落として、すごく小さくしたものを第2弾として公開したんです。

──そうやって、一度作ったツールをまた作り直すことはよくあることなのでしょうか？

大坪　けっこうあります。1回作ってみてイメージと違う場合もあるので、同じものを3回作ってみる場合もあります。何回も作ることによって、ブラッシュアップするサイクルを回していくという感じです。基本的にまずは「捨て」のつもりで作っているので、いわばプロトタイピングをやっているようなイメージですね。

「なんとなくこうなったらいいんじゃない？」っていうモヤっとしたものを、まずは形にしてみる。すると、そこから何かが見えてくることもあるので。

OSSを作って分かった、他者の感覚

──ghqの反響の大きさは予想していましたか？

大坪　ghqがzshで書かれていたときよりは便利だしこれはいいだろうと思ったんですけど「pecoというツールと組み合わせたら便利」っていうのをあんちぽさん（@kentaro）に記事にしてもらって、そこから火が着いた印象があります。言ってみれば、pecoの人気に便乗させてもらったという感じです（笑）。

現在、GMOペパボ株式会社の取締役CTOである「あんちぽくん」こと栗林健太郎さんのブログにて紹介された。

──反響や手応えを感じるできごとはありましたか？

大坪　分かりやすいところだとカンファレンスとかに参加すると「ghq使ってます」と言われることがあります。人の役に立っているんだな、というのはすごい実感できましたね。

──公開を経て、ghqに変化はあったのでしょうか？

大坪　実は、ghqは最初に作っていたときから「おもしろ機能」として、特定のユーザがGitHubでスターをつけたリポジトリを一斉にクローンできる機能をつけていました。ただ、別にふざけて作ったわけではないのですが……。

YAPC::Asiaを立ち上げたPerlの貢献者である宮川達彦さんは「インポート機能がない方がメンテナンスも楽なのではないか」とTwitterで指摘した。

この機能めちゃくちゃ便利だなと思っていて、僕の中では重要だったんですけど、ghqを公開したら宮川達彦さん（@miyagawa）から「この機能いらないんじゃない？」とTwitterで言われてしまって。「超便利で面白いじゃん」って思っていたのですが、指摘されて考えてみると「確かに他の人は使わないよな」と思ったわけです。こういった自分と他人の感覚の差が分かったのは面白かったですね。

──公開後にこういった指摘されることはよくあることなのでしょうか？

大坪　ありますね。僕は自分が作ってるツールは「超便利！」と思って公開しているですけど、他人にウケるものとウケないものが全然違うと思っています。そこの感覚はまだ正確には分からないですね……。自分で作った料理は全部美味い、みたいな感覚です（笑）。

──逆に他の方が作ったOSSを見るときはどんな点を見ていますか？

大坪　僕が気になるのはコンセプトですね。あまりに巨大なものを作ろうとしてないか、あまりに仕事の小さいものを作っていないか、適度な粒度のものかどうか、ということは大切だと思っています。

もう一つ、インターフェースの設計は注意して見ています。ユーザーが使うインターフェースがどんな作りをしているかは、そのプロダクトのコンセプトを示してると思うので。「このツールはこういう仕事をします」というのがしっかりと定まっていて、他のツールと連携させやすい、というのが見えると、良い粒度で作られていると感じますね。

こうしたUNIX 哲学とも言える考え方は、自分の開発でも意識してるんじゃないかなと思います。LinuxやGitを操作していても感じると思うんですけど、小さいコマンドを組み合わせることで、何か一つの仕事をさせるという考えは大切だと思います。

──他の方のOSSのコードの美しさなどは気になりますか？

大坪　いえ、細かい部分のコードの良し悪しは後からどうにでもなるので、設計の方を気にします。後から変えようがない、大きいところが大事だと思うので。

OSSのコードで外の世界と繋がることによって自分自身の世界が広がる

──人気があるツールだとプルリクやissueもかなり来ると思いますが、その中でも「良いプルリク」だと感じるものはどんなものでしょうか？

大坪　プルリクを送ってくれる方の問題意識が共有できてると、すごく検討しやすいと思っています。問題とその解決が同時にプルリクで来ると、それを解きほぐすのに時間がかかってしまうことがあるので。 TwitterとかSlackとか別のチャンネルで「こういうことが気になっている」と先に共有してもらえると自分も解決の準備ができる。やっぱりコミュニケーションが大事ですね。もちろん、「明らかにおかしい」ものはすぐにプルリクを送ってもらいたいですけど（笑）。

ghqに関してはプルリクにあんまり対応できていない状態で、正直「申し訳ない」と感じていて、OSSの作者としてはあまり正しい態度ではないとは思っています。

僕の場合、どんどん新しいものを作るのが好きで、公開してある程度の段階までいくと、それはそれとして次なるものを手がけたくなってしまうんです。 だから、OSSを定期的にメンテきてる人はすごいなと思います（笑）。

──他に印象的だったプルリクはありますか？

大坪　ghq getというコマンドの引数は基本的にURL を指定するのですが一単語だけ指定した場合の挙動もあります。例えば、ghq get railsとすると、自動でgithub.com/rails/railsをクローンするようになっています。

この機能は公開初期にプルリクでもらっていてマージしたんですけど、使っていくうちに、ブラッシュアップする余地があることに気付いたんです。

続いて、この前もらったプルリク（上画像）は自分のリポジトリをクローンするように修正するものでした。例えばghq get railsならmotemen/railsという具合に自分のリポジトリをクローンするんです。

この一連のプルリクは、僕の中でひっかかっていたた要素を解決してくれたと思っているんです。それまで「あんまり破壊的な変更を加えるとツールを使っている方の迷惑になるんじゃないか」という気持ちがあって、大胆な変更を加えることができなかったんです。

──それまでは保守的に運用していたというイメージでしょうか？

大坪　そういう態度だったかなと思います。それまでだと“挙動を変える”と考えたときに「この変更は他の人にどういう影響を与えるか分からない」と思って、なかなか手が進まないということがありました。ツールは1回使われるようになると、大きな変更を加えてはいけない、という思いがあったんです。

しかし、さっきのプルリクをもらったときに「破壊的な変更も時には必要」というのを提案とともに教えてくれたのが、僕には印象深かったんです。「破壊的な変更でツール自体が良くなることもある」ということを実感できたのがよかったですね。

──OSSを自分で作って公開することによって、そういった自分の考えが変わるようなことが起きるんですね。

大坪　僕はブログを書いて思いを共有するって、すごくいいことだと思っています。それと同じで、自分の考えてることや何かしらのコンセプトをコードという形で出せば、そこに人からのフィードバックがあったりする。あるいは、自分がフィードバックを返すことで、自分が外の世界と繋がれると思うんです。

そして、繋がるための媒体としてOSSの存在は重要です。会社以外のパブリックな場所にいつでもコードをプッシュできるというのは、エンジニアにとって支えになると思います。

──一人で何かやるよりも常に外に出す方がいいということでしょうか？

大坪　何かに熱中できるんだったら一人でも全然いいと思います。しかし、何らかの形で外に出すタイミングは持った方がいい。狭いところで一人でずっとやってると、思考や視野も狭くなってしまうことがあります。そこに他の人の目を通す機会があると、また良い方向に変わっていくはずです。

会社に所属するエンジニアであっても、OSSには積極的に触れた方がいいと思っています。会社には何らかの文化があって、その文化の影響を強く受けます。しかし、全然違う会社や世界の文化から生み出されたコードに触れるというのは、刺激をもらうために大事です。

OSSの送り手としては、さっきも言ったように、何かしらの「技術を試したいから作る」「作りたいもののために技術をインプットする」というアプローチです。そして、作ったものをオープンにすることで、新しいものが自分の血肉になる、というサイクルで僕は自分を形作ってきたかなと。

組織として、OSSとどう関わるか

──今後、どのようなものを作りたいですか？

大坪　最近はコマンドラインツールばかりを作ってるいるので、もうちょっと時間をかけてボリュームのあるものを作ってみたいですね。昔は Web サービスたくさん作ってた時期もあったんですけど、最近はGoを書くのがおもしろくて、作るものがコマンドラインツールに寄っていましたね。WebサービスとかElectronでデスクトップアプリ作ったりとか、もうちょっと作るものの幅を広げたいと思っています。

──CTOとして職責もありますが、エンジニア組織とOSSの関係はどうあるべきだと思いますか？

大坪　多くのWeb企業はOSSがなくては生きてはいけず共存していくべき存在です。しかし、会社の中でコードを書くだけではOSSにタダ乗りしてしまうことになる。だから、もっとOSSにコミットしていくべきだと考えています。

OSSのコミュニティに自分たちが入り一員になり、そのコミュニティの進歩に貢献していきたい。OSSのコミュニティに会社が合わせるんじゃなくて、会社とコミュニティの方向を一緒に作っていくのが大切だと思っています。

取材：megaya　{$image_10}megayaのブログ