CTOが訊く#2 Rails Committer と DeNA

「CTOが訊く」は、DeNA CTO の @nekokak（ねこかく）こと小林 篤が、社内のメンバーに、その人となりや仕事っぷり、そして野望を訊く、というコーナーです。

第2回の対談ゲストは、@kamipo（かみぽ）こと上薗 竜太。

Full-Time Rails Committer としての入社

@nekokak
今日は「CTOが訊く」へ、Rails Committer である kamipo さんに来ていただきました。よろしくお願いします。

@kamipo
お願いします。

@nekokak
この「CTOが訊く」は、DeNA で活躍しているスペシャリティの高いエンジニアの人から色々と話を訊きながら、DeNA でどういう活躍をしているか伺って深堀りをしていく、というものになります。

早速、色々と話を聞いていきたいと思うんですが、まず、観ている方からすると kamipo さんて誰？という方もいらっしゃると思うので、簡単に自己紹介してもらえますか？

@kamipo
Ruby on Rails の Committer をやってる kamipo です。

7年くらい Rails に Contribute してて、数年前くらいに Commit Bit をもらって、それから Committer という形で活動しています。

@nekokak
今では kamipo さんのコミットの貢献度は、トップ5に入るくらいやられているんですよね？

@kamipo
そうですね、 Rails Contributors は、 Merge Commit もカウントしてるから、あまり公平ではないんですけど、アクティビティっていうのでいうと、まあそのくらいですかね。

@nekokak
日本の Contributor っていう観点からすると一番 Contribute してる人になるんですよね。

@kamipo
そうですね。

@nekokak
それは素晴らしいですね。

僕が知ってる kamipo さんって、Rails をやってるイメージが元々あんまりなかったので。

@kamipo
そうですね。

最初、Perl のコミュニティで活動していて、その後 MySQL とかやって、その後 Rails やり出したみたいな感じですね。

@nekokak
僕も kamipo さんと知り合ったのが Perl のコミュニティ繋がりで、当時はもう MySQL の人って認知されているぐらい色々とやられてたんで、すごい印象的でした。

kamipo さんは DeNA に入る前からいろんなチャレンジされてましたよね。転職を考えられたのも Rails がきっかけでしょうか？

@kamipo
自分がずっと長いこと Rails の Contributor として活動してて、それを上手くレバレッジできるような活動がしたいなと思ってて、それがどういう形かっていうのは、具体的にはイメージできてなかったんで、いろんな興味を持ってくれる人と話していく中でどういう選択肢があるんだろうって考えてました。最終的に、会社に所属してやるっていう選択肢になったっていう感じですかね。

@nekokak
kamipo さんだったら引く手あまただと思うんですよ。

いろんな会社の話を聞かれたりしたと思うんですけど、そんな中で DeNA を選んで頂いたのはどういった理由でしょうか？

@kamipo
前職が toB だったっていうのと、あと、結構色々声を掛けてくれるところも toB が多かったんですけど、toC の中で、サービスの規模感だったりとか、そういう部分で DeNA は、自分が今まで見たことがないシステムで面白そうかなっていうのはありましたね。

@nekokak
じゃあ、 kamipo さん自身があまり経験したことがないというか、関わったことがない領域の課題だったりとか、そういうのに触れられるかなあみたいな。

@kamipo
そうですね。

『 Rails で困ってるユースケースをめちゃくちゃ知りたいと思ってて、その機会を最大化するのに上手く会社を使えたらいいな、と』

@nekokak
入社される前に、僕から kamipo さんに声掛けさせてもらった後に、「是非 DeNA の現場のエンジニアと話してみてくださいよー」と一回ミーティングをアレンジしたと思うんですよ。

そのとき、いろんな事業部のメンバーがどんな感じで今 Rails 使ってるのか話をしたと思うんですけど DeNA の人がどんな課題を持ってるのか Commiter として見えていたりしましたか？

@kamipo
そうですね。

Bug の Issue の報告も、上がってきてるのは見てたんで、「こういう風に使ってるのかな」というのはうっすら思っていました。

