部屋の隅っこで書く技術ブログ

Web系企業勤務のエンジニアリングマネージャのブログです。技術ブログと称しつつ技術にまつわる個人的な話題が多めです。

Kaigi on Rails 2023に参加しました

Kaigi on Rails Ruby Rails

2023/10/27-28に東京・浅草橋で行われたKaigi on Rails 2023に現地参加してきました。

kaigionrails.org

4年越しでのオンサイト開催とあってものすごく楽しみにしていたのですが、その期待をはるかに上回る楽しい2日間でした。

諸々の事情で3週間も間が空いてしまいましたが、感想を書いていきます。

まずは、チーフオーガナイザーの@okuramasafumi さん、スタッフの皆さん、スピーカーの皆さん、ありがとうございました。大変楽しませていただきました。

トーク

全体の傾向の話

昨年まではRailsとはあまり関係のないWeb開発全般やマネジメントに関する話題もちらほら見受けられたのですが、今年は完全にRailsに振り切った話題が多かったです。

プロポーザル数が100を超え（！）、選定のためにRailsの話題が優先的に採択されたのかな。

全体のテーマとして「Rails」がある中で、トークの傾向としては

  • 業務から得られた生の知見
  • 既存アプリにRailsの新機能や技術を取り込む話1
  • 経験知を体系的にまとめた話

が多かったように思います。逆に、単なる技術解説や一個人の経験に根ざした話はありませんでしたね。

「経験知を体系的にまとめた話」は数自体は少ないもののトークの性質上スピーカーにベテランかつ手練の方が揃っていて、自分には刺さった発表が特に多かったです。

ここからは、個別のトークのうち印象に残ったものについて振り返っていきます。

準備中 by @zzak

準備中 by zzak - Kaigi on Rails 2023

「コントリビュータの妨げにならないよう、CIが壊れないよう頑張る」という方針はkwappaさんの「メタエンジニアリング」2を思い出しました。やってることは少し違うんですけども。

また、情報をとにかく追って、全体像を把握してコントリビュータのブロック要素を取り除く姿勢はまさに自分が仕事でやっていることで、Railsコントリビュータという世界トップクラスのエンジニアが集まる集団でもそういうフォローは必要になってくるのだなとグッとくるものがありました。

そういえば、全部のPRを読んでいくの、お仕事でやると大変役に立つのでおすすめです。

Rails アプリの 5,000 件の N+1 問題と戦っている話 by @makicamel

BulletmarkRepairer: auto corrector for N+1 queries - Speaker Deck

同時期にコミュニティに行き始めて、もう長い知り合いになっているまきさんの発表。

「目の前の問題を技術で解決する」発表が自分は好きなのですが、それだけではなくチームでの議論や実際の運用まで含めた話をしていく、総合格闘技としてのエンジニアリングがきちんと語られていて、職業人としての強さも感じました。

Exceptional Rails by @willnet

Exceptional Rails - Speaker Deck

6社で技術顧問をされている前島さんの発表。弊社もお世話になっております。

Railsの例外に関する「経験値の言語化」なのですが、Rails 7.1での仕様変更など最新の動向も取り込まれていて、まさにこの人だからこその発表だと感じました。

前島さんはさすが発表慣れされていて、理解しやすいペース・1スライドの情報量・シンプルな全体構成に沿ったトークの組み立てなど、ものすごく聞きやすい講演でもありました。

Simplicity on Rails - RDB, REST and Ruby by @moro

Simplicity on Rails - RDB, REST and Ruby by MOROHASHI Kyosuke - Kaigi on Rails 2023

今回のベストトークをあえて1つ選ぶならば、僕はこれを選びます。

イベントエンティティから話が出発し、それをRESTにおけるリソースとして捉えることでRails wayに載せることができる、そのための実装はこうすると良い、と展開していきます。

ずいぶん前に「実践Railsアプリケーション設計」という話をしたことがあった3のですが、そのトークをする際にぼんやりと頭に浮かんでいたことが鮮やかに言語化された上で掘り下げられていて、我が意を得たりと思いました。

初手で中間テーブルにやる気のない命名をしてしまうと、それだけでかなりしんどくなりますよね。ここでイベントエンティティを定義し、しっかり練った設計は長期間機能するという肌感があります4。

発表の構成も非常に綺麗で、あるある話でつかんでどんどん実装に近づいていく過程には30分ずっと引き込まれっぱなしでした。

事業の試行錯誤を支える、コードを捨てやすくしてシステムをシンプルに保つ設計と工夫 by @zuckey

事業の試行錯誤を支える コードを捨てやすくして システムをシンプルに保つ設計と工夫 - Speaker Deck

「コードを捨てやすくする」5「表示に分岐を入れず、画面ごとに疎結合に保つ」6という論旨には首がもげるほど同意なのですが、「同様の情報でも別テーブルにして管理する」という点だけがどうにも引っかかってしまっていました。

