【Kaigi on Rails 2025】「入門 FormObject」で登壇しました

09/26金-27土に開催されたKaigi on Rails 2025にて「入門 FormObject」のタイトルで登壇しました。

先に発表についての補足記事は出したので、この記事ではカンファレンス全体の感想を書いていきます。

改めまして、スタッフのみなさん、聞いてくださったみなさん、ありがとうございました！

• 登壇した
  • テーマ設定
  • 設計を扱うトーク準備の難しさ
    • ストーリー作り
    • 分かりやすさと正確さと尺
  • 発表
  • 他のスピーカーからの言及
  • スライドの背景に使った秘境駅
• 発表を聞いた
  • Keynote: dynamic!
  • Railsアプリケーション開発者のためのブックガイド
  • Railsによる人工的「設計」入門
  • 今改めてServiceクラスについて考える 〜あるRails開発者の10年〜
  • 2重リクエスト完全攻略HANDBOOK
  • Railsアプリから何を切り出す？機能分離の判断基準
  • Rails on SQLite: exciting new ways to cause outages
• タイムテーブル構築の妙を感じた
• みんなと話した
• おわりに

登壇した

スライドはこちらです。

speakerdeck.com

補足記事と併せてご覧ください。

expajp-tech.hatenablog.com

テーマ設定

プロポーザルを書く直接のきっかけはスライドにもある「不要なのにFormObjectを使っていたコードをレビューした」ことでしたが、実はもうひとつテーマがありました。

「Rails Developers Meetup(RailsDM) で議論されたことを改めてコミュニティに伝える」ことです。

Rails Developers Meetup - connpass

RailsDMは2017-19年に開催されたRailsのカンファレンス¹です。

「第一線で活躍する開発者・企業から知見を得る」ことがコンセプトで、当時、Railsを学び始めたばかりだった自分は毎回興奮しながら参加していました。

エース級の人たちが色んなところから集まってきて、自分の知見を惜しげもなく発表する。イベント中はSNSや廊下で議論が始まり、イベント後には皆が笑顔でお酒を飲んでいる。これが技術者コミュニティなのか。

今思えば、見事に脳を焼かれていたんですね。

ところで、RailsDMでは「Railsを拡張する」テーマの発表が多くありました。

• レールの伸ばし方 - Speaker Deck
• フォームオブジェクトとの向き合い方/Grow Form Objects up - Speaker Deck
• Realworld Domain Model on Rails - Speaker Deck
• ApplicationModel のある風景 / Rails with ApplicationModel - Speaker Deck
• Ruby on Railsの正体と向き合い方 / What is Ruby on Rails and how to deal with it? - Speaker Deck

自分も随分と参考にさせてもらったものです。

しかし、RailsDMの終了とコロナ禍によって一度議論は断絶²。そのあいだに初めてRailsに触れた人たちにこれらの議論が届きにくい状況が生まれていました。

そこで「当時の議論を初級者に改めて伝える」ことを目標にしてこのテーマを選んだのでした。

正直なところ、自分がやりたかったことを実現できたとは全く思いません。瑕疵は山のようにあったし、メッセージングとしても中途半端なものに終わったと思っています。

しかし、ちょうどターゲットとした時期にRailsを始めた方々が何名か、興奮気味に話しかけてくださいました。刺したいところにちゃんと刺さったのは本当に報われた気分になりました。

設計を扱うトーク準備の難しさ

大層なテーマを掲げたのは良いものの、発表準備は難航しました。

ストーリー作り

Kaigi on Rails登壇は3回目だったのですが、設計を扱うのは初めて。これまでは仕事での事例をとりまとめて話していたので時系列に沿わせれば自然とストーリーになっていたのですが、今回はそうは行きませんでした。

収集した情報をどうやってまとめるべきか。まとめた要素をどう結びつけるべきか。結びつけた要素をどうストーリーにまとめるべきか。

時間だけではなくもっと多次元的に考えなくてはならず、ずっとうんうん言っていた気がします。

反省点としては、いきなりCosenseを使ってしまったことです。一方向に情報が並ぶのでこれまでの形態にはすごくフィットしていたのですが、今回初手から使うのは良くなかったですね。