でも実際入ってから聞いた話の方が面白い、というか。そうですね、みんな頭良いなと思いましたね。

@nekokak
印象的だったのが、Issue Bug Ticket とか、Issue を上げるときに、もっとユースケースとかを明確にした方がいいよ、みたいなフィードバックをされてましたよね。

@kamipo
そのときのパッチは、何かの Bug を直すとかじゃなくて、リファクタリングだったと思うんですけど、「そういう風にリファクタリングした方が、外から拡張しやすい」みたいな感じで、僕も「そうやな」と思ってるから、別にそれしてもいいんすけど、具体的に「こういうことが今困ってて、これを実現する為にこうできると嬉しい」みたいな感じで来た方が『せやなー！』ってなるっていう。

で、この『せやなー！』感がめっちゃあると、じゃあそうしよう、みたいな感じになるんで。

「そうしてもいいけどそうせんくてもいい」ぐらいのレベルのことやと、なんかこう、進めづらいんですよね。

課題が共有されるというか、「せやなーわかるよー」みたいな課題感がちゃんと共有されると、「それは確かに問題やわ！」みたいな。

@nekokak
なるほど。それ結構重要ですよね。

実際に OSS とかって、いろんな人がいろんなユースケースで使ってるじゃないですか。

Committer としてやってる人たちが想定してないユースケースに関するパッチだったりとか来たときに、その人たちのユースケースが理解できなかったりとかすると、取り込む必要性って感じないと思うので。

そういうところも含めてってことですよね。

@kamipo
そういう感じです。

@nekokak
でも僕、あのやり取りを見た時に、そういう kamipo さんがそういう世界というか、Committer としての視点だったりとか、考え方だったりとかそういうのを知ってるからこそできるインプットだなあと思って、ああいうインプットがもっと DeNA のエンジニアに入るといいな、と思ったのはあったんですよ。

kamipo さんには、DeNA の中で、Full-Time Rails Committer としてやってもらっていますけども、そういうアクティビティを通して、やり方というか、考え方みたいなのが滲み出ていったらいいな、という風にはすごく思ってます。

kamipo さんが DeNA で Full-Time Rails Committer としてやっていく中で、どういうことをチャレンジしたいなって今考えてますか？

@kamipo
んー、難しいですよね。

DeNA だからっていうよりかは、他の人があまりしてないことをやってきているから、その経験を上手くレバレッジをかけたいって思ってるんですよね。

DeNA だけに限らずRails で困ってるユースケースをめちゃくちゃ知りたいと思ってて、その機会を増やすというか、最大化するのに上手く会社を使えたらいいな、と思ってますね。

@nekokak
なるほど。

じゃあたとえば、DeNA のエンジニアにもっとこういうことやってほしいな、というのがあるとすると、各現場で使ってるときに「こういうところ使い勝手が悪いんだよね」とか「実は今こういう問題があって」みたいなのが、実際解決されるかどうかは別として、ケースとして、kamipo さんに共有されるみたいなのがあったら嬉しいって感じですかね。

@kamipo
そうですね。でもね、難しいんですよね。

たとえば、自分で開発してたら、僕はアプリケーションのコードを書くのも Rails 側のコードを直すのも地続きなんで、ここは Rails 側で直そうとか、これは汎用的な要件じゃないからアプリケーション側で対処しようとかっていう考えになるんすけど、地続きじゃないと、頑張ってやってしまえばアプリケーション側で全部対処できちゃうんですよね。

でも、Rails 側で改善できたら、同じことで困る人が少なくなるんですよ。そういう考え方になるのって結構地続きじゃないと難しいかなって思うんですよね。

あとは、ちょっとしたことって Issue あんまり上がってこなくて。

たとえば、MeetUp とかに行くと、「ここの挙動、バグじゃないんですか？」って直接言われたりはするんですよ。

それだと、「確かに バグっとるな、じゃあ直しておきます」ってなるんですけど、そんぐらいのレベルってなかなか Issue 上げてくれなかったりするんですよね。