確かに1テーブル1モデル1コントローラのRails wayには沿っていて作りやすく捨てやすいけど、それだと情報の二重管理が発生して別のつらさが生まれないか？と。

そこで懇親会で本人を捕まえて聞いてみたところ、「メインテーブルとレプリカテーブルを明確に決めてバッチ処理やコールバックで同期を取るようにしており、レプリカの方に反映が遅れるのは受け入れている」とのこと。リードレプリカや検索エンジンへの反映に時間差が生じることなどは普通にあるため、この回答で納得しました。

ちなみにリアルタイム同期を取ろうとするとDB VIEWの使用を検討することになるのですが、DB VIEWをRailsで扱うことは想定されておらず管理が大変です。この方法を取るのは最後の手段だと思います。

質問に快く答えてくださったずっきーさん、ありがとうございました！

管理機能アーキテクチャパターンの考察と実践 by @ohbarye

管理機能アーキテクチャパターンの考察と実践 / Learn Architecture through Admin - Speaker Deck

こちらも白眉でした。

「管理機能」という

  • たいてい後付けで追加され
  • 画面も利用者も別なのにテーブルは一緒で
  • 社内でしか使わないので適当に作られがち

な三重苦をいかに克服するか。これをアーキテクチャの観点でロジカルにパターン分けし、最後に現場にどう適用していったかまできちんと話されていました。

前島さんやモロさんの発表もそうですが、経験知の抽象化と体系化が現場ですぐ使える形でお出しされるの、これぞKaigi on Railsという感じですよね。

あと、スライドデザインが秀逸で、

  • 目に優しい色選び
  • 見出しへの背景色の設定
  • 箇条書きレベル2で文字サイズそのまま色を薄める

あたりは真似したいなと思いました。

発表とは関係ない話ですが、発表者の@ohbaryeさんは僕がスタッフをしているEM Meetupの立ち上げ人ということで、ご挨拶できてよかったです。みんな読書会来てね。

engineering-manager-meetup.connpass.com

A Decade of Rails Bug Fixes by @byroot

A Decade of Rails Bug Fixes by byroot - Kaigi on Rails 2023

クロージングキーノートはバグ退治の話。

発表の前半は

  • まず再現を目指し
  • 再現したら再現コードを書き
  • 原因に対する仮説を立てて再現コードを小さくして検証し
  • 正しそうな仮説を見つけたらテストコードを書き
  • パッチを当ててテストコードを実行して修正を確認し
  • 小さな適用範囲で実運用して
  • それでも大丈夫なら全体に適用

というお手本のようなバグフィックスで、本人も言及していたように「科学的方法」であることの重要さを感じました。

理論を学んで問題を解いていく学校教育の仕組みからか、「科学的」というと演繹していくことをイメージしがちですが、数学を除く自然科学の基本は帰納的に理論を構築することなんですよね。すなわち、実世界の現象について仮説を立て、限定的な条件で検証して徐々にスコープを大きくしていく。

人間の脳には確証バイアスというバグがあって、目の前の現象を一度立てた仮説に無理やり当てはめてしまうことがよくあるので、「仮説の正しさを見極め、徐々にスコープを大きくしていく」ことがいかに難しいことか。

後半は応用編でRuby内部に最近導入されたアーキテクチャにまで踏み込んでいて「真似できないな」と思いつつも、「どんなすごい人でも基本は同じ」という意味で勇気づけられる発表でした。

初のオンサイト開催

2020年から開催されているKaigi on Railsですが、4年目にして今年が初めてのオンサイト開催でした。

他の方のブログでもちらほら見かけたのですが、休憩スペースやハックスペースがゆとりを持って取られていたのが印象的です。ゆっくり過ごしたり、気になったことを調べたり、久しぶりの方と話したりするのに大変快適でした。

Kaigi on Railsはオンライン開催の時からreBakoやSpacial Chatなど「空間の設計」にすごく気を遣われている印象があるのですが、オンサイト開催になってもそれは変わりなく、強く意識されているのではないかと想像しています。何より、めちゃくちゃ忙しいはずの大倉さんがずっと楽しそうでしたから。

参加者としても、場の大切さに気付く良い機会になりました。

個人のふりかえり

過去一番楽しめたカンファレンス

Kaigi on Rails 2023は自分にとって過去一番楽しめたカンファレンスとなりました。

前述の通り場づくりに気の配られたカンファレンスだったのはもちろんなのですが、今年のRubyKaigiで「今ここで、場に貢献しなくては」という自分の中の強迫観念から解放された7ことが大きく働いたと思います（自意識過剰で恥ずかしい話）。

