はじめに
こんにちは！OPTiM Biz 開発チームの石原、河合、Optimal Remote 開発チームの市川、OPTiM ID 開発チームの吉村です。今回はオプティムから 4 名で Kaigi on Rails 2025 に参加してまいりましたので、会場の雰囲気や内容をレポートします！
Kaigi on Rails 2025 について
Kaigi on Rails 2025 は、Ruby on Rails を中心とした技術カンファレンスで、「初学者から上級者までが楽しめる Web 系の技術カンファレンス」というコンセプトで運営されています。Kaigi on Rails は 2020 年から実施されており、今回で 6 回目の開催となりました！ Rails の最新動向だけでなく、Web 開発に関わる幅広い知見が共有される場となっています。
私たちのチームでは Ruby on Rails を活用した開発を行っており、今回のカンファレンスでは、新たな知識や技術を学び、プロジェクトに応用できるものがあれば積極的に取り入れていきたいと考えています。
会場の様子
会場は東京駅直結の JP TOWER Hall & Conference。アクセスの良さもあり、多くの参加者で賑わっていました。
スポンサー企業による展示ブースも設置され、各社のプロダクト紹介や技術資料の配布、ノベルティ配布などで盛り上がっていました。waiwai ルームではコーヒーやお菓子が提供され、Rails 関連の書籍を販売しているブースもあり、参加者同士が気軽に交流できる雰囲気でした。
気になったセッション
石原
moro 氏の Keynote「dynamic!」を聴講しました。「dynamic」という言葉を、Ruby の特徴としてだけではなく、継続的に改善し、変化を起こすためのキーワードとして使われていたのが印象的でした。
このセッションで特に心に残ったのは 3 つの点です。
1 つ目は、IRB (Rails console) はソフトウェア仮説検証の最小単位であり、Ruby にとって感動的な存在であるという視点です。動かしながら学び、欲しいプログラムを作っていく「動的な開発の楽しさ」を改めて実感できました。
2 つ目は、Rails アプリケーション開発において「ハッピーパス」から始めることの重要性です。利用者が期待する最もシンプルな操作をまず実現し、そこから最初のフィードバックを得る。これにより、DB 設計やエンティティの命名といった基盤部分の価値が明確になることを学びました。
3 つ目は、「動くソフトウェアで会話する」という開発スタイルの提案です。ドキュメントベースではなく、レビュー会の場で実際にテスト環境にデプロイし、動くものを触りながら設計を議論する手法は、まさにアジャイル開発の思想と合致しており、私たちのチームでもぜひ取り入れてみたいと感じました。
全体を通して、「ハッピーパス」「継続的改善と動的な変化」「動くソフトウェアでの対話」というキーワードが印象に残り、Ruby や Rails の開発を楽しみながら継続的に進化させていく姿勢を改めて学べるセッションでした。
市川
権限管理は複雑になりがち……。しかし、権限管理の実装ミスは、取引先の情報を公開しちゃったなどといった結果を引き起こし、サービスや事業の大きな損失に繋がります。そのようなミスをしないようにどのようにコードを明快に書けばいいか。これがこの講演の内容でした。
条件をそのまま admin? で表現するような簡易的な分岐による実装をしてしまうと、admin? や manager? などの権限の種類が増え、ついには super_admin? といった謎のロールが誕生したり、条件が複雑になったりして、レビュアーも条件を把握しきれないなどといった技術負債になってしまいます。super_admin? の話が出てきたときは、半分笑っていましたが、たしかに何も考えずに実装したらやりかねないと思って、半分笑えませんでした（汗）。
そこで、解決策としてこの講演では、コードを対象、操作、役割、条件の 4 つに分割して実装することを提案していました。これはファイルを大量に分割するといったトレードオフを引き起こしますが、たしかにコードは読みやすくなっていました。特に事業への影響として、プロジェクトマネージャーが GitHub の 1 次情報、つまり直接ソースコードを確認して理解できるようになったというのが、素晴らしいと感じました。
河合
UI/UX が複雑なユーザー向け画面を作る際、React などのモダンフロントエンドは必ずしも必要ではなく、Hotwire でも十分に対応できるというのがこの講演の主旨でした。
Hotwire と Next.js を比較できるサイト Hotwire for Frontend devs も公開されていますが、Hotwire の使用感は問題ないように感じました。
さらに、Hotwire を使う場合でも、Stimulus で React のような One-way data flow を再現し、状態管理には Zustand を組み合わせることで、複雑な UI 開発も可能になると紹介されていました。
React がもともとリアルタイムダッシュボード用に生まれたという背景も説明されていました。現在では多くの Web アプリで React や Next.js が採用されていますが、その起源を考えると、すべての UI に React が必要というわけではないのではないかと考えさせられました。また、モダンフロントエンドは、ユーザー体験の向上というよりも DX や採用目的で導入されているケースもあるのではないかという指摘もありました。
講演者の Naofumi Kagami さんの Zenn の記事「フロントエンドのリプレイスに、いつまでかけるんだ？」も合わせて読むと、ユーザーの使用感がほとんど変わらない機能に対して、メンテナンスやリプレイスのコストをかけすぎるべきではないという考え方はとても納得感がありました。
開発者の好みが関係するような賛否両論あるテーマかと思いますが、モダンフロントエンドがスタンダードになっている現状に一石を投じるような内容でとても興味深かったです。
吉村
Rails による人工的「設計」入門 のセッションでは、「設計ができない人の状態って？」「そもそも設計って？」「設計ができない人が、なんとか設計できるようになるためには？」などといった内容が扱われました。実際には、設計のできる/できないは経験に依存するところもあり、そう簡単に習得はできないと思いますが、少しでも習得を早くするきっかけを作るための良いヒントが示されていたと感じます。
セッションの冒頭では、「設計」とは、コードのレベルで考えることなく、全体としてどういう構造、どういう技術的要素を使ってどんなものを作るのが良さそうか考えて、作業の段取りを考えてもよい状態にすることだ、という整理がなされました。それに続いて、設計に不慣れな人が強制的に設計をできるようになるために、「逆算」によるメソッドが紹介されています。ここでは、具体例としてユーザーの CSV インポート機能を挙げながら、逆算して設計活動を引き起こすためのポイントが示されました。逆算による設計手法の説明も大変よかったですが、個人的には資料の終盤に出てくる「デザインパーツ」の説明もおもしろかったです。デザインパーツ（再利用性のある小さな設計パーツ）を広く理解していれば、速く、妥当な設計ができるとされており、このデザインパーツの理解の獲得 = 技術イベントでの知識獲得、と言えるので、技術イベントに参加して学ぶことの意義が、イメージしやすくなったと感じます。
セッションの内容は資料によく整理されているため、Kaigi on Rails に参加できなかった方も、資料を読むだけでさまざまな学びを得られると思います。
おわりに
今回の Kaigi on Rails 2025 は、Rails の可能性を再確認するとともに、コミュニティの力を感じられるイベントでした。 引き続き、学んだ知見をチームやプロジェクトに還元し、より良いサービスを提供できるよう取り組んでいきます。
OPTiM では、Ruby on Rails を利用したアプリケーションを開発しています。ご興味のある方は、ぜひ一度ご連絡ください。