@nekokak
確かにね。そりゃそうかもしれないですね。上げにくいですよね、上げる側からすると。

逆になんか MeetUp 的な感じの場がもっと開催されて、カジュアルに雑談できる場があるといいんですかね。

@kamipo
そうですね。

昔はあったんですけど、MeetUp とか。今はコロナで全部オンラインとかだし、ちょっとしたことを言う敷居がめちゃくちゃ上がっちゃってるから、なかなかフィードバックを得られづらいな、と思いますね。

@nekokak
なるほど、たしかに。

そういう意味だと、あれですよね、DeNA だけの問題というか世の中的な問題ですよね。

@kamipo
そうですね。

『結構ムキになって頑張って Open Issue を減らす活動をしてた』

@nekokak
逆に、その Rails とか含めて、Contributor やってる人たちからすると、kamipo さん以外の人たちもそういう課題感みたいなのってあるんですかね？

@kamipo
いや、どうなんですかね。

Rails って、結構大きいところは社内に Committer 抱えて会社ぐるみで Rails 側を直す、みたいな取り組みをしているんですよ。

だから、みんなのやる気でなんとかしてる、というよりかは、会社から Issue の Triage に人を出します、みたいな感じだったりするんですよね。

@nekokak
それは Committer の人以外に？

@kamipo
Committer の人以外に。

@nekokak
へえ〜。

それはどういうやり方なんですか？もうちょっと具体的に知りたいです。

@kamipo
たとえば、GitHub だと、何人かその Issue の Triage に人を出してくれたりとか。

@nekokak
それは GitHub の中の問題ではなくって？

@kamipo
純粋に Rails の Issue を。

@nekokak
あー。なるほど。

Rails 側の Issue があったときに、Committer だけじゃなくて、その Committer が所属しているたとえば GitHub のエンジニアを何人か出して、何人かでその問題を調べたりとかすると。

@kamipo
そうですね。

たとえば、再現方法がわからない Issue が上がってきたら、再現方法を聞くとか。そういう Triage すね。

@nekokak
なるほど、なるほど。

じゃあ、Committer だけに全部任せるんじゃなくて、チームを組んで役割分担しながらその Issue を解決するのを手伝ったりとか、っていう。

@kamipo
みたいな。

@nekokak
へー。そんなのあるんですね。ほうほう。DeNA でもそういうのできたらいいな、と思います？

@kamipo
んー、Committer にも構造があって、 Core チームっていうのと、 Committer チーム、Issue チーム、Triage チームってあるんですよ。

で、 Core チームがフレームワークのデザインとかを決定する権利を持ったチームで、 Committer チームは Bug の修正だったり、レビューだったり、Merge までできる権限を持っているチームで、Issue チームが Issue のクローズだったりハンドリングしていいっていうチームで、Triage チームはそこまでの権限はないけど、なんかそういう活動をするチームみたいな。

@nekokak
なるほど。

じゃ、OSS とかコミュニティへの Conribute っていう観点で、たとえば、DeNAの人がいきなり Committer じゃなくて、たとえば Triage チームに入って、そのチームに入ってる人たちと連携しながらいろんなBug Ticketを再現したりとか、問題を確認したりとか、それを上にあげていって、みたいなのをやるイメージなんですかね。

@kamipo
いやー、それはどうなんですかね。

そのチームに入るのって、コアチームのメンバーが推薦したり、誰かがコアチームのメンバーに対して推薦してなる、みたいな感じなんで。

@nekokak
じゃあ、「なりたいです！」って言っても簡単になれるわけじゃないんですね。

@kamipo
一応、Active Contributor の、Basecamp のグループみたいのがあって。

この人はアクティブだからここに招待しましょうみたいな感じで、Active Contributor のグループに招待されて、そこで手を挙げるというのはあると思うんですけど。

@nekokak
kamipo さんは Rails 使っている中で、たとえば、Pull-Req 送ったりとか、そういう Active Contributor みたいな感じでやっていく中で色々 Contribute もできてたので誘われた感じなんですね。

