2023年9月26日に開催した『STORES.rb × Asakusa.rb』のトーク部分を文字起こし形式でお届けします。 hey.connpass.com
STORES がRubyコミッターを迎えた理由
藤村：STORES.rb×Asakusa.rbにお越しいただきありがとうございます。よろしくお願いします。ご存知の方も多いと思うんですが、笹田さんと遠藤さんが STORES に入社されました！やったー！プレスリリースが9月1日に出たんですね。写真を撮りました。
笹田：なんかプレスリリースに出る系エンジニアって言われました。
遠藤：入社時にプレスリリースを出すことを要求するエンジニアっていう。
一同：（笑）
藤村：こんな感じで記事も出しました、という感じで STORES に来ていただきました。 people.st.inc
で、これはただの自慢なんですけど、遠藤さんが作ってくれました。
笹田：入社すると作ってくれる。
参加者：熱すぎ。
参加者：あいかわらずすごすぎて気持ち悪い。
藤村：実行できるんですよね。これを全社総会で見せびらかすという役得を味わわせていただきました。
Rubyコミッターとしてジョインというのはどういう意味かというと、STORES でプロダクト開発ではなく、Ruby本体を開発する仕事に従事してもらっています。なんでそんなことをやるのかっていう疑問があると思うんですよ。なんとなく我々Rubyエンジニアはそれがいいことだとは思うし、僕もそう思ってるんですけど、なぜかっていう理由がちゃんとあるので、それを話してみようと思います。
なぜRubyコミッターの2人をRubyを開発するために雇ったかを話すために、簡単に会社の話をします。STORES はミッションとして、Just for Funという言葉を掲げています。これは代表の佐藤裕介がリーナス・トーバルズの本からとったと言ってました。STORES は自分の内側から出てくるこだわりやこういうものを生み出したいっていう情熱とか、楽しみに駆動される経済を作っていきたい。そういうことをやってる人を応援したいし、そういった人たちがもっといい仕事をできるようにしたい。そういった人たちが生み出しているものがもっと世の中に増えてほしいという思いで STORES を作っています。
ルーツとしてネットショップのSTORES.jpもあるんですけど、今はもうちょっと広くて、中小企業の方々が事業をやる上で必要なツールをまるっと揃えています。かっこよくない言い方をすると統合された業務ソフトウェアです。ERPの話も大きな技術的アーキテクチャの話をする時に出てくるんですけど、そういう統合された業務ソフトウェアを目指しています。
従業員数も増えていて、恵比寿と仙台にオフィスがあります。STORES というプロダクトで流れているお金、流通額としても去年時点で750億円ぐらいです。利用されているのは小売やサービス業が多いんですけど、日本の産業界を支えている部分が多少なりともあるのかなと思っています。
プロダクトは5つあります。STORES ネットショップと、ネットショップと在庫が連動している STORES レジ。オンラインで物を売りつつ、実店舗で物を売ると在庫がずれちゃうんですよ。それが大変なので、何とかしようとするとバックエンドはひとつにしないといけないんですけど、10年前にネットショップを作っている時にはそんなことを思ってないし、iPadレジを作る人もそんなことは想定してないので、なかなか大変なんですけど頑張ってやっています。
あとは猿田彦珈琲さんが一番メジャーな事業者さんかと思うんですけど、お店用の公式アプリを作る STORES ブランドアプリ。お店に行って、会員バーコードをスキャンしてもらうとポイントが貯まるものです。あと、お店のキャッシュレス決済端末とオンライン予約システムがあります。これは数年前に新型コロナウイルスのワクチンの職域接種で数百万件使われた実績があります。
ネットショップとレジはバックエンドのシステムが一緒で、Rubyでできています。アプリ開発の STORES ブランドアプリ もRuby on Railsで作られています。STORES 決済 はJavaです。IdPがあってそれはGoでできていて、もうひとつ裏にあるシステムもGoでできています。オンライン予約システムもRubyでできているんですね。大きいプロダクトとしてのバックエンドシステムはRubyでできていて、6割がRubyなので、STORES ってRubyでできているようなものなんですよ。
これを変えるのは難しいんですよ。我々はもうRubyと一蓮托生の部分があるんですけど、STORES の未来を作るために、Rubyの未来を作るっていうのは会社として大いにやるべき仕事だろうと思っています。Rubyって誰かが作る必要があるオープンソースソフトウェアなんですね。
僕らは10年後もRubyを使い続けるつもりでいます。10年後も STORES のプロダクトがRubyでできていて、Rubyを使ってSTORES のプロダクトを作ることが魅力的で生産的な仕事であるためには、Ruby自体も魅力的なものになってないと辛い。10年後に誰もRubyはやりたくなくなっていると悲しいし、だんだんメンテする人もいなくなって面白くない言語になっちゃうと STORES でプロダクトを作ること、つまり我々が事業を発展させることも大変になっちゃうんですよね。なのでやろうと。誰かがやらないと魅力的で生産的な仕事にはならないし、未来を自分たちで作ろう、我々はお二人を迎えることができる規模でもあったので、お声掛けしました。
ということで、STORES は STORES の未来を作るためにRubyにも携わるべきだろうと思いました。他にも、例えば採用の面でいうとプログラマにとってはめちゃくちゃ刺激的な場所になると思うんですよね。プログラミング言語の処理系の開発ってプログラマにとっては花形中の花形だと僕は思っています。笹田さんはどう思いますか？
笹田：あんまり花形って言われたことなかったんで、ちょっとびっくりしています。
藤村：良かった。プログラミング言語の処理系の開発、Rubyっていう面で見ると、笹田さんと遠藤さんって中核をなすお二人だと思うんですよね。社内のみんなには、エンジン部分って説明してるんですけど、VMを作ったのは笹田さんだし、そういう人たちが職場で同僚としているのは、プログラミングする空間としては業界最高水準じゃないですか。プログラミング言語の処理系というプログラミングの最先端中の最先端を同じ職場で見れるっていうのはすごいことだと思うんですよね。
まとめです。笹田さんと遠藤さんが STORES に来てくれたのは大変うれしいことです。STORES でRubyを開発してもらいます。STORES は半分以上Rubyでできていて、STORES の未来のためにRubyが楽しくて良い言語にすることを STORES としてこれからやっていこうと思います。みなさま、今後ともよろしくお願いします。
RubyKaigiのスポンサーに対する安心感
藤村：ここから笹田さんと遠藤さんにお話を聞いていきます。では遠藤さんから自己紹介をお願いします。
遠藤：遠藤と言います。2008年ぐらいからRubyコミッターになって、Rubyの開発を断続的にやっています。前職の2017年からフルタイムでRubyの開発をするようになりました。
Rubyの実装した機能で多分みんなが一番使っているのはキーワード引数だと思います。あとはカバレッジ測定ライブラリ。最近はRuby 3で入る型に関するプロジェクトを、soutaroさんとpockeさんとまつもとさんと議論しながらやりました。RBSという形でRuby本体に入ってるし、自分の作った型推論器のTypeProfもRuby 3からバンドルされています。TypeProfの解析がちょっと遅すぎて実用にならないっていう問題があったので、今年の頭から作り直しています。よろしくお願いします。
笹田：笹田です。Rubyのバーチャルマシンを作ったというふうにご紹介いただいたんですけども、2004年くらいから始めて20年近く同じようなことをし続けられていて非常にありがたいです。会社とか所属は変わったんですけれども、やってることは20年変わらないです、つぶしの効かないというか。
一同：（笑）
笹田：昼にもインタビューを受けて同じような話をしたんですけど、Rubyコミッターで雇われなかったらどうしてましたかねと。Railsでもやりますかね？みたいな。その仕事で少なくとも今の年収をいただくのは無理だと思っていて、まだRubyのコア部分に需要があって何よりです。代表作はGCやVM、Rubyを触っていると皆さんが使ってくださっているところを作ったので感謝してください。
一同：（笑）
笹田：使っていただいてありがとうございます。最近は並行並列処理の話をずっとやっていますが、なかなか難しい。まだ、やったー！って感じにはならないんですが、頑張りたいと思います。よろしくお願いします。
藤村：ちょっとお二人に聞いてみたいんですけど、初回でお話しした時やその前の STORES はどういう風に見えてたんですか？
笹田：ECサイトだと思ってました。
藤村：そうですよね。
笹田：プロダクトがたくさんあることを知って、すごい会社だなと思いました。あのお店も使っているんだって。遠藤さんはどうですか？
遠藤：僕は面接の時にShopifyとどういう関係になるんですか？って聞いたんですよね。それで STORES は実店舗の方をベースにしているのに対して、Shopifyは基本的にネットショップをやりたい人が使うものだと説明を受けて、そういう関係なんだなと。
笹田：競合じゃないって言われましたね。
遠藤：ネットショップの印象が大きいんですけど、実店舗のIT化、フロントオフィス業務全般をサポートするためのSaaSになっていると聞いて、へーって思いましたね。あと就職先として考えた時には、RubyKaigiにブースを出展していたので、その時点で一定の安心感はありました。ブースの前で藤村さんとちょっとだけお話させてもらったこともあったり、知ってる人が何人も働いていたので、最初からだいぶ特別な存在な感じでした。
笹田：言わされてない？大丈夫？
遠藤：言わされてない、言わされてない。
笹田：あなたは特別な存在ですって。
遠藤：RubyKaigiにブースを出してくれてる会社は一定、特別な存在になっているかなと思いますね。
笹田：RubyKaigiにスポンサー出すといいよねっていう宣伝？
遠藤：スポンサー出したほうが本当にいいと思う。宣伝のために言ってるわけじゃなくて、転職する時にRubyKaigiのスポンサー一覧を見ましたよ。一定の安心感がすでにあるなって感じました。
笹田：知らない会社さんからもお声掛けいただきましたからね。真面目に色々と探しましたね。
ニコイチで進めた転職活動のこと
笹田：就職の話を少ししていいですか？
藤村：はい、もちろん。
笹田：二人でリストラにあったので、二人で就職活動をできたのが面白かったですね。大抵就職活動は一人だと思うんですけども、ニコイチで転職できるところを探してたんですよ。だからある程度、情報共有ができたので、二人でスプレッドシートを埋めて、この会社はどうだったっていう感想を書いてました。楽しかったですね。ストレスはあったけど。
遠藤：ストレスっていうか一定の緊張感みたいなのがあって、その間はRubyの開発は難しかったですね。一日どこか一箇所の面接があるだけで、他のことをついでにやれなくて大変でしたけど、社会勉強になりました。色んな会社の話が聞けてよかった。
笹田：こんなにRubyの会社があるんだって。
遠藤：いっぱいありましたね。
笹田：STORES に決めた理由は何かありますか？
遠藤：藤村さんと面接させてもらった時に僕が一番印象に残ったのは、「STORES に来ていただいてとにかくRubyの開発を楽しくやってほしい」って言われたんですね。仕事を探しているので、こちらから自分ができることをいろいろ言うんですけど。
笹田：Quineができるとか？
遠藤：Quineは言わなかったけど、会社の広報の手伝いもできたりしますよとか。実際前職ではRubyKaigiでお手伝いをやっていたので、そういうこともできますよと伝えたんですが、「やりたければやってもいいけど、Rubyの開発を楽しくやってほしい」って言っていただいたのが印象的でした。僕もそれが一番大切なところだって本当に思ってるので。
笹田：社会貢献とか、Rubyへの感謝があるからぜひうちに来てやってくださいっていう感じじゃなくて、STORES の業務のためにはRubyを良くすることが大事だから、とにかくそれをやってくださいっていう言い方をしていただいて。
実は同じようなこと言われたのが2社目で、前職のクックパッドでもそういうふうに言われてたんですよね。同じように STORES の未来のためにとお話をいただいたのは、本当にありがたかったですね。同じようなポジションで続けさせていただけたっていうのが転職活動の顛末ですね。
藤村：遠藤さんと笹田さんが辞めざるを得ないっていうのを見たときに、誰も手を挙げなくて、プログラミング言語技術としても止まってしまって遅かったり使うのが大変になって、5年後とか10年後にRubyをやりたがる人が少なくなってしまったら経営問題になるって強く思ったんですよね。 採用広報や社会貢献みたいな文脈でRubyコミッターを雇うことが悪いとは思わないですが、事業としてやる意味があるっていうロジックが割とストンと自分の中で落ちたので自信を持って説明できました。
もうすぐ入社されて1ヶ月ですけど、ちょうど先週 STORES のプロダクト開発をしているエンジニア、プロダクトマネージャ、デザイナーの全員集まるプロダクト会議があって、お二人が色んな人と交流しているのを見てました。入社してどのような印象ですか？
遠藤：毎週新しい会議があってまだ落ち着いてない状態なんですが、先週のプロダクト会議で初めてCTO室のメンバー全員と会えました。CTO室のメンバーは色々で面白いですね。自由に動いている人たちが多いのかなという印象で、楽しい人が多いです。
笹田：STORES はコミュニケーションをする機会を作ろうっていうのを感じますね。先週開催されたプロダクト会議も何時間もやっていて、工数にしたらいくらなんだろうって考えちゃった。その工数をかける価値をコミュニケーションにちゃんと見出しているんだなって。あまりたくさんの会社を見てきたわけではないのですが、私には新鮮でした。ここのラウンジも18時以降はお酒を飲んでいいんですが、そういう風にコミュニケーション施策をたくさんしている印象を持ってます。
遠藤：リモートワークをベースにしつつ、ちゃんとチームワークをやるような環境を作ることをめっちゃ頑張ってるなって思います。日本全国いろんなところから働いている人がいて、同期で入社した方も岐阜に住んでると言ってました。
笹田：働き方はコロナで変えたんですかね？
藤村：変えました！この会社、僕が入った2020年4月は従業員が100人いなかったんですよ。そこから今400人前後まで大きくなってるんですよね。その間にコロナがあって、リモートワークのまま規模を大きくしつつ、ちゃんとチームとして成り立つようにいろいろな工夫をしていますね。
笹田：この間、社長と話をするという機会をいただきました。社員誰でもカレンダーに予定を入れられるってすごい制度*1ですね。
藤村：佐藤さんが話してるのが聞こえてきて、これは笹田さんと話してるなって内容から察しました。
笹田：聞かれちゃった。経営者として、こういう直接の利益を生まない我々は大丈夫ですかって聞いてみたけど、ウェルカムだと言っていただいてありがたかったです。
遠藤さんの構想と野望
藤村：今後の構想とか野望をぜひお二人に伺いたいです。というのも、僕はお二人と面接で今後の長期的なビジョンの話を聞いて応援したい思ったところもあったので。
笹田：また面接の話に戻っちゃうんですけど、10年後どうしてたいですかって聞いてくださったのが藤村さんだけだったんですよ。そこまでちゃんと気にしてくれてるんだなっていうのは印象的でした。遠藤さん、3年後のRubyはどうなってますか？
遠藤：とりあえずこの3年は今やっているTypeProfをちゃんと動くようにすることに注力したいですね。それと、Rubyの開発体制が3年から5年ぐらい先に変わるかもしれなくて。RubyKaigiのRuby Committers and The Worldの中でまつもとさんが委員会制を使った言語仕様策定を試したいと言ってたんですよね。それが2025年だっけ？
笹田：わからない。
遠藤：そんなに遠くない未来に試される可能性があって、単純に委員会制にすると保守的な判断しかできなくなるんですね。そうするとRubyの進化が止まってしまうし、それはまつもとさんも嫌だと思ってるだろうし。
笹田：今の体制は、提案があった時にそれがどんなに変な話でも、どんなにギョッとする話でもまつもとゆきひろがOKと言えばOKになる制度です。もちろんまつもとさん自身が変な判断をするというわけじゃなくて、これまでの信頼からまつもとゆきひろがOKだったらいいだろうっていう、そういうプログラミング言語なんですけど。まつもとさん、今何歳くらいでしたっけ。
遠藤：もうすぐ60才じゃない？ 節目に1年間ぐらい休みたいと話はしてました。
笹田：そこでまつもとゆきひろみたいな、変なアイデアにOKを出せる人がいなくなったらどうなるかっていうのが今の問題設定ですね。その問題設定に対して、じゃあ委員会制でやると「いや、あいつが出した提案は気に食わん」ってなったりして。
遠藤：人で判断するのは良くないですけど、どうしてもアグレッシブな判断はしにくくなりそうですね。
笹田：それ入れるの？まじで？っていうのは、入れづらいですね。
遠藤：まつもとさんは変な判断をしないって言ったけど、正直変だなと思うこともあって。
笹田：最近は何かあった？
遠藤：最近じゃないんですけど、Lambdaの右矢印とか導入時にはあの文法はまつもとさん以外誰もいいと思ってなかったと思いますよ。
笹田：今となってはみんないいって言ってますよね。
遠藤：そうそう。だから、それは本当にセンスだなと思いましたね。もし今こういう文法を入れましょうっていう提案が来て、普通の委員会制だったらOKとはならないと思うんですよ。
笹田：エンドレスメソッド定義構文とかもさ。絶対入ると思わなかったよね。
遠藤：そうですね。エンドレスメソッド定義構文は僕がRuby 3ぐらいの頃にエイプリルフールネタとして提案したんですけども、まつもとさんがこれはエイプリルフールじゃなくて真面目にいい機能だと思うので入れてくださいと言って。
確かそのチケットの反応は、信じられない、やめた方がいいとか、そんな感じのコメントばっかりだったんですけども、まつもとさんが入れるんだって言って入っちゃった機能ですね。
エンドレスメソッド定義構文が広く受け入れられるかどうかはまだ正直よくわからないですけども、使っていると便利だなと思うことはありますね。僕はまつもとさんの判断は良かったのかもしれないなと思い始めてるところですけど。何が言いたいかというと、アグレッシブな判断は独裁制で一人で判断するからできてたところが大きいと思ってまして、単純に委員会制だとそれができなくなるかもしれないですね。
笹田：という問題意識があってどうするの？
遠藤：どうしましょうね？
笹田：遠藤さんが独裁者になるとかそういう話じゃなくて？
遠藤：代わりの独裁者になるっていうのはまずやりたくないし、責任が多すぎる。
笹田：やりたくないよね。なんか変なことやったら色々言われるもんね。
遠藤：Rubyが終わったって言われるでしょうね。
笹田：それこそまつもとさんから交代してダメになったらあいつのせいでとか言われて、嫌だよね。
遠藤：と思うんだけれども、いい感じにアグレッシブな判断ができるような体制にしていかなきゃいけない。
笹田：体制作り。
遠藤：委員がいっぱいいるのはダメなんでしょうね、とかそんな話をしたり、しなかったりしています。
笹田：じゃあ5人ぐらいの委員会に。じゃんけんとかで決めるかな。
遠藤：Array#shuffleとか使ってランダムにする。
笹田：なるほどね。
遠藤：今回のこの決定にはこの3人のコミッターが選出されました。 コミッタリストから選ぶ人を決めると。
笹田：いいですね。
遠藤：コミッターガチャになる。
笹田：どうなるのか。さっきShopifyの話がありましたが、ShopifyはRuby開発のビッグプレイヤーなんですよね。アクティブなメンバーはShopifyが過半数なんじゃないかな。彼らは命令系統を持って、ゴールを持って、プロダクト開発と同じラインでRubyの開発をされているんですね。我々は朝起きたら、今日は曇ってるからこっちの開発をしようみたいな感じなんですが。あれ、そこまではない？天気で決めない？
遠藤：天気で決めることはあんまりないかな。気分で決めることはありますけど。
笹田：年1の12月リリースに向けてというゴールはあるんですけど、あんまり細かくは決めてないんですよ。彼らはちゃんと工程管理をやって決めていて、予算配分をどこにするかをちゃんと決めてるんですよね。例えばLSP、VSコードの拡張によってRubyを書きやすくすることに対してこれだけのお金をかけましょう。パーサをどうするかがRubyの中ではホットな話題なんですけども、それもLSPの文脈、開発生産性を上げるという文脈で大きな投資をされている。そういうふうにきちんと考えられているので、正直言ってShopifyに任せておくといいと思うんですよ。
一同：（笑）
笹田：だって真面目によくなっていきますからね。着実なステップを踏んでる。YJITなんかすごい顕著なものだと思うんですけど、あれは素晴らしい。
でも、それだと面白いのかなっていうのが個人的にもあって。例えば委員会制になりました、アクティブな人の半分はShopifyですとなると、Shopifyの提案ばっかり通る世界にもなりかねない。もちろん彼らはコミュニティに対していい感じに受け入れられるように敬意を払って、労力を払って、いろんなことをされているナイスな人たちなんですけども。逆に何もしないとそれだけになっちゃうのはちょっとした危機感としてあるかなと思うので、いい感じの委員会になるといいですね。
遠藤：何かできないかなという気持ちがあります。なんとかRubyをチャレンジングな判断ができるような言語にし続けるっていうところが。
笹田：どうやったらチャレンジングにできるんだろうね。
遠藤：少人数制の委員会制なのかなと思いますけどね。Shopifyばかりにしない。
笹田：Shopifyはすごいよね。
遠藤：内部実装の改善は本当にすごいですよね。
笹田さんの構想と野望
遠藤：笹田さんの構想や野望は？
笹田：3年ぐらいは並列並行の話にちゃんとオチを付けたいと思っています。RubyKaigi 2023でM:N Schedulerをご紹介しましたが、それをなるべくみなさんのお手元に届けたい。
さらに今いくつかアイディアを試しています。Ractorという並列処理の仕組みはオブジェクト空間がなるべく隔離された空間で実行するので、その隔離という性質を使って並列処理を書きやすくするというものを提供していますが、さらにその隔離されたという性質を使ってGCを並列に動かせないかと思っています。Google Summer of Codeで2年くらい協力してくれた方と一緒に作っているんですが、やってみたらうまくいかなかったので、抜本的にアルゴリズムを考えなきゃいけません。それができると超早い並列並行処理みたいなもので、少しオフロードするような処理、例えばSidekiqとかの処理を大量にRactorに逃がしてやることもできるといいなと。互換性はないからRailsは動かないんですが。その辺を2、3年でやるのが目標、野望です。
また、もうちょっと長期的な話なんですけれどもRubyは今年で30周年を迎えました。30周年ということは1993年、IT業界的には、もう紀元前ですよね。
一同：（笑）
笹田：実はRubyのソースコードの構造が、実はあんまり変わっていません。30年前のソフトウェアとかメンテナンスしたくないじゃないですか。いや、してるんですけれども。
一同：（笑）
笹田：さすがにそろそろ変えてもいいのかなと思っていて。30年も経つと、インタプリタの作り方もトレンドが変わってるんですね。1980年代にスモールトークがあって、1990年くらいにSun labがSelfというのを出して、1995年Javaが出て、みんながそれに乗っかった。そういう系譜があって、2010年ぐらいまでバイトコードがいいよねと言ってたんだけど。
最近はRuby1.8がとっていた、Tree traversal型インタプリタ方式っていう木構造の表現がよいというのが、ここ10年ぐらいで話として出ています。いや、VMの方が速いんじゃないの？って思ってたんですけど、実はツリートラバースの方がこういう工夫をすると速いという論文も今年に出ています。そうすると、今までVMと言っていたのは実は間違ってたかもしれないわけですね。たかだか20年の成果なので、それに固執する必要はなくて。
あとガベージコレクションも、今はマーク・アンド・スイープという1950年代に作られたものなんですが、Rubyは最初の設計を大体そのまま使っています。もちろん拡張したり、いろいろな工夫はしてるんですけれども。で、それをそろそろ別の方法でやり直したら、もっと速くなるかもしれないなと考えています。例えばPythonは参照カウントを使っていますが、参照カウントでありながらGIL（グローバルインタプリタロック）を外して、並列にスレッドが動くようにすることをこの間委員会制で決めたそうです。
そうすると、どこがボトルネックになるか、というのは知られていたんだけど、こういう工夫をするとそこはボトルネックではなくなり、高速にうまくいくみたいなことをご提案されていて、なるほど確かにそうだなと。実際にRubyよりもPythonのほうが世界中でよく使われてますので、その中でチャレンジングな提案をできるというのはすごいなと思っています。Rubyも現在の仕様にこだわらずもう一回作り直せるといいなと思っていて、設計とかをもうちょっとじっくりやりたい。ただ、実際にRubyとして使っていただくには、完全な互換性っていうのは必要なんですよね。
例えばさっきツリートラバース型インタプリタ方式は速いって言いましたが、TruffleRubyはベースを木構造としてもっているんですよね。我々が作っているMRIよりも100倍とか速いことがあるすごい処理系です。だけどあまり使われてないんですよね。いくつか理由がありますが、一つが完全な互換性がない。CRubyをやってる人たちからすると、よくわからないけど時々自分の使っているgemで動かないと100倍早くても腰が重くなってしまう。
20年間Rubyと付き合ってきたので、ある程度互換性をどうするかの目処はつきそうで、中身は全く変えて互換性も維持するのはチャレンジングで面白そうだなと考えてます。その辺を長い期間でやっていきたいなというのがあります。だから論文を読み直して、最近のインタプリタをどう作るのかをもう一回勉強し直してやりたいなというのが野望ですね。この10年ぐらいのスパンでやりたいと思っています。
遠藤：前にその話を聞いた時は互換性をぶっ壊すって言ったのに、今言ってることは全然違いましたね。
笹田：ちゃんと互換レイヤーを作るって言ったじゃん。
遠藤：TruffleRubyも互換レイヤーを作ってるような気がするんですけど。
笹田：なんで使われないんですか？互換性がないから？
遠藤：細かいところで互換性がないことと、スタートアップは遅いのが問題じゃないんですかね？僕はすごく問題だと思っていますが。コマンドを実行して0.2秒とか0.3秒で返事が返ってくるのが重要だと思うんですけど、TruffleRubyはあんまり得意ではないんですかね。
笹田：1時間走らせるサーバだったら、最初の10秒遅くてもいいでしょうみたいな思想はわからんでもない。
遠藤：プロダクションだったらいいのかっていうとデプロイ頻度とかにもよるのかなと思いますけど。
笹田：この間見た資料で、最近の人気ウェブアプリケーションは30分に1回デプロイしてるという話があって。そうするとJITコンパイラの最初の10分は遅いけど20分は速いとなった時に、3時間における10分は許容できるけれど、30分における10分はそんなに許容できない。だからインタプリタの初速は大事なんだという理論武装がされていて、俺も今度使おうと思って今使ってみましたが。いい感じのものを作っていきたいですね。
遠藤：細かい話を繰り返しますけど、初速は重要だと本当に思いますね。Ruby 3.0の時に、Ruby 3x3ってRuby 2.0から比べて3倍にするっていう目標を掲げて、MJITやYJITの開発が進んでたんですけれども、ぶっちゃけて言うと僕の作ったベンチマークプログラムOptcarrotはファミコンエミュレータなんですね。
ファミコンのソフトをエミュレータとするプログラムをRubyで書いてて、それを2.0で動かした時には実際の機器の3分の1のスピードが出たんですね。それを3倍にすることができたら、実際のファミコンと同じ速度で動く性能が出せるっていうことで、3倍にすることにちゃんと意味があるっていう設計でつくったのがOptcarrotなんですけども。
最初の僕の設定ではファミコンの電源ボタンをつけてから、3秒後に実測になることを目標にしてほしいという意味で作ってたんですけども、JITではどうも3秒では全然ウォームアップが間に合わなくて実測にならないというのが見えてきてて。結局、起動後30秒経ったら実際の実測の3倍のスピードが出るっていうのが今のJITになっている。でも電源をつけてからタイトル画面が出てるんだけど、まだ全然遅くてもたもた動いてて、30秒後にはじめてまともな速度になるって言われても嬉しくないんですよ。
なので速度を測定する基準点を僕は3秒後に最初に設定したんだけど、JITがそれじゃダメだから30秒ぐらいにしてくれって、JITの開発者の人たちに言われて、結局そうしちゃったんです。僕は今のJITには満足してないです。なので、笹田さんがASTベースで最初から早いインタプリタを作り直してくれるっていう構想を聞いた時にめっちゃ興奮して、これを待ってたんだよ！って感じですよね。
笹田：JITまでやらないと速くはならないけどね。
遠藤：初速の部分で60fps出てくれた方が嬉しいですよ。
笹田：そうね、180fpsがちょっと後に出るよりも60fpsが。
遠藤：30秒後に180fps出ても意味なくて、1秒後ぐらいに60fps出てくれないといやだ。Optcarrotを作った時にJITは多分、このベンチマークを達成しませんっていうふうに言ったんですけどね。でもみんなJITの方ばっかりやって。
笹田：なるほどね。
遠藤：2016年の東京RubyKaigiでOptcarrotを発表して、JITは有望じゃないですって言ったんだけど、みんなJITしかやらなかった。地味に卜部さんがやったVMの作り直しはベースアップになってますね。
そういえば STORES にはもう一人Rubyコミッターの卜部さんがいて、卜部さんがいるっていうのも STORES に入る時の安心感の一つだったりしましたね。
笹田：卜部さんはRubyの開発で雇われてるわけじゃなくて、サービスをいかによくするかという根幹を担われています、すごいよね。
遠藤：バラバラしてるRailsアプリやJavaのアプリを全部統合するための何かをやっていた、よくわからないんだけど。Ruby限定でなくかっこよく活躍されていますね、すごい。
藤村：RubyよりもTypeScriptとTerraformを書いてる。
笹田：何でもできてすごい。
藤村：僕はこの野望を聞いてこれは応援したいぞって思ったっていうのがすごいありました。ということで、お品書き的には以上なんですけど、ご質問とかがあれば。
笹田：何かたくさん適当なことを並べてきたので、10年後ね。そんなこと言ってましたっけみたいになるかもしれないですけど。いろんな選択肢は検討していきたいと思っております。
質疑応答「どんなアーキテクチャになりそうか？」
参加者：普段ASTの面倒をよく見ております、金子と申します。今ASTをまたトラバースするのかと思ったんですけど、その話ももうちょっと詳しく聞きたいです。どんなアーキテクチャになりそうか、いつ頃ぐらいから着手したいか。
笹田：アーキテクチャとしては1.8の頃のをもっと進化したものになると思うんですけど、VMにした時にだいぶ仕様を整理したんですよね。それを踏襲したらまた違うノードツリーになると思っていて、アーキテクチャとしては1回ユニバーサルパーサとしてYARPが出すノードツリーではなくて、さらにそこから1段ぐらい変換した実行用のノードをもう一回作り直す感じにはなるかなと。
参加者：構造としての構文木は割とピュアに構文に寄せておいてよくて、その後実行する前に一旦トラバースで変換処理とか最適化を挟むレイヤーを入れた上で、実際に実行するようになると。
笹田：という風にするといいと思います。
参加者：そのペナルティも結構あると思います。
笹田：先ほど話した論文で提案されているのは、頻出するノードのパターンをいくつか特殊化して持っておいて、置き換えていくのをやっていくと、どんどんビッグノードができてくるんですよね。さらにそこからJITコンパイルする、これはTruffleRubyがやっていることですけども。VMよりももしかしたら速いかも、いや速くないかも。
あとは論文に出ているかわからないけども、実行時コンパイラでもトラバースする部分だけ、コールする部分だけをピックアップして並べると実は同じ構造ができるみたいな話があります。ある種のJITコンパイラがツリートラバーサルのインタプリタから簡単に作れるっていうのは自明に得られる話ではあるので、それをJITコンパイラでいろいろやらなきゃいけない。例えばYJITはすごいたくさんのことをやっているんだけど、難しいことはしないである種の特定のパターンだけ入れ替えるっていうことをやると、YJITまではいかないんだけれども最初からソコソコ高速なもの、インタプリタよりも速いものができるかもしれない。最初からその最適化したパターンに変えられるんですよね。.NETだとそういうアーキテクチャなんですけども、そういうのを用いるとさっきの初速が速いみたいな話がうまくいくかもしれないなと、野望としてはあります。ただまだ妄想レベルなので、Rubyでやるかはわかんないんですけど、もう一回考え直すのをやらなきゃいけないなと。
細かい話なんですけど、Wasmを対応するっていうのに対して、setjmp/longjmpっていうのをCで使ってるんですけど、Wasm対応を実現するために難しいことをやってるんですね。ツリートラバーサルで、Resultみたいなのを使うとsetjmp/longjmpをなくせるわけじゃないですか。作り直してみたら、もうちょっとWasmフレンドリーなRubyにならないかなとか。いろんな側面の野望をがっちゃんこしてできないかなっていうので悩んでいます。
いつからやるかみたいな話はまだアイデアはないんですけども、少し落ち着いたらやりたいなと思っています。多分1〜3年くらい後かな。その頃にはパーサの周りが落ち着いてるといいですね。
参加者：ここにぶつかってくると面白いなと思ったけど、とりあえずはこちらに集中してできそうなのがわかりました。ありがとうございます。
遠藤：ASTレベルでのインライニングとかやる見込みですよね。コールの呼び出し、メソッド呼び出しがあったら、単純にそのメソッドの中身に直接置き換えてしまう。バイトコードだと、命令列を1箇所の命令に埋め込むってやると、命令を移動させなきゃいけないとかっていう単純にはメモコピー的なことやらなきゃいけないのがだるいけど、ツリーであればそこの参照先を変えるだけで理論上はいけるっていうのが。
笹田：メソッドコールだとそれなんだけど、さらにRubyってブロックがあるので。ブロックのインライニングとかがもしかしたらやりやすいかなとか、そういうのもありますね。
遠藤：YARPなりparse.yをそのまま解釈するっていう本当にRuby1.8の時のようなものにはならないんじゃないかとは思いますね。一回変換は必要だと思う。ちなみにRuby Wasmのためにとsetjmp/longjmpを取り除くっていうのは、正直些細な話だと思ってて。保守的GCのためにどうにかするっていうことの方が圧倒的に大きいと思います。
笹田：なるほどね。
遠藤：setjmpを使ってるのも、大域ジャンプのためにとsetjmp/longjmpを使ってるというよりは、レジスタの中身を無理やりはかせるために。
笹田：それは今でもlongjmpを使ってるじゃん。
遠藤：longjmpをするのはそれはそれで解決しなきゃいけないけど、Wasm側でも大域ジャンプをちゃんと対応したっていう動きがあるっていうことを話している。
笹田：C++のやつね。
遠藤：例外を普通にサポートしたいっていうのはあるので、そっちの方はひょっとしたらWasmの方が歩み寄ってくれるかもしれなくて、どちらかというと保守的GCの方は絶対歩み寄ってくれないので。
笹田：Wasmに関してはそうかもしれない。
遠藤：すげえ細かい話をしました。
笹田：だから、あなたのRailsを明日3%速くしますみたいな話はあまりしてないですね、すみません。それはShopifyがしてくれるので。3%良くなっていくっていうのは素晴らしいことだけれども、そこからは出てこないわくわくする、そんな風になったらすごいかっこいいねみたいな仕事ができたらいいなというのがありますね。
質疑応答「TypeProf周りが落ち着いた先の未来の野望は？」
参加者：遠藤さんはTypeProf周りが落ち着いた先の未来の野望はあるんですか？
笹田：開発体制とかそういうのじゃなくて。
参加者：委員会とかじゃなくてRubyの技術的なコミットということに関して。
遠藤：Rubyの技術的なコミット…そうですね。TypeProfが落ち着くのかっていう話がまずありますかね。
参加者：まだあんまり考えている余裕ない感じですか。
遠藤：正直全然ない。
参加者：わかりました、ありがとうございます。
笹田：RailsでTypeProfを動かせたら大成功だと思うんですけど。
遠藤：すぐにはできないと思うんですけど、大きなマイルストーンですね。
笹田：現状ではどれくらいできそうですか？
遠藤：TypeProfを使って開発するっていうのを最近はやっていて、それをRubyKaigi 2023の時にも話したんですけど。定義ジャンプが便利なのはすごく感じています。メソッドをコントロール押しながらクリックすると定義に飛べるんですよ。
笹田：他の言語でそれって結構前からできてるんじゃないですか？
遠藤：普通なんだけど、Rubyではなかなか難しいみたいなのがあって。
笹田：Rubyはとくに難しいですか。
遠藤：TypeProfは正直他の言語で追いつくための活動っていうのが大きいですね。だけど正直舐めてましたね、それが実際にできるとめちゃくちゃ便利だっていうのは自分自身でよくわかるようになって。
Ruby3.0にバンドルしたTypeProfは正直ドッグフーディングがだいぶ後の方になっちゃったんですね。まずはRubyの全機能をサポートして一通りできてから試そうと思ってたんですけど、そうした後だとちょっと手遅れだったというか解析が遅すぎてにっちもさっちも行かなくなった。
今回は今年の初めに解析性能を気にしながら作り直すとなってからは、Rubyの全機能をサポートするより前にTypeProfを動かすために必要な機能だけ、Rubyの小さなサブセットをサポートすることを優先しました。それによって2、3か月でTypeProf自身をTypeProfで解析できるようになって、定義ジャンプとかメソッドの保管とかがパッパッとできるようになって、めっちゃ便利だっていうのがわかってきました。
今度は逆にRubyの他の機能をサポートできてないので、みなさんのRailsアプリとか全然解析できないし、それでなくてもちょっとしたタイププログラムでもまだまだ動かないものパターンマッチを使ってて動かないとかあるので、その辺をちゃんとサポートしていって使えるかどうかなっていうのを試さなきゃいけないっていうフェーズです。
笹田：Rubyのやつがうまくいったとして、Railsにっていうのは技術的なジャンプがあるんじゃない？
遠藤：そこからまたジャンプがあるんですよね。Steepの方でrbs_railsとかRailsのための型、RBSのスタブというか型生成するっていうところはそちらでやってもらってるので、その辺に乗っかればいけるといいなと思ったりはしていますが。正直まだ具体的にいけるっていう見通しがたってるわけではないですかね。
参加者：Steepもまだ結構きつかったですね。
遠藤：そうですよね、わかります。
笹田：その辺で10年ぐらい経ちそう？
遠藤：10年経ってるとさすがに…
笹田：飽きちゃう？
遠藤：自分が飽きるというよりは、それこそ他の言語にどんどん置いていかれすぎるので、もうちょっと頑張らないとなと思いますね。
笹田：TypeProfに解析しやすい書き方をみんながするようになるのかね、そうすると。
遠藤：TypeProfで解析しやすいように書いてもらうことは、どうしても発生すると思うんですけど。今はだからこう書いてくださいみたいなのを言えるほどの知見が自分自身に貯まってないのでわからないです。そういうことはあるかもしれないです。何の話だったっけ？
笹田：野望。
遠藤：野望、そうですね。みんないろいろやってくれるからいいんじゃないですか。楽しいなと思ってます。僕はそういう大きい話以外にも脆弱性の報告の対応をするとか、バグオープンにチケットのトリアージをやるとかそういう細かい仕事も好きでやっています。そういうところを止めないようにやっていきたいなと思っています。
笹田：今の開発をさらに加速するサポートするという話ですかね。
遠藤：そうですかね。
笹田：委員会の話も合わせて。
遠藤：実際本当に委員会制はどうなるのか分からないですよね。
笹田：楽しみですね。
遠藤：怖いですね。
質疑応答「VMを考えるにあたって他に考慮していることは？」
参加者：VMを考えるにあたって他のここも考慮している、例えば型であったり何か他の別の部分とかを考慮しているところはあるんですか？
笹田：VMを開発するときに考えていること。さっき作り直すみたいな話をしたんですけど、Cでいいのかなって。みなさんがいろんなご意見があるのは重々承知で私自身はRustの知見が全然ないんですけれども、ただC99が24年前かみたいな、そんなレベルで。どうしようかなみたいな話もありつつ、あと大枠としてはGCの話と実行形の話、それから並列並行の話がよくある話なんだけど、面白いところだと何かあるかな。
Wasmって一つ面白いなと思っているのが、少なくとも現在の仕様だとアーキテクチャ的に実行時コンパイルができないんですよね。なのでインタプリタを速くするとそれで喜ばれるところがあるので、そこはもしかしたら作っていく上で、JITじゃないくらい速くするっていうチャレンジは面白いなと思いますね。
遠藤：ぶっちゃけると逆なんですよね。RubyWasmを考慮してそういうことができたらと言ってたけど、本当は逆で先日ツリートラバースインタプリタを作り直したいっていうのがあって、それがたまたまRubyWasmだとうまくいくというか。RubyWasmのためになるっていう口実があったから見つかったっていうのがぶっちゃけたとこでしょ？
笹田：いや！（笑）
遠藤：Wasmが本当に主流になるかどうかも正直まだわかんないので、それのためにっていうのはなかなかチャレンジングな判断だなという感じがしますが。
笹田：そうだね。
遠藤：でもブラウザの上で動くのはやっぱり楽しいよね。
笹田：楽しいよね。もうちょっと簡単に使えるといいよねと思って。今サイズが10MBで、ダウンロード時間を考えると、みなさんのWebサーバでWebアプリでパッと使えるかっていうとなかなかあれなんですが。後何個かうまくいくと面白い世界にならないかなっていうのはありますね。
遠藤：Rustで書き直すんですか？
笹田：勉強しなきゃ。
遠藤：Rustの勉強してたんですよね。さっきシュっと、Resultとか使えばって言ってたけど、今日RustのResult型を僕が教えてあげましたっていう。
笹田：さすがにResultは知ってたよ。
遠藤：Resultの全体がわかんないとか言ってたじゃん。
笹田：Rustでの文法がわからなかった。概念は知ってた。
遠藤：概念ね。
笹田：Scalaとかで理論は知ってる。
遠藤：Rustの型パラメータの説明をさせていただきました。
笹田：読み方がわからなかった。
質疑応答 「refinementを消したいか？」
参加者：笹田さんが委員会制の委員長になったらrefinementを消したいと思いますか？
笹田：いい質問ですね。いやーだから委員長になれないと思いますね、消しちゃうから。
遠藤：refinementを消すとかもアグレッシブな話ですね。
笹田：ぶっちゃけ消すの難しいよね。
遠藤：そう、正直わかんない。
笹田：だってまつもとさんでさえもう機能を消せないじゃん。この間3.2で入ったから3.3で消そうってのがあったんですよ。だけどさすがに2.0では入ったやつを4.0で消しましょうってなかなか言えないと思う。
遠藤：大変な話だと思いますが。
笹田：昔よりも、みんなから文句言われるってわかってるから。
遠藤：非互換はね。
笹田：消すことに対して、すごく慎重になっている気はします。
遠藤：ただrefinementは本当に二級市民的な扱いを受けているので、実装上でだrefinementを使った時にどんなに遅くなってもいいやっていつも言ってるんですよね。
笹田：動かないよりはいいんじゃない？この間3.3で速くしたのも。
遠藤：そうですね、文句言われ続けたので。
笹田：難しいと思うんですね、使うの。
遠藤：使うのが難しい。使ってほしくないじゃなくて。これ以上悪口はやめよう。
笹田：好きな機能、嫌いな機能、いろいろありますよね。
質疑応答「嫌いな機能は？」
参加者：Refinement以外で嫌いな機能はなんですか？
笹田：嫌い…トップレベルのevalは消したいですよね。
遠藤：絶対ダメ、絶対ダメ。
笹田：bindingをキーワードにしてBinding#evalを残したいっていうのは昔から思ってて。つまり今トップレベルのevalは、evalがevalであるかわからないので。例えばbindingメソッドをキーワードにしておけば、そこはevalが来るから気をつけろみたいな。実際JRubyではbindingとかevalメソッドを特別扱いしているそうです。だけどRubyってエイリアスがあるのでevalじゃなくて、hogeっていうメソッド名にするとevalができちゃうんですよね、とかそういう変な機能ができないようにしたいなって昔から思ってはいるんですけれども、今更変えられないですよね。難しいと思います。なんかある？
遠藤：思いつかないなと思って。
笹田：Rubyの機能はみんな素晴らしい。
遠藤：使わない機能はあるけど。
笹田：キーワード引数で整理したじゃん。
遠藤：それでもまだ足りなかったですね、もっと粉砕したかった。
笹田：Ruby 3.0でみなさんがアップデートするのに苦労されて、そちらのkamipoさんがすごい活躍されて、キーワード引数の周りがRailsで救われたのは彼のおかげです。
遠藤：ありがとうございます。
笹田：その元凶を作ったのが遠藤さん。
遠藤：いやー、きびしかった。
笹田：大変でしたね。何度もミーティングしてましたもんね。
遠藤：あれは大変でしたね。主に議論したい相手というのがアメリカにいるJeremy Evansとスイスかベルギーにいるeregon、Benoit Dalozeの3人。日本とヨーロッパとアメリカって3大タイムゾーンなんですよね。直接話そうとすると誰かが真夜中に話さなきゃいけないので基本的にはSlackとか非同期のコミュニケーションでやるんですけど、寝る前に送っておいて、次の日の朝には返事が来てるので、それに対する返事を考えなきゃいけないっていうのを毎日繰り返すみたいな感じでやってましたね。
笹田：あとkamipoさんもあったけど、Railsコミュニティとの対話とかしてたよね。あの頃。
遠藤：（kamipoさんに向かって）ありがとうございました。でもみなさん乗り越えて素晴らしい。
笹田：雇用を創出したかもしれない。
遠藤：そう言ってる人はよく言ましたよね、この非互換は雇用を創出するみたいな。別にそうしたいわけじゃないんだけど。みなさんが対応してくれたおかげでなんとかなっているのかなと思います。
笹田：一番最近の大きな機能削除はそれでしたよね。
遠藤：非互換ですかね。削除はしてない。
質疑応答「Rubyがどうなっていると嬉しい？」
参加者：藤村さんの方に質問なんですけど、藤村さん個人としてRubyこうなっているといいなみたいなの二人にフィードバックとかありますか？
藤村：逃げっぽい答えになっちゃうんですけど、この二人に STORES でRubyを作ってもらうと我々の想像する延長線上じゃないものになるに違いない、そうしてもらいたいです。そうなると面白いじゃないですか。
2030年の話をしてましたけど、2030年にRubyが最新のプログラミング言語になったら面白いじゃないですか。CTOとして採用競争力ができるし、プログラマとしても仕事が面白いので、そうなってくれるといいなっていうのは思っています。それがRactorなのか、Type Systemなのかはわかんないけど、そういうことが起きるはずだと思っています。
笹田：構文をタブで制御するみたいな。
藤村：聞いたことある。
遠藤：endがなくても。
笹田：そういうのじゃない。
遠藤：ぶっ壊す。
笹田：ぶっ壊さないで。
遠藤：ぶっ壊れてるでしょ。
藤村：延長線上のはShopifyさんとかがすごい頑張ってくれていて、僕らもただ乗りさせてもらおうと思ってるので。という感じです。そろそろお時間ですよね。STORES.rbのパートを終わろうと思います。ありがとうございました。（完）
Rubyエンジニア募集中＆イベント情報はXをチェック
STORES ではRubyエンジニアを募集しています。
また、STORES ではさまざまなイベントをオンライン、オフラインで開催しています。 イベント情報はXで投稿していますので、 https://twitter.com/storesinc_techのフォローをお願いします！
*1:経営陣と1on1ができるオープンドアという制度
