こんにちは。フィードフォースのエンジニアの thiger7 です。 2024年10月25日〜26日に開催された「Kaigi on Rails 2024」に参加しました。

Kaigi on Rails に初めて参加しましたが、とても良い刺激をもらったので記事にさせていただきます。

Kaigi on Rails 2024 への参加を通じて

Kaigi on Rails 2024 への参加を通じて、当初掲げていた「技術カンファレンスへの第一歩」「エンジニアとの交流」「先進的な技術事例の収集」という3つの目標を達成することができました。

特に印象的だったのは、技術コミュニティへの貢献者たちの姿勢です。最新技術への探求心と、その知見を惜しみなく共有する姿に刺激を受け、自分も技術事例の創出と共有に挑戦してみたいという意欲が湧きました。会場全体の熱量は、まさにエンジニアコミュニティの醍醐味を体現していたように思います。

また、普段の業務では気づきづらい視点や、明日から使えそうな実践的な知見との出会いは、自身の業務へのモチベーション向上にもつながりました。特に、企業やチームとしてコミュニティに参加する姿勢から、技術組織としての在り方について多くを学ばせていただきました。

Rails way に従うだけでは解決できない複雑な現実の課題に対して、様々な企業が生み出している実践的な解決策を知ることができたのも大きな収穫でした。これらの知見は、既存サービスの改善にも活かせる貴重なヒントとなりました。

今後への展望

今回の経験を通じて、技術コミュニティへの貢献が企業認知の向上や社内モチベーションの醸成に大きく寄与することを実感しました。来年の Kaigi on Rails 2025 は東京駅での開催が予定されており、よりアクセスしやすい環境での開催に期待が高まります。

Kaigi on Rails 2024 で得た知見と情熱を、日々の業務や自己研鑽に活かしていくとともに、いつか自分自身も知見を共有できる立場になれることを目指していきたいと思います。

イベント概要

開催概要

Kaigi on Rails 2024

日程：2024年10月25日（金）〜26日（土）
会場：有明セントラルタワーホール
形式：オンライン・オフラインのハイブリッド開催

「初学者から上級者までが楽しめるWeb系の技術カンファレンス」をコアコンセプトとする Kaigi on Rails は、技術カンファレンスへの参加障壁を下げることを意図して企画されています。また、Rails を中心としながらも、フロントエンドやプロトコルなど、Web に関する幅広いトピックを扱うのが特徴です。

参加規模

今回の Kaigi on Rails 2024 は、過去最大となる692名の参加者を迎え、Rails 技術カンファレンスとしての注目度の高まりを示す結果となりました。参加希望者が多数だったため途中で枠を追加したものの、それでも参加をお断りせざるを得ないほどの盛況ぶりでした。

参考として、2024年に沖縄で開催予定の RubyKaigi は1,400名の参加者を予定しており、Ruby および Railsコミュニティの活況ぶりが伺えます。これらの参加規模は、Webアプリケーション開発において Rails が重要な選択肢であり続けていることを示すとともに、実践的な技術知見への需要の高さを表していると思いました。

主要トピック

カンファレンスでは、現代の Rails 開発における重要なテーマが幅広く取り上げられました。

パフォーマンスと最適化
- Ruby と Rails のパフォーマンス特性（Goとの比較）
  - メモリ管理、GVL、スレッドモデルなど低レイヤーの考察
- OpenTelemetry を活用したパフォーマンス分析手法
- フラグメントキャッシュの効果的な活用
アーキテクチャと設計パターン
- Form オブジェクトの実践的な採用事例
- GraphQL のカスタマイズ手法
- フロントエンド戦略：Hotwire/Stimulus vs React（SPA）
- One Person Framework の考え方
技術的負債への取り組み
- Ruby/Rails バージョンアップグレードの実践
- ERB から ViewComponent への大規模移行
- バックグラウンドジョブ実装：Sidekiq と Solid Queue の比較検討
セキュリティと運用
- 最新の CSRF 対策ベストプラクティス

