【後編】企業所属のRubyコミッター対談! 〜Ruby開発の裏話と今後の取り組み〜

こんにちはCTO室の緑川です。今回はアンドバッドさんが主催しているPodcast「ANDPAD TECH TALK」のゲストに弊社の@mameが出演した記事の後半です。Podcastとしてお聞きしたい方は下記のアンドパッドさんの記事からお聴きください。

tech.andpad.co.jp

前編の記事はこちらです。

【前編】企業所属のRubyコミッター対談! 〜企業に所属するOSS開発者って何?〜 - クックパッド開発者ブログ

トーク本編

櫻井:皆さま、こんにちは。アンドパッドの開発本部でエンジニアリングマネージャーをしている櫻井です。

櫻井:13回目のANDPAD TECH TALKです。ANDPAD TECH TALKはアンドパッドの開発チームの中の人をゲストに招いて、あれやこれやお話しするカジュアルなテック系Podcastなのですが、今回は前回に引き続き社外ゲストをお招きしたスペシャル会の後編となっております。企業に所属するRubyコミッターであるお二人をお招きしています。

櫻井:アンドパッドからはフェローでありRubyコミッターの柴田さん。対談相手はクックパッド株式会社所属のRubyコミッターであるmameさんこと遠藤侑介さんをお呼びしています。前回はお二人の今までの経緯、Rubyコミッターが普段どんなことをしているのかをお話いただき、非常に良いところで後編となっていたところです。今回はRuby開発の裏話と今後の取り組みなど深振りをさせていただきたいと思っております。それでは後編をお聞きください。

Ruby開発の裏話

櫻井:まずは遠藤さんからお伺いしますが、開発裏話みたいなものはありますでしょうか?

遠藤:クックパッドでRubyをめちゃくちゃ現場で使っている職場に転職したから、現場感がつかめてなかったので、よくわからなかったところがうまくいくようになったのはちょっとあったりしますね。

遠藤:最初に述べたカバレッジの測定をする機能を担当しているんですけれども、カバレッジの測定を止めたり再開したりする機能が欲しいという要望が以前Rubyに来たことがあったんですけれどもその時は必要性がよくわからなかったんですね。実装するのも大変なので断っていたんですけども、クックパッドで働くようになって、現場で働いている人 から同じ問題で困っているという話を聞くことができて、どういうふうに困っているのか理解がちゃんとできたので今回対応することにし、oneshot coverageという機能を導入するようにした話があったりします。

柴田:その話で言うと、RubyコミッターRubyのコード書いていない問題みたいなものをよく言われたりしています。Cプログラマーの皆さんだから会社の中でRubyをどう使って何を書いているかとか、またRailsをメインに開発されている人とかRailsを使ってアプリケーションを開発している人とかが「Rubyでこういうことができるといいんだけどな」みたいな部分とあとRubyを開発しているRubyのコミッターの人たちが「こういうRubyのコードは書かないでしょ」って言った矢先に「書きますよ」みたいな話とか、逆にこう書けたら便利じゃないって「誰も書きませんよ、そういうこと」みたいな話は結構イベントとかSlackとかそういったところでよく散見されたりするのはあるあるネタですよね。

遠藤:そうですね。本当に現場感がない人がRubyを作っているっていうのはちょっと問題としてはあったりしますね。

柴田:ただ最近はShopifyのエンジニアであるとか、あとはよく喋る場みたいな部分が割と増えてきたような気はします。スタートアップ中心にRubyを採用している会社も結構な数があったりするので、「こういうことができるといいんだけどなー」みたいな部分とか拾ったりヒアリングしたりしやすくなったりしているのかなというのはありますよね。

遠藤:ありますね。