気持ちが軽くなったことで必死にメモを取ることもなくなり、自分なりの整理のために二言三言残す程度になりました。おかげで話に集中して楽しむ余裕ができたように思います。楽しむ余裕ができたことで記憶にも残りやすくなりました。だとすると、あんなに必死にメモ取ってたのはなんだったんだ。

楽しい場ですから、リラックスして臨むのが一番です。

記事投げおじさん

トークは基本X(Twitter)で実況しながら聞いていたのですが、たくさん「いいね」をいただける投稿がちらほらありました。トーク内容の補足となるような記事の紹介です。

Web上での情報収集を系統立てて行っているのが皆さんのお役に立てて何よりです。

expajp-tech.hatenablog.com

今後も機を見つけてやっていきます。

プロポーザルのリジェクト

今年は『認知科学の知見から考える「優秀なプログラマ」への道』というタイトルでプロポーザルを出していたのですが、リジェクトされてしまいました。

ここ2年ほどで認知科学の本をたくさん読んだので、その知見を詰め込んだ発表にしようと頑張って書いたのですが、いま思うと大上段に構えすぎです。

Railsからも現場からも離れすぎてしまう上、実際に現場に適用した事例にも乏しいとなると、それは採択厳しいよなあ。

Kaigi on Railsには来年以降もできるだけプロポーザルを出していきたいですが、地に足をつけて、仕事で得た知見をコミュニティに還元するという基本に立ち返っていきます。

Kaigi Effectとしてのむきなおり

ふりかえると、今回のKaigi on Railsでは個人的ベストトーク「Simplicity on Rails」のほか、Railsの密結合に言及する発表8がとりわけ印象に残りました。

なぜ印象に残ったかというと、自分の中に引っかかりを感じたからです。

仕事で10年以上にわたって運用しているRailsアプリに向き合ってきているため、「Railsは密結合である」ことは理屈だけでなく実感を伴って理解しているつもりです。実際、フォームオブジェクトやサービスクラスへの分離をはじめ、対策を講じたことも複数回あります。

しかし、自分は6年前に初めて触ったWebアプリケーションフレームワークがRailsで、そこからずっとRailsを使っています。他のフレームワークを知らないので、Railsが相対的にどう密結合なのかが分からないのです。

そんな身分で何を偉そうにRailsアプリの設計を語ってるんだ、と引っかかったのですよね。

同様に言語に関しても、この6年間はほぼRubyだけです。他はJavaScriptくらいで、いずれにせよ動的型付けのスクリプト言語です。学生時代にCやFortranに触れた経験はありますが、現代的な静的型付けのメリットを享受したことがなく、Rubyへの型導入も正直いまいちピンと来てないのが現状です。

そろそろ、といっても6年経ってるので遅すぎるくらいですが、RubyとRails以外にも時間を割く時なのかもしれません。

Railsを通してWebアプリケーションの基礎をずいぶんと勉強させてもらいました。幅を広げることで自分の中で新しいモノの見方が生まれるのを期待しています。

最近は職責が徐々に広がっているため読書の幅も広げたく、時間の確保が問題になりそうです。この記事を出すのに3週間かかっている現状は流石にまずいので、何か対策を考えます。まずはアドベントカレンダーちゃんと書けるかなあ。

あ、もちろん仕事ではRubyを使い続けていくので、コミュニティの皆さんは今後ともよろしくお願いします。

まとめ

  • 過去一番楽しめたカンファレンスだった
  • 今年は完全にRailsに振り切った話題が多かった
  • RubyとRails以外にも時間を割いていきたい

カンファレンスは楽しいだけでなく自分の学びを見つめ直す良い機会ですね。それでは。

  1. 特にHotwireに関する発表が多く、熱の高まりを感じます。Hotwireだけに↩
  2. メタエンジニアリングについて考えた2022年 // Kwappa研究開発室 https://randd.kwappa.net/2022/12/22/meta-engineering/↩
  3. 実践Railsアプリケーション設計 #meetup_rails / Practical Rails Application Design - Speaker Deck https://speakerdeck.com/expajp/practical-rails-application-design↩
  4. ただ、日本語（やまとことば）には動詞の名詞形がないので、日本語ネイティブには難易度が高いという罠があるんですけどね…… https://x.com/expajp/status/1717902257738686791?s=20↩
  5. 不要な機能を残したままだとメンテする複雑さが無駄に増して、コストが上がる↩
  6. 発表のように別ロールのユーザが同じviewを参照すると、認可で事故って機密保持の問題になりやすい↩
  7. RubyKaigi 2023に参加したら新しい繋がりが生まれて悩みが解消した話 - 部屋の隅っこで書く技術ブログ https://expajp-tech.hatenablog.com/entry/2023/05/24/020827↩
  8. 上記「コードを捨てやすくしてシステムをシンプルに保つ設計と工夫」のほか、「テーブル分割で実現するdeviseの責務の分離と柔軟な削除機構」↩