RubyKaigi 2026に行ってきた
今年も会社として参加できました。ありがたいですね また、ko1 sanの本屋さんのお手伝いと選書をしました
Day0
ここ数年で気がついたのですが、Day0にドリンクアップを開催してくださる会社があってありがたいものの、自分の移動予定を夕方にしがちで微妙に開始タイミングに参加できない（30分くらい遅刻しそう）ということがわかってきたので、もっと早いタイミングで移動すべきなんじゃない？という知見を得られた気がします
な〜〜んてことを考えていたのですが、当日はJALの管制システムトラブルがあり夕方の飛行機自体、飛ぶかどうかわからない状態になってしまい、夕方の新幹線移動へフォールバック*1
東京から函館まで、4時間40分くらい掛かった💨
到着した時には22:30くらいになっていたので、この日は色々諦めて就寝🛌
Day1
移動の疲労なのか、ここ1ヶ月くらい不調になっている胃の問題なのか、全体的に疲労感が拭えない1日だった
morisさんの基調講演でRuby::BOXの話を聞いて感動してしまった。作るための動機の話ももちろんだし、作ろうとしている取り組みが野心的だし、自分も昔から欲しいと思っていた機能ではあったけれど自分で作ろうという発想にはなれなかったので本当に尊敬しています
📝Rubyでここら辺できると良いなポイントメモ
- require時に読み込むファイルのオブジェクトが読み込み側に展開されちゃう問題
- これがMatzのいうパッケージの話な気がする
- ネームスペース（Ruby::BOX）スコープのオブジェクト拡張
- これはRuby::BOXで解決できるはず
- 現実世界ではコアドメイン（往々にしてデカい）なモデルに対して、特定のユースケースのみに公開したいメソッドなどがあり、そこをスコープで切れるとうれしい。concerningとか使えばそれっぽくはできるような気はするけど現実世界では試したことがない
- Ruby::BOXモジュール単位でのライブラリ管理
- モジュラーモノリス界隈の（デカRailsアプリ界隈）気持ちとしては、特定のモジュール内でのみ使うライブラリが整理できると嬉しみがありそう（さすがに各モジュール単位でRailsを別バージョンで動かしましょうみたいな事は考えてないけど）
閑話休題
お昼は会場の通路？にあるキッチンカーしかないのかと思ってめちゃ寒い中頑張って並んだんだけど、後にANDPADさんのお弁当配布があると知る。30分くらい並んでしまったので早めに知れていればよかった……
前述の通り胃がオワなのでOfficial Partyではノンアルで行くぞ、と思ったけど結局（自制できる範囲で控えめに）アルコールを摂取してしまった。その晩は胃が終わって明らかに消化が進んでない感じだったのでやはり体調は良くなかったのだろう。悲しいね
また、今となっては記憶が定かではないのだけど、Official Partyで「これが金言なんですよ！！！！！！！！！！1」と力説して、自分が表示したこのツイートを周囲の人が写真に撮るという状況があった気がする。なぜこんな話になったのか全然思い出せねえ（本当になぜ）
#phperkaigi @koriym さんが突如キーノートみたいなトーク始めてる pic.twitter.com/G52wtZOsfV
— uzulla (@uzulla) 2023年3月24日
詳しくはご本人のブログをどうぞ PHPerKaigi 2023 | BEAR Blog
Day2
jRubyの開発の歴史は本当にすごい。一時期hoge言語でのRuby実装というのが流行った時期はあったけれど、jRubyはずっと継続されているのもすごい。jRuby、なんとなくしか知らなかったのでこうやって生産者の顔が見れるのはやっぱり面白いし、RubyKaigiならではだな〜〜〜！
この日は、前日の反省を生かしてANDPADさんのランチをいただけた。有り難し
夜はFindyさんのドリンクアップに参加したのだけれど、そこで出た野菜（隣町で採れた野菜らしい）がバリ美味かった
Day3
Matzの基調講演でSpinelの話を聞いて、「あ〜〜そういえば去年くらいにそんな話をしていたかも？」と思ったのですが、全然去年ではなかったもよう
spinelはまだ開発1ヶ月なのに、なんだか聞いたことがあると思った人は優秀で、実は2023年のRuby30周年イベントでチラっと予告していたのです。名前すら3年以上前から構想していたのですね。今日のために
— Yukihiro Matz (@yukihiro_matz) 2026年4月24日
コードは全然見れてないので、後で見てみよう。AOTコンパイラの仕組みとか全然知らないので、こういうところからキャッチアップのモチベーションが高まるのもRubyKaigiの醍醐味かもしれない。最近はAIに聞くと色々教えてくれるから未知のものを知りやすくなったのもうれしい
https://github.com/matz/spinel
それはそれとして、Ruby Committers and the Worldでも話されていたけど、昨年のRubyKaigiでは生成AIを使ったコーディングは使えるけど使い所を選ぶ、みたいな感じだったけど今は当然使ってるよねという感じで普及の速度や進化の速さはすごいなあと小並感を持ってしまった。いや、仕事でもめっちゃ使うようになったのでそれはそうなんだけど
でも、Matzが生成AIのおかげでやりたいことがめっちゃできる、と言っているのはめちゃくちゃ良い話で明るい話題だったな
夜はhacomonoさんのドリンクアップで焼肉を食べた。店の周辺に何もなくてちょっとビビったけどご飯はめちゃうまかった
Day4
RubyKaigi的なイベントには不参加で、夕方から妻との函館旅行に移行するための幕間の時間
函館を徘徊して土方歳三の最期の地らしき公園に行ったり、ジンギスカン食べたり
ko1 さんの本屋さんのお手伝いをした
RubyKaigiの期中を通じて、少しだけ本屋さんで売り子（というのか？）をしていました 今回は事前に「開発方法論・組織論」という観点でいくつか選ばせていただきました。その中で現実の在庫状況などの都合で実際に売られたのは以下の書籍くらいかな？
自分が選んだのはそれくらいだったけれど、本屋さんに並んだこれらも本当におすすめの書籍
Rubyの書籍であれば来場者 = 対象者なんですが、マネジメント色のある本だと多少なりとも読む人を選ぶ傾向はあるのでなかなか万人に「これおすすめですよ！」とは言えないものの「最近マネジメントやり始めてて……」という方にこういう本おすすめですよ！とか紹介したりコミュニケーションができたのでとても楽しかった。気になった方は上にあげた書籍など、ぜひ読んでみてね
*1:結果論としてはDay0ドリンクアップは不参加にしておいて良かった
EMとして開発チームのマネジメントするときに気をつけていること
この記事はSmartHR - Qiita Advent Calendar 2025 - Qiita シリーズ2の3日目です。
ここに書かれている文章は100%オーガニック、人間の手でタイピングされたものです。
まえおき
この文章の前提として、私はエンジニア組織のセカンドラインマネージャーとしての立場からエントリを書いています。 プレイングマネージャーなど、別の立場から見ると違う意見や感じ方があるかもしれませんので、その点を留意してください。
正確を期すため所属会社であるSmartHRのレポートラインの資料で示すと、このDirectorというポジションでの観点となります。
https://www.figma.com/board/HFNrUtz5Bf1c52YABCxxrY/SmartHR-%E9%96%8B%E7%99%BA%E7%B5%84%E7%B9%94%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6?node-id=0-1&p=f
開発チームのマネジメントをする
いきなり主題から外れますが、自分自身においても、チームにしても、より良くしていくには理想との差分を考えることが大切です。例えばアーキテクチャやコードの書き方一つとってもそうですね。
「いま困ってないからオッケー」も間違いではないのですが、変化が大きい環境ではより良くしていくためには同じ場所で考え続けるのではなく、何らかのチェックポイントからバックキャストしてどう近づけるか（あるいはこのままで良いか）を考えないと先に進むのが難しいです。
スクラムでいうところの透明性・検査・適応が大切なのはそういったことを実現するために必要なのかなと考えています。
閑話休題
「開発チームをマネジメントする」とはなんでしょう？チームメンバーの採用？プロジェクト進捗？チームの雰囲気？色々な観点があると思います。私がEMを始めた頃はチームのスクラムイベントを通じてチームの雰囲気を見ていることが多かったです。
今振り返って見ると、この頃のチームの接しかたは「問題が起こったら（起こりそうなら）対処する」という側面が強く、チームがより良くなっていくという観点はチーム任せだったように思います。
もちろん、それも大きな間違いではないと思うのですが、マネージャーとしてチームをより良い状態にしていくためには理想との差分を追求していく必要がありました。
そこに気がついてから開発チームの状況や長期的な計画を考える際に重要としているのは、以下のドキュメントに書かれている「ピープルマネジメント」「テクノロジーマネジメント」「プロダクトマネジメント」「プロジェクトマネジメント」のバランスです*1
これは広木さんがEMとして求められるスキルを体系化したものですので、ご存じの方も多いでしょう。このエントリでは、このドキュメントで整理された4つのカテゴリをベースに進めていきます。 エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド #マネジメント - Qiita
こちらのドキュメントはEMとしてこうしたスキルの獲得や強みを把握して意思決定などのマネジメントに活かしていきましょう、という話ではありますが、私はEMとしてのケイパビリティだけではなく、組織・チームなど各単位のケイパビリティとして各カテゴリのバランスを考えることが多いです。
EMにはEMとして求められる時間軸、影響範囲がありますが、チームという単位においても、求められる時間軸、影響範囲があります。もちろん、個人に対しても。 それらの枠の中で適切なケイパビリティが確保されているのか？あるいは支援が必要かを考えながらマネジメントをしているよ、という話です。
チームと4つのケイパビリティのバランス
個人の能力として4つのケイパビリティを全て十分な水準で備えるのは難しいですが、チームとしてケイパビリティをどの程度備えているか？あるいは苦手とする部分はあるか？ということを考えると、チームメンバーのバランスやマネジメント上注視する部分などを整理しやすくなります。
チーム内で長所や短所を理解して補っていけることが理想ではありますが、そうはいっても目の前のタスクがあるのでなかなか難しい面もあるでしょう。そんな時は、EMとしてプレイングマネージャーを通じて（あるいはチーム全体に対して）、仕組みや成長を促すことでバランスを取れるようにしていきます。
例えば、SmartHRのプレイングマネージャーというポジションにおいてピープルマネジメントを除外することはできませんが、プロジェクトマネジメントは別のメンバーに任せる、といった委譲は可能です。あるいは、得意なメンバーに背中を預けながら経験の浅いメンバーに挑戦を促すといったこともやりやすくなると思います。または、チームに人を配属する際には不足している能力を補える人を配属するなどが考えやすくなりますよね。
ケイパビリティと規模
自分自身がプレイングマネージャーだった頃、4つのケイパビリティの話を見ても「ほえ〜〜〜EMって大変なんだな」くらいにしか考えてなかったのですが、自身がEMとなってわかったことは、自分たちで決められる規模に応じて、それぞれの立場に応じたケイパビリティが備えられるようにチーム作りや委譲、支援などをしていくことが重要なんだな、ということです。
EMであれば事業成長に対してプロダクト開発がボトルネックにならないようなアーキテクチャや技術戦略、組織設計などが当たるでしょうし、チームであればロードマップなどのスケジュールに対して価値提供できる機能開発やその機能開発を阻害する課題の発見、解決などが当たるでしょう。 個人であればそのコードが妥当性のあるコードなのか？決定した仕様の懸念点をどこまで考えられか、といったことが当たると思います*2。
これは当時の自分に言いたいことなんですが、どのポジションにおいても、自身の責任範囲におけるテクノロジーマネジメントやプロジェクトマネジメント、プロダクトマネジメント、ピープルマネジメントは必要になるので、「EM大変そう〜〜〜」じゃなくてもっと体系立てた情報を咀嚼しておくべきだったな、と反省しております😓
そうしたことを踏まえて、今は管掌チームと話す際もこれらの4つのケイパビリティをチームとして十分満たせているか？誰かががんばりすぎていないかといったことを気にかけながらコミュニケーションを取っています。
こうした様々な要素をケイパビリティとして整理し、強み・弱みを把握した上でチームや組織の運営をしていけると透明性・検査・適応がやりやすくなり、より良い状態を目指しやすくなると考えていますので、皆様の参考になれば幸いです
なんか久しぶりにブログ書いたら文章のテイストがわかんなくなっちゃったんですが、これもオーガニック文章ならではの迷走ということで許してください。
Kaigi on Rails 2025へ参加した
今年も会社で参加させてもらってありがたい話ですね
SmartHRはKaigi on Railsにブース出展しています！！
— SmartHR Developers (@smarthr_dev) 2025年9月26日
会場でお会いしましょう🙌#kaigionrails #kaigionrails_booth pic.twitter.com/UiEi2BQo9m
とても印象に残ったトーク
2日間で聞いたトークはどれも面白かったり興味深かったのですが、とくに以下はRailsに限らずイチWebアプリケーションエンジニアとして大切な示唆が含まれていたな〜〜と感じました（今回テーマに多かった非同期処理なんかもそうですが）
- Keynote: dynamic! / MOROHASHI Kyosuke | Kaigi on Rails 2025
- Railsアプリケーション開発者のためのブックガイド / Masayoshi Takahashi | Kaigi on Rails 2025
- 5年間のFintech × Rails実践に学ぶ - 基本に忠実な運用で築く高信頼性システム / ohbarye | Kaigi on Rails 2025
スライドはこちら
それはそれとして、ぼくはこの紹介文を全身に刻んで山に篭ります。さいなら……
https://speakerdeck.com/takahashim/a-guide-to-japanese-books-for-rails-application-developers?slide=48
閑話休題
↑にあげたテーマなんかも顕著ですが、「使っている道具」「取り組んでいる仕組み」を高いレベルで引き出すのはとても大切な話だと思う。
およそこの業界は新規作成よりはメンテナンスのほうが時間が長いはずで、その時にどれだけ王道のポテンシャルを発揮させるかは腕に見せどころだし、トータルの運用コストを減らすといったことにもつながる。
30%しかポテンシャルを引き出していない中でXXに大移行しました、というよりは*1*2、80%くらいは引き出した上で不足している点を別の何かに接木する、くらいが良い塩梅なんじゃないかと思うわけですよ。
こうした内容は最近読んだ「エンジニアリング統括責任者の手引き」の「付録 E」に書かれている「標準化」のトピックにも通じるものがあるように感じるのですが、当たり前のことを当たり前にやって高い水準に到達する、というのは自分がプレイヤーの時に考えていた以上に重要なのでは？ということを近年マネジメントを生業とするようになって強く思うようになってきたんですよね。
というようなことを考えながらトークを聞いていたのですが、物事に深く向き合うための地に足がついた話が多くてとても実りのあるカンファレンスでした。登壇した方、運営スタッフの皆さん、ブース出展の皆さん、大変良い時間を過ごせました、ありがとうございます！
さいごに
こちらも何卒（ダイマ）
RubyKaigi 2025 荷物ストラテジー
基本方針
まず、大前提としてPCを捨てる いや、持っていっても良いんだけど、明確な用途がない限り滞在時間の3%も使わないことが（悲しいことに）わかってしまったから持って行かない方向で検討してる*1。あとPC持って歩き回ると腰が……
もちろん、メモを取るのにPCがあると便利なんだけど机がない場合も多いから結局スマホで実況メモを残すのが楽って結論を出しています
持ち物リスト
- iPad
- 主に時間潰し用なのでスマホで代替できる可能性は高いです。今回のRubyKaigiでは出番がなかった……
- 着替え
- 充電ケーブル
- モバイルバッテリー
- リュックとは別に現地で動きやすいようにサコッシュ的な小さめのバッグ
- 10年？くらい前にbuildersconでもらったサコッシュを使い続けていたのだが、ついにぶっ壊れたので新調しなければ……
- 細々したものとしてはティッシュや常備薬、何かと使うことがあるビニール袋的なものを1〜2つ
着替えについて
着替えは初日に身につけてる分 + 二日分の着替えを持ってきてる 多くの宿泊施設にはコインランドリーがあるから、滞在3日目に初日〜2日目の衣類を洗えばなんとかなる コインランドリーに失敗して、本当に本当のどうにもならなければ下着類だけ現地で調達しても良い（上着はガチの夏場以外は着回してもなんとかなるじゃろ）
あとは季節にもよるけどイベントのノベルティでもらえるTシャツなどをあてにすることで1着減らす、というテクを使うこともあります
ここ1〜2年くらいはこんな感じで旅行やカンファレンスへ参加しています。良いと思ったらいいジャン！お願いします
*1:カンファレンス中はともかく観光中は取り扱いにも気を使うので
DRY原則とDRYさせない方法
SmartHR Advent Calendar 2024 シリーズ1 の3日目です。
前日はalpaca-tcさんのRailsで任意のキャッシュストアを移行する - alpaca-tcでした。
さて、12月ですね。皆さん乾燥していますか？私は冬場の寒さに耐えられずエアコンを使いまくってしまうので当然のように乾燥しまくっています。
少し前まで空気清浄機兼加湿器を使っていたのですが、タンクの形状が複雑で汚れがちだったり加湿が十分なのかわからん、という状態でした。
そんなわけで2023年に象印のいわゆる魔法瓶的な加湿器を買って利用するようになったのですが、かなり潤ってる感じがしていて、なんなら加湿器に近い部分の布団は若干湿ってるような勢いなので乾燥対策はできていると考えて良さそう。
ちなみに、買った機種はこれです。 www.zojirushi.co.jp
給水のためには本体ごと持って行かないといけないので少々重かったり、デカいので風呂場でシャワーヘッドを使って給水することになっていますが、部品を外す手間などもないので楽と言えば楽です。シンプルな分取り扱いしやすいしオススメです。
これがDRYさせない方法ってｺﾄ!? ーーそうだよ！
というわけで閑話休題
DRY原則
良くも悪くもDRY原則、よく聞きますよね。「DRYにする」といって同じ仕様ではなく同じコードをまとめちゃってPRでやり取りをする、なんていうのは一生に一度は経験しているものかもしれません。
でも待ってください。そもそも、ぼくらはDRY原則について何を知っているのでしょうか？よく言及される原則ではありますし、大筋はわかると思うのですが原典ではどのように書かれていたのでしょう？
我々は原典を探すため、Amazonの奥地へと向かった
DRY原則の原典
Wikipediaによると、達人プログラマーが出典と書いてあります。
おお、俺たちの達人プログラマーが原典だったのか。大昔に読んだ気がするけど全く覚えていない。
改めて読んでみても良いかもしれない……と考えたところで思い当たったのですが、達人プログラマーは初版と第二版が出版されています。
初版と、およそ20年の歳月を経て出版された第二版で内容を見比べてみると、当時と現代で気をつけているポイントが異なるかもしれないし、この二つを見比べてみると面白いかもしれない。
というわけで見比べてみました、というのが本エントリーの趣旨です*1。
DRY原則に関する初版と第二版の違い
まず、目次のタイトルからして違います。なんと初版ではDRY原則という名前がついてない（本文中に出てくる）。
| 初版 | 第二版 |
|---|---|
| 1章 7 二重化の過ち | 1章 9 DRY原則 - 二重化の過ち |
この時点で、20年の時を経てDRY原則が概念として確立した気配を感じますね。
ではもう少し見てみましょう。
流石に本文を丸々載せるわけにはいかないので、ざっと見出しを抜き出してみます。
初版
- どのように二重化が発生するのか？
- やむを得ない二重化
- 不慮の二重化
- 手抜きによる二重化
- 開発者間の二重化
第二版
- DRY原則はコード以外にも適用される
- コードの二重化
- コードの二重化すべてが知識の二重化というわけではない
- ドキュメントに二重化
- データにおけるDRY原則の違反
- 表面上の二重化
- 内部APIの間での二重化
- 外部APIの間での二重化
- データソースの二重化
- 開発者間の二重化
比べてみて
シンプルな話ですが、第二版になって分量が増えています。それはなぜかというと、第二版にこのような記述があるのです。
「まず最初に述べておきたいことがあります。本書の初版では、「 DRY原則」が意味することについて書き足りない部分がありました。多くの人々はこれがコードの話だと受け取ってしまったのです。つまり、 DRYを「ソースコードのコピー＆ペーストをしてはいけない」と解釈してしまったのです。これも DRY原則の一部ですが、ほんの些細な一部でしかありません。 DRY原則は「知識」や「意図」の二重化についての原則です。つまり、異なった場所（おそらくはまったく異なった場所）に同じことを表現するという問題を避けるための原則です。」
—『達人プログラマー ―熟達に向けたあなたの旅― 第2版』David Thomas, Andrew Hunt著 https://a.co/bGDC7rE
こうして見ると、当時の後悔だったのかそれ以降の時勢を読み取ったのかは分かりませんが、第二版で丁寧な解説になっているように見えます。 ソースコードの例も増えていて、わりとイメージつきやすくなっている印象もあります。
ただ、「データソースの二重化」に関しては趣旨はわかるけれども、あまり自分の好みじゃないかもしれねえ……。
それはさておき、第二版では「DRY原則」が指していることが詳細化され、言いたいことが誤解なく伝わるような構成になっていることと合わせて、内部APIや外部APIなどに言及されている点は現代っぽいなと感じました（とはいえ、API関連の話はそこまで記述が厚くなくて無念）。他にも、コミュニケーション面での話ではデイリースクラムやslackが例として挙げられるなど、本当にモダナイズされています。
詳しくは本書を買って君の目で確かめてくれ！という話なんですが、改めて読んでみた感想としては初版・第二版それぞれ良さがあるものの、DRY原則については「プログラマが知るべき97のこと」のDRY原則のエッセイを見るでも十分かもしれませんね……。
xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com
それはそれとして、改めて達人プログラマーに目を通してみて再確認したのですが、ぼくは達人プログラマーの「まえがき」と「第一章」が好きすぎるかもしれない。自分のプログラマーとしての考え方の原型はここにあるなと再確認しました*2。 特に「まえがき」で書かれている "「単なる石を切り出すのが我々の仕事であったとしても、常に心に聖堂を思い描かなければならない」" が本当に好きすぎるんですよね
あなたの石切工はどこから？と聞かれたら「達人プログラマー！」と答えるくらい好きなので……
Kaigi on Rails 2024への参加とプロポーザルを出した結果得られたもの
1ヶ月経ってしまいましたが、ようやっとこの文章を書いています
Kaigi on Rails 2024、大変楽しめましたし普段会わないRubyistな皆さんとも交流できてとても楽しめました
ちなみに、これは会場へのルート選択を誤ってビッグサイトに着いてしまった事例です
#kaigionrails 会場デケェ！ pic.twitter.com/l6VFpVB4Kd
— sugamasao (@sugamasao) 2024年10月25日
Kaigi on Rails で得たソフトウェアとの向き合い方
自分がそういうトークを見にいったから、ということもありますが……
以下のトークを見て、改めて感じたのはソフトウェア開発をどこまで深いレベルに潜って設計・開発できるかだな〜〜〜と思いました。表層的に解決しようとすると痛い目を見るのは経験しているものの、それを高いレベルで解決するためには練度が必要
Railsの思想やRailsが提供しているものを理解して上手に使おうというものがベースにありつつも、モデリングやRailsの拡張を通じて、どう破綻しないように事業成長を止めることなくソフトウェア開発を続けられるか。質とスピードの両方を維持していけるか、というのはやはりWebアプリケーションエンジニアとしての腕の見せ所だし、そこを深く考えられる人は尊敬してしまいますね……
speakerdeck.com speakerdeck.com speakerdeck.com
今回はプロポーザルを出した
それはそれとして、今回はKaigi on Railsにプロポーザルを出しました。事の成り行きは↓の同僚氏が書いたブログを見ていただくとして
はじめてのKaigi on Rails 2024 ── 初プロポーザルから登壇までの道のり - SmartHR Tech Blog
自身でプロポーザルを出したのは（たぶん）人生で2回目。今のところプロポーザル→登壇という流れは経験したことがないのでいつかは達成したいものですね
今回は「良いコードの書き方」的なかなり抽象度の高いテーマで応募したため、「それRailsと関係あるんか」という問いに対して芯を食った打ち返しができなくて落選したのかなと思っています
テーマ的にそれはそう、という話ではあるものの見せ方、伝え方次第であろうとも思っていて、もっとRailsでこういうコードあるよね！という文脈をセットで書ければもうちょっと良い線行けたんじゃないかとも想像しており、「この場（Kaigi on Rails）で、あなたが話すべき理由は何ですか？」という観点をもっと強くプロポーザルに乗せられるようにすべきだったなと反省しています
とはいえ、プロポーザルを出すということで自身がボンヤリ考えていたことを体系的に伝えるにはどうしたら良いか？など考えるきっかけにもなったし、プロポーザルを出す際の観点も（結果から考えれば当たり前の話ではあるけれど）しっかり受け止められたので良かったなと思います。
ちなみに、登壇できた暁にはJoel Spolsky氏の「間違ったコードは間違って見えるようにする」をフックにして話す予定でした。コード自体というよりはコメントなども含めた少し幅広いテーマではありますが 😆 （プロポーザル提出前の仮タイトルは「令和最新 間違ったコードは間違って見えるようにする」でした）
間違ったコードは間違って見えるようにする - The Joel on Software Translation Project
Kaigi on Railsの企画・運営していただいたスタッフの皆さんや登壇者、スポンサーなど関わった全ての皆さんのおかげで楽しく過ごせました。ありがと〜〜〜〜！
知識の探求と喜び #RubyKaigi 2024
（タイトルはAIに考えてもらいました。確かにそうだな！？と思ったので採用しました）
沖縄開催
元来出不精でとにかく家に居たいパーソンなのですが、なんとか一念発起して沖縄に行くことにしました
そして、せっかく行くのであればある程度観光も、ということで妻と一緒に前乗りして5/11-5/13は家族旅行、5/14-5/18(day0からday3の翌日まで)はRubyKaigiというスケジュールにしました
RubyKaigi - はじまりはじまり
ここ数年は会社のお金で参加させていただいており、今年はドリンクアップスポンサー
SmartHR Drink Up at RubyKaigi 2024 Day2 (5/16) - connpass
をやったり貢献できる幅が増えてきているのは嬉しいです
これは単なる社内事情ですが、DevRelの立ち上げを起点として社内でのスポンサー時の体制がしっかりしたものになってきて、社内でのモチベーションや熱量がうまく企画に昇華させられたことにより事前勉強会・事後勉強会・ドリンクアップの実施などいい感じに企画・運営ができていて組織力の高まりを感じます
day0 - すでに疲労
前乗りの旅行ですでに疲弊していたので、day2に行われるドリンクアップの下見で少し飲んで終了
ちなみに、「ぱいかじ」とは「南風」を沖縄の方言で読む言葉だそうです。勉強になりますね
day1 - 初手からわからん
Writing Weird Code
PEN sanのキーノートは本当に「わけわからない（褒め言葉です）」を無限に浴びせてくるのですがその中で他のセッションを紹介していく流れが美しすぎて本当に練度の高いトークでした。TRICKとか全くできる気はしないものの、だんだん興味が湧いてきました……
The grand strategy of Ruby Parser
実質parserのキーノートだなと思いました。parser.yについては過去のRubyKaigiなどを通じてなんとなく知っているものの、取り巻く環境などはまったくわかっていなかったので、関連技術要素がマッピングされて説明されてFF3の飛空艇を手に入れてからのような感覚*1*2を得ました
それはそれとして話しているkaneko sanがとても楽しそうだったのが印象的です
Namespace, What and Why
Namespace、ぜんぜん実現できるイメージが湧いてなかったのですが本当に動いてる……!!という感動がありました
Namespaceで解決する話ではないような気もするけどRubyでは require したタイミングでrequire先の定数などがグローバルに展開されてしまうのは制御できるオプションがあると嬉しいなあというのはずっと思っています
Ruby 3.1から load の第二引数にモジュールを渡せるようになったやつがrequire でもできたり事前にモジュールを定義するのではなく何らかのシンタックスシュガーでシュッとかけると嬉しいと言いますか……
update: ↑で書いた内容はMatzの話していたpackageに相当するとのことです
これがMatzのキーノートで言われていたPackage相当のものだと思います “事前にモジュールを定義するのではなく何らかのシンタックスシュガーでシュッとかけると嬉しいと言いますか……” / https://t.co/8U4xN9GjQT
— tagomoris (@tagomoris) 2024年5月22日
夜の部
夜はRubyKaigi 2024 Official Partyへ行き、BBQを楽しみながら本当にさまざまなお久しぶりの人と話せてよかった。お互いの近況であるとか、若者にドリームキャストってなんですか？と聞かれるなど時間を感じる一日でしたね😌
day2 - 話を聞くと興奮してくる
Leveraging Falcon and Rails for Real-Time Interactivity
リアルタイム通信（というのか？）の歴史とFalconでFlappy Birdを作るデモ
サーバーサイドで計算して、その結果を描画しているんだと思うけどあんなに滑らかに動かせるものなんだなあ、というのとああいうインタラクティブな操作とかは昔にFlashでやっていたのを思い起こされる
Embedding it into Ruby code
soutaro sanのRBSをコメントに埋め込めるようにする話。現在のIDEやGitHubなどの状況だとやはりrbsファイルが別にある状態でのメンテナンスが難しいのはそうなので、コメントに埋め込むというのは良さそう〜〜〜〜と思いました
Reducing Implicit Allocations During Method Calling
メソッド呼び出し時に余計なオブジェクトを生成しないようにしていく話。メモリのアロケート状況を見ながらチューニングしていく流れは参考（何のだろう）になりました
このセッションを見ていなかった同僚に話たところ、研鑽Rubyに書いてある内容が近いっぽいですね。研鑽Rubyを積読しているのがバレてしまった……
Good first issues of TypeProf
毎年、TypeProfのトークは楽しみにしているのですが、今年はコントリビュートしやすくするためのチュートリアル的な話でした
TypeProfは毎年「期待しています！」という気持ちを持っているのですが、今回のトークで「1人で開発してるの大変ス」という話を聞いて自分も何らかのお手伝いができれば、、という気持ちになっています（なっているだけじゃダメなの手を動かしましょう）
夜の部
day 2は会社のドリンクアップ準備のためLTの途中で抜けて事前準備へ
ドリンクアップでは入口の案内パーソンとして階段を上がったところでお出迎えする役をやりました。来場していただいたみなさん本当にありがとうございます
ドリンクアップ後は適当なお店で会社の人と飲みつつ、@kwappa san / @tagomoris san / @tompng san / @gachacomplete san へ近況やトークの感想などお伝えできてよかったです。ガチャピン先生はmalloc動画のころからのファンだったのでちゃんとお話できたのがめちゃくちゃ嬉しかったです😌
沖縄の締めはステーキ、と聞いていたので一日の最後にステーキを食べに行ったのも良い経験でした。さすがに40歳過ぎ & 24時過ぎにステーキを食べるのはためらいがあったのですが、赤身のステーキだと意外とシュッと行けて新しい概念を獲得してしまいました……
締めのステーキ、赤みの肉だとイケるということを知ってしまった #rubykaigi pic.twitter.com/g1Lw80cSdW
— sugamasao (@sugamasao) 2024年5月16日
day3 - 来年のRubyKaigiも楽しみすぎる
前日、IVRy社さんからもらった酒豪伝説を飲んでいたおかげか、わりと元気に起床。酒豪伝説しゅごい……
Ruby Committers and the World
例年、英語でのフリートークになると20%くらいしか理解できなくて「楽しいけどわからね〜〜」という感じになりがちだったのですが、今年はトークテーマなどをいい感じに整理してもらえたおかげかだいぶ理解できた気がします。コミッター陣の中でも意見が分かれたりしていたのは側から聞いていて面白かったです
soutaro sanがコメントに記載するRBSの記法について来場者に聞いていて、自分が手を挙げたほうがめちゃ少数派だったりして「うおお」となったりしました
これはコメントに記載する云々という話ではないと思うんですが、型によるサポートが強くなればなるほど、class（あるいはDataなど）でのオブジェクトの定義が重要になってくるかなあと思ったりしています。例えば Integer であるだけではなく、「1〜10までのIntegerである」などが表現できて型情報で事前条件（と表現するのが正しいかわからないけど）が明示できるようになると嬉しい……。というかこれは単にunionで型を定義したいという話な気がしてきました。忘れてください……（？）
Speeding up Instance Variables with Red-Black Trees
ちょっと事情があってトークに遅れてしまったのですが、赤黒木の説明をしつつそれをRubyで活用している実例に展開する流れはめちゃくちゃ面白かったです。Object Shapes、毎年話を聞いていてちょっとずつわかり具合が高くなっている気がします
ERB, ancient and future
関さんファンなので今年も聴きました。ERBの話を聞いていて「これはCGI!!」と興奮していたら「CGIだよ」という展開になって楽しかったです
自分が本当に文字通り駆け出しエンジニアだった頃は print であらゆるものを出力していたものですが、その時代にERBのアーキテクチャを検討できたのって本当にすごいなあ。今見ると「それはそう」となるかもしれないですが……
Matz Keynote
Ruby2（2.0ではない）の構想と現在実現されている機能の話や、Namespaceが入ってRuby2時代の構想が一通り実装できたらRuby 4にしようかなという内容
Namespaceの仕様などはこれからより詰めていく段階だと思いますが、めちゃくちゃ夢のある話でよかった。毎年、RubyKaigiでMatzの話を聞くと未来に対してワクワクさせられてすごいなあと思います（小並感）
夜の部
RubyKaigiの最後はmov社さんのAfter Partyへ
@kamipo sanと人生について話したり、@masaya_dev san と久しぶりにお話したり、LeSS について話したりといろいろな話をできて満足です。会場の導線などオペレーションがしっかりしていてとても過ごしやすい空間でした
day4 - また来年
飛行機の搭乗時間まで時間があったので、うわさの千日でぜんざいを食べたり、波の上ビーチで海を感じたりして解散
RubyKaigi Day 4やっていくぞhttps://t.co/ov3aiPF4HT pic.twitter.com/JKjMWZMT1N
— sugamasao (@sugamasao) 2024年5月18日
#rubykaigi やっていくぞ！ pic.twitter.com/Wq2BMYdHGN
— sugamasao (@sugamasao) 2024年5月18日
くぅ～疲れましたw これにてワイの #rubykaigi は完結です！ pic.twitter.com/JVxiiBZ0Cr
— sugamasao (@sugamasao) 2024年5月18日
もはや方々で言われているので言語化されつつある話ではありますが、RubyKaigiって「明日使える便利テクニックを得ました！」とかではなく「なるほどわからん」を積み重ねて各トークの関連やRubyという言語のアレコレ*3を知っていくことで繋がりが生まれてくる快感や高揚がすごいんですよね（(自分の性格として"物事を知る"ということが好きっぽい)）。そしてまたわからないことが増えていく。無限か？
さらにさらに、それを作っている・トークしていた人が目の前にいる、なんなら隣で酒を飲んでる的なことが普通に発生する。
この"良さ"を未経験の人に伝えるのは難しいのですが、私は今年もRubyKaigiを十二分に楽しめました！RubyKaigiのSpeakerのみなさん、RubyKaigiスタッフのみなさん、スポンサーブースの皆さん、お久しぶりに/はじめましてでお話できたみなさん、あらゆる人のお陰で今年も素晴らしい体験をすることができました！
また来年、松山で会いましょう〜〜〜☺️
