Kaigi on Rails 2025 参加レポート

こんにちは、YOUTRUST Webエンジニアの寺井(YOUTRUST/X)です。

2025年9月26日と2025年9月27日に行われたKaigi on Rails 2025に今年も参加してきたので、参加レポートをまとめたいと思います。

なお、YOUTRUSTへ入社してからKaigi on Railsへの参加は3回目で、今年も一年間運営として準備に取り組んできたので、当日だけでなくそちらのお話も書きたいと思います。

セッションレポート

moroさんによるKeynote

5年間のFintech × Rails実践に学ぶ - 基本に忠実な運用で築く高信頼性システム @ohbarye

speakerdeck.com

今年聞くことができたセッションの中で最も印象的なセッションでした。

5年の歴史があるFintechサービスの品質を保つために実践してきた開発と運用の取り組みが紹介されていました。

具体的には、パフォーマンス確認ミーティングを隔週で実施することで直近リリースによるパフォーマンス低下を検知したり、各バッチ処理のドキュメンテーションを必須化することでアラート時の対応を属人化させずに全エンジニアが分かる状態を保っていたり、アラートを1つずつ潰していってもしアラートが届いたら誰かが至急見ないといけない状態を作ったりといった取り組みが紹介されました。

弊社でも障害がない週でもSentryアラートが数多く発報されてしまっており、アラート整備の重要さと困難さを身を持って理解しているからこそ、旗振り役がやり切ってアラートを90%減らした取り組みに心から感動しました。

障害対応においても、インシデントコマンダーの選定を含めたフローを整備することで、障害発生時に全員のスプリントタスクが止まってしまうことを防止している点など参考にできる点を学ぶことができました。

今改めてServiceクラスについて考える 〜あるRails開発者の10年〜 @joker1007

speakerdeck.com

jokerさんがパRailsでServiceクラスについて書かれてからおよそ10年が経過し、今改めてServiceクラスについて考え直すというセッションでした。

Serviceクラスと似た概念として扱われることが多いUseCase層を弊社では導入しているため*1、必ず聞きに行こうと前から期待していました。

セッション内では、Serviceクラスの困難さについて、チームで共通の基準を作りチームメンバーが想像しやすい状態にしづらいことが挙げられていました。

これまでServiceクラスに関する記事やセッションを聴講したとき、つらみポイントが弊社では該当していないなと感じることが多かったのですが、改めてServiceクラスと弊社で呼んでいるUseCase層は別物であることを知りました。(まだあまり自信がないのでDDDやPofEAAをしっかり学習しようと思います)

弊社のUseCase層は、命名規則から責務*2、処理の流れまでテンプレートパターンで統一されており、開発組織内での共通認識の構築もうまくいっているためServiceクラスのつらさは顕在化していませんが、逆に言えばこの共通認識が開発組織内で取れなくなると困難な点が一気に出てくるとも言えるので、その点は注意しないといけないなと感じました。

今改めてServiceクラスについて考える 〜あるRails開発者の10年〜 (30P)

また、jokerさんの問いかけやmoroさんのKeynote*3など、今年の数多くのセッションで何度も語られていた「よりシンプルにできないか?」を考え続けることの重要さを改めて認識し、常に念頭に置いておく必要性を学びました。

運営としての活動

2023と2024に引き続き、今年もスポンサー周りの対応を担当していました。

今年はずっとやりたいと思っていた、スポンサー企業との連絡ツールとしてSlackの導入に新たに取り組みました。

2023と2024は各スポンサーとの連絡をメールを使って行っていましたが、意思疎通の手間やタスク管理の困難さなどの課題を感じていました。

昨年同僚の朝日さんからFlutterKaigi ではSlackでコミュニケーションを取っていることを教えてもらい、今年はKaigi on RailsでもRubyスポンサーとGoldスポンサーの企業をSlackに招待する取り組みを試験的に導入してみました。

結果としては、

  • 質問に対する初期返信が速くなった
  • スタンプを付けることでタスク管理がしやすくなった
  • 質問への回答を他スポンサーも閲覧できることで同じ質問がなくなった

など多くのメリットがあり、オペレーションを昨年より改善することができたと感じています。

やり取りの一部

タスク管理の部分は、今年一緒に活動したスポンサーチームの他メンバーのみなさんのおかげでうまく管理できていたので大いに感謝しています。ありがとうございました。

また、今年はおやつスポンサーやドリンクスポンサーなどを始めとしたカスタムスポンサーも初めての取り組みとして導入しました。

初年度のため至らぬ点もあったと思いますが、カスタムスポンサーのみなさんの出展のおかげでKaigi on Railsがより一層盛り上がったと思います。

一方、まだまだたくさんの伸びしろポイントがあると思うので、引き続きチームで振り返りを行って来年もより良いKaigi on Railsにできるようにがんばります。

スポンサーのみなさん、本当にありがとうございました!

終わりに

来年はさらに規模を拡大して渋谷での開催となります。

Kaigi on Rails 2026

個人的には、来年は運営だけでなく発表することができたら良いなと思っています。

みなさん、また来年のKaigi on Railsでお会いしましょう!

Kaigi on Rails 2025 お疲れ様でした!

herp.careers