iPadなり紙なりでまず情報を収束させた上で³、それをCosenseで並べて取捨選択する方向に行くべきでした。

Yusuke Iwaki（@yi01imagination）さんが良い記事を上げてくださっていたので、今度はこちらを参考にしたい。

yusukeiwaki.hatenablog.com

発表で扱う題材によって、情報の整理の仕方は変わりますね。

分かりやすさと正確さと尺

今回はトーク尺に15分を選びました。

プロポーザル時点で頭の中に「FormObjectの使いどころは3つ」という整理があって、このワンイシューを説明し切るならばおそらく15分で大丈夫だろうという見立てがあったためです。

ただ、抽象度の高い話をすると、どうしても内容が膨らんでしまいますね……。

初級者に向けて難しい話をするならば、そこに向き合う理由の説明が必要。

ただのお題目でなく現場から出てきた話だと感じてもらうために、具体例を準備しなくてはならない。

具体例としてのコードには、説明を足さないといけない。

聴衆に視覚で訴えられるよう、スライドの情報は最小限にしないといけない。

技術プレゼンとしては当然、正確を期さないといけない。

何を含め何を省くかが本当に難しく、煮えきらないまま本番を迎えることになってしまいました⁴。

補足記事が必要になったくらいなので取捨選択に成功したとは言えないな、と思っています。

設計の話にしては一定「分かりやすさ」に振ることはできたと思いますし、そういう反応もいただけて大変嬉しいのですが、今後の技術プレゼンのあり方はやはり見直さなくてはいけないでしょう。

発表

情報の取捨選択にギリギリまで悩んでいたので、喋りの方は練習不足でした。ここは大きな反省点ですね。

ただ、ド緊張だった昨年に比べて今年は落ち着いて話せていたと思います。

噛んだり詰まったり日本語が変だったりしたにもかかわらず「喋りが上手かった」というコメントを頂けたのは、場数踏んでハッタリが効くようになったからかもしれません。

そういえば今回は最初に大きな声で挨拶して軽く雑談したんですが、それのおかげで皆さんがしっかりこちらを見てくださった気がします。

つかみとしてはシンプルですが、最初に軽くボケる⁵より全然効果があるなと思いました。

他のスピーカーからの言及

keynoteのmoroさん・初日ラストのjokerさんから言及していただきました。

嬉しいやらプレッシャーを感じるやらでしたが、RailsDMの頃に仰ぎ見ていたおふたりに水を向けてもらえて感慨深かったです。

おふたりの発表に関しては、この記事の後ろの方で。

スライドの背景に使った秘境駅

前回好評だった秘境駅の写真。今回は「奇妙な場所/奇妙な駅舎」をテーマに選びました。

土讃線・土佐北川駅
宗谷本線・糠南駅
土讃線・新改駅
日高本線・浜厚真駅
東京駅……に似せて作られた飯田線・大嵐駅（これだけウィキメディアコモンズ）

でした
#kaigionrails https://t.co/ZMM8yPcKRz pic.twitter.com/qOCQ6BcMKi

— expa / Shu Oogawara (@expajp) 2025年9月26日

ラストページの写真に悩んでいたところ、通りが買った炬燵さんに「（会場のある）東京駅」というアイデアを頂きました。

ただ「東京駅の駅舎に似せて作った、飯田線・大嵐（おおぞれ）駅⁶」が「巨人の肩に乗ろう」というメッセージにぴったりだったので、一捻りしてそちらを採用。誰が気付くんだって話ですけどね。

Asturio Cantabrio, CC BY-SA 4.0, via Wikimedia Commons

ちなみに、東京駅の写真は手元にあると思っていたのですがウェディングフォトしかなく、採用を見送ったのが大嵐駅を思いついた理由です。妻を消しゴムマジックすることにならなくて良かったです。

発表を聞いた

Keynote: dynamic!

dynamic! - Speaker Deck

昨年の島田さんのクロージングキーノートから地続きに、「設計」と「たのしさ」の話。というか「修復」の実践編です。