柴田:最近のライブラリというかプログラミング言語のGoとかRustみたいな言語はライブラリ自体がGoとRustで書いてあるというような言語なので、初学者の方とかが最初にGoとかRustをやりましょうみたいなときに割りかし開発を始めるまでのつまづくステップが比較的ないんですよね。それに比較するとRubyはC言語で書かれていて、C言語を動かすためにはコンパイラーとコンパイルした後の実行パイナリを実行する場所が必要になっていて、その辺の組み合わせで動かないとかビルドできないとか、何かプログラムを書こうと思ったんだけどプログラムを書くまでに1日とか何なら数日かかってしまう。Googleで検索しても何かエラーメッセージが出てこないみたいなことが増えていますと。

柴田:あとはAppleのmacOS、MacBookのアーキテクチャーがガラッと変わったことでいろいろビルドできない問題が引き続き多いとか、ARMのCPUの上では何かうまく動かないとかそういったいろいろな社会のコンピューティング環境の変化にともなって、自分が使いたいものがすぐ使えない、みたいな部分に散見されるなっていう問題があります。僕はいろいろやってはいるんですけど、その辺のプログラムを書こうと思ったときにすぐ書けるようになるみたいな部分の時間をとにかく小さくしたいと思っているので、その辺をいろいろやったり、前回遠藤さんの方から紹介があったkateinoigakukunさんがmacOSについてすごい詳しくて本当に助かったんですけれどもその辺のmacOSでビルドできない問題、動かない問題みたいな部分もいろいろ複数人で協力しながら解決していったりしているっていうのが現在進行系の話になってますね。

開発者に知ってもらいたいこと

櫻井:ありがとうございます。Ruby開発の裏側を聞いてきましたが、開発者に知ってもらいたいことなどがあれば、お二人からお伺いしたいんですけれどもいかがでしょうか?

柴田:はい、そうですね。昨今のプログラミング言語界隈の流れというか流行りみたいな部分の話をちょっとしたいんですけど、VS Codeと呼ばれるエディターが割とメインというかメジャーな存在となっていて、VS CodeはTypeScriptであるとか、Go言語であるとか、最近だったらRust言語みたいなもののサポートが非常に豊富なんですよね。

柴田:それもちろんMicrosoftが今すごい投資をしているんですけど、開発者体験という言葉があってデベロッパーエクスペリエンスというんですけど、開発者が何かをしようとした時に「うっ」てつまずかないように、なおかつ、こういうものを書きたいと思った時にスラスラっと書けます、テストも実行できます、不具合があった場所を見つけますみたいなものをできる限り提供していこうというのがどのプログラミング言語でも非常に重要視されています。

柴田:RubyもVS Codeのサポートであるとか、そういった型システムみたいな部分については少しずつ頑張っているんですけれども、やはり他の言語と相対的にはまだまだだなという部分があります。その中でも2022年にリリースするRubyのバージョン3.2でも今話したようなエラーを見つけましょうとか、そういう開発者にとってスラスラっとRubyのコードを書けるようにするための機能がいくつかあるので、その機能の開発を頑張っていた遠藤さんに詳細を聞くといいんじゃないかなと思います。

遠藤:僕がRuby3.2の中で新しくやったこととしてはRubyの例外が出たときに「このコードのせいでおそらく例外が出てるんじゃないの?」というのをエラーメッセージでサジェストをするという機能を少し拡充するのをやってみました。ErrorHighlightと呼ばれる機能なんですけども、それを拡充していました。また僕が作ったやつ以外にもSyntaxSuggestっていう機能がRuby3.2に増えまして、Rubyでコードを書いててありがちなのはendでステートメントを区切る言語なんで、endを書きすぎたり、逆にendが足りなかったりした時にどこにendが足りなかったのかというのはよくわからなくなりがちなんですよね。

遠藤:シンタックスサジェストとはコードの構造を大きく抜粋して「おそらくここにendが多すぎるんじゃないか」とか「足りないんじゃないか」というのをエラーメッセージの中にヒント情報として出してくれるという拡張が行われていて、これもエラーがでた時に開発者がどこを直せばいいのかというのをサジェスチョンしてくれるという機能がちょっとずつ増えています。

