- バックエンド
- PdM
- 急成長中の福利厚生SaaS
- Other occupations (25)
- Development
- Business
- Other
こんにちは。バックエンドエンジニアの西野です。9月26日、27日に開催された Kaigi on Rails 2025 に、ウォンテッドリーのメンバー5名で現地参加してきました。
どのセッションも素晴らしいものでしたが、本記事では特に印象に残ったものをご紹介します。
Keynote: dynamic!
今年のオープニングキーノートの「dynamic!」は、継続して変化し続ける「動的な」開発をテーマにした内容でした。変化に合わせた開発というのは、修復し続ける開発ということであり、その心構えの参考として Kent Beck 氏の著作『Tidy First?』が紹介されました。この本では「修復」を「整頓(Tidy)」として表現しており、日々の開発の中でコードを整えていく重要性と手法について書かれています。
発表では動的な開発とは、小さく丁寧に作ることだとも語られており、「丁寧に作る」というのはどういうことか、自身の開発を振り返るきっかけになりました。
そのpreloadは必要?──見過ごされたpreloadが技術的負債として爆発した日
ActiveRecord の preload は関連レコードを事前に読み込むことで N+1 問題を防ぐ機能です。発表では、システムの変化により不要になった preload が蓄積され続けた結果、Out of Memory による障害が発生した事例が紹介されました。振り返りとして、メモリ監視やアラート検知に弱かったこと、preload のメモリ負荷についての認識が不十分だったことが挙げられていますが、これはキーノートでの「丁寧に作る」という意識と結びつく内容に思いました。
また、不要なコードを削除するという点については、『TIdy First?』の第1部 2章でも「デッドコードを消すことに強い抵抗を感じる人もいるだろう」と述べられています。残したくなる心理に流されない勇気を持つということが、変化し続ける開発において重要であると感じました。
非同期処理実行基盤、Delayed脱出〜SolidQueue完全移行への旅路。
今回は非同期処理に関するセッションがいくつかありましたが、こちらは Delayed から SolidQueue へ移行した手順について紹介したものです。移行における数々の判断の背景や、その選択におけるメリット・デメリットが詳しく説明されていて大変参考になりました。また、SolidQueue の監視のために内部実装の理解が必要だったという点は、先の preload に関する発表での振り返りに通じる話ではないかと思います。
ここまで念入りに準備を進めていても、リリース後に Rails のバージョンに起因する問題が発生したとのことで、システム開発の難しさを再認識する発表でした。
まとめ
大規模カンファレンスへの参加は初めてでしたが、実践的な内容のセッションが多く、自分たちの開発をもっと良い方向に変えていきたいという刺激を受けた 2 日間でした。
このような素晴らしい機会を提供してくださった運営の皆様、本当にありがとうございました。