@kamipo
そうです。で、Commit Bit 頂いて、みたいな。

@nekokak
なるほど、なるほど。

@kamipo
僕は特にチームに入ってないときから、結構ムキになって頑張って Open Issue を減らす活動をしてたので。

たとえば、権限を持ってる人に「これはクローズできるよ」ってメンションを送ったりとかしてたら、「権限やるから自分でクローズして」みたいな感じになって。そこから一年ぐらいで Commit Bit もらった、みたいな。

@nekokak
その間はかなりの量の Contribute をしてた、って感じなんですか。

@kamipo
そうですね。

Railsの好きなところ、嫌いなところ

@nekokak
Rails の好きなところと嫌いなところを聞いてみたいんですけど、好きなところってなんですか？

@kamipo
好きなところ。うーん、好きなところかあ。難しいけど、きっかけは、Active Record 。

2005年ですかね、Rails って出たときにめっちゃいろんなフレームワークに影響を与えたじゃないですか。

@nekokak
与えてましたねー。

@kamipo
僕もめちゃくちゃ影響を受けて、当時は Perl の Catalyst で開発してたんですけど、めちゃくちゃ Rails っぽく動くようにやってたんです。

だからその、Active Record の手触りというか、そういうところがめちゃくちゃ好きでしたね。

@nekokak
確かにあれ、出た当時めちゃくちゃ影響与えてましたからね。

逆になんか、ここは嫌だな、嫌いだなというところはあります？

@kamipo
好きじゃないところは、僕は結構ミニマリストだから、あんまり余計な機能を付けたくないんですけど、いっぱい機能が増えるところは嫌だなって思ってますね。

@nekokak
ちなみに、Rails って、バージョンアップで大きくするときに断捨離じゃないですけど「ここはいらんやろう」って削ったりとかってあるんですか？

@kamipo
あります。

@nekokak
ほう。それは結構ドラスティックにやるんですか？

@kamipo
そうですね。

次の7.0とかは、結構そのアセット周り、CSS だったり、JS のバンドリングがめちゃくちゃ整理されるんですよね。

@nekokak
なるほど、なるほど。

そんな感じで一応削られてはいるけど、やっぱり時間が経つにつれていろんな機能が付いてくるっていう。

@kamipo
そうですね。

Rails って一番早めに CoffeeScript とかを採用して、賛否両論あるけど、それで来て今はその CoffeeScript はもう外してて、普通にナチュラルな JS をバンドリングしてるみたいな感じになってきてて。

結構、世の中の潮流と違うことをしてる時もあるんですけど、ちゃんとアップデートしていってるっていうのはすごいなって思います。

@nekokak
そのグランドデザイン的なやつは、さっき言ったその Commiter のさらに先にあるデザインをしてる人達がメインでやってるっていう感じなんですか？

@kamipo
そうですね。

この辺の、今言ったあたりをしてたのはDHH（David Heinemeier Hansson）ですかね。

DHH はアセット周り、JS とか、そこら辺のやり方になんかすごいこだわりがあるというか。で、その DHH のやり方がアップデートされて、7.0はすごい整理されるっていう。

@nekokak
なるほど、なるほど。

DHH は今でも影響力があるんですね。

@kamipo
そうですね。

そういう、なんか大きな方向転換みたいなのは、DHH が決めてることが多いですね。

逆にその、既存の機能の拡張だったり、インプルーブメントみたいなのは、GitHub だったり、Shopify がやってることが多いですかね。

これは、僕の性格なんですけど、自動的に価値が享受できるものが好きなんですよね。

たとえば、速くするとか。速くするっていうのは、別に何も知らなくても価値が享受できるじゃないですか。バージョン上げてくれれば。そういう変更が好きなんですよね。

まあその、速くした内訳説明してもいいすけど、でも知らなくても速くなってるからっていう。

