シェア
はてブ
お店のデジタル化を支援するSTORES 株式会社（以下、STORES）は、Rubyコミッターの笹田耕一（@koichisasada）さんと遠藤侑介（@mametter）さんの両名を社員として採用しました。笹田さんと遠藤さんはフルタイムのRubyコミッターとして STORES に入社し、Rubyの機能改善や品質向上のための仕事に専念します。
どのような経緯で、両名は STORES への転職を決めたのでしょうか。そして、今後の具体的な活動内容とは。笹田さんと遠藤さんにお話を伺いました。
- 「6月は2人で一緒に、フルタイムRubyコミッターとして働く道を探ろう」
- 笹田さんが取り組む並列並行処理の改善
- 遠藤さんが取り組む静的型解析
- 世の中のニーズと本人のモチベーションが合致して生まれる、奇跡的なキャリア
「6月は2人で一緒に、フルタイムRubyコミッターとして働く道を探ろう」
――転職活動どうもお疲れさまでした。まずは、STORES に入社した経緯について知りたいです。
笹田：私と遠藤さんは前職でもフルタイムのRubyコミッターとして働いていましたが、残念ながら業績不振により大規模なリストラの対象となりました。リストラが発表されたのが2023年6月で、そこから2人で話し合ってまずは転職活動の戦略を立てたんです。
次の会社でもフルタイムRubyコミッターとして働けるのがベストだから、6月中はその仕事に就けるように2人で一緒に転職活動をしよう。もしダメだったら7月は2人で別々に転職活動をしようという話をしました。
――2人で一緒に転職活動をするのは珍しいケースだと思うのですが、自分と近い立場で働いている人がいるのは、フルタイムでRubyの開発を続けるうえでプラスになるものですか？
遠藤：1人だけでフルタイムのOSS活動をしていると、どうしても会社の業務から遠い立場なので孤独になってしまうんです。でも、自分の身近に相談できる相手がいることで、気持ちの面でも楽になりますし、相手から何かを学ぶこともできます。実際、笹田さんからはソフトウェア開発に役立つような知識をよく教えてもらえます。
笹田：方針を決めた後、SNSで転職活動中である旨の投稿をしたところ、大きな反響がありました。フルタイムRubyコミッターは会社の売上に直接貢献する立場ではないので、このポジションを次の会社でも維持できるのか不安でした。でも、ありがたいことに多くの企業が「ウチで働きませんか」とお声がけしてくださったんです。それだけではなく、自分たちから申し込みをした会社もあります。遠藤さんと一緒にたくさんお話をさせていただき、STORES で働くのが一番良いと思ったので入社を決めました。
――職種を変えてアプリケーションを開発するエンジニアになるなどの選択肢もあったと思うのですが、フルタイムRubyコミッターを続けたいと思われたのはなぜですか？
遠藤：純粋に、Rubyの開発がめちゃくちゃ楽しいんですよね。STORES は「Just for Fun」をミッションとして掲げているんですが、まさにこの言葉の通りだなと思います。フルタイムRubyコミッターになる前は、趣味としてRubyの開発を続けてきました。睡眠時間や土日の時間を削って取り組むくらい、夢中になってやってきたんです。それほど楽しいことを仕事にできるのは、幸せなことでした。
よく「好きなことを仕事にすると、嫌いになってしまう」と言われることもありますが、私の場合はそれが全く当てはまりませんでした。前職では6年近くRubyの開発を続けてきましたが、いまだに好きなままでいます。
――就職先としてさまざまな選択肢があったなか、STORES に決めた理由は何ですか？
笹田：まず、STORES は知っている人がたくさんいたんですよね。Rubyコミッターの卜部（@shyouhei）さんや前職時代の上司だった小室（@hogelog）さん。他にも、前職からSTORES に転職した方もたくさんいます。そういった意味で親和性の高い会社でした。
遠藤：STORES のCTOである藤村さんと面接をした際に最も印象的だったのが、「とにかく楽しくRubyの開発をしてほしい。会社にとっても社会にとっても、それが一番良い結果になるから」と言ってもらえたことです。
笹田：他の会社の面接では「社員教育もしてほしい」とか「広報活動にもある程度力を入れてほしい」と言われるケースが多かったですよね。
遠藤：STORES の場合は「本当にそれでいいんですか？」と逆にこちらから聞き返してしまうくらい、思いきりが良かったです。「それでいいんです」と藤村さんが力強く断言してくれて、すごく安心しました。
笹田さんが取り組む並列並行処理の改善
――笹田さんは前職時代から、並列並行処理の改善に注力されてきました。これまでの活動内容について教えてください。
笹田：キャリアの初期の頃の話をすると、まず大学生の頃にRubyのバーチャルマシンを設計・開発する研究をしていました。そして2007年くらいのRuby1.9の頃に、スレッドの仕組みを作っていたんです。
その後、GoやElixir、Rustなどのプログラミング言語が登場しました。これらの言語は並行並列処理が得意でして、Rubyにもその良さを取り入れられないかと考えて、ずっと研究を続けてきました。方針が概ねまとまったのが、2016年くらいです。
その後に前職に移り、並行並列処理を実現するための設計・開発に注力して、2020年にリリースしたRuby3.0でRactorを試験的に導入しました。RactorはRubyプロセス内で利用できる並列処理の仕組みです。
プログラミング言語において処理の高速化を実現する場合、スレッドを用いるケースがよくあります。そして、あるオブジェクトを複数のスレッドで共有して読み書きをする場合には、意図せぬ状態の変更を防ぐために必ずロックが必要になります。
ですが、人間はコーディングをする際、オブジェクトをロックすることをよく忘れるんですよね。もしくはロックをしたつもりが適切にロックできていないこともあります。こうした事態を防ぐために「ロックをする範囲をいかに減らすか」を考える必要があります。
笹田さん
この問題を解消するために、世の中にあるシステムではさまざまなアプローチを用いています。たとえばUnixなどのプロセスでは、領域そのものを完全に分けてしまいます。ElixirやErlangなどの言語ではすべてのデータをImmutableにすることで、スレッド間でImmutableなデータしか共有できないようにしています。
Rubyならどういったアプローチが取れるだろうと考えた末に「Immutableなデータしか共有できないようにする」なら、なんとかなりそうだという発想でRactorを設計しました。イメージとしてはUnixなどのプロセスの仕組みに近いのですが、Ractorの場合はスレッド間で共有可能な部分は共有しますし、たとえMutableなデータであってもロックを必須とするなら共有可能にする、というところがElixirやErlangなどと近いです。
ただ、Rubyの場合は言語仕様の都合上「定数にMutableなオブジェクトを入れる」というケースが普通にあり得るので、この場合に複数のスレッドがMutableな情報を参照できてしまうという課題があります。つまりRubyの言語仕様そのものを制限しなければ、Ractorのための隔離が実現できないんです。そのためプログラムの互換性に問題があります。
また、それ以外にもいくつかの課題があります。Ractorでは既存のRubyがそうであるように、1:1スレッドを踏襲しています。Ractor内に1つのRubyスレッドを作るのですが、それが1つのネイティブスレッドを要求します。つまり、10万個のRatorを作ると10万個のネイティブスレッドが発生してしまうため、システムがうまくスケールしません。
また、現在の設計ではガベージコレクションを行う際にすべてのRactorの動作を止める必要があり、その状態で唯一のネイティブスレッド上でガベージコレクションが実行されるような仕様になっています。これもシステムのスケールの課題を発生させています。
こうした問題を解決するために、1:1スレッドモデルではなくM:Nスレッドモデルを導入できないか、という試みを行っています。これがMaNy Project*です。そして、Ractorごとに並列でガベージコレクションを実行するRactor local GCという仕組みが実現できないかを試行錯誤しています。これらの試みがうまくいけば、実用可能な機能になるのではないかと考えています。
*…MaNy ProjectやRactor local GCの詳細は https://techlife.cookpad.com/entry/2023/08/31/152511 にて解説されています。
――M:Nスレッドモデルは、Goでも同様の手法が用いられているそうですね。
笹田：はい。概ねGoと同じ仕組みを導入しようと考えています。もともと学生の頃から「M:Nスレッドモデルにすれば、もしかしたらRubyの処理が高速になるかもな」とぼんやり考えていました。でも、本当に性能が出るのかよくわからなかったんです。でも、Goがその設計を取り入れて成功したので、「ならばRubyでもいけるかな」と考えました。
遠藤：M:Nスレッドモデルって昔は「システム設計で誰もが考えるけれど、うまくいかないもの」の典型例でしたよね。でも、解く課題を限定することで、この機能の導入を成功させたのがGoでした。
遠藤さんが取り組む静的型解析
――では次に、遠藤さんが近年取り組まれている静的型解析についても教えてください。
遠藤：前職でフルタイムRubyコミッターで働くことが決まった際、ちょうどその頃まつもと（ゆきひろ）さんが「Ruby3.0に静的型解析を入れる」という宣言をされていました。そこで、まつもとさんや静的型解析に取り組むsoutaro（@soutaro）さん、pocke（@p_ck_）さんなどと、どうやってその機能を実現するか議論をしました。
正直なところ、Rubyは開発者体験として他の言語に後れをとっている部分があります。具体的には、エディタやIDEなどでのコード補完に課題があります。それを補助するために、Rubyのコードに型定義情報を提供するRBSという技術が存在しています。soutaroさんとpockeさんは「他言語のような開発者体験をなるべく早く実現すること」を目標に、RBSを用いることでエディタやIDEなどの支援をするSteepというツールを開発しています。
ですが、「型宣言を書かなくてもある程度の検査や編集支援をしてほしい」というのがまつもとさんの意思なので、私は別のアプローチを用いました。解析対象のプログラムを型レベルで実行することで、メソッドが受け取ったり返したりする型やインスタンス変数に代入される型などを推論するTypeProfというツールを開発しています。
Ruby3.0にTypeProfがバンドルされたので、ある程度の成果は出せたと思います。ただ、開発者体験を向上させるという意味で言えば、まだ全然足りていないんですよね。コード補完を行うためには、開発者がコードを入力している最中に、その内容をスピーディーに解析する必要があります。
遠藤さん
その処理を実現するためには、既存のTypeProfの型推論方式では遅すぎて実用できません。開発初期の頃から「大規模なアプリケーションでは性能が出ないかもしれない」と思っていたんですが、徐々に「数千行ほどの中規模なアプリケーションでも厳しい」とわかってきました。
そこで現在は、プログラムの解析方法を抜本的に見直しています。具体的に言えば、JavaScriptでも同様に型解析をするための方法が研究されており、そのなかにTernという型解析ツールがあります。これはコードをデータフローグラフに変換して型推論をする方法なんですが、これならば規模の大きなアプリケーションでも良い性能が出そうだとわかったので、Ternの手法をベースとしてTypeProfを作り直しているところです。
この作り直しの作業では、最初のバージョンのTypeProfの開発の反省点を活かして改善をしています。最初のバージョンでは「どのような解析を行う必要があるか」の調査・分析にかなり時間をかけており、TypeProfを実際にドッグフーディングするのは後半のフェーズになってしまいました。その結果、性能に問題があると判明してもやり直すことができなかったんです。
今回はその反省を活かして、「なるべく早めにドッグフーディングをやろう」と意識しています。まずは必要最小限のRubyの機能だけに対応して、開発の初期フェーズからTypeProfをドッグフーディングすることを心がけています。2023年1月から作り直しに取り組んで、2月か3月にはドッグフーディングできる状態になりました。
自分でもびっくりしましたが、すごく便利なんですよね。今回のバージョンにはかなりの将来性を感じています。とはいえ、まだまだ対応できていないRubyの機能がほとんどなので、それぞれに対応するための設計・実装を今後進めていきたいです。
世の中のニーズと本人のモチベーションが合致して生まれる、奇跡的なキャリア
――笹田さんも遠藤さんも、他言語の設計をうまく取り入れていることが特徴的ですね。どのような方法で他言語の仕様をキャッチアップしていますか？
笹田：たとえば自分が扱っている専門分野に関して何かの機能を実現する際に、他の言語ではどうやって実現しているのかを必ず調べるようにしています。
遠藤：笹田さんはもともと研究者としてキャリアをスタートしているので、何かを調査する際のスタンスがしっかりしていると感じます。型解析の情報についても、笹田さんからよく「この言語だとこうやっているらしいよ」と教えてもらえて、すごく役に立っています。
自分の場合は、いろいろなプログラミング言語を実際に使うように心がけています。それほど有名ではない言語まで含めて、確実に100言語以上は触っているはずです。そのなかでも特に有名な言語については、GoであればWSL用のssh-agentツールを書いてみるとか、RustはWebAssemblyに強いのでブラウザ上で動くAIオセロゲームを書いてみるなど、ある程度の規模のソフトウェアを作ることで、その機能を学ぶようにしています。
――今回の転職に関連したお話も伺います。企業がフルタイムのOSSコミッターを雇うことで、プログラミング言語やライブラリ、フレームワークなどの発展にはどのようなプラスの影響があると思われますか？
遠藤：OSS開発者側にとっては、良いことしかないと思っています。開発者がそのプロジェクトに割く時間をたくさん確保できますから。OSS開発ではコードを書くだけではなくて、機能の設計方針やバグの修正方針などを一人でじっくり考えることや、詳しい人と相談することなどが必要なんです。本腰を入れて活動に取り組むには、かなりの時間が必要になります。
趣味でOSS活動に取り組む人は、寝る時間を削ったり土日を費やしたりと、プライベートの時間を割くことになります。その結果、OSSのコードの品質または開発者の生活のどちらかが犠牲になりやすいんです。燃え尽きてしまい、活動を辞めてしまう人もいます。でも業務としてOSS開発に取り組むと、当然コードの品質は向上しますし開発者もゆとりを持った生活を送ることができます。
――OSS開発者の生活を守る意味でも、コミッターを雇用することは重要なのですね。
笹田：私がまだ独身だった時代は、すべての時間を自分のために使えました。ですが、現在は結婚して妻や子どもと生活するようになったので、自分の時間をなるべく家族のために使いたいと思っています。おそらく、業務としてOSSのコミッターができなければ、Rubyの開発を続けるのは無理だったんじゃないかと思いますね。特に私の場合は、他のエンジニアと比べると手が遅いほうなので、隙間時間を利用してコードを書くことが苦手です。
――今後、遠藤さんや笹田さんに憧れて「自分もフルタイムのコミッターを目指したい」と考えるエンジニアも出てくると思います。そういった方に向けてのアドバイスはありますか？
笹田：大切なのは第一にコミッターたちとのコミュニケーションだと思います。既存のOSSのコミュニティ内で周囲の人々からの信頼を得て、活躍できる場を広げていくプロセスが必ず必要になります。その活動をまずは丁寧にしていくと良いです。そのうえで、自分の得意領域をアピールしていくための広報活動が重要になります。私の場合は、Webの媒体やSNSなどで活動内容をなるべく広報するように心がけてきました。
また、基本的にはやりとりをするOSSのコミッターが海外の方であるケースが多いと思うので、言語や文化の違いなどもうまく乗り越えていく必要はあると思います。幸いなことに、Rubyの場合は日本人のコミッターが多かったため、言語や文化などの要素がハードルにならなかったという意味で、稀有なOSSでした。
遠藤：フルタイムのOSSコミッターって、正直なところ目指してなるものではないと思います。フルタイムのOSSコミッターが成立するには2つの条件があります。まずは、そのOSSのプロジェクトが社会的に価値を認められており、企業がお金を出してでも開発を支援したいと思ってくれていること。さらに、本人がそのプロジェクトをフルタイムでやりたいくらいに大好きであること。前者については運の要素もかなり大きいです。
Rubyは幸運なことに世界中の人が使ってくれて、さまざまなサービスで価値を発揮できたので、私たちのような働き方を実現できました。だから、「こうすればフルタイムのOSSコミッターになれる」と断言することは難しいですが、笹田さんの言うようにOSSのプロジェクトに貢献して、かつ情報発信を続けることは必要だと思います。
もしフルタイムのコミッターになれなかったとしても、自分の好きなOSSを見つけてコントリビューションすること自体は確実に本人のためになるので、どんどん取り組むことをおすすめします。私もかつて趣味でRubyに関わっていた頃は、これが仕事になるなんて全く想像していなかったですから。
笹田：若い人に向けたアドバイスがあるとすれば、「この領域なら○○さんが強いですね」と周囲から言われるような、自分の看板になるスキルを身につけてください。確実に、その後のキャリアで有利になると思います。
――最後に、お2人の考える「Rubyの魅力」についてお話しください。
笹田：Rubyはチャレンジングなテーマがたくさんあって、かつ私たちのような開発者に容赦がないんですよね。どういうことかというと、プログラミング言語のなかには「コンピューターリソースを効率よく使うために、コンピューターに人間が寄り添う」というスタイルのものもあります。
一方、Rubyは言語設計において「人間が書きやすいようにする」というコアな思想があり「速く動くように頑張るのはRubyのほう」なんです。Rubyのほうとはつまり、処理系開発者が努力するということなんですが。解決すべき課題がたくさんあり、やればやるだけ成果につながるので、Rubyは私にとって魅力的でした。日本人のコミッターが多いので日本語で議論できる点も良かったです。
遠藤：これだけ長い間使っていても「こんな落とし穴があったのか」とか「こんな特徴があるんだ」といった発見がいまだにある、奥が深い言語だと思います。ときおり、「プログラミング言語は課題解決をするための道具であり、特定の言語にこだわるべきではない」とおっしゃるエンジニアもいますが、私は「プログラミング言語は単なる道具ではない」と思っています。もし、たとえ道具なのだとしても、1つの道具を使い続けなければ見えない境地が間違いなくあるはずです。Rubyの開発者である私たちは、Rubyを「みんなが選び続けてくれる言語」にするために、これからも活動をしていきたいです。
取材・執筆：中薗昴
撮影：漆原未代
