Ruby25周年を記念して学生時代からのRubyファンを公言するSideCI株式会社代表 角 幸一郎がRubyのパパである、まつもとゆきひろ氏にインタビューを行いました。
角 : Ruby25周年おめでとうございます。これまでRubyを開発していて嬉しかったことは、どんな時ですか？
（左 : SideCI株式会社代表 角 幸一郎 右 : Ruby開発者 まつもとゆきひろ）
まつもと : Rubyユーザーの皆様からこんないいことがありました！という報告が来るのは嬉しいですね。例えば、プログラミングを楽しくないなと思ってた学生がRubyを使うことによって楽しくできるようになったとか、Rubyを使っていい仕事をやり遂げたとか、給料があがりましたなど、そう言った話を結構聞きます。いい事柄ばかりでRubyの広告みたいになってしまいましたが、こういったプラスの現象を実現できているのは素晴らしいですよね。
角 : それは間違いないですね。私もRubyがなかったら卒業論文を無事に書き終えることができた気がしません。学生時代からRubyには、随分お世話になっていますし、SideCIのプロダクトも当初はRailsのコードをターゲットにして作られたものでした。
Rubyで大きな節目となった時期は？
角 : Rubyが広く普及していく過程で大きな節目になったのは、まつもとさんはいつだと考えますか。
まつもと : 1999年に私と石塚圭樹氏で書いたRubyの本が日本語で出て、2000年にはDave Thomas, Andy Huntが書いた『Programming Ruby』が出版されました。翌年2001年には初めてとなるRubyConfが開催されています。21世紀に入った頃が1つの大きな節目だと言えますね。
角 : Rails 1.0が誕生した頃ですか？
まつもと : Railsはまだまだ先の話で、2004年7月にRails 0.5.0がリリースされています。私の記憶によれば、2001、2003年とデンマークで開催されたJAOO Conferenceというイベントに呼ばれて出かけに行きました。2001年の時にDave Thomasと私、さらに学生ボランティアとして参加していて当時はPHPプログラマーだったDavid Heinemeier Hansson（DHH）の3人で言語について何か話をしたような気がします。
角 : おおっ。すごい。それがRailsにつながった。
まつもと : そうかもしれませんね。その後、DHHは37signals(現Basecamp)の仕事をリモートでやっていた時に、Rubyで書いたWeb用のフレームワークをリリースしますが、それがRailsだったと。
角 : なるほど。
まつもと : 2004年くらいまでは、Rubyなんて聞いたことない、もしくは聞いたことあるけど使ったことないとか、自分達と違うどこかの世界で頑張ってるんだね。これからも頑張ってよ。という感じで、どこに行っても他人事みたいな感じの対応が多かったですけど、2005年くらいからはRuby使ってますというような人も増えてきて、個人的にはちゃんと使ってもらえてるということを実感できて嬉しかったですね。
角 : そこからは、皆さんが知るように誰もが知るプログラミング言語になっていったんですね。私がRubyを使い始めた2009年にはもう既に一般的な言語という感じでした。
まつもと : そうですね。Rubyがテクノロジー的にホットという意味では大体ピークは2009年くらいだった気がします。いまはRubyはプログラミング言語として、ごくごく当たり前な存在になっていますよね。ただ、この当たり前の存在というのは怖くて、いまは当たり前なんだけど、新たな技術の登場で将来的にはフェードアウトしてしまうかもしれない。いまRubyのコア開発チームで努力してるのは、次の25年のために、技術に追従しながらどのように新しいRubyを提供していくかということです。昔よくつかっていた、と言われるのではなくて、昔からあるけど今も使っているよという存在にしたいと思いますね。
コーディング規約は不要？ まつもと氏が考える「基準」とは
角 : ここからは弊社のプロダクトであるSideCIと少し関係がある内容を質問させていただきたいと思います。まつもとさんのコーディング規約に関する個人的な考え方を教えていただけませんか？
まつもと : あまり私自身はコーディング規約を気にするタイプではないですね。でもコーディング規約にこだわる人はいっぱいいますよね。
角 : いっぱいいますね。
まつもと : コーディング規約を決めてくれないと仕事できないよ！っていうような人もいて、「君、本当に仕事してる？（笑）それは自分で考えようよ」と思っちゃう。ただ、インデントの幅とかスペースかタブかみたいな話は、修正するとdiffが大量に出てくるのでそれは事前に考えておいたほうがいいと思いますね。
角 : オートフォーマットで触ってないところもガーッと変わってしまったりしますよね。
まつもと : そうですね。それだけはよくないと思うんだけど、無駄なdiffが発生しないようにすればコーディング規約は特に必要ないんじゃないかなと思ってしまいます。例えば、変数名は必ず長い表現にしようとか。3回しか出てこない変数が長い名前だろうが、iだろうがどうでもよくない？と考えてしまうんです。
角 : 3回だったら全く関係ないですね。もしi がグローバルでどこでも使われていたらそれは問題ですけど、そんな馬鹿げたコードは書かないと思います。
まつもと : それは普通に考えたらわかることですよね。仮にそう書いちゃったとしても、コードレビューの時にダメだっていう理由があるわけだから、「これだけじゃわからん」みたいに指摘されちゃえばいいわけです。そう考えるとコーディング規約はそこまで重要じゃないんじゃないかなと思ってるんですよね。
Rubyコミュニティーの一部でもRuboCop万歳みたいな人たちが一定の割合でいて、でもRuboCopのデフォルトだと僕の好みとだいぶ違ったりして、どうして？となるようなルールも結構入ってる。もちろんRuboCopのような静的解析ツールの価値はわかるしRuboCopの人たちを尊敬してもいます。
角 : デフォルトのRuboCopは私も苦手ですね。SideCI社内のSlackでもこのプルリクエストがRuboCop本体にマージされちゃうのかぁ。という苦言のようなコメントが出ることはありますね。
まつもと : 基本的にプログラマは自主的な側面があると思うので、自分の事は自分で決めたらいいんじゃないかな。赤ん坊を扱うみたいに1から10までこれに従っとけばいいんだというのは、プログラマとしてまともに扱われてないんじゃないかと思います。私はそう扱われなくないし、だからこそ、他の人に対してもそういう扱いをしたくないと考えています。
角 : なるほど。
まつもと : ただ、ツールの支援で色々面倒くさいことが減るという明確な理由があれば、それでチェックすればいいしそれに従えばいいんです。
角 : SideCIに関して言えば、これでどうだろう？というSideCIの提案に対してユーザーがそれを受け止めるかどうかを決めてもらう形にしているので、従えというのは全く言わないスタンスのプロダクトになっています。
まつもと : それは素晴らしい！
角 : それでも、書き方に悩む人っていうのはやっぱり一定数いると思うんですよね。極論ですが、そういう人はどういう風に書けばいいと思いますか？自由に好きに書けというのか、それ以外なのか。
まつもと : 場合にはよりますけど、仕事のソフトウェアに関しては、まわりの人が書くコードから逸脱しないほうがいいんじゃないかと思いますね。個人的な開発の場合は自分で好きなように書けばいいと思います。酷い内容を書いて酷い目に遭うのは自分なので（笑）
角 : 私が最近よくお客様から相談を受けることに、こんなのがあります。コードレビューをしてくださいと依頼があってコードがあがってきた時、コードの機能要件は満たしているし、ちゃんと動くのだけど、コピペが多いなど保守性が低いコードで困る、というですね。こういう場合、まつもとさんならどう対応しますか？
まつもと : そういった場合は情け容赦なくリジェクトするようにしていますね。
角 : 情け容赦なしのリジェクトですか（笑）
まつもと : これこれこういう理由で採用できないのでリジェクトという感じですね。パフォーマンス上の懸念がありますとか、コピペによる保守性の低さが気になりますとか言ってリジェクトすることが多いです。場合によっては自分で引き取った後、書き直してコミットという場合もありますね。
仕事だと締め切りがあるのでその辺をどうするかというのは悩ましいことですが、仕事でも、オープンソースでも、コミットしたコードを自分が将来的にメンテナンスするはめになるけど、それをできるのか？っていうのが私の基準です。
角 : それがYesだったらマージすればいいし、Noだったらリジェクトすればいい。
まつもと : そうそう。特にオープンソースの場合はプルリクエストが来るということはある意味、将来、仮にそのコードから問題が発生した場合でも、必ずその人がメンテナンスをしてくれるとは限らないんですよね。
角 : 連絡が取れないとか、してくれない可能性も高いですね。（笑)
まつもと : そうなるとコードを引き受ける決心の問題もレビューの中に含まれているんです。だから、ゴミを投げつけるとか、プルリクエストに対して酷い表現をする人たちもいましたけど、実際にはそういった側面もあると思います。仕事であれば、君がプルリクエストしたんだから自分でやってくれと言えるかもしれないけど。
角 : OSSだとそういう側面が強いですね。
まつもと : 自分がメンテナンスするコードとして受け入れることができるか、できないのかというのは私の中の1つの基準になっていますね。
プログラミングはよりインタラクティブになっていく
角 : SideCIは、コードレビュープロセスの一部を機械に任せて人は楽をしながらより生産性が高い業務に注力することができる開発補助ツールです。SideCIに応援のメッセージがあればコメントをいただけませんか？
まつもと : 未来のソフトウェア開発というのはよりインタラクティブになっていくと思ってるんです。文法的に間違っているときはシンタックスエラーにはなるんだけど、そういうことではなくて、これはきっと間違いだけど、こういう意味なの？という感じでコンピュータが教えてくれる。それを参考にしながら書けばより品質の高いソフトウェアが作れたりとか、より早い段階で間違いを見つけることができたりする。Rubyというコードは今のコンパクトさのまま、それに付随して例えば外側に型推論の情報が来るとかそんな風になっていくんじゃないかという感じです。人間はRubyのコードしか見ない。知りたかったらIDEとかエディターに聞くと、この変数の型はこうですよとか、呼び出せるメソッドは何ですよとか、さらには、あなたの書いたコードは全体的に矛盾してるよと教えてくれたり。
そういう観点で言うと、SideCIのようなコードレビューを補助してくれるツールがソフトウェアの開発プロセス中に存在するというのは、ぼくが理想とする世界の一部を実現してるのかなという感じですね。
角 : ありがとうございます。
まつもと : 今日私が講演で触れたlanguage server protocolにも関係してくることなのですが、開発者とコンピュータがイントラクトする接点が未来永劫ずっと同じ箇所なのかはわからないのだけど、ソフトウェアに対する理解に関してコンピュータが支援してくれる、書くときにより正しいソフトウェアとなるように手助けしてくれることはソフトウェア開発の理想だと思います。せっかくコンピュータはどんどん賢くなっているので、それをプログラマーが楽になる方向に使っていけたらいいですね。
(取材日 : 2018年2月23日)
