KCS Carrot logoKCS キャロットBlog

Kaigi on Rails2025 初参加レポート

書いた人: @t-suzuki-carrot

こんにちは、H2開発グループのt-suzukiです!
9/26(金)と 9/27(土)の2日間に渡って開催された Kaigi on Rails 2025 に初参加してきました!

この記事では、初参加者の目線から見たKaigi on Railsの雰囲気や、印象に残ったセッション、そして「来てよかったなあ」と思えたポイントを書いていこうと思います。

初参加のKaigi on Rails

今回Kaigi on Rails初参加だったので、初見の印象から話していこうと思います!

正直、参加前はちょっとだけ緊張していました。Rails強者ばかりだったらどうしよう、とか、知らない人だらけで浮いたらどうしよう、とか。でも会場に入ってみると、そんな心配は一瞬で消えました。

まず受付の時点で、スタッフの方が明るく迎えてくれました。カンファレンスは、最初の数分がいちばん緊張すると思うんですが、そこでちゃんと暖かく迎えてくれたのが印象的でした。

セッションも、「Rails力が高くないと置いていかれるのでは…?」という不安はいい意味で裏切られました。もちろんディープな話もあるのですが、前提から丁寧に説明してくれる発表が多く、「なぜそれをやるのか」や「どういう背景があるのか」といった文脈をきちんと共有してくれるセッションも多く、初心者にもやさしいカンファレンスだったと感じました。

また、他の参加者と交流する場がありました。ここでは、普段話すことがない他のRuby使いと会話ができます!
自分は初めての人と話すのが苦手ですが、ここなら共通の話題があるのがうれしいですね。「よかったセッション」や、「どんなプロジェクトをやってきたか」など貴重なお話を聞くことができました!こういったカンファレンスの良いところですね!

印象に残ったセッション

高度なUI/UXこそHotwireで作ろう

「Hotwireの強み」について説明いただきました。
Hotwireで作成したページと、reactで作成したページを実際に動かして、動作の速さや、なぜそうなるのかといったお話でした。
セッションでは、実際にHotwireとreactで作成されたページの応答速度を見比べたのですが、reactはもっさり感があるのに対し、Hotwire(turbo)は素早いページ遷移でストレスレスに感じました。どうやら、turboではキャッシュ表示→サーバにリクエスト→最新内容をレンダリングとしているそうです。
実際に動作しているページを見ながら聞くと、やっぱり説得力が段違いですね。特にHotwireはこのストレスレスな環境がデフォルトで実装できるのが強いと感じました。多少複雑な動きや部分的な動きはStimulusで補完できるのが良いですね。
Hotwireは「サーバを中心に、必要な分だけJS(Stimulus)を使う」といった思想になるのかなと感じました。部分的な切り分けがしやすくて設計が楽になりそうですね。

Railsによる人工的「設計」入門

「設計を教える際、教える側と教わる側の認識の齟齬」がとても分かりやすく言語化されていました。
教わる側は、これまで実装した経験が残っているため、DB→モデル→コントローラー→viewの順で設計してしまう。そうじゃないよね、「逆順」で設計するべきだよね。というお話でした。
こういった齟齬は、教える際に一番難しい点だと思います。齟齬を発見するのも、それを教えるのも難しいよな、と。その点、このセッションでは、どのように教えるかについてもわかりやすく説明されていました。自分の中のフワフワした「設計」という言葉をわかりやすく言語化してくれました。
今後人に教えることになってくると思うので、その際にぜひ取り入れたいなと感じました。

Sidekiq その前に:Webアプリケーションにおける非同期ジョブ設計原則

「非同期ジョブは便利だけど万能ではないから、このようにジョブ設計するべき」というお話でした。
このセッションでは、ジョブ設計は「パラメータを小さくする」「ジョブはトランザクショナルにする」「長時間ジョブを避ける」べきであると説明されていました。
特に、「長時間ジョブを避ける」という内容は、とても納得感がありました。
「どの処理で失敗したか」がすぐにわかるため、エラー箇所が特定しやすい、ということでした。確かに、ジョブにかかわらず、コードが長い処理ではエラー特定のためにブレークポイントをいっぱい打ったりして時間をかけて特定するため、エラーを見つけにくいジョブでは必要ですよね。また、短いジョブなら「もう一回実行する」で解決できたりするため、運用上でも大きい意義があります。
大きなジョブは処理が固まっているため、一見スッキリして見えるけれど、リスクも固まっている状態なのかもしれません。一度長いジョブで設計すると、短いジョブに分割できないため、設計の段階からジョブの大きさについて考えることが大切なんですね。

まとめ

Kaigi on Rails初参加で緊張していましたが、参加してみるととても良いカンファレンスだったなと思いました。セッションも初学者にもわかりやすく、ためになるものが多かったです。そして何より、他の参加者と交流する場もあり、直接コミュニケーション取れるのが良いですね!
Raigi on Railsに興味あるけど話についていけるかな、オフラインで参加するの緊張するな、なんて方がいらっしゃいましたら、ぜひ参加してみてください!