柴田:今の遠藤さんのお話はRubyのコードを実行したときに「この辺がエラーではないか?」というのを開発者の方にすぐお知らせするというような機能だったりするんですけど、他にもRubyの開発会議とか開発のこういうふうな変更を加えてはどうかみたいな時にも割と新しい機能を入れたりこういうメソッドを入れて警告を出すとか、「この辺が良くないのでは?」みたいなのを教えた方がいいんじゃないっていう提案が来るたびにじゃあそのエラーメッセージなり警告メッセージをプログラマーが見て「なにかできることはあるの?」みたいな話をしたら「いや、ないかも」みたいな話とか結構開発の方針を決めたりするときはあるあるネタです。メッセージを出したりプログラミング言語の動きとして、それを使った人が、「じゃあそれ見てなんかできることはあるの?」とか逆に「こうすればもっと良くなる」みたいなことをすぐ適切に知らせるにはどうしたらいいのかみたいなのは本当にRubyコミッターの中でも熟考というか結構紛糾しがちなネタだったりします。

柴田:例えばワード1個をセーフって言い切ってしまっていいのかみたいな話とかでも、1時間とか2時間とか議論して「いやこれセーフって言うとダメでしょう」とか「いやじゃあなんて言えばいいの」みたいな話とかは結構あるあるネタだったりしますよね。

遠藤:名前はね、本当にデベロッパーエクスペリエンスに直結するところなので、だいぶ長く議論をしますね。その結果がやや不自然な結果になることがあるんですけど本当に熱意を持って設計されているところだと思います。

今後の計画

櫻井:なるほど。ありがとうございます。さまざまなお話を伺ってきまして、ぜひ今後のお話も伺いたいと思うんですけれども、今後お二人がやっていきたいRuby開発にはどんなことがあるでしょうか? もし計画などがあればぜひ教えていただきたいです。

柴田:はい。計画はないのでそれぞれが勝手にやりたいことをやっている、という話のあとに計画の話をするというのもあれなんですけど、僕が思っている部分としては、やっぱりRubyを開発する人が、開発をもっとしやすくなるようにできるといいなと思っている部分があるのでそこの部分の支援ですね。

柴田:具体的にはRubyがちゃんとサポートしている動く場所、コンピューターの上として10個とか20個とか、Linuxの上であるとかmacOSの上であるとかWindowsの上であるとか、そういったいろんな部分で動かせるようにしましょうというのをユーザーと約束していて、ちゃんとそこの上で動かせるようにするというのをやっているんですけど、何かの変更を入れた時にWindowsは動きませんでしたとか、Windows向けに入れた変更はmacOSではダメでしたみたいなことがよくあるんですね。

柴田:ただ、やはりRubyコミッター1人1人が持っているコンピューターは1個とか2個とかに限られているので、あるRubyコミッターがサポートするよって約束している10個とか20個とかの環境に即座に自分の目の前のコードを実行したりテストできるようにするみたいな部分を来年何かしら用意したいなというのが1個目の野望というか計画で、2つ目はリリース作業をもっと楽にしたいと思っていて現状は僕と遠藤さんとあとは3、4名のリリース担当のRubyコミッターと呼ばれる人たちが18時ぐらいから大体いつも22時から23時過ぎまでいつもリリース作業と呼ばれる作業をします。皆様に最新のRubyをご提供みたいな仕事をしているんですけど、もうなんかやるたびに(少しずつ良くはなっているんですけど)ほぼみんながもうやりたくないなっていう風に考えて、また次頑張るみたいな消耗戦を繰り広げているので、もう念じたらリリースできるというくらいまではちょっと頑張りたいなと思っているところです。だからいろいろ問題があるんですよね。

遠藤:不思議ですよね。リリースは本当にびっくりするぐらい何かしら必ずはまるという感じで。

