はじめに
2025年9月26日（金）、27日（土）に Kaigi on Rails 2025 が開催され、今年は会社から「参加してみないか」と声をかけていただいたため、オンライン視聴で参加することにしました。
Kaigi on Rails は、Railsを中心にしつつフロントエンドやプロトコルなどWeb全般も扱う、誰もが参加しやすい包括的な技術カンファレンスです。
存在自体は前々から知っていましたが、今回初めて参加してみて、登壇者の成功/失敗談に触れたときに自分の現場で思い当たる点がいくつもあったのが大きな収穫でした。
視聴を進めるうちに、それらの気づきが自然と「未然防止」という形で整理されていった——そんな体験を中心にまとめたいと思います。
本記事では、印象に残った3つのテーマについて、
① どんなセッションだったか
②概要と感想
③学び
④今後の活かし方
の順でまとめます。
どれも今まさに困っている話題ではないものの、問題になる前に気づけてよかったと感じた点ばかりです。
Day 1
1. Railsによる人工的「設計」入門
資料：kaigi_on_rails_2025_設計.pdf - Speaker Deck
① どんなセッションだったか
「設計」は“自然と身につくもの”ではなく、“人工的に到達させるための手引き”を用意できる──という提案。完成像から逆算し、必要なステップに短い名前（デザインパーツ）を与えて全体像を先に作るアプローチ。
② 概要と感想
- 初学者が陥りがちなのは、「手順思考（DB→モデル→コントローラ…）」＝設計だと誤解してしまうこと。これは“いきなり実装”に近く、あとから未考慮が噴き出しやすい。
- そこで、先に完成したシステムを思い浮かべ（例：CSVインポートの成功/失敗の画面・履歴）→ 必要なこと（ステップ）を洗い出し → それぞれに短い名前をつけて仮置き（Importモデル、UserImportJob、非同期処理、一覧/詳細など）→ 後から必要に応じて選択肢を差し替える、という流れが紹介された。
- 自分はこれまでベテラン側の前提が掴めず、「設計してください」＝“手順を言うこと”になりがちだった。上長との認識ズレの原因が、まさにこの抽象度の差にあったのだと腑に落ちた。
③ 学び
- 設計＝コードを書かずに構造を決める活動。まずゴール（本質）を定め、そこから逆算してステップ化する。
- ステップには短い名前をつけ、デザインパーツ（非同期、Service/Model配置、トランザクション設計など）を仮置きして思考を一本道にする。
- 設計ができると、手順（作戦）の質が変わり、PRの分割や優先度判断も自然に良くなる。
④ 今後の活かし方
- 新規タスクは必ず、短時間で「逆算メモ」（完成像 → 必要ステップ → デザインパーツの仮置き）を書いてから着手する。
- PR の先頭に逆算メモを貼るように様式化を試してみる。
Day 2
2. 非同期Jobをtransaction内で呼ぶなよ！絶対に呼ぶなよ！
資料：非同期jobをtransaction内で 呼ぶなよ！絶対に呼ぶなよ！ - Speaker Deck
① どんなセッションだったか
transaction の コミット前 に非同期Jobが走ってしまい、DBの状態が未確定のまま参照されることでエラーが発生する事例と、その対策について。
② 概要と感想
transaction内で非同期Jobをエンキューすると、スケジューラの都合で コミットより先に Job が開始 され、対象レコードが未コミット → ActiveJob::DeserializationError などが起きうる。- 発生頻度が低く 「たまに起きる謎エラー」 になりがちでデバッグが難しいため、設計・運用・設定の三面での対策が示された。
- 自分も 「同様のことをやってしまっているかも…」 と感じ、仕組みで未然に防ぎたいと思った。
③ 学び
- 非同期は便利でも、データのライフサイクルを越境させやすい。
- 状態が確定するタイミング（commit） を基準に、Job のキック位置 を決める。
- “たまたま動く”は危険サイン。再現しづらい＝放置してよい ではない。
④ 今後の活かし方
- 設計／レビュー運用
- PR確認項目に 「enqueue は
after_commitか？」 を追加。
- PR確認項目に 「enqueue は
- 実装
- transaction の外 で非同期Jobを呼ぶ。
- フレームワーク設定
- Rails 7.2 以降で利用可能な
enqueue_after_transaction_commitの設定 を活用してみる。（※導入段階で要検証）
- Rails 7.2 以降で利用可能な
3. 「技術負債にならない・間違えない」権限管理の設計と実装
資料：「技術負債にならない・間違えない」 権限管理の設計と実装 - Speaker Deck
① どんなセッションだったか
admin? などロール直判定の分岐から脱却し、対象（resource）× 操作（action） × 役割（role） × 条件（attributes）に分解して権限に依存する実装へ移す設計・実装の話。
② 概要と感想
- 事業や機能の変化で役割（admin / manager…）の意味は揺れるため、ロール直判定はアンチパターンになりやすい。
- RBAC × ABACを整理し、対象・操作・役割・条件を分けて表現することで実装／利用／理解の各局面で「間違えない」を実現する。
- 具体実装では Pundit を例に、record / scope / list の各モードで「判定」「絞り込み」「権限定義の一覧化」を明示できる構成や、モジュール分割＋メタプログラミングで見通しを確保する工夫が示された。
- 自分の現場では権限がそこまで複雑ではないものの、将来的な仕様拡張や問い合わせ対応で効いてくる設計だと感じた。「誰が何をできるか」を言語化しておく意義が腑に落ちた。
③ 学び
- 役割ではなく権限に依存する（
admin?直判定からの卒業）。 - 対象×操作×（役割／条件）を分けて、権限一覧の表にできる形で表現する。
- Pundit などで Policy を整理し、見通しの良い構成を保つ
④ 今後の活かし方
- まずはコード検索で
admin?/manager?を棚卸しして、Permission/Policy 層への移行対象を可視化。 - 実際に移行するかはチーム内や現状の複雑さを考慮して要検討。
- 1画面だけで良いので、UIを権限一覧に基づく宣言的制御に置き換えて効果を確認してみる。
まとめ：成功/失敗談を“仕組み”に変える
今回の視聴で共通して感じたのは
「当時は正しかった対策も、時間と変更で負債になり得る」
ということでした。
非同期・権限・設計のどれも、背景には見えない前提と更新されない仕組みがあります。
そこで本記事では、未然防止のために気を付ける3原則を自分なりに言語化してみました。
| 原則 | ねらい / 定義 | 具体例 |
|---|---|---|
| 可視化 | 効果と副作用を数値や一覧で見える化する | 権限一覧の明示 |
| 定型化 | レビューやPR様式を“質問とメモ”で型にする | 「enqueue は after_commit か？」／短時間の逆算メモ |
| 宣言化 | 設計や権限をコードより先に言葉で表す | 対象×操作×条件の表／デザインパーツの仮置き |
これらは大掛かりな修正がなくても始められる小さな仕組みになります。
明日からは、
1．PRテンプレの確認項目の追加
2．新タスクでの逆算メモ運用
の2つから着実に進め、問題になる前に気づけるチームを目指していきたいと思います。
さいごに
今回Kaigi on Railsに参加する機会をいただき、今後のためになる話をたくさん聞けて良い経験になりました。
初めてなので日和ってオンライン視聴にしましたが、時間の柔軟さが大きな価値だったと思います。
業務の合間に区切って視聴することができ、後日見直す前提で理解の深掘りがしやすい点も良かったです。
一方、登壇者や参加者とのコミュニケーションは現地に比べて薄くなるため、次回は現地で参加してみたいな、と思いました。
