はじめに
合同会社春秋でエンジニアをしているmugi(@mugichan3da)と申します。
9/26(金)・27(土)に開催されたKaigi on Rails 2025に現地参加してきました。Kaigi on Rails に参加するのは去年に引き続き２回目で、今回は弊社Ruby/Railsエンジニア総出の６名で参加です！
参加したトークセッション
1日目
- Keynote: dynamic!
- RailsのPostgreSQL 18対応
- そのpreloadは必要？──見過ごされたpreloadが技術的負債として爆発した日
- Railsアプリケーション開発者のためのブックガイド
- 全問正解率約3%: RubyKaigiで出題したやりがちな危険コード5選
- 5年間のFintech × Rails実践に学ぶ - 基本に忠実な運用で築く高信頼性システム
- 2分台で1500examples完走！爆速CIを支える環境構築術
- GraphQL×Railsアプリのデータベース負荷分散 - 月間3,000万人利用サービスを無停止で
- 今改めてServiceクラスについて考える 〜あるRails開発者の10年〜
2日目
- ActiveRecord使いが知るべき世界：Java/Go/TypeScriptのORMアプローチ比較
- 小規模から中規模開発へ、構造化ログからはじめる信頼性の担保
- Sidekiq その前に：Webアプリケーションにおける非同期ジョブ設計原則
- Railsアプリから何を切り出す？機能分離の判断基準
- Introducing ReActionView: A ActionView-Compatible ERB Engine
- 非同期jobをtransaction内で呼ぶなよ！絶対に呼ぶなよ！
- マンガアプリAPIと共存するWeb体験版の作り方 〜 コンテンツ保護技術を添えて
- "複雑なデータ処理 × 静的サイト" を両立させる、楽をするRails運用
- rails g authenticationから学ぶRails8.0時代の認証
- Keynote: Building and Deploying Interactive Rails Applications with Falcon
セッション
自分用にセッションのスライド一覧をまとめたもの
↑が完成した後に見つけたスライドの他に、感想などもまとまっているこちらを是非
以下いくつかのセッションの感想を
そのpreloadは必要？──見過ごされたpreloadが技術的負債として爆発した日
N+1対策で追加されたpreloadが、サービスの成長や仕様変更後も放置され、技術的負債として蓄積し、最終的にメモリクラッシュを引き起こしたというお話。
ある時点での最適解が、常に今後の最適解であり続けるとは限らない。サービスの成長に合わせて、実装が現状に適しているかを見直すことの重要性を痛感しました。ではいつ見直すべきか？という問いに対するヒントは、アプリケーションの継続的な観測。監視ツールでメモリ使用量などを日頃から可視化し、アプリケーションの「健康状態」から異常の兆候を掴むというアプローチ。
セッションを通して、自分はこれまで実装時点でのパフォーマンスは考慮しても、サービスが成長してデータが増えた将来のパフォーマンスまでは意識があまり向いていないことに気付かされました。かといって、将来のために過剰な実装をするのも違う。大切なのは、その時点での最善策（Betterな選択）を取り、アプリ/サービスの状態を継続的に観測し、必要になったタイミングで適切な改善を加えていく姿勢なんだなと強く感じました。アプリは生き物だ。
Railsアプリケーション開発者のためのブックガイド
30分という時間があっという間に感じられるほど、数多くの技術書が紹介されたセッションでした。AIがコードを書き、大抵の質問に答えてくれる時代に突入したからこそ、改めて「本」で学ぶことの重要性を深く考えさせられました。
Webの情報は断片的で、特定の問題解決には役立ちますが、知識が「点」になりがち。また、詳しくない分野では「そもそも何を学べば良いか」すら分からない状態に陥りやすいもの。その点、本は情報が体系的にまとまっており、知識の全体像を時間をかけて把握する上で非常に有用である、という話に改めて納得しました。
紹介された本の数は膨大なので、ぜひスライドを直接ご覧ください。
これだけあると「どうせ読まずに積むだけでは？」と心配になりますが、その懸念を払拭してくれる素晴らしいスライドが最後にありました。このスライドに勇気をもらい、自分も「いっぱい積んで、いっぱい読むぞ！」と決意を新たにしました（笑）
非同期jobをtransaction内で呼ぶなよ！絶対に呼ぶなよ！
つい最近、同様の問題に遭遇したばかりだったので、大きく頷きながらセッションを聞きました。非同期Jobを実装する際に出くわす、あの「謎のバグ」の正体が非常に分かりやすく解説されていました。
セッションの核心である「トランザクション内で非同期ジョブをエンキューすることがなぜ危険なのか？」という問い。その答えは、ジョブの実行タイミングとDBへの書き込みタイミングの競合。ジョブがエンキュー直後に走り出しても、トリガーとなったトランザクションがコミットされていなければ、ジョブは必要なレコードを見つけられずに ActiveRecord::RecordNotFound といったエラーを引き起こす。そして何より厄介なのが、このエラーは発生したりしなかったりと、再現性が低い点...
この問題に対し、セッションでは対策が3つ提示されていました
- エンキュー処理をトランザクションの外に記述する。
- gem (after_commit_everywhere)を使う(初めて知った）
-
enqueue_after_transaction_commitの設定を利用し、DBコミット後のジョブ実行を保証する（Rails 7.2以降で利用可能）
また、別セッションのSidekiq その前に：Webアプリケーションにおける非同期ジョブ設計原則では、非同期ジョブの設計原則が語られており、本セッションと合わせて学ぶことで、非同期処理への理解が一層深まると感じました。
その他
交流会
交流会では大学生とお話しする機会がありました。そこで受けたのが「ポートフォリオは必要ですか？どんな内容がいいですか？」と言った感じの質問でした。
自分は、「何を作ったか」という結果以上に、「なぜそれを作ろうと思ったのか」「開発中にどんな困難があり、どう乗り越えたのか」といった思考のプロセスこそが重要...って感じのことを言ったと思います。さらに、同席していた別の方は、「作ったものをどう運用し、成長させるか」といった、サービスを「当事者」として捉える、より一歩進んだ視点を加えてくれました（確かに..と自分も含め深く頷いていました）
もしインターンなどに参加しているなら社員さんにバンバン質問しましょう！「大学生だから」と無下にする人なんていません。みんな喜んで耳を傾け、素敵なアドバイスをしてくれるはずです！ガンガン行こうぜ！
また、今回は仕事でお世話になっている方々と、初めてリアルでお会いする機会もありました。
Slack上でのやり取りと、実際に対面で話すのとでは、得られる情報量が100倍くらい違うと感じました。話してみると実は同学年だったことが判明したり、お互いの経歴について語り合って盛り上がったりと、改めてリアルでお会いする価値や醍醐味を感じました。今後とも何卒よろしくお願いいたします。
食事
画像は割愛しますが、滞在中は毎日欠かさず麺類を食べていました。台湾混ぜ麺、家系、パスタ、蕎麦、担々麺、我らが富士そば、鴨ラーメン、台湾ラーメン...。 エンゲル係数と摂取カロリーは爆上がりでしたが、東京滞在中は深夜徘徊するなどたくさん歩いて消費もしたので実質摂取カロリーはゼロだと信じています。牡蠣も美味しかった...
会場から見下ろす東京駅。美しい...
この作りに興奮。すげぇ
まとめ
今回で2回目の参加となったKaigi on Railsでしたが、前回以上にセッション内容へ深く共感でき、多くの学びを得られたと感じています（同時に自分の知識、実力不足も痛感...）。すぐにでも実践したい実装や考え方、そして今後直面しそうな課題への向き合い方など、実用的な知見がいっぱいでした。個人的には、Keynoteだけでなくカンファレンス全体を通して「動的に変化すること」の重要性を強く感じた2日間でした。
ここで得た多くの学びと経験を糧に、来年はCFPに応募するなど、登壇者としてこの場に戻ってこられるように頑張ります。
最後に、登壇者、運営、スポンサー、そしてKaigi on Railsに参加されたみなさん、本当にありがとうございました。
それでは来年のKaigi on Railsで！
Discussion