@nekokak
たとえば Rails のカンファレンスを聞きに来てる人の視点からすると、これどうやって速くなったんだろうとか、そのディテールを知りたかったりもする気がするんですよね。

@kamipo
ああ、確かに。

@nekokak
たとえば、自分はできないかもしれないんだけども、そこから、「あ、そういう発想があったのか」とか「そういうやり方あったのか」とか、「すげーな、もしかしたら自分の現場でそのテクニック活かせるかな」みたいな気付きになる気がしていて。

そこは発信するとすごく価値あるんじゃないのかなと思ったんですけどね。

@kamipo
そうなんですよねえ。

なかなかねえ、今やってることを置いてまで、やるかどうかっていうところですかね。

@nekokak
なるほど。

じゃあ、ちょっとタイミングを見つけて一回やってみましょうか。

ちょうど、来年の3月に DeNA TechCon っていう大きなカンファレンスがあるんですよ。

@kamipo
お、マジっすか。

@nekokak
今そのコンテンツをまさに仕込もうとしてるんですけど、まだ時間あるのでそこに向けてちょっとずつ、こんなんだったらできそうだみたいなのをアウトプットするっていうのはどうですか。

@kamipo
じゃあ、考えときます。

@nekokak
よし。考えるところからいきましょうか。

『難しいと思ってなかったんですけどね。やる気無限だと思ってたんですよね』

@nekokak
kamipo さん自身が今目の前でやっていることで、これをやりきりたいと思っていることはありますか？

@kamipo
うーん、難しいすね…

長いこと触ってるコードベースだから、ここがバグってるな、とかわかってるけど直してないところがいっぱいあるんですよね。

だけど、僕のやる気の総量がもうかつて程ないから、この限られたやる気を、『直った方がいいけど別に直らんくてもめっちゃ困ってる人はおらん』みたいなことにもう使えなくなってきてるんですよね。重要度が高いことにしかもう使えなくなってきてて。

でも、そのコードベースは知ってるから、ここは直す気があるんだったら直した方がいいってみたいなのはいっぱい知ってるので、自分の手数がもうこの先限られてきてるんじゃないかなって思うと、新たに Contributer になる人たちを見つけたいな、と思いますね。

@nekokak
おお。それ結構重要ですよね。

じゃあたとえば、「実は僕もやってみたいんです」みたいな人が若手で現れたら、「おお、いいぞいいぞ」みたいな感じで、じゃあちょっとこれまずやってみなよ、みたいなのは面倒くさがらずに出来ますか？

@kamipo
まあ、そうですね。

@nekokak
それすごい素敵だと思いますよ。

やっぱり、ずっと自分が永遠とやり続けるって、なかなか難しいじゃないですか。

@kamipo
難しいと思ってなかったんですけどね。やる気無限だと思ってたんですよね。

@nekokak
なるほど、もしかしたらコロナが落ち着いてきたら、また無限大に戻ってくかもしれないですけどね。

でも、kamipo さんのやる気が無限大に戻ってきたとしても、他にやりたいと思う人がやれるようになっていく世界って、僕はすごく素敵だなと思うので、それはできたらいいですね。

DeNA での面白いユースケース

@nekokak
最後に、DeNA に入って、色々見てる中で面白いユースケースってありましたか？

@kamipo
面白いなって思ったのは、Rails って6.0で複数 DB 対応っていうのが入って、Read/Write Splitting が入ったんですよ。

6.1で Sharding の対応が入って、一応、複数データソースを持てるっていうか定義できるようにはなってるんですけど、複数 DB があると、こっちの DB に書いて、あっちの DB に書いて、両方コミットしたい、みたいなユースケースがあるじゃないですか。まあ、分散トランザクション。

@nekokak
2相 Commit 的な。

@kamipo
そうそう。これ、みんなどうやっとるんやろな、みたいな。

普通に Sharding とかやったら起こり得るユースケースやけど、こうやったらいいよみたいなのって、Rails は提供してないんですよね。