これらのトピックは、現代の Rails アプリケーション開発が直面する課題と、それに対する実践的な解決アプローチを網羅的に扱っており、参加者それぞれの課題に応じた知見を得られる構成となっていました。

講演内容

以降のレポートでは、参加したセッションの内容や、得られた気づきについて詳しく共有していきます。

Day 1 - 10/25（金）

11:05 〜 11:10 スポンサーLT1 | DeNA on Rails

LT概要

DeNA さんの Ruby on Rails を活用したサービス開発事例として、声で繋がるライブ配信アプリ「Voice Pococha」などの紹介がありました。「一人ひとりに想像を超えるDelight」というミッションのもと、スモールチームでの大規模アジャイル開発を実践し、高いパフォーマンスと品質にこだわりながら開発を進めているとのことでした。

感想

技術スタックとして Ruby on Rails を選択しつつ、小規模チームの機動的な開発アプローチが印象的でした。特にパフォーマンスと品質へのこだわりと共に、「一人ひとりに想像を超える Delight」というミッションを掲げている点に、現代のサービス開発における技術と理念の調和を感じました。

11:10 〜 11:15 スポンサーLT2 | minne の Shoryuken 活用

LT概要

GMOペパボさんの「人類のアウトプットを増やす」というミッションのもと、minne のサービスにおける技術活用についての紹介がありました。特に Amazon SQS と Shoryuken を活用した非同期処理基盤について、AI による作品説明文作成や動画変換処理などの具体的な活用事例が共有されました。 Shoryuken の高いスケーラビリティや信頼性、CloudWatch によるモニタリング性能などについて、Sidekiq との比較を交えながら解説がありました。

感想

非同期処理基盤の選定において、各ツールの特性を深く理解した上での比較検討が印象的でした。特に Shoryuken の活用事例とその特性の解説を通じて、現代のシステム開発における技術選定の考え方について学ぶことができました。

11:15 〜 11:20 スポンサーLT3 |クラシルの現在とこれから

LT概要

クラシルさんの開発規模や取り組みについて、3年前との比較を交えながら紹介がありました。マネージドサービスへの移行による障害低減や、AWS Bedrock API（Claude3 sonnet）を活用したレシピデータの構造化・基準判定の仕組みについて具体的な解説がありました。レシピの構造化によって UI・UX の改善や Google クローラーの理解度向上につながり、公式レシピ・UGCレシピともに「きちんと美味しく作れる」ことを目指しているとのことでした。

感想

レシピプラットフォームにおけるAI活用、特に AWS Bedrock API を用いたコンテンツの基準判定と構造化の取り組みが印象的でした。技術的な改善が直接的にユーザー体験の向上と SEO 改善につながっている点に、現代のサービス開発における技術活用の理想形を見ることができました。

11:20 〜 12:00 基調講演 | Rails Way, or the highway

講演概要

「Rails Way, or the highway」というテーマで、Rails を他のものと混ぜるのではなく、拡張していくアプローチについての基調講演がありました。フレームワーク作者の視点を持ち、Presentation・Application・Domain・Infrastructure といった抽象化レイヤー間の明確な境界設定や、既存の抽象化からの抽出の重要性が解説されました。特にフォームオブジェクトの担当分野の明確化や、全ての抽象化におけるベースクラスの必要性など、実践的な知見が共有されました。

感想

レイヤードアーキテクチャと Rails の対応表を用いた説明が非常に分かりやすく印象的でした。Rails の拡張において「混ぜ合わせる」のではなく「拡張する」というアプローチと、明確な境界設定の重要性について、具体的な実装レベルでの示唆を得ることができました。

13:30 〜 14:00 Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング - | Kaigi on Rails 2024

講演概要

「Rails の仕組みを理解してモデルを上手に育てる」というテーマで、モデルの発見や分割のタイミングについて解説されました。 PORO の活用や、サービス層を避けてイベント型モデルを丁寧に探すアプローチ、そしてモデルの肥大化の判断基準について具体的な解説がありました。特に、フォーム用とDB用のバリデーションについて、初期段階での共有のメリットと、時間経過に伴う分離の必要性について、ActiveModel::Attributes や ActiveModel::Model を用いた実践的な知見が共有されました。