柴田:なんか解決したはずなのに新しい問題がまた起きるみたいなことを本当に繰り返していて、誰かがサボリとか悪意を持ってやってしまったとか、そういう話ではなくて本当に新しい技術的な課題が毎回起きていて、そのたびにちゃんとこれはポストモーテムして対策を入れるみたいのを毎回少しずつ対策してるんですけど毎回新しい問題が起きるんですよね。

遠藤:普通にソースコードをtarballにまとめるだけでなんでこんなにハマるんだっていう風に思う人もいるかもしれませんけど、本当になぜかtarballに固めたバージョンだけで発生するバグとかが毎回ちょっとずつ混入するのでパッケージを作ってテストしてみたら失敗するとかっていうのが発生するんですよね。なので、いざ本当にリリースバージョンを作ったら新しい問題が分かるのでそこから慌てて直すとかっていうのが何かしら発生する感じで大変ですよね本当に。

柴田:ですよね。Webサービスの場合は自分たちが面倒を見て全責任を持っているコンピューターの上で動かすようにソフトウェアをリリースしますっていう感じなんですけど、Rubyとかプログラミング言語の場合は自分たちの外に向かってソフトウェアをリリースするみたいな部分です。なので、使う人の数だけそのソフトウェアが動く場所があって可能な限りそれを広くカバーしたいけどカバーしきれないこともあって「とあるソフトウェアがこういうバージョンだったらビルドできませんでした。これあかんみたい」な話とかを何回も繰り返しています。そこの大変さをちょっと広い目っていうか大きいスコープで捉えて解決するような仕組みを用意することでリリースとかはもっと毎月でもバンバンやっていいんじゃないのくらいのほうが、短いサイクルのほうがちょっとした不具合があっても「3ヶ月待たないとRubyは直らないんだよな」から「来月直るし」みたいなほうがユーザーにとってはおそらくいいことだろうし、開発する側にとっても何かミスっても来月直せばええやみたいな感じになって、みんなが楽になると思うので、少しずつがんばりたいなっていうのは僕の2023年の目標活動に入れています。

遠藤:ほんとリリース頻度上げたいですよね。定期に3、4ヶ月くらいしたら1回入れるかどうかっていう。

柴田:年3、4回ですもんね。

遠藤:nodeとかは実質的に2ヶ月に1回リリースしてるみたいなので、そういうのをまねしていきたいですよね。

柴田:そのくらいになりたい、、、隔月くらいになりたいですよね。

遠藤:隔月くらいになるとユーザーも「そろそろRubyの新しいバージョンが出るらしい」みたいな備えができるかなと思っていて、いいなと思ってます。

柴田:それに雑に壊れても、次回直せばいいなみたいな感じにもなれると思うので、やっぱり儀式化すると挑戦する意欲を高めるのにもすごい時間がかかるし、やってしまったときの「あー」みたいな気持ちもすごい高まるので、その辺の敷居はどんどん雑に下げていきたいですね。遠藤さんも何かあるんですか?

遠藤:そうですね。最初のほうに話したTypeProfっていうやつを今まで作ってきてるんですけど、今年はですね今の実装のアプローチ、バイトコードを解析するというベースのアプローチだとちょっと限界を感じてきていて、抽象構文木ベースで解析し直すように作り直すというのを考えています。そのためにまずParserをどうにかするという必要があって、その辺りをShopifyの人たちがやってくれているのがそろそろ形になってきているのでそれをベースに2023年に作り直したいなというふうに思っています。それによってVS codeでのRubyの対応が弱いとかって言われているのを改善するように1つの提案ができたらなというふうに思っております。

個人の開発者がRuby開発へ貢献できる方法

櫻井:では最後にですね、ここまで聞いてきたリスナーで自分もRuby開発に貢献したいと思ったエンジニアが結構いるんじゃないかなと思ってるんですが、どうやったら個人の開発者がRuby開発へ貢献できるのでしょうか?

