今年もペパボは、Kaigi on Rails 2025に参加してきました！
登壇・一般参加・運営スタッフなど、それぞれのイベントへの関わり方で楽しみました。
この記事では、私たちがどのようにイベントを過ごしたのか、印象に残った出来事や感じたことなどを、それぞれの視点からお届けします！
Kaigi on Rails とは
Kaigi on Rails のコンセプトは「初学者から上級者までが楽しめるWeb系の技術カンファレンス」です。その名前の通り、Ruby on Railsを中心としながらも、Webに関する話題を幅広く取り扱うのが特徴です。例えば、フロントエンド技術、プロトコル、設計手法、決済などをテーマにしたトークも行われています。
初回の2020年にオンラインで開催されたことを皮切りに、2023年からはオンラインとオフラインのハイブリッド形式で開催されています。2025年の今年は3度目のハイブリッド開催で、オフライン会場はJPタワー ホール＆カンファレンスで行われました。
登壇者のレポート
yumu
minne事業部の@yumuです。今回「Railsアプリから何を切り出す？機能分離の判断基準」というテーマで登壇しました。
発表内容
13年以上運営されているminneでは、コアとなるRailsアプリケーションのコードベースの複雑化やDBパフォーマンスの悪化といった課題に直面し、様々な機能の分離を検討・実施してきました。しかし、その都度「この機能は分離すべきか」という判断に悩まされていました。
そこで、2年間で経験した様々なプロジェクトの中で得た知見を体系化し、5つの判断軸として整理しました。
| 判断軸 | 分離推奨 | 要検討 | 分離回避 |
|---|---|---|---|
| ビジネスロジックとの関連度 | 低 | 中 | 高 |
| インフラ依存 | 弱 | 中 | 強 |
| 複雑さ | シンプル | 中 | 複雑 |
| 運用コスト vs 開発スピード | 開発スピード重視 | バランス | 運用コスト重視 |
| ビジネス上の柔軟性 | 求められる | 中程度 | 求められない |
1. ビジネスロジックとの関連度 コア機能（商品管理・注文・決済など）や複数テーブル・モデルと密結合している機能は分離を避けるべきです。一方、技術的処理や分析系の機能は分離候補になります。
2. 他インフラリソースとの依存関係 MySQLの直接参照や認証基盤への依存がある機能は分離が困難です。S3経由でのデータ受け渡しや、異なるDB（BigQuery、DynamoDBなど）を使える機能は分離可能です。
3. 機能の複雑さ 単一責任で外部依存が少ないシンプルな機能は分離しやすいです。複数サービス連携やデータフローが複雑な機能は要検討となります。
4. 運用コスト vs 開発スピード 複数デプロイパイプラインの管理などで運用コストは増えますが、独立したリリースサイクルにより開発スピードが向上するというトレードオフがあります。
5. ビジネス上の柔軟性 他サービスでの活用可能性や、ビジネス判断による機能の切り離しやすさといった柔軟性の観点も重要です。
これらの軸で評価し、3つ以上が「分離推奨」なら積極的に検討、2つ以上が「分離回避」なら慎重に判断するという基準です。発表では、動画変換機能やアナリティクス機能の成功事例、リワード広告機能の要注意パターン、サブスクリプション機能の分離回避事例などを紹介しました。
登壇を終えて
今までの登壇の中で一番規模の大きいカンファレンスだったのでとても緊張していましたが、社内のメンバーの協力もあって無事やり遂げることができました。発表後、多くの方から「同じような悩みを抱えていた」「今度からその基準を使ってみたい」といった反響をいただき、とても嬉しかったです。小規模チームでの現実的な課題と向き合いながら作った判断基準が参考になったのであれば幸いです。
昨年のKaigi on Rails 2024ではスポンサーLTをさせていただき、Rubyコミュニティの温かさに触れました。私がRubyコミュニティにさらに一歩深く踏み込む転機となったカンファレンスでした。今年は登壇という形で参加し、さらに多くの学びと刺激を得ることができました。また来年も参加、できれば登壇できると嬉しいです！
一般参加者のレポート
akatsuura
EC事業部の@akatsuuraです。今年は一般参加でトークと廊下を楽しみました。
印象に残ったできごと
私がRubyistになるきっかけとなった書籍のことを思い出し、著者の方々にサインをいただけたことが会期中の廊下での良い思い出となっています。
Keynote: dynamic!の中では価値を生むために継続的な変化をし続けることを「動的、dynamic」と表現し、それを実現するためのRubyとRailsによる開発の手法や、チームによるプロダクト開発の考え方が紹介されていました。そして、その動的な開発を「たのしい」と繰り返しお話しされていました。
私はこのトークを聴いて、「たのしい」という言葉から「たのしい開発 スタートアップRuby」という書籍のことを思い出しました。この書籍は、Rubyの入門書という立ち位置ではありますが、Rubyをとりまく文化、コミュニティの解説が詳細に書かれているのが特徴的で、この書籍の中でも「たのしい開発」の話が繰り返し登場します。私がRubyistになるにあたり大きな影響を受けた本であり、なぜ自分がRubyを使う仕事を選んだか、というのを思い出すとても良いきっかけとなりました。
そこで、2日目に家の本棚にあったこの本を会場に持ち込み、会場にいらっしゃった著者の大場さんと櫻井さんにお礼を伝えつつ書籍にサインをいただくことができました。実はこの本には既に著者の一人である五十嵐さんからサインをいただいていたので、12年ぶり(!)に書籍にサインが増えることとなりました。その節は本当にありがとうございました。
tossy
minne事業部の@tossyです。Kaigi on Railsには初めて参加しました。
初めてのKaigi on Rails参加だったので、どのトークを聴講するかを事前に決めるため、Kaigi on Rails 2025 タイムテーブル解説会に参加しました。 事前に聴講するトークを決めておいたことで、当日に判断する負担を減らせたので良かったです。
Kaigi on Railsに参加して、印象的だったのは、Railsに関する実用的な学びが得られるトークが多いということでした。 個人的には、日々の業務の中で地道な改善を通じた取り組みを紹介されているトークが印象に残りました。 特に印象に残ったトークについて、私の目線から紹介します。
5年間のFintech × Rails実践に学ぶ - 基本に忠実な運用で築く高信頼性システム
5年間のFintech × Rails実践に学ぶ - 基本に忠実な運用で築く高信頼性システム
株式会社スマートバンクのohbaryeさんのトークでは、決済や残高管理を扱う金融サービスをRailsで5年間開発・運用してきた中での工夫が紹介されました。
決済や残高管理を扱う金融サービスでは、Fintech関連の規制に基づいて求められる品質特性を満たすため、運用を見据えた開発上の工夫をされているそうです。 規制対象の機能や特定の要件を持つ機能を本体から分離するため、システムのアーキテクチャは、大きなモノリスのRailsアプリケーションを中核として、特定の課題ごとに小さなアプリケーションを組み合わせる構成とされていました。規制対象の分離により要求されるセキュリティの水準を満足するため、このアーキテクチャ設計にされているようでした。
高信頼性を築く運用では、「発生に備えて、予防する」、「速やかに検知する」、「速やかに問題を解決する」という観点に分けて取り組みを紹介されていました。 特に、バッチ管理においては、実装時のバッチドキュメンテーションが必須化されていました。バッチのドキュメントがあることで、アラートを受け取ったエンジニアが実装の詳細を知らなくても、リトライ可否や手順を判断できる仕組みになっており、良い取り組みだと感じました。また、バッチ処理時間をSLOとして設定することにおいては、実行時間の伸びから、SLO超過するまでの期間を予測して対処するメトリクスを運用しており、「発生に備えて、予防する」と「速やかに検知する」を満たす取り組みだと感じました。
他にも運用を行う上で参考にしたい事例がたくさんあり、実用的な発表でした。基本に忠実で地道な改善を通じて、高信頼なシステムが運用されているんだなあ、と感じることができる発表でした。
感想
Kaigi on Railsに初めて参加して、Railsに関する実用的な学びはもちろん、Rubyコミュニティの活気を直接感じることができた2日間でした。 いろんなトークを通して、新たな気づきや他の方の知見がたくさん得られました。 この気づきや知見を今後の開発に活かしていければと思います。
また、トーク以外でも休憩時間や懇親会で、様々な人と交流することで、良い時間を過ごすことができました。 来年のKaigi on Railsには、日々の業務での課題解決事例を抽象化した内容のプロポーザルを出して、ぜひ登壇者として参加したいと思いました。
yancya
毎回そうですが、いち観覧者として参加しました。結構沢山トークを見ましたが、本稿では抜粋して感想を述べていきます。
dynamic! の感想
なんかを作るときには、まず小さく作って、動くソフトウェアを使って対話を行いながら、変化させやすい構造を保ちながら開発すると、おのずとリリース後にも外部環境の変化にスッと対応出来る状態になっているでしょう？という感じで、良い開発チームってそういう感じなんだろうなというのをまざまざと見せつけられた感があって、とても良い気持ちでした。
入門 FormObject
本来は複数のフォームに分かれていてもよいようなものが１つのエンドポイントで捌けるように作られたいというシチュエーションって、どういう風に生まれるんだろうと思っていたんですが、トーク中で「ビジネスは甘くないんですよ。１クリックで終わらないとダメって時が必ずあるんです」みたいな感じで熱く語られていて、胸を打ちました。
2分台で1500examples完走！爆速CIを支える環境構築術
昔、PostgreSQLでどうしても速度が出したくてTABLESPACEにtmpfsを設定した思い出が蘇ってきて、つい心の中で「そうなりますよね」って言ってしまいました。可用性の要件によってはそういう選択肢もあるということがその場にいた多くの人に示されたことに価値があったと思います。
Railsによる人工的「設計」入門
冒頭で「あなたは設計が出来ていると思いますか？」みたいな事を言われてドキっとしましたが、ある程度は普段考えている通りの内容だったので安心しました。逆算することで破綻なく目的を達する計画が立てられるし、逆算するときには手札が多ければ多いほど助かるので、色々と勉強しないとね、という感じで、身が引き締まりました。
今改めてServiceクラスについて考える 〜あるRails開発者の10年〜
長年にわたる葛藤の末に、ひとまず出した結論をシェアしてもらえるという貴重な機会でした。コードの中に一般論として正しい構造が存在するのではなく、チームのメンバーの出入りなどにも対応出来るようなカタチをしているかどうかを気にしないといけなかったんだという、組織をマネジメントする立場の人ならではの良い結論が見られて眼福でした。
Range on Rails ― 「多重範囲型」という新たな選択肢が、複雑ロジックを劇的にシンプルにしたワケ
個人的にRDBMSはPostgreSQLが好きなんですが、比較的最近リリースされた多重範囲型という型を紹介するトークでした。以前、PostgreSQL の範囲型と、それを Rails で使う方法みたいなBlogを書いたことがあって、機会があるたびに「これを使えば期間の範囲同士の演算が楽に行えてバグが減るんですよ」みたいな事を言いまくっていたので、当トークで見た多重範囲型はとても興味深かったです。単一の範囲型だと１つの範囲しか扱えませんけど、多重範囲型であれば歯抜けになっている範囲を１つの範囲として扱えるので、より実装が楽になると思います。気持ちが高まって、トーク後にスピーカーの方に「特定カラムで範囲の重複がない事を保証するチェック制約を付けたくなりますよねこれ」みたいな質問をしに行って、少しだけ盛り上がったりしていました。
“複雑なデータ処理 × 静的サイト” を両立させる、楽をするRails運用
確か、スピーカーのhogelogさんは以前middlemanというRubyで静的サイトを作るフレームワークにハマっていたハズで、そんなhogelogさんが、今静的サイトを作るならどうする？という話をされるのであれば、聞きに行かないわけにはいかないと思って聞きに行きました。管理画面としてのRailsとか、非同期処理コントローラーとしてのRailsを上手く使って静的サイトの管理をイイカンジにしていこうというのは納得の結論という感じで面白かったです。
rails g authenticationから学ぶRails8.0時代の認証
普段、Railsで認証機能を作るときにはGemを使わずにRailsの標準機能を使う事が多いんですが、どうやら世の中では結構Gemで実装してしまう人が多いらしくて、Gemを使った方が良い、とか、使わない方が良いという論争？を見る事が多いです。それはさておき、最近ではrails g authenticationというジェネレーターコマンドがリリースされて、これを実行するだけで標準的な認証機能のコードが生成されるようです。当トークでは、この機能で生成されるコードを読んで、基本的な認証機能について自分で分かっておきましょう、その上でGemを使うかどうか、使うならどう使うべきかなどを判断出来るようになりましょうという非常に教育的な内容で良かったです。
Building and Deploying Interactive Rails Applications with Falcon
「すべてFalconとAsyncで出来ます！」みたいな内容で、怖いくらいすごかったですね。「そんなことまでやっちゃうんですか」って感じで。開発者が使うCoding Agentにコンテキストを共有するためにGemに情報を詰め込んでpublishしておき、みんなが gem install でそれを簡単にインストールできるようにするという発想が新しくて、感銘を受けました。この圧倒的な量のアウトプットは、おそらくそのようにCoding Agentをめちゃくちゃ使い込んでいるからこそ出来てるんだろうなと思って、見習いたい気持ちになりました。
全体的な感想
なんか、Kaigi on Railsって、もちろんRailsのカンファレンスなんですけど、ソフトウェア開発組織のありかたとか、そういえば設計ってなんなんだろうとか、開発に際して発生する意思決定に用いる指標とか、RailsというWebアプリケーションフレームワークという枠より、かなり広く、ためになる話ばかりされているので良いですね。
オーガナイザー(運営スタッフ)のレポート
shiorin
EC事業部の@shiorinです。Kaigi on Railsの運営スタッフは2年目になります。
昨年の様子はKaigi on Rails 2024どうだった？運営メンバーで座談会をしました！で詳しくお話ししているので、ぜひご覧ください。
運営スタッフでの活動
今年も運営スタッフとして、準備段階から会場設営、当日の運営サポートまで、様々な業務に携わりました。特に力を入れたのが懇親会の企画・運営です。昨年好評だった日本酒コーナーを今年も設置したところ、すぐになくなってしまうくらい大好評で、とても嬉しかったです。
英語でRubyistと交流
個人的に印象に残ったのは、懇親会で海外から来た登壇者と英語で話をしたことです。
RubyKaigiでの交流をきっかけに英会話の勉強を始めていたこともあり、「懇親会では英語を使ってRubyistと話をしてみたい！」と意気込んでいました。
実際に英語話者のRubyistが集まるテーブルに入り、BundlerのコミッターであるAndré Arkoさんから、どうしてBundlerの開発に携わるようになったのかを直接教えてもらうことができました。英語での会話にチャレンジしなければ聞けなかった話なので、すごく嬉しかったです。
Kaigi on Railsは来年から国際カンファレンスを目指していくので、海外のRubyistともコミュニケーションが取れるように、もっと頑張っていきたいです。
chiroru
技術部のchiroruです。運営スタッフとして参加するのは今年で5回目となりました。
運営スタッフでの活動
当日はホールBlueを担当し、スピーカーの接続確認、翻訳モニターのトラブル対応、トークのタイムキープ、立ち見の方の誘導など、会場運営全般をサポートしていました。
それに加え、今年は「お弁当大臣」という役割も兼任しました。これは、運営スタッフとスピーカー総勢約70名分の昼食を発注・配布・回収する仕事です。
中でも特に配慮が必要だったのが、お弁当のゴミ回収です。 発注先の選定段階からゴミ回収のオペレーションを考慮していたのですが、お弁当関連のゴミとそれ以外とでは、最終的な回収場所や分別方法が異なりました。
会場では他の配布物も多かったため、少しでも分別がわかりやすくなるようデザイナーさんにサインを作ってもらったり、回収場所が分かりづらいものに関しては、お弁当を配布する際に直接お伝えする工夫も行いました。
また集まったゴミも分別が必要なものがあったため、トークセッションの合間を縫ってスタッフでゴミの分別作業も行いました。
今回初めてお弁当大臣を担当してみて、フード提供やゴミ回収のオペレーションは、参加者皆様の快適なカンファレンス体験にもつながる大事なポイントだと実感しました。 来年に向けて、この辺りの環境整備をさらに改善していきたいと考えています。
(余談ですがゴミ関連のオペレーションに没頭していたところ、様々なカンファレンスをサポートされているプロの方から「動きが業者みたいですね」とお褒めの(？)言葉をいただきました)
Kaigi Effect
懇親会ではいろんな方と交流することができました。特に日本Rubyの会の高橋会長と初めて直接お話しでき、RubyKaigi創設にもつながる学生時代のご経験を伺えたことは大変貴重でした。 さらに別のオーガナイザーとは、高橋会長からお薦めいただいた本をテーマにした輪読会を行うことになりました。こうした新たな出会いや学びが次の活動につながっていくKaigi Effectを強く感じられた2025KoRでした。
まとめ
Kaigi on Rails 2025についてトークの感想や学び、カンファレンス中に起きた出来事まで様々な視点からお届けしました。
今年のKaigi on Rails 2025には約750名(オーガナイザー情報)ほどの方々が参加しましたが、来年は今年よりもさらに広いベルサール渋谷での開催が決定しており、さらに国際化も進めていくとのことなのでよりパワーアップしたカンファレンスになるのではないかと予想しています。ペパボのオフィスからも近いので、より多くのエンジニアを巻き込んでカンファレンスを一緒に盛り上げていけたらなと考えています!また来年渋谷でお会いしましょう!