感想

モデルの肥大化を単純なコード行数ではなく、「バリデーションを条件分岐したくなったとき」という具体的な状況で判断する視点が印象的でした。また、フォーム用とDB用のバリデーションの分離について、「時間経過とともに良い設計が変わっていく」という考え方から、初期段階での共有と段階的な分離の重要性について学ぶことができました。 Rails の練習帳についても一読しようと思います。

参考 Railsの練習帳

14:10 〜 14:25 そのカラム追加、ちょっと待って！カラム追加で増えるActiveRecordのメモリサイズ、イメージできますか? | Kaigi on Rails 2024

講演概要

カラム追加が ActiveRecord のメモリサイズに与える影響について、具体的な数値とともに解説がありました。 integer型を1カラム追加するごとに、 224バイトものメモリ増加が発生することが示されました。一方で、Ruby 3.2 から導入された Size Pool 機能により、文字列の埋め込み可能範囲が23バイトから615バイトへと大幅に拡大され、メモリ使用の最適化が進んでいることが紹介されました。

感想

普段何気なく行っているカラム追加が、実はかなりのメモリ消費を伴うという事実が印象的でした。また、Ruby 3.2 での Size Pool 機能による最適化など、言語レベルでの改善が進んでいることを知り、パフォーマンスを意識したスキーマ設計の重要性について改めて考えさせられました。

14:35 〜 15:05 モノリスでも使える！OpenTelemetryでRailsアプリのパフォーマンス分析を始めてみよう | Kaigi on Rails 2024

講演概要

「モノリスでも使える！OpenTelemetry」というテーマで、Railsアプリケーションのパフォーマンス分析について解説されました。 OpenTelemetry の導入により、分散トレーシングを用いたログとトレースの関連付けが容易になり、導入・運用コストがメリットを下回るようになったことが解説されました。特にモノリシックなアプリケーションでも有効な分析手法として、具体的な実装方法や活用事例が共有されました。

感想

従来は導入・運用コストが高いと考えられていた分散トレーシングが、OpenTelemetry によって現実的な選択肢となった点が印象的でした。モノリシックなアプリケーションでも活用できる点が示され、自身のプロダクトでも分析に取り入れてみたいと強く感じました。

15:45 〜 16:00 カスタムしながら理解するGraphQL Connection | Kaigi on Rails 2024

講演概要

「カスタムしながら理解するGraphQL Connection」というテーマで、GraphQLにおけるページネーション実装について解説されました。 GraphQL Connection を用いたページネーションの実装方法と、独自モデルでの Connection 実装には Custom Connection が利用できることが解説されました。特に offset を利用する際の遅延評価について、Promise クラスを用いた具体的な実装手法が共有されました。

感想

GraphQL Connection の実装において、Custom Connection を活用した柔軟な実装方法が印象的でした。特に Promise クラスを用いた遅延評価の手法は、パフォーマンスを考慮したページネーション実装の具体例として、実践的な知見を得ることができました。

16:10 〜 16:40 リリース8年目のサービスの1800個のERBファイルをViewComponentに移行した方法とその結果 | Kaigi on Rails 2024

講演概要

「リリース8年目のサービスの1800個のERBファイルを ViewComponent に移行した方法とその結果」というテーマで、大規模な移行プロジェクトの実例が共有されました。 ViewComponent の主要なメリットとして、ロジックの分離、テストのしやすさ、インターフェースの明示性、そして10倍高速という大幅なパフォーマンス向上を実現できるとの説明がありました。また、既存の ERB ファイルを元にした自動生成による工数削減の手法も紹介されました。

感想

1800個もの ERB ファイルという大規模な移行プロジェクトにおいて、自動生成を活用した効率的なアプローチが印象的でした。特に ViewComponent への移行による具体的なメリットが、パフォーマンスの数値とともに示された点は、同様のリファクタリングを検討する際の重要な知見となりました。

