アプリケーション基盤チームの深野です。
普段は社内の開発環境の整備やいくつかのアプリケーションのRuby/Railsのバージョンアップなど、SRE的な業務のインフラ寄りでない部分を主に行っています。
弊社では、業務時間内の扱いとして勉強会や技術カンファレンスに参加できる制度があるため、Ruby Kaigi 2024に続いて人生で2回目の大規模な技術カンファレンスとしてKaigi on Rails 2024に参加してきました。
Ruby Kaigi 2024とは異なり、Kaigi on Rails 2024は弊社は特にスポンサードなどはしていないのですが、快く送り出していただけました。
Kaigi on Railsとは
今回私の参加したKaigi on Rails 2024は、「初学者から上級者までが楽しめるWeb系の技術カンファレンス」をコアコンセプトにした技術カンファレンスです。
今年6月に弊社の大庭が参加レポートを書いたRuby Kaigi と異なるのは、名前の通りRuby KaigiがRubyという言語を中心にした技術カンファレンスであるのに対し、Kaigi on RailsはRailsを中心とした技術カンファレンスとなっています。
Ruby Kaigiに1回、Kaigi on Railsに1回しか参加していない技術カンファレンス経験の浅い自分がこれらを比較するなら、以下のようになるでしょうか。
- Ruby Kaigi
- 基本的に全てRubyに関する話題
- 開催地は全国各地
- セッションは基本的に30分
- Kaigi on Rails
- Railsに関する話題が中心だが、たまに直接はRailsと関係ないものもある
- 開催地は今のところ全て東京都内(2025年は東京駅直通の建物内でやるそうです!)
- セッションは15分の比較的短いものと30分のもので分かれている
ただこれらは2025,2026...と続いていくとどんどん変わっていくかもしれませんし、感想としては参加者の顔ぶれや全体的な雰囲気など2つのイベントは色々似ているところも多いと感じました。
講演感想
どの講演も面白かったのですが、個人的に特に印象に残ったものの感想が以下になります。
1日目
Rails Way, or the highway(オープニングキーノート)
非常に濃密で中身のある発表で、スライドの中で出てくる言葉がとても印象的でした。特に
- Rails Way is a philosophy of building Rails applications
- Think as a framework author, not a custom application developer
という2つは優れたRails開発者になるためのマインドセットを的確に言語化してくれたと思いました。また、これらを実現するためにキャッチーな一言で終わるのではなく、
- 抽象化レイヤーの間に明確な境界を引いて、各抽象化は自身より下の情報しか見ないようにする
- RailsでデフォルトのMVCだけでは対応できない要件にぶつかった時には、Railsフレームワークの製作者のように考えてベースのclassを作ることで抽象化を実現する(こちらは少し私の解釈も入っているかもしれないです)
と言った具体的な方法論まで述べられていました。
今後Railsで開発していて単純な方法論としてのRails Wayでは解決できない問題(MVCだけで完結しない種類の要件を実装しないといけない時)にぶつかった時にどう対処するべきか、というマインドセットが手に入ったのは本当に大きかったです。
Ruby Kaigi 2024もそうでしたが、Kaigi on Rails 2024は贅沢なことに同じ時間に複数のセッションがあるため、懇親会などで昼間のセッションの話をしようとしてもなかなか同じセッションを聞けておらずあまり深い話ができないということがありました。
そんな中で、オープニングのキーノートセッションは参加者のほぼ全員が聞いていることで話題の中心になることが多かったのですが、今回のこの発表は分かりやすく、面白く、それでいて他の人にこの話題について色々語りたくなるというオープニングキーノートとして欲しいものが全てあって大満足でした。
現実のRuby/Railsアップグレード
私が最近の業務でRuby/Railsのアップグレードをしていると言うこともあり、タイトルを見た時点でかなり気になっていました。
実際に聞いてみた感想としても、自分が業務で今実際にやっていることや、これからやろうとしていることが多く紹介されており、共感できるとともに自分の今やっていることが大枠では間違っていないという自信になりました。
一方でこれまでの自分にはなかった視点の内容も多く、これから意識したり導入したりしたいというように思えました。特にこれから参考にしようと思ったのは、
- gemを導入するかどうかの判断基準として、もしそれの更新が止まったときに自分が保守したり、別のgemに置き換えられるかの視点を持つこと
- gemを導入する時には、Railsをモンキーパッチしているものは一見とても便利に見えても基本的に避けること
というgemの導入判断基準を紹介されているところでした。
実際にアップグレード作業をしていても、古かったりサポートが切れているgemの扱いにはよく困るので、次からはgem導入時にこれらの視点を持っていきたいです。
2日目
都市伝説バスターズ「WebアプリのボトルネックはDBだから言語の性能は関係ない」
Ruby Kaigi 2024でのosyoyuさんが作成したRubyプロファイラpf2についての発表である「The depths of profiling Ruby」が個人的にとても面白かったので、今回の発表についても是非聞きたいと思っていました。
実際に、発表内容はRuby Kaigi 2024での内容からある程度関連性がありつつも、Kaigi on RailsということもありWebサーバーにフォーカスした内容になっていました。
内容としては、「WebアプリのボトルネックはDBだから言語の性能は関係ない」という都市伝説を根拠を持って打ち砕いた上で、具体的にRubyとGoという異なる言語で実装されたWebサーバーでは、現実的な条件下でどのようなパフォーマンスの違いがあるのかを実際に検証して考察するものになっていました。
私は不勉強だったため、Ruby Kaigi 2024に参加したことで初めてRubyの言語的な制約であるGVLの存在や、Rubyの言語開発者がパフォーマンス上の問題にどのように立ち向かおうとしているかを知りました。本発表を聞いたことでそこから発展して、それらのRubyの制約やこれから導入される新しい機能が具体的にRubyによって構築されたWebサーバーのパフォーマンスとどのように繋がっているのかというところの一端に触れることが出来ました。Ruby KaigiとKaigi on Railsの橋渡しをしてもらえるような発表内容だったと個人的には思いました。
WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと(基調講演)
Kaigi on Railsを締めくくるラストの基調講演であり、これから成長していきたいエンジニアに向けられた発表内容はとても印象に残りました。
最初にタイトルを見た時には正直、どちらかというと抽象的な話なのかなと思っていたのですが、実際にはこれから経験を積んでいく段階のエンジニアが良いWebシステムを作れるようになるためにやるべきことが具体的にまとめられている内容になっていて、偶然かもしれませんが初日のキーノートとも上手く対応しているような関係にもなっていると思いました。
特に、うまく機能するWebシステムを作るために必要なシステムのWHOLENESS(全体性)への理解を深めるために、
- LB, CDN, キャッシュサーバー, Webサーバーなどのシステムコンポーネントがなぜそこにあり、どのように機能しているのかを知ることが重要
- なぜなら、設計とは現実世界の問題を1つずつ解いていくことの積み重ねにあるものだから
- 分散アーキテクチャやマイクロサービスなどは設計していった結果、「そうなる」もの
という主張がされていたのはとても納得感がありました。ただ流行りに飛びつくのではなく、基礎である要素技術への理解を積み重ねていったその先として新しいアーキテクチャを理解できることが優れたエンジニアへの道だと思うので、Webシステムの構成要素をそれぞれ地道に一歩一歩勉強していくことへの背中を押してもらえました。
おわりに
Kaigi on Railsは初参加でしたが、どの発表も面白かったり、共感できたり、ためになったりして色々な角度から楽しむことができました。
発表だけでなく懇親会でも以前同じ職場で働いていたエンジニアと話せたり、新しいRuby/Railsの機能を実際に運用している他社の人からリアルな感想を聞けたりしてとても充実感がありました。
Ruby KaigiもKaigi on Railsもチケットが売り切れるのがかなり早いので、来年以降に参加しようと思っている方はチケットが販売されたら早めに購入することがおすすめです!