🚀

Kaigi on Rails 2025 レポ

に公開
Ruby
Tech
Kaigi on Rails
kaigionrails2025
idea

Kaigi on Rails 2025 参加レポート

2025年9月に開催された Kaigi on Rails 2025 に参加してきました！
2023年の時は行きましたが2024年の時はいかず、1年ぶりとなります。RubyKaigiと比較すると業務寄りの内容が多いため、仕事に活かせる部分がありそうか？というポイントでセッションを見てまわりました。
2023年の頃はまだRubyを始めて1年半年くらい、まだまだペーペーだった私にはその業務活用の実践イメージが浮かばない部分もありました。しかし現業務で技術的負債や様々な技術的困難を乗り越えて見る景色は全く異なっており、とても楽しい時間を過ごすことができました。

そんな2日間の中で、印象に残ったセッションや学びについてまとめます。

会場

セッション編

そのpreloadは必要？──見過ごされたpreloadが技術的負債として爆発した日

スライド

3行メモ

  • bullet gemなどのツールを活用した監視
  • 銀の弾丸は存在しない→とりあえずpreloadはやめろ
  • 年単位での継続的な監視が必要

N+1問題を解決するために何気なく使っているpreloadが、実は技術的負債として積み重なっていたという話。メモリ監視やアラートによる早期発見の重要性が強調されていました。私も過去にpreloadでIN句が上限値を超えてしまい、CPUを爆増させた事があります。そのため発生した時の問題の大きさも、その検知のしづらさもよく理解できるので難しい問題だな〜と感じました。
preloadの導入は「念の為」ではなく「意思を持って」行うべきなのでしょう。また追加した時にはどのようなクエリが発行されているのか、開発者は認知しておくべきだと感じています。

Railsアプリケーション開発者のためのブックガイド

スライド

紹介された書籍から気になったものたち

最初に話していた内容の中で、Railsでサービスを作ることはソフトウェアないしはチーム、文化を育てることーその中でチームのメンバーに変化があったとしても同じようにソフトウェアを作れるようにするにはドキュメントが時間を越える必要がある、という話にとても共感を感じました。
個人的な余談ですが懇親会で前職の方にお会いした時に、後輩さんを紹介してもらいました。その後輩さんに名前を伝えた時に「あの〇〇さんですか！！残してくれたドキュメントにいつも助けてもらっています！」と言ってくださいました。例え自分が居なくなったとしても文字や言葉は残り続ける。時を超えて自分があの時書いた文章に価値が生まれる事はとても嬉しく思いました。

技術を学ぶという目線だけで本と向き合うのは面白くないと思っていて、その書籍の意図や歴史を知るとより残るドキュメントに変わるなぁと改めて感じるセッションと出来事でした。

とは言いつつ、めちゃくちゃ積読があるので読まないとですね..。

2Fの本屋で購入。サインもらいました！

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

スライド

3行メモ

  • 信頼性の指標は明確なものは存在していない、プロダクトによって異なる
  • 開発後の運用プロセス上で信頼性がわかっていく
  • 運用とは：本質的にはビジネスを可能にすること
    • 「資金移動業の適正かつ確実な遂行」が重要なポイント

技術的な取り組み:

  • 規制対象の機能を本体から分離して別途権限も厳しく管理
  • Citadelによる機能ごとのモジュール化
  • API定義はcommitteeで必須化
  • 障害が発生しない事ではなく、発生した時の速やかな検知と解決、予防
  • 「障害」という大きなくくりではなく、ビジネスが毀損される障害にフォーカス
  • SLI/SLOもビジネス毀損するラインで考える

監視とアラート:

  • バッチ管理：アラートを受け取ったエンジニアがどう対応するか？を定義
  • Sentryアラートは旗振り役が頑張った
  • PagerDutyを参考に整備
  • Runbookの活用
  • 特定のリアクションをつけるとrunbookがサジェストされる

一番心に残るセッションでした。

私は過去に前職も含めてSLI/SLOの定義をする話に2回くらい関わった事があります。結局そこの誰も答えを持ち合わせていなくて、直近こんな感じだからこうだろう、そんな曖昧な選択をしていました。このセッションでは信頼性とは何か？SLI/SLOの指標はどうあるべきか？そんな話がメインでされていましたが、どの話の中心にも「ビジネスを毀損するか否か」という話がありました。
もしあの時にこのセッションを知っていたら、技術者だけのコミュニケーションに留めずPDMとも話す選択をしたと思います。ここにおいて重要なのは職位や知識や経験だけではなく、ユーザーに近いメンバーとの意見を交えて「絶対落としてはならないライン」と「ここは許容できるライン」を定めるべきだからです。そのラインの先に数値として定義できるSLI/SLOが存在しているべきなんだ、と考え方を大きく変えさせられた瞬間でした。
自分が向き合っているものは技術であると同時にプロダクト開発であり、プロダクトの先には必ずビジネスがある。だからこそ技術で何を担保するか？という定義は「一般的にはこうだから」などと曖昧なものに責任を持たせるのではなく、自分たちのプロダクトにとってどうか？というユーザーやビジネス視点にあるべきなのだと思わされました。