16:50 〜 17:05 Rails APIモードのためのシンプルで効果的なCSRF対策 | Kaigi on Rails 2024

講演概要

「Rails API モードのためのシンプルで効果的な CSRF 対策」というテーマで、API におけるセキュリティ対策について解説されました。 CSRF 対策の基本として Origin ヘッダーの確認、より安全な実装として Fetch Metadata の確認や SameSite 属性の指定について具体的な解説がありました。特に「リクエストの出どころ」の確認が重要であり、Rails Viewではトークン方式、Rails API では Origin チェックを基準とした選択指針が示されました。

感想

CSRF 対策について、Rails View と Rails API それぞれの特性に応じた具体的な実装方針が示された点が印象的でした。特に API モードにおけるOriginチェックを中心とした段階的な安全性の確保方法は、実装時の明確な指針として参考になりました。

17:15 〜 17:45 現実のRuby/Railsアップグレード | Kaigi on Rails 2024

参考現実のRuby/Railsアップグレード

講演概要

「現実のRuby/Railsアップグレード」というテーマで、実務におけるアップグレードプロジェクトの進め方について解説されました。「余裕ができたらやる」という考え方では永遠に着手できない現実があり、必要に応じて外部リソースの活用を検討する提案もありました。特にアップグレードにかかるコストについて、ビジネス側に分かりやすく説明することはエンジニアの責任であり、そのための信頼関係構築の重要性が強調されました。

感想

アップグレードプロジェクトの推進において、技術的な課題だけでなく、ビジネス側とのコミュニケーションや信頼関係構築の重要性が示された点が印象的でした。「余裕ができたらやる」という考え方の危険性を指摘しつつ、現実的な解決策を示してくれた点は、実務での参考になりました。

17:55 〜 18:10 Hotwire or React? 〜Reactの録画機能をHotwireに置き換えて得られた知見〜

講演概要

「Hotwire or React?」というテーマで、Reactで実装されていた録画機能を Hotwire に置き換えた事例について解説されました。 Hotwire を活用する際には、画面遷移を紙芝居のように捉える視点が重要であることが示されました。特に実装の判断基準として、機能を CRUD に集約できるかどうかという観点が重要であることが共有されました。

感想

Hotwireでの実装において、「紙芝居」という分かりやすい概念で画面遷移を捉える視点が印象的でした。また、CRUD への集約可能性という具体的な判断基準が示された点は、今後のフロントエンド技術選定において参考になる知見でした。

Day 2 - 10/26（土）

10:00 〜 10:30 都市伝説バスターズ「WebアプリのボトルネックはDBだから言語の性能は関係ない」 | Kaigi on Rails 2024

講演概要

「WebアプリのボトルネックはDBだから言語の性能は関係ない」という都市伝説に対して、実測データを基にした検証結果が共有されました。 New Relic の分析から、I/O（DB）処理が65〜70%を占める一方で、Ruby の Giant VM Lock（GVL）の制約により同時にCPUを使える処理が1スレッドに限られる現状が示されました。特に Puma のスレッド数設定の重要性や、JSON.parse、libmysqlclient、Rack::Sessionに関する具体的なパフォーマンス改善のTipsが紹介され、Ruby 3.3 からは Go 言語に近いスレッドモデルが導入される展望も示されました。

感想

「Web アプリのボトルネックは DB」という一般的な認識に対して、実測データと具体的な検証結果を示しながら多角的な分析を行った点が印象的でした。特に Puma のスレッド数調整や Oj への置き換えなど、明日から実践できる具体的な改善策が示された点は、実務での即戦力となる知見でした。

10:40 〜 10:55 Cache to Your Advantage: フラグメントキャッシュの基本と応用 | Kaigi on Rails 2024

講演概要