Rubyの「たのしさ」についてはLTしたことがある⁷のですが、「動的である」という軸でRailsやXP、アジャイルソフトウェア開発宣言につながっていくのは手品の種明かしを見ているような気分でした。

諸行無常を受け入れ「たのしい」という内面に向き合っていく姿勢には日本文化（もっと言えば仏教？）的な面を感じました。楽しさを生活の糧としていくためにどうすれば良いか、というのはまた別の議論ですけども。

ところで、FormObjectの話。

自分がFormObjectを使ってきた理由はあくまで「現場にあったから」なので、moroさんがFormObject(FO)推しである理由をセルフ考察するスライド⁸は非常に興味深かったです。

気になったのは「コントローラをFO層にする」意見があること。これは初めて知りました。

確かにFOへの委譲を突き詰めると1アクション1FOに落ち着くので、これをコントローラに書かない理由って実は明確じゃないよな、と思っていたのですよね⁹。

DHH流のコントローラ分割はこれの一種だと思うのですが、ひとつの落としどころなんでしょう。「リソース分割を徹底的にやって全てのアクションをCRUD処理として扱う」、このレベルで厳しい規約であれば、チーム内で徹底させるのも比較的難しくなさそうです。

Railsアプリケーション開発者のためのブックガイド

Railsアプリケーション開発者のためのブックガイド - Speaker Deck

うわー、こんな発表を待ってた。高橋会長にしか語れないんじゃないでしょうか。

自分も、デブサミで読書法を語るほどには¹⁰本に対しては強い思いがあるので、こういう発表がKaigi on Railsで聞けるのは嬉しい。

知らない本がいくつか紹介されていたので、笹田さんの書店で2冊買いました。

お買い上げ #kaigionrails pic.twitter.com/xEx78HZMcA

— expa / Shu Oogawara (@expajp) 2025年9月27日

カンファレンス内でこういうシナジーの設計がされるのは良いですね。

Railsによる人工的「設計」入門

kaigi_on_rails_2025_設計.pdf - Speaker Deck

エンジニア歴が同じくらいでも、設計ができる人とそうでない人に分かれるのはなんとなく感じていました。

かといって設計の本は本人に興味がないと読み切るのが難しく、どうしたものか、本人の資質と割り切るしかないのか、とぼんやり思っていました。

設計を「逆算」と捉え、その過程をフォローアップしていくという手法には膝を打ちました。

このアプローチを取ればベテランの過程を小さなステップで見せられる上、細かいフィードバックが可能です。コードと違って設計作業って過程や意図を見せることが難しいので、これが「自分で気付くしかない」状況を作り上げていたのかもしれませんね。

人間の学習を促す要素のひとつが誤りフィードバックで¹¹この手法はそれを促すので、「再現性がある」のも納得できる話だと思いました。

今改めてServiceクラスについて考える 〜あるRails開発者の10年〜

今改めてServiceクラスについて考える 〜あるRails開発者の10年〜 - Speaker Deck

「共通認識」への着目は「やられた」と思いました。

「入門 FormObject」を作りながら困ったことのひとつに「現場によって違うものに対して、天下り的になりすぎる」こと。

「あくまで初級者が現場のコードを理解するため」としてこの点には目をつぶり「わかってる人向け」に解説することで逃げたのですが、そうか、こういう整理があったのかー……

Formという言葉の意味とWebアプリケーションの役割から出発して、当初は入力のハンドリングとサブミットしたときの処理を書くためのレイヤだった。それが色んな処理を飲み込んで、現場ごとに違う役割を持つようになった。それを踏まえた上で今回想定するスコープはこれ、とすれば綺麗な話になったかも知れない。

僕の現場でFormObjectが機能していたのも、長く在籍するメンバーが多く「ユースケースを組み立てる層」としての共通認識があった（ただし、それが暗黙知だったので「いつ使わないのか」の認識に差が生まれた）からなのですよね。

この「チームで共通認識を持つためにどうすれば良いか」という考え方、応用範囲が広そうな気がします。

実際、最近「リポジトリを小さく保つことの重要性」をぼんやり考えていたのだけども、これも同様の考え方で説明できてしまいますね。

2重リクエスト完全攻略HANDBOOK