だからやるとしたら、こっちの DB のトランザクションを開始して、あっちの DB のトランザクションを開始して、ブロックがネストして、みたいな。で、どっちか失敗したら、もう片方もロールバックして、みたいな。結構、頑張って書かなきゃならないんですよ。

で、他に複数 DB 使ってるところ、たとえば Shopify だったり、GitHub だったりも同じ問題で困りそうなもんやのに、どうやっとんねん、っていう。

DeNAは nekokak さんか zigorou さんが書いてた TransactionManager みたいなのがありますよね。

@nekokak
ああ、僕書いたやつですね。

@kamipo
そう、古のソリューション…

@nekokak
懐かしい（笑）。

@kamipo
その古のソリューションを Ruby にポーティングしてやってる、みたいな感じなんすけど。

これね、他社の人に「みんな困ってへん？」って聞いたら、「困ってる」ってなると思うんですよね。

だから、そういうユースケースを持ってるのは面白いなって思いましたね。

@nekokak
じゃあ、Rails には Perl の TransactionManager みたいなやつはなかったんですかね？

@kamipo
今ないですね。

@nekokak
それを入れるっていう感じなんですか？

@kamipo
まず、入れるっていうか、こういうユースケースがあってこういうときに困るよねっていう共通認識にしないと、新機能って入れられないんで。まずそっからなんですけどね。

上手くユースケースをあげてくれると、そのユースケースに対処しよう、その話を進めようってなるんですけど。

@nekokak
なるほど。

でもそういう意味だと、そういうユースケースって、GitHub とか Shopify にありませんかーって聞いたら、「うちはこうやってるよ」って返ってきそうな気もしますよね。

@kamipo

そう、そうやとしたら、GitHub 実装かShopify 実装かわからんけど、Rails としてはこういうユースケースに対して、こういう風なソリューションを提供しますっていう風に話を進めれるんですよね。

@nekokak
なるほど、それは面白いですね。

ちなみにそれは、kamipo さんが面白そうだなと思ってその辺やってみようかなみたいな感じはあるんですか？

@kamipo

僕がやってみようかなという感じではないですけど。このユースケースは、みんな「せやな」っていうユースケースだからいいなって思ってる。

@nekokak
なるほど、なるほど。あるよな、っていう。

ある程度の規模になってきたら絶対複数 DB とか Sharding とかやるし。そのときに Rails でどう実装すんねん、みたいな。

で、普通にやったらめんどくさいやん、ってなりますよね。

@kamipo
そう、だから、改善できるポイントですよね。

@nekokak
うんうん、たしかに。

Rails の Commit っていうところも、そういうのが見つけられながらやれると面白いですよね。

@kamipo
そうですね。

@nekokak
わかりました。ありがとうございます。

TransactionManager とか10年前とかですよ。

@kamipo
いやー、懐かしいですね。

@nekokak
懐かしいですね。僕が DeNA に入ったときくらいに書いたやつなんで、10年前。

@kamipo
僕も Ruby のコード見せられたときに、めっちゃ懐かしい！と思って。

@nekokak
うんうん。

@kamipo
この書き味、みたいな。

@nekokak
この書き味（笑）。なるほど。いいですね。

じゃあ、ぼちぼち時間になってきたので。kamipo さんと話すの久々なので本当はもっと色々と話したいんですけど、コロナ落ち着いてまた飯に行けるようになったら是非行きたいなと思ってますし、それから、DeNA のエンジニアも kamipo さんと絡みたいと思うので、もうちょっと大人数でも話せるようになったら社内の MeetUp とか企画したいなと思ってます。

色々と話ができて、僕はすごく楽しかったです。 じゃあ、今日は kamipo さん、ありがとうございました。

@kamipo
ありがとうございました。

この記事を読んで「面白かった」「学びがあった」と思っていただけた方、よろしければ Twitter や facebook、はてなブックマークにてコメントをお願いします！

また DeNA 公式 Twitter アカウント @DeNAxTech では、 Blog記事だけでなく色々な勉強会での登壇資料も発信してます。ぜひフォローして下さい！

Follow @DeNAxTech