「Cache to Your Advantage」というテーマで、Rails におけるフラグメントキャッシュの基本と応用について解説されました。キャッシュの基本概念から、キーベースのキャッシュ失効の仕組み、特にモデルのインスタンスからキーを生成し更新タイムスタンプを活用する手法が解説されました。また、アクション単位でのキャッシュを実現する gem の紹介と、session、cookies、current_user、flash、csrf_meta_tags などキャッシュ不可な部分には Turbo Frames を活用する方法が示されました。

感想

フラグメントキャッシュにおいて、キーベースのキャッシュ失効という「キャッシュを消さない方法」の考え方が印象的でした。特に実装上の制約事項を明確にしながら、Turbo Frames を用いた解決策まで示された点は、実務での具体的な実装指針として参考になりました。

11:05 〜 11:35 OmniAuthから学ぶOAuth 2.0 | Kaigi on Rails 2024

講演概要

「OmniAuth から学ぶ OAuth 2.0」というテーマで、認証（個人の識別）と認可（権限付与）の基本概念から、現代のWeb開発における実装方法について解説されました。 Rails における認証（authenticate_by、has_secure_password）と認可（cancancan、pundit、action_policy）の基本的な実装方法から、OmniAuth を用いた Google 認証の実装方法が解説されました。特に OpenID Connect におけるIDトークン（OpenID）とアクセストークン（OAuth）の違いや、OmniAuth.config.test_mode を用いたテスト手法について具体的な知見が共有されました。

感想

認証と認可の違いを「パスポート」と「チケット」という身近な例えで説明した点が印象的でした。また、実務でよく必要となる Google 認証の実装から、テストモードまでの一連の流れが示された点は、実践的な開発指針として大変参考になりました。

13:05 〜 13:20 約9000個の自動テストの時間を50分から10分に短縮、偽陽性率(Flakyテスト)を1%以下に抑えるまでの道のり | Kaigi on Rails 2024

講演概要

約9000個の自動テストの実行時間短縮と偽陽性率低減について、具体的な改善手法が共有されました。 Capybara の sleep 削除や Loading アイコン待機用 Helper の導入、test-prof の before_all や let_it_be を用いたデータ作成の最適化、parallel_tests による並列実行のためのファイル分割など、具体的な施策が紹介されました。また、Allure Report によるテスト結果の可視化や、capybara-playwright-driver の活用、only-failuresを用いた自動リトライの導入など、テストの安定性向上策についても解説がありました。

感想

テスト実行時間を50分から10分に短縮した具体的な手法が、実装レベルで示された点が印象的でした。特に test-prof や parallel_tests などのツールの効果的な活用方法や、Allure Report による結果の可視化など、実務での具体的な改善施策として参考になる知見が得られました。

13:30 〜 14:00 Hotwire光の道とStimulus | Kaigi on Rails 2024

講演概要

「Hotwire 光の道と Stimulus」というテーマで、Hotwire + Rails と SPAの特性の違いや活用方法について解説されました。 HTML・ブラウザの拡張、サーバ処理への対応、描画の拡張など、それぞれのアプローチの特徴について体系的な解説がありました。特に、登壇者自身が個人開発しているアプリケーションでの Stimulus の実践的な活用事例を通じて、具体的な実装パターンや使い道について詳しい知見が共有されました。

感想

Hotwire + Rails の実践的な活用方法、特に Stimulus の具体的な実装例が示された点が印象的でした。個人開発のアプリケーションでの実例を交えた説明は、実務での活用方法を考える上で非常に参考になる知見でした。

14:10 〜 14:25 The One Person Framework 実践編 | Kaigi on Rails 2024

講演概要

The One Person Framework の実践について、チームビルディングの観点から解説されました。チームの共通語彙を増やすことで認知負荷を下げ、「議論の余地」を減らしていく具体的なアプローチが示されました。特に「心地よくかつ自信を持って変更を加えられる」状態を目指し、フレームワークを通じてチームワークを発揮していく考え方が提案されました。

感想

