はじめに
こんにちは、エンジニアの id:kiryuanzu です。 2025年9月26日(金)、27日(土)の二日間で東京駅のJPタワー ホール＆カンファレンスにて Kaigi on Rails 2025 が開催されました。
弊社からは2025年度新卒メンバーを含む複数名のメンバーが参加し、弊社メンバーの id:da1chi24 が「Web Componentsで実現する Hotwire とフロントエンドフレームワークの橋渡し」というタイトルで登壇しました。
本記事では弊社エンジニア の id:kiryuanzu、新卒メンバーのakinko、id:nekobitsdreams、yuu.kun、id:kanapiiii の参加レポートをお送りします。
id:kiryuanzu
今回の Kaigi on Rails 2025に参加した id:kiryuanzu です。
去年は2日目のみの参加でしたが、今年は新卒メンバー4名+同僚の id:da1ch24 さん、id:kozy4324 さん と一緒に両日とも現地参加しました。
当日は様々な発表を聴講し、たくさんの刺激を受ける機会となりました。
ここでは 同僚の id:da1chi24 さんの発表と、id:hogelog さんの発表についての感想を述べていきます。
Web Components で実現する Hotwire とフロントエンドフレームワークの橋渡し
同僚としてプロポーザルのレビューをさせてもらったり、社内で行われた発表練習会のレビュアーとして関わったりしたのもあり、現地で聴講することができて大変嬉しかったです。
Web Components を Rails に導入する段階的な導入事例をシンプルなものから複雑な内容まで順を追って紹介しつつ、試行錯誤した点についてもしっかり盛り込まれていて15分の中でとてもボリュームのある構成となっていました。
社内の予行練習会では、id:dai1chi24 さん本人から「近い技術構成の他チームがこれから Hotwireを使う際にモチベーションを上げられるような内容を意識している」という話を聞いていました。
その時から更にブラッシュアップされた発表を現地で聞くことができ、これからチームで着手するHotwireでの開発への気持ちが高まりました！
"複雑なデータ処理 × 静的サイト" を両立させる、楽をするRails運用
当日の発表では、実務での経験を元にしたテーマの内容が多くありましたが、その中で筆者の好きなジャンルである個人開発をテーマに話されていた id:hogelog さんの発表も印象に残りました。
CRubyコントリビュータを可視化する「Ruby Contributors」というサイトを個人で開発した過程を述べられている発表でした。
作った動機が「自分のCRubyコントリビュートを眺めたい」という、まずは自分が一人目のユーザーということを意識して作られているのが個人開発ならではの動きだなと感じました。
Railsの開発経験を活かして複雑なデータ処理のバッチを書いてみたり、一般利用者が触れるのは静的サイトのみなのでセキュリティリスクを最小限に抑えることができたりと、無理ない範囲で楽しく運用できるバランスを見出されていました。
筆者自身もいまRails で動く個人のサービスを運用しているため、とても共感できる要素が多くありました。この発表を受けて、自分も手持ちのサービスの改良できそうなところを探して手入れをしたくなってきました。
終わりに
今回は過去最多の新卒メンバー4名の方々と参加し、去年登壇された id:kozy4324 さんに続き id:da1ch24 さんの発表を現地で見ることができたのがとても印象的でした。
ここでは紹介しなかった発表を含め、カンファレンスに参加した週明けの月曜からすぐに役立ちそうな話をたくさん耳にしました。それらの話を思い出しながら、私自身も次回の Kaigi on Rails ではプロポーザルを出せるよう日々開発に向き合っていきたいと思います！
akinko
今回は、新しい用語や知識、そしてスピーカーの方々の経験から得られるティップスを通して、カンファレンスならではの醍醐味を感じられる回でした。スライドや話の内容が難しくても必死に食らいつきながらメモを取り、学びを深めました。Railsひとつを取っても、さまざまな観点や視点から課題や解決策が語られ、その議論は尽きることがないのだと実感しました。さらに、今回のカンファレンスに関連したイベントも多様で非常に楽しく、人との交流もあり、思い出に残る一日となりました。特に印象に残った3つのセッションを紹介します。
Keynote: dynamic!
プロジェクト立ち上げ時には「こういう機能もあったら嬉しいんじゃないか」とアイデアが次々に浮かびますが、そういう瞬間こそ冷静さが求められるのだと学びました。「ハッピーパス」という言葉は初耳でした。最もシンプルで、うまくいきそうなものだけをまず形にすることで、議論や開発、その後の拡張も軽やかかつスムーズになり、より現実的で効率的に進められることがわかりました。今後の業務では、新しい機能や要件が出たときに、まずは最低限の機能を備えたプロトタイプを作るところから始めたいと感じました。
もう並列実行は怖くない コネクション枯渇とデッドロック解決の実践的アプローチ
これまで人間が担っていた作業をAIに置き換える場面は今後ますます増えていくと考えられます。その際、人間の操作とAI処理を並列実行する中で生じる問題は、多くの企業が直面する可能性が高いと感じました。セッションを通じて、別プロセス化やコネクションプールサイズの調整といった工夫によって、コネクション枯渇の課題を解決できることを学びました。特に、数々の問題に直面しながらも原因を丁寧に分析し、設定を見直し実装を重ねることで、リサーチ件数を1日3,500件から45万件へと大幅に拡大させた事例は、大きな成果であり非常に印象的でした。
GraphQL×Railsアプリのデータベース負荷分散 - 月間3,000万人利用サービスを無停止で
テレビ放送後にアクセスが集中し、サービスダウンにつながった事例は決して他人事ではないと感じました。せっかく興味を持って調べてくれた新規ユーザーを失ってしまうのは大きな機会損失であり、こうした現象を事前に防ぐように設計しておくことが重要だと学びました。興味深かったのは、通常時は検索でヒットした商品ページからアクセスするためキャッシュが効いていたのに対し、放送後はサービス名で検索したユーザーが多く、キャッシュを効かせていなかったトップページにアクセスが集中した点です。ユーザーの動きによってシステムへの影響がこれほど変わるのだと実感しました。
Classiでも「欠席連絡」画面に朝アクセスが集中するため、ある程度の動きを予測して対策をとっていますが、今回のように例外的な動きがあった場合でも、その変化を推測し、未然に備える必要があると強く感じました。今後は日頃からユーザーの行動を意識し、柔軟に対応できる設計を心がけたいと思います。
最後に
今回登壇されたエンジニアの方や会社の先輩方が、普段どのようなことを考え、リスクを察知して設計・開発を行っているのかを学ぶことができました。私はまだ新卒でリスクの高い箇所を担当することは少ないですが、「どんなリスクが起こり得るか」を意識してアンテナを張ることは今からでもできます。今後は自社のサービス全体の状態をより気にかける姿勢を大切にしていきたいです。
id:nekobitsdreams
現在、私はRailsをふだん使わないチームに所属しており、Kaigi on Railsでの話についていけるか不安でしたが、Kaigi on RailsではRailsに限らない設計に関する話も多くとても楽しめました。
今改めてServiceクラスについて考える 〜あるRails開発者の10年〜
チーム開発におけるソフトウェア設計の難しさについて考えさせられました。中でもServiceクラスは実際の仕事の現場では出来る限り使わないほうが良いと仰られたのには驚きが有りました。
当初は複数のモデルにまたがる複雑なビジネスロジックを表現するにはServiceクラスを用いるという認識があり、Serviceクラス無しで表現するのはコードの肥大化を招くのではと思っていました。
ですが、講演を聞いていく中で自分の中で一定の理解を得ることができました。それは、チーム開発における「共通認識」の重要性です。Railsなどのフレームワークにおける利点として「どこに何が書かれているか」という共通認識が存在するが、Serviceクラスという層を追加すると、想像がつきにくくなり、全体像の把握が難しくなるということです。Serviceという名前も曖昧で開発者ごとにServiceクラスの解釈がバラバラで実装に差が生じてしまう点も納得です。
一方でServiceクラスが活きる場面も紹介されており、一概にダメでは無いという点も考えさせられました。ServiceクラスやFormクラスはあくまで表現技法の一つに過ぎないので、ドメインコンテキストを理解し、ビジネスの変化に合わせて継続的に改善し続けることを頭におき、チームメンバーや、ユーザーにとって驚きが少ない開発をしていけるようにしていきたいと思いました。
「技術負債にならない・間違えない」権限管理の設計と実装
権限の管理はとても重要です。Classiでは学校に関する情報を取り扱っています。他校の生徒情報や、先生しか閲覧することのできない情報など、権限管理が重要なサービスのため技術的な方法で事故が起きないように取り組むなどの対策を行っています。
そんな中、本講演ではadminという名前の権限を使った判定はアンチパターンだと言う話には正直驚きがありました。多くの記事やチュートリアルでadminという話は出てくるので当たり前の概念として認識していまいた。ですが、実際はadminの中にも様々な役割が出てきてsuper_adminなどの概念も出てきてしまうというのもあるので難しい話だなと思いました。発表の中でも役割が変わったり、機能が追加されたりすることで変わっていくものだと仰られていたようにadminという名前は変更に弱いのだなと知ることができました。
ではどうするのか、adminではない名前を変えた役割を作るのだろうかと思いましたが、そうではありませんでした。役割に依存した実装は権限が暗黙的になってしまうため、レビュアーは常に役割ごとの権限を把握する必要が発生してしまいます。そこでcan_〜〜?（〜〜を実行可能か？）というユーザーが何を行えるのかを明示的に書く方法です。これによりコードの意図は明確となり、役割の変化にも強い実装となるというのには納得でした。実装の方法は更に工夫があったのですが、ここでは省略させていただきます。
権限管理においてもビジネスの変化に合わせて継続的に改善し続けられるということが重要で、変更に強い実装を心がける必要があるのだなと感じました。
最後に
今回、Kaigi on Railsに参加する支援をしてくださったClassiの皆様に感謝いたします。今回は非常に多くの刺激や知識を得られたと思っています。この経験を業務に活かせるよう日々努力していきたいと思います。
yuu.kun
みなさんこんにちは！2025年度新卒エンジニアのyuu.kunです！
今回は、Kaigi on Rails 2025にて設計について興味深い登壇があったので紹介しようと思います。
なぜ「設計」が興味深いか
私が「設計」という分野に強く惹かれるのには、明確な理由があります。
第一に、フレームワークなどの技術は急速に変わっていきますが、その根底にある設計思想自体は変わらない「普遍性」があるからです。
第二に、設計の考え方は、開発だけでなく仕事の進め方など他分野にも応用が効く「汎用性」があるからです。
そして最後に、私自身が研修で悩んだ際、「あの時この概念を知っていれば、もっと楽だったはずだ」と痛感した「実体験」があるからです。
だからこそ、設計は今学ぶべき本質的な技術だと感じています。
Railsによる人工的「設計」入門
株式会社万葉の社長である大場さんの登壇です。 私が所属しているチームにも万葉の方が在籍しており、大場さんがどのようなお話をされるのか気になって拝見しました。
この登壇は、「設計とは何か」を理解するために、まず「設計を体得できていない状態」とは何かを具体的にイメージしながら理解を深めていく、というユニークな内容でした。ここで「状態」という言葉を選ぶあたりがエンジニアらしく、個人的に好きなポイントです。
以前、Classiの研修でゼロからプロダクトを設計する機会がありましたが、その時私が考えたのは「DB→モデル→コントローラー→ビュー」という実装の「手順」でした。しかし大場さん曰く、それは設計ではなく手順である、とのこと。
では設計とは何か。大場さんは、設計とは「逆算」で考えるものだと提唱しています。 まずは「完成したシステム」を想像し、次に「中核的な価値の実現」にフォーカスする。そして「そのためには何が必要か？」を順々に掘り下げ、全体像を明らかにしていくアプローチです。
私が考えたような実装の流れを「順算」とするなら、大場さんの考え方はまさしく「逆算」です。この逆算思考は、作りたいものの抽象的な構想から、必要な要素という具体的な構想へと落とし込んでいくため、様々な場面で応用できます。
また、目的を達成するための手段も複数考えやすく、比較検討しやすいので、初学者でなくても非常に有用な概念だと感じました。 説明が明快で、色々な場面に活かせるお話だったので、エンジニアに限らず多くの方におすすめしたい発表です！
Railsだからできる、例外業務に禍根を残さない設定設計パターン
株式会社坂ノ途中さんのeiichiさんによる登壇です。 この登壇では、避けられない「例外業務」と、その問題にどう立ち向かうかといったテーマでした。
坂ノ途中さんの事業は、生産者からお客様へ野菜を届けるというもので、そういったオペレーションの中で、様々な例外業務が存在するといいます。
しかし例外業務は、引き継ぎが困難だったり、仕様変更時の影響範囲が不明瞭になったりと多くの問題を生み出すため、システム担当者が全てを実装し続けるのは現実的ではありません。なので業務担当者が掌握（運用・メンテナンス）できるようにしていくことが肝心になります。それを叶えるためにeiichiさんが提唱するのが、例外を「設定」として捉え業務担当者が主体的に運用・メンテナンスできるようにするというアプローチです。
ここでの「設定化」とは要件を段階的に実装していく手法を指します。具体的には「変更の多さ」「設定パターンの複雑さ」を軸に、6段階の実装パターンから最適なものを選択・適用します。このアプローチによって過剰な実装や実装不足を防げるだけでなく、段階的に進める中でプロダクトへの理解が深まる「ドメインの蒸留」にも繋がり、システムの柔軟性を高める効果も期待できます。
この「設定」という考え方は例外処理だけでなく、複雑になりがちな業務を処理する上で非常に有効な手段だと思います。
今回の発表を通して、例外業務に向き合う上での考え方について学ぶことができました。
私の現在の業務においても、標準的な機能開発とは異なる例外業務の可能性について考えることがあります。例えば、私が担当している保護者連絡サービス「tetoru」の欠席連絡機能では、欠席・遅刻・早退の理由を、あらかじめ用意された選択肢の中から選ぶ仕様になっています。
以前から複数の学校より「うちの学校独自の欠席理由を追加してほしい」という個別の要望が寄せられていました。この課題に対するアプローチとして、まず、各学校が管理画面から自由に欠席理由を追加・編集できる「カスタマイズ機能」を開発することをチームで検討していました。
tetoru（テトル）プレミアムプランに新機能「欠席連絡カスタマイズ」を2026年4月から提供開始（予定）いたします | Classi（クラッシー） - 子どもの無限の可能性を解き放ち、学びの形を進化させる
このような汎用的な機能開発ではなく、要望をいただくたびに私たちtetoru側が個別に理由を追加していくといった「例外業務」での対応をするといった方法ももう一つの選択肢としてあり得たのではないかと考える機会となりました。
終わりに
今回は、設計というテーマで、登壇されたお二人の紹介をしました。
このように日々の業務課題を解決するヒントやアイデアを見つけられるのも、Kaigi on Railsの楽しみの一つだと感じました。
また、gifteeさんの新卒エンジニアの方との出会いや先輩方に知り合いのエンジニアの方を紹介していただき大変刺激を得られる機会でした。
こういった付き合いは大事にしていきたい限りです！
id:kanapiiii
このたび、Kaigi on Rails 2025 に初めて参加しました。
Rubyは研修の中で少し触れた程度で、私はまだ初学者です。ですが、先輩のid:kozy4324さん、id:kiryuanzuさん、id:da1chi24さん に案内していただき、緊張することなく交流の場を楽しむことができました。その中で yumuさん を紹介していただき、つながりを持てたことがとても嬉しかったです。
Railsアプリから何を切り出す？機能分離の判断基準
内容を聞きながら「機能分離を判断するのは、機能実装経験が少なく、失敗から学ぶ機会もこれからだと感じたので、まだ自分には先のことだ」と思っていました。ですが、一番心に残ったのは「失敗から学び、判断基準を磨く」という言葉です。
5つの判断軸があり、チームの状況によって重みが変わるため、常に判断基準を磨き続けることが大事だというお話がありました。完璧な分離や実装はなく、状況に応じて変化していくものだと学び、失敗を恐れず挑戦していこうという気持ちになりました。
お友達の発表を聞き、「いつか自分も登壇してみたい」と思うようになり、ロールモデルを見つけられたことが大きな刺激になりました。
Railsアプリケーション開発者のためのブックガイド
日頃から本を読むことが多い私にとって、一番興味を持った講演でした。 本を購入して積読してしまうことが多いので反省していましたが、高橋さんが「読まない・積読する」と話されたのは衝撃的で罪悪感がなくなりました。
特に印象に残ったのは、
- 「本はみんなが同じものを読める」こと
- 「共有財」としての価値があること
というお話です。社内で参加している読書会も、まさに共有財として機能していると感じました。Railsに限らず、他の言語を学ぶ際にも参考になる本ばかりで、気づけば紹介された本を購入していました。すでに持っていた本もあり、改めて読み返したくなりました。
今回のカンファレンスでは、知らない単語も多く理解が点になる部分もありました。ですが、それ以上に「もっと勉強したい」という強い刺激をいただきました。
来年は、自分の意見を持ちながら講演を聞けるように、日頃から技術を磨き、本を読み、イベントに参加して学びを深めていきたいと思います。
まとめ
以上、Classiメンバー5名による参加レポートをお届けしました！ 来年もぜひ、Kaigi on Rails 2026 でお会いしましょう！
