こんにちは！
株式会社グロービスのデジタルプラットフォーム（GDP）部門のGLOPLA事業開発室のエンジニアをしております、太田です。
RubyKaigi2025に参加してきました！
とても楽しくて、あまりにも楽しかったのでこうしてテックブログに書くことができて嬉しく思っています。
それぞれとても長く書きそうなので、ピックアップをして記載をします。
現地の雰囲気が少しでも伝わってくると嬉しいです！
基調講演
RubyKaigiのオープニングを飾るセッションは、ima1zumiさんによる文字コードに関する基調講演でした。
愛媛県出身というima1zumiさんは、まず「Welcome!」と温かく歓迎してくださいました。そして、最近Rubyコミッターになられたとのことで、会場からは盛大な拍手が送られました。
この基調講演では、文字コードの歴史が、なんと狼煙による伝達の時代まで遡って語られました。そこからASCII、EBCDIC、そしてUnicodeの登場へと話は進み、古くから存在するこの概念に対して、ima1zumiさんがなぜ文字コードに情熱を注ぐようになったのかが語られました。
熱中していることを愛情たっぷりに説明する様子は、会場の聴衆の熱い視線からも伝わってきました。
非常に興味深かったのは、IRBで「👨👩👧👦」という家族の絵文字に見つけたバグを修正したというエピソードです。IRBでこの絵文字を入力し、バックスペースを2回押すとクラッシュ(nil can't be coerced into Integer (Typeerror)というエラーが発生)
するというものでした。見た目は1文字ですが、実際には7つのコードポイントが組み合わさってこの文字を形成しているとのこと。
バグの原因のところがはっきりと理解できなかったので発表者にお聞きしたかったのですが、会期中になかなか出会うことができず、、！
RubyKaigiが終わって社内で議論してみたところ、おそらくバックスペースを2回押すことによって末尾がZWJという状態になり、IRBがZWJにつづく何かしらのintegerの値を求めたがnilであったためにエラーが発生したのだろうという話をしました。
また、上記のスライドを参照するとZWJと👦で合計3マスを持っていますが、なぜバックスペース1回ではエラーが発生しないかというと、おそらくその時点では何かしらのintegerを持っており、ZWJとしてはエラーが起きる条件にはなかったのだろうと推測をしました。
（頭の中では👦が顔半分になっているのを想像しました。）
このバグの修正には、UnicodeのGrapheme Clusterという概念が用いられたそうです。Grapheme Clusterについて初めて知ったのですが、複数のコードポイントからなる文字を、人間が認識する1つの文字として扱うという概念とのこと。Unicode、本当にすごいですね。
また、Rubyが使用しているUnicodeのバージョンが古いことに気づき、それをアップグレードしたという話も興味深かったです。Ruby内部でのUnicodeのバージョン管理はどのようになっているのだろう？どうやってアップグレードするのだろう？と疑問に思っていたので、ima1zumiさんが実際に行った作業の説明は非常に参考になりました。
全体を通して、非常に面白く、学びの多い基調講演でした。
Introducing Type Guard to Steep
Steep Gemの機能である「Type Guard」に関するセッションです。Steepは、Rubyの型検査を支援してくれるGemです。
現在、Rubyで型検査を導入しているアプリケーションはまだ少ないと感じていますが、このセッションは、実際のRubyアプリケーションに導入する際のイメージが具体的に湧いてくる素晴らしい内容でした。
セッションのあと
セッション後、ランチをご一緒させていただいた方から「グロービスでは型検査を導入していますか？」と質問されました。少なくとも私が関わっているGLOPLAでは導入していません。
先ほどのセッションで導入のイメージは湧いたものの、実際に本番運用しているアプリケーションに導入するとどうなるのか、まだ具体的に想像できていませんでした。導入を考えると、当然メリットはあると思いますが、記述量が増え、大変そうだという印象が先行しました。また、既存のアプリケーションへの導入は特に困難だろうというイメージも持ちました。
しかし、それは単に今まで型を書くことに慣れていないだけなのかもしれないとも思いました。GLOPLAではRSpecを厚く記述する方針を取っているため、それがある意味型検査に近いことなのかもしれないな、とも思いました。
そんなことを一日中ぼんやりと考えながら迎えた一日目の夜、Roppongi.rbのDrinkUpに参加させていただいた際に、偶然にも本番運用しているアプリケーションにSteepを導入しているという方にお会いしました。
これは非常に幸運なことだと思い、先ほど抱いた疑問を率直にぶつけてみました。すると、その方は逆に型を書くことに慣れてしまい、型を書かないとむしろ少し不安だと話していました。例えるなら、Reactの開発でTypeScriptを書かない感覚に近いとのこと。確かに、そう考えると少し不安になるかもしれません。非常に分かりやすい説明でした。
さらに、現状RSpecを厚く書いているなら、RSpecから型定義を出力できるツールもあるらしく、それは一日目の14:40に#rubykaigiCで行われた神速さんのセッションでも解説があったと教えてくださいました。残念ながらその時間帯は別のセッションを聴講していましたが、少し興味が湧きました。
Eliminating Unnecessary Implicit Allocations
JeremyさんによるRuby 3.4のアロケーション最適化に関するセッションです。Ruby 3.3によってアロケーションのリグレッションが発生しましたが、Ruby 3.4でそれが修正されたそうです。
Jeremyさんは、わずか2週間で3件ものアロケーションのリグレッションを発見し、その原因と修正内容について説明してくださいました。
「どのようにしてリグレッションを回避するのか？」という問いに対して、「そう、テストを追加するのです」と大きな文字で表示されたスライドには、思わず笑ってしまいました。やはりテストは非常に重要ですね。
このセッションで興味深かったのは、アロケーションを回避するための具体的な説明です。Ruby 3.3において、配列のアロケーションがどのように行われているかが解説されました。VMスタックのサイズには制限があるため、大きなリテラルの配列を定義すると、要素ごとに値をVMスタックにプッシュしているそうです。それに対し、pushtoarrayを使用することで、配列のアロケーションを大幅に削減できるとのことでした。
Rubyの内部構造や、バージョンごとの最適化について知ることができ、非常に興味深いセッションでした。
Matz Keynote
Rubyの作者である、Matzことまつもと ゆきひろ氏のKeynoteです。
いきなりステージの床が開き、Matzがせり上がってくるという演出は、とても面白かったです。
盛大な演出で登場した直後、最初のスポンサーセッションの間、Matzが観客席を一瞥しながら舞台袖に退場していく様子は、とてもシュールでした（笑）。
スポンサーセッションの後、いよいよMatzのKeynoteが始まりました。
Matzは冒頭で「最近はどのカンファレンスに行ってもAIの話題が多いが、今回は驚くほどAIに関するセッションがない」と述べ、確かにその通りだと感じました。そのため、MatzはこのKeynoteでAIについての発表をすることにしたそうです。
MatzがAI時代に危惧しているのは、AIと人間の関係が逆転してしまうことだと指摘します。本来、人間がAIを使う側であるべきなのに、いつの間にかAIのために丁寧に準備したり、AIのために開発するようになってしまうと、AIが人間に使われる関係になってしまうことを懸念しているという話でした。
グロービスでもかなりAIを取り入れており、私も普段Cursor、Devin、GitHub Copilotなどを利用した開発に慣れているため、「自分はAIに使われていないか」という問いを改めて考えさせられました。
Matzが静的型について触れた内容も非常に印象的でした。静的型付けは人間が間違いを見つけやすいというメリットがあり、現在でもそれは有用だが、今後はどうだろうかと問いかけます。この辺りから少し考え込んでいたため、Matzさんの話が完全に頭に入っていたわけではありませんが、AIによってその点が解決されるなら、もしかすると良いのかもしれないと感じました。
また、Matzが「多くの場合、型エラーはそれほど大きな問題ではなく、それよりもロジックミスや要件とのずれの方が重大である」と述べたことには、私も全く同感でした。
Matzがこの基調講演で一貫して伝えていたのは「楽しさ」についてだったと思います。AIと楽しさ、静的型と楽しさ、そしてRubyの楽しさ。
AIにおいては、「AIに使われている」ことは本当に楽しいのか。「AIを使うこと」で得られる楽しさ、もっとその楽しい部分を存分に味わえないか。
静的型に関しては、型を書くことは楽しい作業ではあるものの、それがRubyを書く楽しさに直接つながるのか。
私自身は静的型に関して賛成でも反対でもない立場ですが、Matzが考えている「楽しく書けるRuby」の世界観に触れることのできた基調講演でした。
まとめ
会期中を通して"Ask The Speaker"というメッセージをしばしば聞きました。
発表に関することは発表者が一番詳しいので発表者にぜひ質問してほしい、というメッセージです。
本当は私も発表者に聞きたいことがいくつかあったのですが、私がなかなか発表者に出会うことができず、あっという間にタイミングを逃してしまいました。
今度はぜひ発表者にも質問をして行きたいな、と思いました。
RubyKaigiには本当にいろんな人が集まっていて、どんな人と話をしても収穫がたくさんあります。
本当に素晴らしいカンファレンスでした。
来年は4/22〜4/24に函館で開催するそうです。
またぜひ行きたいなと思いました。
Discussion