「実家のような安心感」という例えを用いた開発体験の説明が非常に印象的でした。One Person Framework が単なる個人の開発効率化ツールではなく、チームの共通言語として機能することで、より良い開発環境を作り出せるという視点は、フレームワークの新しい可能性を示唆するものでした。"The way it used to be" という言葉に込められた、原点回帰としてのチーム開発の在り方について、深く考えさせられる内容でした。

15:05 〜 15:35 Tuning GraphQL on Rails | Kaigi on Rails 2024

講演概要

「Tuning GraphQL on Rails」というテーマで、GraphQLにおけるパフォーマンスチューニングについて解説されました。 N+1問題への対策として、lookahead、Shopify/graphql-batch、GraphQL::Dataloader の活用方法が紹介され、APM（Sentry など）を用いたパフォーマンス問題の特定方法が解説されました。また、サービスレベル指標（SLI）とサービスレベル目標（SLO）の設定方法、OpenTelemetry の活用、そして定期的なダッシュボード確認の重要性について具体的な知見が共有されました。

感想

パフォーマンスチューニングにおいて、技術的な解決策だけでなく、サービスの KPI と連動した指標設定の重要性が示された点が印象的でした。特に「カートインの数」のような具体的な指標と、チーム全体でダッシュボードを定期的に確認する取り組みは、実務での改善活動の具体的な指針として参考になりました。

15:45 〜 16:00 大事なデータを守りたい！ActiveRecord Encryptionと、より安全かつ検索可能な暗号化手法の実装例の紹介 | Kaigi on Rails 2024

講演概要

「大事なデータを守りたい！」というテーマで、ActiveRecord Encryption を用いたデータ暗号化と、より安全で検索可能な暗号化手法について解説されました。セキュリティ対策を入口・内部・出口の3つの観点から整理し、特に暗号鍵の管理方針や暗号化の単位、検索性能への影響について具体的な解説がありました。また、rails db:encryption:init による初期設定や、config.active_record.encryption.support_unencrypted_data = true を用いた既存データへの対応など、実装面での具体的な手法が共有されました。

感想

セキュリティ対策を3つの観点から体系的に整理し、各段階での具体的な実装方法が示された点が印象的でした。特に暗号化したデータの検索における制約と対策について、実務での活用を想定した実践的な知見が得られました。

16:10 〜 16:25 omakaseしないためのrubocop.yml のつくりかた | Kaigi on Rails 2024

講演概要

「omakase しないための rubocop.yml のつくりかた」というテーマで、開発体験向上のための取り組み方について解説されました。既存の定期MTGの中で少しずつ実施すること、意見が割れやすい設定についての具体的な合意形成方法（Slack での天気マークによる投票「賛成」・「反対」、「気にしない」）が紹介されました。特に成功要因として、メンバーの温度差を考慮したオーナーシップの醸成と、テスト文化や心理的安全性といったチーム文化の重要性が強調されました。

感想

売上に直結しない開発体験向上の取り組みを、具体的な実施方法から合意形成のプロセスまで示した点が印象的でした。特に「rubocop.yml はチーム文化の反映」という視点と、時間経過による変更ニーズへの対応を見据えた運用方法は、実務での改善活動において参考になる知見でした。

16:35 〜 17:05 Identifying User Identity | Kaigi on Rails 2024

講演概要

「Identifying User Identity」というテーマで、ユーザー情報の適切なモデリングについて解説されました。 ActiveRecordモデルのUserは主キーのidのみとし、メールアドレスやプロフィールは user_credentials や user_profiles として別テーブルに分離する設計手法が提案されました。また、登録中のデータを UserRegistration で管理することで状態管理を簡素化し、退会時も users レコードは維持したまま user_credentials のみを削除する手法など、実践的な設計パターンが共有されました。

感想

ステータスカラムを使わずにユーザーの状態を表現する設計アプローチが非常に印象的でした。特に個人情報の分離による利点（サービス利用開始時の離脱率低減、分析環境からの秘匿情報の隔離）や、管理スタッフを別モデルとして分離する考え方など、実務での設計判断に活かせる具体的な知見が得られました。

