10/25-26に開催されたKaigi on Rails 2024で、表題のタイトルで登壇しました。
この記事では感想をつらつら書いていきます。
登壇した
スライドはこちらです。
プロポーザル
Kaigi on Railsには来年以降もできるだけプロポーザルを出していきたいですが、地に足をつけて、仕事で得た知見をコミュニティに還元するという基本に立ち返っていきます
という昨年の反省1を活かし、現場で実際に行った取り組みをまとめて提出したところ無事採択されました。
最近、いくお（@dora_e_m ）さんが
出したそれぞれのプロポーザルに対するリアクションから、その場で求められているのがどちらなのかは見えてきます。なので、まだ経験が浅いのであればこそ、複数プロポーザルを書いてみるとよいでしょう。
と仰っていました2。ほぼ毎年プロポーザルを出しているKaigi on Railsでは、少しは求められる内容が掴めてきたように感じます。
準備期間
プロポーザル段階でトーク冒頭の「rubocop-rails-omakaseの話」と後半の「実施プロセス」「ふりかえり」の話は固まっていました。
一方で、前半の「難しさを克服する」パートは取捨選択に苦労し難航しました。例えば
- デフォルト設定を基に.rubocop_todo.ymlを削る方針にした理由
- 「コストかけたくない」と「コストかけないと話し合えない」の板挟みの解決法
- 「少しずつ改善する」アプローチの背景にあったサービス特性
などを入れるか削るか悩み、軸にすべき話がどれなのか分からなくなっていました。
本番2週間前にはまだ内容が定まっておらず、随分と胃の痛い思いをしました。
そんなとき「迷ってるならとりあえず人に見せよう」の精神で、スライドをでっち上げて同僚に見せたのは正解でした。
社内発表練習を3回行いアドバイスを都度取り入れることで、構成が見違えるように明確になり我ながら自信を持って話せる内容にまとめられました。
今回は初めてデザイナーさんにもスライドを見てもらい「スライドに視覚的な起伏が少ないので、写真・暗転・デカ文字を増やすべき」と指摘をいただきました。このおかげで発表が見やすく仕上がったと思います。
また、このアドバイスを受けてスライドに写真を取り入れることにしました。素材サイトを巡りながら悩んだ末、自ら旅して撮影した秘境駅の写真を採用しました。
「深堀り」という章タイトルへの被せで土合駅3を思いつき他の箇所も秘境駅の写真で統一した、という経緯だったのですが、気付いてくれる方がいたのは嬉しかったです。こういうところで自分らしさを出すのも悪くないですね。
スライド最終ページに使った函館本線・森駅の朝焼けの写真です
— expa / Shu Oogawara (@expajp) 2024年10月26日
もちろん自前で撮影#kaigionrails https://t.co/j0dh1A3nLO pic.twitter.com/KOARitE9gM
他に使った写真です
— expa / Shu Oogawara (@expajp) 2024年10月27日
室蘭本線・小幌駅付近の文太郎浜
宗谷本線・雄信内駅
石北本線・西女満別駅付近の道路
上越線・土合駅#kaigionrails pic.twitter.com/ENUlMMvS9R
今回、無事に発表を形にできたのは同僚たちの支えのおかげです。ここで改めてお礼を言わせてください。本当にありがとうございました。
当日
発表前
発表は2日目の後半で、上記のように胃の痛い期間が続いていたので会期中はほとんど気が休まりませんでした。
その一方で多くの方に「発表楽しみにしてます」と声をかけていただきました。ありがたいやら落ち着かないやらで「怖い怖い」と苦笑いしちゃってたのですが、倍率5倍の中で選んでいただいたのですから堂々とすべきでしたね。反省。
発表
そんなこんなであっという間に時間は過ぎていき、ついに自分の出番に。
僕は発表する際、原稿を作らずスライドにすべてを盛り込むスタイルを取っています。この手法は聴講者に視線を向けながら話せるメリットがある一方、その裏返しで視線をしっかり感じるため、ものすごく緊張します。今回も例外ではなく、発表の最初はスライドを送る手が震えていたのが自分でもわかりました。
しかし、みなさんが頷きながら聴いてくださったおかげでトークがきちんと伝わっている感触を得られ、中盤以降は次第に熱が入ってきて軽いトランス状態になっていました。Rubyistたちの温かさに本当に救われました。
冒頭に緊張して途中からノリ始めるのはデブサミも同じでした。次回は最初からノれるようにしたいです。やっぱりこういうのは場数を踏まなきゃダメですね。
発表後
発表が終わった後、RuboCopコアチームコミッターで発表内でもスライドを引用させていただいた@koic さんが話しかけてくださいました4。
「文化はomakaseしない」という締め方がかっこよかったとの一言で、長く悩んだ日々もチャラになった気がしました。
ご本人の記事5にもあった通り、koicさんは沖縄で最後まで飲ませていただいた方の一人です。EMとしてもOSSコントリビュータとしても活躍する姿に密かに尊敬を抱いており、一度しっかりお話ししたいと思っていたところで偶然ご一緒することになりました6。
「EMとコントリビュータ、どうやって両立してるのか？」という質問をぶつけてみたり、RuboCopメンテナとしてどんな日々を送っているのかをお聞きしたりと良い話がたくさん聞けたのですが、何より印象的だったのはずっと楽しそうにお話されていたことでした。プライドと責任感を持ちつつ、何よりやりたいことを楽しんでいるという様子だったのです。「これは誰にも真似できない本人だけの生き方なんだな」と強く感じました。
ロールモデルを参考にすることは大切だけども、自分とその人との間に好みや人柄の差はいずれ見えてしまう。この経験からそんなことを悟り、RubyKaigiから帰って「自分なりのやり方で良い」と納得した7のでした。
そして、その「自分なりのやり方」を世に出す場が先日のデブサミであって今回のKaigi on Railsだったのです。
今回RuboCopを題材にしたのは偶然8だったのですが結果的にRubyKaigiからつながる形になり、カンファレンスに参加しつづけることで生まれる縁を感じました。
もちろん、他にも良いフィードバックをくださった方はたくさんいらっしゃいました。
技術顧問としてもGinza.rbオーガナイザとしてもずっとお世話になっている前島（@willnet）さん。
koicさんと共に沖縄での酒席をご一緒した@ydah_ さん。
マネジメントの話題で最近良くお話ししている@onkさん。
そして昨年の登壇で「技術で解決する」ことの大切さを再認識させてくれた@makicamelさん。
多くの方から評価いただいて本当に嬉しく思います。この内容で発表して本当に良かった。
他の方のトークを聞いた
自分の準備で聞けていない部分も多いため、手短に。
全体の傾向の話
今回のテーマは「Rails way」と言い切って良いのではないかと思っています。
- Rails Wayをいかに道しるべとするかを語った2つの基調講演
- Rails Wayのない場所に道を作っていく話
- 近年新たにできたRails Wayの話
- importmap, Solid Queue, Hotwire
- rubocop-rails-omakase もこの範疇かな
いずれも、DHHが作り出したコンセプトの秀逸さを再確認するようなイベントでした。
それから、イベントが5回の歴史を重ねたことで過去の発表にインスパイアされた発表も増えてきました。igaigaさんやTsujitaさんの発表がそうでしたね。
運営に携わってはいないものの、イベントの継続自体が良い影響を生み出していることが感じられ、初回から参加している人間としてはなんだか嬉しいです。
RailsのPull requestsのレビューの時に私が考えていること
RailsのPull requestsのレビューの時に私が考えていること - Speaker Deck
Railsコントリビュータ向けかと思いきや、
- Issueでの問題の伝え方
- PRが適切なレイヤで問題を解決しているかという観点
- 貢献にリスペクトを伝えることの大切さ
など、幅広く応用の効く話でした。
20年続くフレームワークのIssueテンプレートですから、それはもう洗練されているわけで。
最近所属先でIssueテンプレートを見直す動きがあるので参考にさせてもらいます。
現実のRuby/Railsアップグレード
現実のRuby/Railsアップグレード - Speaker Deck
3年前に似たような話9をしたので、首がもげるほど頷きながら聞いていました。Rubyアップグレードもその後にやっているので余計に共感しました。
こちらの発表は自分の発表よりもさらに実践に寄っており、スライドを様々な現場で役立てられるよう気を配って抽象化しているような印象を受けました。末永く参照できそう。
推し活のハイトラフィックに立ち向かうRailsとアーキテクチャ
推し活の ハイトラフィックに立ち向かう Railsとアーキテクチャ - Kaigi on Rails 2024 - Speaker Deck
お笑いライブのチケットを申し込むときに常々「どうしてるんだろう」と思っていたテーマでした。
1在庫1レコードにしてFOR UPDATE SKIP LOCKED をすることで行ロックによる競合を避ける、というアプローチは目からウロコが出ました。発表中では触れられていませんでしたが、この実装ならスレッド並列化もやりやすくなるので大量のトラフィックを捌くのに効果的ですね。
あと、決済の話題での「正しく諦める」というのは良い表現でした。明示されている限界を無理に越えようとせず、レートリミットを導入して手前でリクエストを止めるアプローチはハイトラフィックを扱う様々なサービスで応用が効きそうに思いました。
入門『状態』
入門『状態』#kaigionrails / "state" for beginners with Rails - Speaker Deck
状態を決定づける要素が増えすぎて変更が追いづらくなっているコードには見覚えが……というより、所属先のサービスにも過去に似た問題があって（昨年ステートマシンにリファクタリングした）、例示されていたコードに見覚えがありすぎました。
しんくうさん本人にそのことを伝えると「ステートマシンの話までするには尺が足りなかった」とのこと。
ただステートマシンへの導線は用意されていて、イミュータビリティと名付けの効用が述べられているのはさすがの「入門」でした。
Sidekiq vs Solid Queue
Sidekiq vs Solid Queue - Speaker Deck
サービスにSidekiqの導入を検討しているので個人的にタイムリーな話題でした。
現代のジョブキューに必要十分な機能を実装した上で、ハードウェア性能の向上に目をつけて「RDBでいいじゃん」と割り切れるセンスはさすがDHH。
次のginza.rb でSolid Cable/Cache/Queue の三兄弟を扱うそうなので楽しみです。
Data Migration on Rails
Data Migration on Rails - Speaker Deck
ちゃんと聴けた中では個人的ベストトークかも。
情報を網羅的に集めて整理し、経験知と掛け合わせて形にする。カンファレンスでトークをするなら斯く在りたい、という自分の理想を叶えたような発表でした。
社内でのデータマイグレーション実施法が紆余曲折あって現在のRuby Scriptに落ち着いたのもあって、各手法のメリデメには強く共感できました。一方で片手間でしか向き合わない課題でもあるので、綺麗に整理されているのは本当にありがたい。
maintenance_tasks の導入は一考の価値ありですね。
WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと
WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと - Speaker Deck
自分の発表が終わった直後で少し気持ちがふわふわしていたため聞き逃した部分がかなりありましたが、聴けた部分の感想をば。
「全体が機能するように設計」するために「自分のアプリケーションを取り巻く要素について勉強していく」との話があって、前職を辞める決断したときを思い出しました。
当時、勉強し直そうという気持ちで新たにRailsを選んだのは「フルスタックだから全部学べるのでは？」と考えたからでした。甘い考えではあったが、大きく間違ってはいなかった。実際、Railsアプリケーションの運用を通して周辺領域を学ぶきっかけを得られたからです。
「なるほどUNIXプロセス」はそんな中で読んだ本の中の一冊なのですが、島田さんが実際にそういう狙いで書いたことを示唆するようなスライドがあって、思わずニヤリとしてしまいました。
そして楽しむこと。簡単なようでいて、とても難しいですね。
日々、目の前の課題で視野が狭くなったり自意識過剰でやりたいことをできなかったりすることはよくあることです。やりたいことを楽しんでやるのは芯を持っている人にしかできないことだと感じています（というか、沖縄でそう感じた）。
キャリアとしてもフラフラできない段階に来ているので、どうにか自分も芯を持ってやっていきたいと思いました。
その他のこと
ワークショップ: Rackを理解しRailsアプリケーション開発の足腰を鍛えよう
「海外カンファレンスではよくある」という触れ込みのワークショップ。Rackのしくみやアプリケーションサーバとの関係を改めて理解できたのはもちろん、コードを書く楽しさを思い出せました。
写経して、小さい単位で試行錯誤して改善して、自分で考えて工夫していく。ものづくりの楽しさが詰まった時間でした。
@hogelog さん、ありがとうございました。そして資料の誤りを次々に見つけていくしおいさんの強者感がすごかった笑
「場の設計」
昨年、
Kaigi on Railsはオンライン開催の時からreBakoやSpacial Chatなど「空間の設計」にすごく気を遣われている印象があるのですが、オンサイト開催になってもそれは変わりなく、強く意識されているのではないかと想像しています。
と書いたらオーガナイザーのぷぽ（@pupupopo88 ）さんから
そうなんです、私たちがやりたいのは「場を作る」ことで、人と交流して欲しいし、できるようにするというのを心がけてるんですよね。ただ発表をするだけ、聞いてもらうだけ、じゃ足りないんです。
とアンサーをいただきました10。
ですので今年も「場」を楽しみたかった……のですが、発表でそわそわしてて「他の方の発表を聞く」以外のことをする心理的余裕がなかったのが残念です。
来年も猫廼舎が開店してると良いなあ。「もくもく部屋」「わいわい部屋」というネーミングも良いですよね。本当にもくもく・わいわいしていたところも含めて。
ふりかえりと今後のこと
採択していただいたことへの感謝
まずは採択をいただいたことに心から感謝します。
発表を通じて「自分なりのやり方」でコミュニティに貢献でき、大きなきっかけをくださった方から良いコメントを頂いて、これ以上なく嬉しく思います。
また、準備段階では頼れる同僚たちに恵まれたことを強く実感しました。
コードを書く楽しさを思い出した
それから、hogelogさんのワークショップのおかげでコードを書く楽しさを改めて思い出しました。
読んだり写経するだけじゃなくて、またなにか自分で作ってみたい気持ちが湧いています。自分にはライブラリよりアプリを開発するのが向いているかもしれません。
立て続けに登壇するハードさ
今回もう一つ印象的だったのは「大きめのカンファレンスで立て続けに発表するハードさ」を初めて体感したことです。
デブサミの準備が差し迫った7月以降は本やコードに向き合い余裕がなく、キャパオーバー寸前だったと感じます。
けれども、この経験には良い影響もありました。「登壇を継続可能なものにしよう」という意識が芽生えたことです。
普段からネタをたくさん拾って広げておき、トーク構成とスライド作成を省力化することで継続的な登壇を実現できるはずです。今回はネタがあっても構成とスライドに苦しんだので、まずはプレゼンテーションに向き合って改善を図りたいと思います。
おわりに
なんだか随分とっ散らかっている上に随分と長い記事になってしまいましたが、それだけ様々な感情が湧いたカンファレンスでした。
Kaigi on Railsにはまた来年もプロポーザルを出せたら良いなと思います。それでは。
- Kaigi on Rails 2023に参加しました - 部屋の隅っこで書く技術ブログ↩
- 2つ目のプロポーザルで登壇チャンスを引き寄せる｜dora_e_m↩
- 土合駅 - Wikipedia↩
- 最前列にお座りになっていたので、発表中ちょっと恐縮していました笑↩
- Kaigi on Rails 2024に参加した - koicの日記↩
- 他に@ydah_ さん、森塚（@sanfrecce_osaka ）さん、 寺井（@krpk1900_dev ）さんがいました↩
- RubyKaigi 2024に参加しました - 部屋の隅っこで書く技術ブログ↩
- そもそも2本出しているし、.rubocop.ymlを作ったのは昨年↩
- Railsバージョンを倍にしたサービスのそれまでとそれから / Till and from that time of a web service whose rails version was doubled #kaigionrails - Speaker Deck↩
- 2023年をふりかえってみたらなかなか最高な年だった - すむとこ探し↩