柴田:一番簡単な方法はとにかくRubyを使うっていうのがあって、手元の仕事で開発しているソフトウェアであるとか仕事じゃないソフトウェアもいっぱい皆さんのお手元にあると思うんですけど、その辺のコードをとにかくRubyで実行するということがまず最初の一歩です。

柴田:2つ目はですね、ここがちょっとアクションが必要になってくるんですけど、その動かした結果をRubyの開発チームに伝えるっていうのがポイントだと思っていて、動いたっていうことも重要なんですよ実は。

柴田:Rubyの開発チームはPreviewバージョンとRCバージョンっていうのを1年間に2、3回リリースするんですけど、その2、3回リリースしたPreviewバージョンを使って自分の手元のコードを実行してみて動いたら動いたって言ってほしいですし、動かなかったらこういうエラーが出て動かなかったっていうのを教えてほしい。どちらも実は重要でまず実行してもらわないことには不具合なり、そのちゃんと正しいっていう動きも我々が知ることができませんし。で実行した後に動いた動かないっていう状況を伝えてもらわないことには我々はそれを知ることができないっという二段構えになってまして、本当に本当に大事で、ベータバージョンを出してみんながテストしてくれたから、大丈夫だったと思ってベータじゃない正式バージョンをリリースしたら全然動きませんでした。「なんでだ?」「ベータバージョンは誰も実行していなかったからだ」みたいなのは本当ソフトウェアあるあるな話なので、とにかくベータバージョンみたいなものを触ってみて「なんだこれ?」みたいなものがあったら動かなかったっていう報告であるとか、あとこの動きはちょっとおかしいんじゃないとかもぜひ教えてもらいたいなと思います。

柴田:それで、教えてもらう方法もできる限りいろんな窓口を用意していて、メインで使ってるのはRedmineっていう課題管理ソフトウェアなので、Redmineの方で報告してもらうっていうのが一番の王道というかメインの手段なんですけど、それ以外にも例えばSlackにRubyのグローバルなコミュニティーとかもあったりするんですけど、そこの部分で動かなかったとか動いたみたいなものを僕とか遠藤さんにお伝えてもらってもいいですし、なんかTwitterとかそういう類似のソーシャルネットワークのサービスでメンションして、このコードが動きませんでしたみたいなことを伝えてもらってもいいですし、何かしらの手段でとにかくRubyの開発をしている「Rubyコミッターです」って名乗っている人たちに伝えるっていうのが一番最初にまずできることだと思いますね。

柴田:で、第3ステップ目がちょっとハードルが上がるのかなと思うんですけど「なんだこれ」みたいな動きに対して「こうした方がいいんじゃないのか」っていうようなコードを書いて、それをGithubなりのプルリクエストでサブミットするとかRedmineの方にコードの断片をパッチとして貼り付けて投稿するとか、そういった部分を繰り返していくっていうのがRuby開発への貢献。Rubyのコミッターサイドとしてすごいありがたいなっていうような動きになるのかなと思います。

柴田:皆さんが会社で行われてるような陸続きだと思っていて、RubyコミッターはただRubyを開発してる人でしかないので、チーム開発とかサービスを開発するときに隣の人が作った機能を実行してみたら動かなかったんだけどみたいなことだったら、皆さんは多分すぐSlackとかGitHubとか何かしらのチャットツールとかで動かなかったよって伝えると思うんですね。本当それと同じようなノリでいいと思っていて、ほんとまつもとゆきひろさんにTwitterで「これ動かないんですけど」みたいなって言うくらいでもいいと思って、まつもとさんすごいフレンドリーなので、まあそういう形でこうどんどん伝えて一緒に作っていくっていうのがRubyの魅力だと思うのでぜひなんかやっていただけるといいのかなと思います。