17:30 〜 18:10 基調講演 | WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと

講演概要

「WHOLENESS, REPAIRING, AND TO HAVE FUN」という基調講演で、ソフトウェア設計において「全体が機能するよう設計する」「変化に向けて設計する」という2つの重要な観点について解説がありました。正確なシステムコンポーネントの理解に基づき、標準的な解決策を用いて必要十分なシンプルな設計を行うことで、将来の変更に対するオプションを確保できることが示されました。特にRailsを「オプションのための設計をサポートするフレームワーク」として位置づけ、システムの修復の重要性、そして「楽しむこと」がプログラマの生産性を左右するという価値観が共有されました。

感想

複雑なシステムの変更において「元の状態に戻す」のではなく「変わった後の全体を見据えて作り直していく」という考え方が、システム設計の本質を突いていると強く感じました。特に Martin Fowler の「楽しさにはビジネス価値がある」という言葉とともに示された、技術と人間性を両立させることの重要性は、日々のプログラミングにおける私たちの在り方そのものを問いかける、非常に印象的な内容でした。カンファレンスの締めくくりに相応しい、技術だけでなく開発者としての心構えまでも考えさせられる素晴らしい基調講演でした。

Ruby on Rails — A web-app framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern.

楽しさにはビジネス価値があります 結局、モチベーションこそがプログラマの生産性を左右するのですから。
ー Martin Fowler

Don't forget to have fun!^^

その他内容・スライド

参加できなかった講演のスライドや内容については、以下のページにまとめられています。興味のある講演がありましたらこちらをご確認ください。多くの素晴らしい講演があり、特に印象に残った内容を中心にまとめさせていただきましたが、他の講演も非常に興味深い内容となっていますので、ぜひリンクから他の講演内容もご覧いただければと思います。

参考 Kaigi on Rails 2024 - ruby-jp

当日の様子

国際展示場駅

会場最寄駅の国際展示場駅です。

国際展示場駅での看板

駅構内にも Kaigi on Rails 2024 の看板があり、気分を上げてくれました。

フロアマップ

会場には、「Hall Blue」「Hall Red」「わいわい部屋」「もくもく部屋」があり、Wi-Fi 環境も整備されていました。オープニングでは、「急にコードが書きたくなったらもくもく部屋をご利用ください」との案内があり、会場が盛り上がっていました。

スポンサー一覧

たくさんの企業が協賛していました。

案内モニター

Kaigi on Rails 2024 のボックスがおしゃれに飾ってありました。

受付

続々と参加者の皆さんが集まっていました。

わいわい部屋

わいわい部屋では、コーヒーを配布しており、休憩や雑談など、自由に過ごすことができました。

各ブースの様子

一部ですが、各ブースの様子をお伝えします。各ブースとも、参加者が興味を示すような工夫がされていて、お祭り感がありました。

hacomono developers 様

プログミングスクール RUNTEQ 様

スマートバンク様

ANDPAD 様

SMS 様

ホールの様子

こんなにもたくさんの Rails エンジニアがいると思い、なんだか嬉しくなりました。

基調講演の様子

Day 1 の基調講演の様子です。会場の熱量や一体感はとても素晴らしかったです。

お弁当・公式ノベルティ配布会場

とんかつ弁当と天ぷら弁当が用意されていました。

また、公式のノベルティとして、Tシャツ・トートバッグ・ピンバッジの配布がありました。

懇親会

Day 1 の講演終了後、カンファレンス会場すぐそばの東京ベイ有明ワシントンホテルで懇親会が開催されました。

様々な企業のエンジニアの方々と交流する機会があり、それぞれの現場での取り組みや課題について興味深いお話を伺うことができました。プログラミングスクールから転職された方、SaaSプロダクトの開発に携わる方、事業会社でDX推進をされている方など、多様なバックグラウンドを持つエンジニアの方々との対話を通じて、業界の現状について多くの気づきがありました。

特に印象的だった内容について