そしてこのセッションを聞いて、こんなに熱量も技術力も高いエンジニアのいるプロダクトを使ってみたいという気持ちになり、即ワンバンクをインストールしました。

2分台で1500examples完走！爆速CIを支える環境構築術

スライド

3行(?)メモ

  • specそのものの改善ではなくCIツールの改善についての話
  • 直列実行でCPUを使い切れないため並列実行する
    • parallel_test gem
    • マルチプロセスでの並列実行をサポート
    • DB cleanerも実行されてテストができない問題があるが、論理DBを分けることができる！
  • 均等な並列実行
    • knapsack pro
      • spec単位の実行時間の履歴を記録して最適な分割をしてくれる
  • I/Oスペックの向上
    • tmpfs
      • メモリ上に作成できるファイルシステム
      • tmpfsすご

会社のCIもとても遅いので、tmpfsの導入は検討の余地アリかもなと思いました。会社の品質強い人に聞いてみようと思って忘れていた事を書きながら思い出しました。
オチは物理マシンにしたら安くて30分かかるCIが2分になったという話でめっちゃ笑いました。

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

スライド

3行メモ

  • 設計≠コードである事を伝える必要がある
    • コードとは違うレベルで考えることを設計という
  • 設計したのではなく手順を説明しているだけかも
  • 設計は手順の前にくる

教える側と教えられる側のギャップ:

  1. 図や表を書く→教える側は図や表とコードを並列で考えることができる→教えられる側は図や表からコードに落とすことができない、脳内実装ができない
  2. 重要な技術的要素はどう考えるか？→考え始めたら調査して
  3. 教えられる側はコードからしか考えられない

私はいつから設計ができると思えるようになったのか、改めて考えるセッションでした。最後は経験値だと思うんですけど、分解して考える機会が得られてよかったです。もし初学者に伝える機会や、設計の話でうまく伝わらない体験をしたらここのスライドに戻ってこよう、と思いました。

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

スライド

3行メモ

  • serviceクラスについて書いたjokerさんがserviceクラスについて話す話
  • 重要なのは開発者にとって想像がつくこと、驚きが少ない開発、読めるコードにすること
  • ServiceクラスにしてもFormクラスにしてもModelと向き合う事が重要である

現在FatModelとずっと向き合っているし、Serviceクラスでのアンチパターンも見たので痛いほどわかるなーという話ばかりでした。でも最近の思考が、最終的に伝えている話と一致したのでなんだか安心しました。結局上位層でなんとかしようとしても、Modelが複雑であればチームや人が変わるタイミングで必ず綻びが生まれるんですよね。
ただじゃあModelを簡単に変える事ができるかというと運用を続けていればレコード数は増え変える事には大きなリスクを伴う事が増えていくと思います。だからこそそういう場合に適用されるのがDomainModelなのかなーとか考えていました。

非同期処理実行基盤、Delayed脱出〜SolidQueue完全移行への旅路。

スライド

3行メモ

  • DelayedJobからSolid Queueに置き換えた話
  • 技術的困難を乗り越えて無事置き換えは完了した
  • が、Solid Queueが早すぎる割に元のJobは重たいままなので負荷に耐えられなくなったから並列化をやめた

非同期処理が重たくなりがちなのは本当にわかる。パフォーマンス面で最も問題となり得る。どのようなケースでも早い！軽い！が一番良いけれど、そうも言ってられないので機能ごとでそれはバッチ処理であるべきなのか/非同期処理であるべきなのか、またそこから時間がかかっても良いものか、なる早で解決してほしいものなのか...、これは一括更新だから非同期処理だよね、みたいな選択をしがちだけど、もう少し深く考えて違う方法はないのか考えよう、と思いました。

rails g authenticationから学ぶRails8.0時代の認証

スライド

3行メモ

  • rails8から提供されているrails g authenticationについて内部を理解しよう！
  • 認証機能のセキュリティを担保するには我々が頑張る必要がある
  • しばらくはdeviseが使われるだろう

iCARE時代にお世話になっていたwillnetさんのセッション。Rubyに触れて始めてOSSや、内部構造を理解したいと思う感情を持った事を思い出しました。業務でこの認証ジェネレータを使う事はしばらくないと思うけど、内部構造の理解はやっぱ楽しいですね。個人開発とかで使ってみたいなぁと思いました。

まとめ

セッションに関してはここまでで、ランチや懇親会でいろんな方とお話ししました！2日という期間はやはり短いですね。お話ししたかった方が他にもたくさんいたのですがなかなか話せず...春のRubyKaigiではぜひ話しましょう！！

同じ会社の米sanとRubyistのメンバーでランチ！パンがとても美味しかった！！

ランチ1
ランチ1

タイミーさんのもちもちぬいぐるみが欲しくて2日連続でブースへ行きました。2日目に当たってよかったー！

timeeのもちもちぬいぐるみ

オフライン3年目も運営の皆様お疲れ様でした！！いつも楽しいカンファレンスをありがとうございます。
来年も今から楽しみだ〜〜。

Discussion