遠藤:そうですね。本当に動かなかったときに誰にも言わないで諦めてしまうっていうのが一番残念で、誰かが困った問題では他の人が困るのでいったん声を上げるっていうのが重要だと思います。声を上げるのもできればTwitterで誰ともなしに語るだけではなくて、僕らのようにRubyの開発やってる人になんとか伝わる形で、一番簡単なメンションとか、より理想的にはやっぱりバグトラッカーに報告をするっていう形で伝えてもらえたら嬉しいなと思います。本当に時々あるんですけどTwitterで動かなかったというツイートを誰かコミッターが拾って直すっていう対応をすることもあるんですけども たぶんほとんどのやつは気が付かずに流れていってると思うので伝えてもらえると嬉しいなと思います。個人の開発者がRuby開発へ貢献できるかっていう話だと、RubyはCで書かれているのでちょっとハードルが高いっていう風におっしゃる方が時々見かけるんですけれども、そんなに難しく考えなくても(もちろんCが書けるに越したことはないと思うんですけども)そのようにバグ報告をするっていうのも重要な貢献ですし、特に機能提案に関してこういうユースケースでこの機能が欲しいとか、この機能提案だとこういうケースで問題があるだろうという議論に参加するという形の貢献もあると思います。実際にそのRubyのコードに手を動かして貢献したいっていう時も何かしら声をかけてもらえれば課題を紹介したりとか書こうとしているプログラムを手伝ったりとかもできると思いますので、やっぱりこれも声をかけてもらうというのがすごく重要かなと思います。

櫻井:ありがとうございます。思っているだけではなくて、アクションに起こすことでRuby開発への貢献もできるし、コミッターへの道も開けるのではないかと。皆さんぜひどうしても見構えてしまう方もいるのかなというところがあるので、そういったところはちょっと一旦置いておいて、ちょっとした勇気を持ってコミュニケーションを取ってみるとそこから先に進めるのかなという気がしました。

遠藤:そうですね。自分が実際にRubyを使っていて、こういう機能が欲しいっていう思いから貢献してもらうのがベストではあるんですけども、何かやりたいけれども特にアイデアがないっていう時には、時々Google Summer of CodeとかRubyのコミュニティからこういう課題があるっていうのを紹介することがあるので、それを参考にこれだったら自分ができるかもというのを選んでもらうというのもいいかなと思います。

遠藤:この間柴田さんが書いたブログの記事とかね。そういう感じでRubyの長い懸案になっている課題みたいなのを紹介することもあるのでそういうのを考えてみてもらえといいかなと思ったりします。

柴田:そうですよね。結構発信してなかったなと思ったんで、こういうことをやりたいとか。プログラミング言語業界の懸案事項って実は結構あって、どの言語でも実は今この問題があって、どの言語も解決できてないとか、ある言語だけこういうアプローチで解決できているとか、何なら無視しているとか、結構そういうのはRubyコミッターの中では議論として出たりしているんで、そういったものをできる限り開発ネタとして発信をして意欲のある人が「えいっ」て頑張って作るみたいな部分でネタを提供したりもできればいいかなと思ってますね。

遠藤:そうですね。バグトラッカー上で議論しているのを頑張っておりますが、ちゃんとまとまってないのでどういう課題があるかというのを一覧できないのがやっぱり難しいですね。発信していかないとですね。

櫻井:ありがとうございます。今回も本当にいろいろな裏のお話だったりとか、深いお話もお伺いできたかなと思うのですが、そろそろお時間となりますので、今回のANDPAD TECH TALKとしては以上で終了とさせていただきたいと思います。

さいごに

Rubyコミッターによる対談はいかがだったでしょうか?クックパッドではサーバーサイドやOSSに関わりたい仲間を募集しています。Rubyについてもう少し詳細を知りたい方はカジュアル面談も実施していますので、ご興味のある方はぜひ気軽にご連絡ください。

cookpad.careers