はじめに
9/26(金)・27(土)開催のKaigi on Rails 2025に現地参加してきました。
株式会社Inner Resource（以降 弊社）からは3人のエンジニアが参加させていただきました。
私はRails経験半年であり、初めてのKaigi on Railsです。
以下、気になったトークの感想を書いていきます。
Day1
Keynote: dynamic!
Rubyの動的型付けとかけて、開発も動的にやっていこう、という話でした。
個人的にアジャイルな開発は好みなので、とても共感できるキーノートでした。
変化の多い時代に、特に弊社のようなスタートアップ企業はdynamicに開発していくべきですね。
高度なUI/UXこそHotwireで作ろう
HotwireとReactを比較するデモが、視覚的にとても分かりやすかったです。
弊社のシステムのフロントエンドは、Railsの画面とReactの画面が混在しています。
Railsの画面でのreactiveな動きはAjaxやFetchを用いて実現しているため、Hotwireの導入を検討してもよさそうだなと感じました。
入門 FormObject
Railsを使い始めて半年。最近、複数モデルをまたがるような処理はどこに書くべきなんだ？FormObjectやServiceクラスってなに？と思っていたので、どんぴしゃなトークでした。
ただ、一度に操作するモデルが複数というのはよくあると思うので、その判断基準だとFormObjectだらけになりそうなだと思いました。
Railsアプリケーション開発者のためのブックガイド
早口で高速に技術本を紹介していくトークでした。（合計90冊くらい？）
癖がある、まだ発売していない本、日本語翻訳が微妙など、本音話が面白かったです。
生成AIで簡単に大量文章が作成できる時代ですが、一定の質のあり、作者の思考が入る「本」はむしろ価値があると思うので、技術本読んでいきたいです。
全問正解率約3%: RubyKaigiで出題したやりがちな危険コード5選
特に「トランザクション内で、外部APIを呼ぶ、非同期処理を行う」は、弊社でつい最近話題に上がっていたので、自分ごととして聞けました。
AIや駆け出しエンジニアはこのようなコードを書いてしまいそうなので、しっかりと気づけるようにしたいです。もちろん自分自身も書かないように気をつけたいです。
5年間のFintech × Rails実践に学ぶ - 基本に忠実な運用で築く高信頼性システム
信頼性向上の取り組みは、どれも基本的ではありますが、積み重ねが大切ということが強く伝わってきました。
弊社は、少人数のエンジニアチームなので、一人が開発・運用を両方やらないといけません。
弊社システムは金融システムほど法的に厳しくなく、ユーザー数も多くないですが、信頼性はもちろん重要です。基礎的なことを一つずつやっていく必要があるなと感じました。
2分台で1500examples完走！爆速CIを支える環境構築術
弊社でも最近、テストコードの拡充に伴って、テストの実行時間が長くなってきているので、とても身近な話題でした。
特にRSpecの並列実行の際に気にすべきところは、大変参考になりました。
オチは、高性能な物理マシンを買うのが、実行速くコストも安い、というもので、笑いました。
Railsによる人工的「設計」入門
設計をジュニアエンジニアに教えるにはどうすればいいか？設計とは何か？を解説したトークでした。
たしかに駆け出しエンジニアのときは、目の前のコードをどう変えるかしか考えれておらず、システムや機能の全体像を考えれてないのだよな、と自分の初心者のころを思い出しながら聞いていました。
今後、設計を人に教える際は、これらを意識したいです。また、自分が設計するときも気を引き締めてやりたいと思いました。
Day2
ActiveRecord使いが知るべき世界：Java/Go/TypeScriptのORMアプローチ比較
私は他言語のORMだとPythonのSQLAlchemy、TSのTypeORMなどを使ったことがありました。
他のORMと比較しながらActiveRecordの特徴を説明されていて、とても勉強になりました。
ORMによって思想が異なるので、絶対的な良し悪しではなく、チームやプロダクト文化によって選定すべき、という意見に納得しました。
小規模から中規模開発へ、構造化ログからはじめる信頼性の担保
ログの構造化は、弊社でも話題に上がっていたので、興味を持って聞くことができました。
Rails8.1以降で標準実装されるという構造化ロギング機能が待たれますね。
Sidekiq その前に：Webアプリケーションにおける非同期ジョブ設計原則
弊社のシステムも、非同期ジョブがあり、また今後非同期ジョブ化を検討した方がよいのではという機能もあるので、とても参考になりました。
設計時に本当に非同期ジョブが必要なのか、バッチ処理などで代替できないか、を考えることが必要、というのは納得しました。
非同期ジョブを作るなら、短時間で終わるシンプルな処理にする、を意識したいと思います。
Railsアプリから何を切り出す？機能分離の判断基準
弊社システムでも、今後機能分離を検討するタイミングは来ると思うので、この5つの判断軸を参考にしたいなと思いました。
判断軸
- ビジネスロジックとの関連度. 関連度が低いものを分離する
- 他インフラリソースとの依存関係
- 機能の複雑さ
- 運用コスト vs 開発スピード
- ビジネス上の柔軟性
非同期jobをtransaction内で呼ぶなよ！絶対に呼ぶなよ！
弊社では最近after_commit_everywhere Gemを導入しようとしており、タイムリーな内容でした。
また、enqueue_after_transaction_commitオプションは初めて知ったので、大変勉強になりました。
「技術負債にならない・間違えない」権限管理の設計と実装
「役割ではなく、権限に依存するべき」という話は、聞いたことありましたが、順を追って丁寧に説明されていて、分かりやすかったです。
ここで提案された権限管理の導入はコストが高い気もしますが、エンプラ向けやステークホルダーが多いなど、権限管理が複雑なシステムでは、効果的なんじゃないかなと思いました。
Keynote: Building and Deploying Interactive Rails Applications with Falcon
デモ、ライブコーディング、ジョーク、日本語を駆使したセッションは、上手いなーと関心してしまいました。
スピーカーのSamuel Williams氏がコミットしているFalconをRailsのアプリケーションサーバーとして使わないかという提案をされていました。
現在はPumaがデファクトスタンダードですが、他の選択肢が出てくることは、Rails界隈にとってよいことではないかなと思います。
私たちが普段Railsを用いて快適に開発できているのは、Ruby・Rails・周辺ツールのOSSのコミッターの方々のおかげです。頭が上がりません。
まとめ
明日にでも使えるような内容のトークも多く、とてもためになる技術カンファレンスでした。
また、他の人も同じようなRailsの悩みをかかえているんだなと実感しました。
来年のKaigi on Railsにもぜひ参加したいです！
来年は渋谷！
株式会社Inner Resource のエンジニアブログです。 忙しい研究者・研究施設の業務効率化のためのクラウド購買管理ソフト「リプルア」を開発しています。
Discussion