2重リクエスト完全攻略HANDBOOK / Double Request Handbook - Speaker Deck

二重リクエストに対する対処法、サブミットボタンの無効化とAPI設計を可能な限り冪等にするくらいしか引き出しがなかったのですが、こんなにあるとは……スライドの資料的価値が高く、今後も末永く参照できそうです。

金融業界にいるだけあって需要が高いんでしょう。現場の話をほとんどしていないのに、現場感がある発表でよかったです。

ところで、三谷さんは登壇4回目なんですね。

同じくSmartBank所属の大場さんが5年連続で登壇しているのとあわせて、社内でどういう仕組が回っているのか気になるなあ¹²。

Railsアプリから何を切り出す？機能分離の判断基準

Railsアプリから何を切り出す？機能分離の判断基準　Kaigi on Rails 2025 - Speaker Deck

スライドの資料的価値が高いシリーズその2。

軸が明確であるおかげで、星取表を作って議論する場面が鮮やかに想像できました。

EMコミュニティにいるとどうしてもコンウェイの法則の話になりがちなのですが「理想的なアーキテクチャを描いて逆コンウェイ作戦」とはなかなかいかない。チームの認知負荷をむやみに上げる決断はしづらいものです。

そういう意味で分離する決断には胆力がいるのですが、基準があれば必要な思い切りが少し減ります。そういう意味でも有用だったと思いました。

Rails on SQLite: exciting new ways to cause outages

発表者のAndréとは2日目のあとに飲んで、色々と教えてもらいました。

Day2 Uchiage!! Thanks!! #kaigionrails #rubyfriends pic.twitter.com/9WlOEFTfTy

— クドウマサヤ | iCARE CTO (@masaya_dev) 2025年9月27日

SQLiteを使うことでFull text Searchがデフォルトで使えるし、バックアップがGitHubにコミット積むだけでできる そうです。

ファイルシステムの方がRDBMSよりも操作の自由度がよほど高いので、応用範囲がめっちゃ広そうですね。

タイムテーブル構築の妙を感じた

@sylph01さんのブログにこんな文言がありました。

オーガナイザーのタイムテーブル構築の妙を感じる流れだった。

Kaigi on Rails 2025に参加した - そんなことはさておいて - https://d.s01.ninja/entry/20250929/1759157871

実際、彼とも「タイムテーブルに明確な意図を感じる」と話をしていました。

設計・非同期処理・データベース・フロントエンドといくつかの軸があって、2日目の終盤に固まった"外タレ"¹³に収束していく流れは本当に綺麗だったし、発表の間でのシナジーも強く感じることができました。

実際、例年に比べて「カンファレンスの中で別の発表に言及する」下りが多かったような気がします。

外山滋比古先生の「思考の整理学」にこんな一節があります。

上手に編集すれば、部分の総和よりはるかにおもしろい全体の効果が出るし、各部分もそれぞれ単独の表現だったときに比べて数等見栄えがする¹⁴。

それからこんな一節も。

編集の機能を、表現する筆者と、受容する読者との手をつながせることであるとするならば、エディターシップは自分の個性や才能を縦横に発揮してケンランたる誌面をつくり出すことにあるのではない。むしろ、自分の好みなどを殺して、執筆者と読者との化合が成立するのに必要な媒介者として中立的に機能する¹⁵。

今回のタイムテーブルはまさにエディターシップが発揮された結果だったと思います。僕は読んだだけではピンと来ていなかったこのくだりを思い出し「ああ、これが"エディターシップ"なのか」と心で理解することができたのでした。

おかげさまで「設計」のSpeakerどうしでコミュニケーションが取れましたし、sylphさんの言う通りAttenderにとってもシナジーがあったのではないでしょうか。

みんなと話した

イベントの1週間前で現所属先が最終出社になっていました。

次の所属先も含めて様々な方に近況報告ができてよかったです。

退職についてはまたこのブログに書くつもりです。

おわりに

長々と綴ってきましたが、改めて素晴らしいカンファレンスをありがとうございました。

次の所属先もRailsを使っているので、来年もぜひ行きたい。

引き続きよろしくお願いします。