エンジニア歴3年、Kaigi on Railsの舞台へ
まず一番に伝えたいのは「こんな自分でも登壇できた」 という事実です。
私はRIZAPに新卒で入社しましたが、そのときの採用は総合職です。ITとは全く無縁の自分がKaigi on Railsのスピーカーとして舞台に立つとは、夢にも思っていませんでした。
転機は当社のchocoZAPという新規サービスの立ち上げです。社内で「エンジニアを育てよう」という流れがあり、そこでジョブチェンジをすることにしました。2022年の夏から実務に携わり始め、最初の1年半はフロントエンドが中心。Railsを日常的に触るようになるのは、そのさらに後のことです。
そうした中で、2023年10月に初めてKaigi on Railsに参加しました。そのときはバックエンドの実務経験はなく、研修でCRUDアプリを作ったくらい。発表の半分も理解できず、登壇者はまるで雲の上の存在でした。
それでもRubyやRailsのコミュニティはとても温かく、「自分は蚊帳の外ではない」と思わせてくれる空気がありました。登壇者も聴講者も同じ仲間としての一体感がある。その雰囲気に触れるうちに、自然と「いつか自分もこの壇上に立ちたい」という気持ちが芽生えたのです。
その思いが少しずつ膨らみ、CFPを提出する勇気につながりました。そして今、登壇を果たした自分が伝えたいのは、この舞台に立てるチャンスは誰にでもある ということです。
チャンスを掴むために
大事なのはそのチャンスにどう向き合うかです。
私自身、この数年は愚直にRubyやRailsと向き合い、1行のコード、1つのメソッドに対して理解を怠らないよう取り組んできました。
そこに近道はなく、少しずつ積み上げていくのみです。
その積み上げを加速させてくれたのがRIZAPの環境でした。
成長を後押しする環境
RIZAPではポテンシャル採用を積極的におこない、未経験者や新卒でも急速に成長して活躍できるよう、育成の仕組みを整えています。私がここまで来られたのも、この仕組みに支えられたからでしょう。
この取り組みについては、Ruby World Conference 2025 で詳しく発表する予定です。ぜひ楽しみにしてください。
発表内容
さて、今回の発表テーマは「多重範囲型を活用してコードをシンプルにする技術」 です。
chocoZAPの予約システムを刷新するにあたり、ユーザーが好きな時間に自由に予約できる仕組みが求められました。
一般的な予約システムは、あらかじめ固定の予約枠を用意し、ユーザーがその枠を選択する形が多いかと思います。
しかし、chocoZAPの予約システムでは「枠」という考え方を取り払う必要がありました。
ところが枠がないことで「この時間は予約可能か？」という判定が一気に難しくなり、コードは複雑化し、パフォーマンスも悪化しました。
そこで辿り着いたのが、範囲（Range）の数学的発想をコードに持ち込むアプローチです。
「予約できない期間」をすべて範囲として捉える
「確認したい対象期間」との差集合を計算する
残った範囲を「予約可能時間」として算出する
こうすることで予約の空き状況を一撃で導けるのではと考えました。
ただし、PostgreSQLの通常の範囲型では複数の分断された範囲を扱えません。
そこで利用したのが 多重範囲型（multirange型） です。
多重範囲型を使えば、分断された複数の期間をひとまとめに扱え、差集合や積集合といった演算も可能になります。
今回のセッションでは、この多重範囲型をRailsでどのように扱うか、その実践的な方法まで紹介しました。
予約システムに限らず「連続した値の集まり」を扱う処理全般において、応用できる知見だと考えています。
登壇して感じた３つのこと
Kaigi on Railsのチーフオーガナイザーである大倉さんは、「プロポーザルを出す良さ」について語られています。
実際に登壇してみて、その内容はまさに自分が感じたことと重なっていました。
私が登壇を通じて強く実感したのは、次の3つです。
1. 自らの学びを抽象化し、一般的に使える技術へ昇華する
登壇を準備する過程で、自分がこれまで取り組んできた内容を整理することができ、よい振り返りになります。
さらに、単なる振り返りにとどまらず、次に応用できる形へと昇華させることができます。
登壇となれば、少しでも多くの人の役に立つ話をしたいと思うものです。
そのためには実務で得た知見をそのまま話すのではなく「どうすれば一般化して他の人にも役立つか」を考える必要があります。
実務ではどうしても要件や制約が細かく、このサービス、この場面だからこそ成立する知見になりがちです。
私の今回の発表は「多重範囲型」というニッチな技術が中心で、聞き手を選ぶ内容だったかもしれません。
それでもできるだけ一般化し、聞いてくださった方に少しでも役立つようにと意識して話しました。
2. 当日のコミュニケーションが格段にしやすくなる
正直に言えば、私はエンジニアとしてまだまだ未熟です。名だたる登壇者や界隈で知られたエンジニアを目の前にすると、どうしても物怖じしてしまいます。
しかし「登壇者」という肩書きがあるだけで少し気が大きくなり、自分から話しかけやすくなりました！
実際に多くの方と会話でき、普段なら遠慮してしまうような質問や相談もすることができました。
1年あるいは数年かけて取り組んできたことを、15分や30分の限られた時間で全て話し切るのは到底無理があります。おそらく他の登壇者の方々も泣く泣く削った話が山ほどあるはずです。
だからこそ、カンファレンス中に登壇者へ直接質問したり、興味ある話を深掘りできることこそが、現地参加の大きな意義だと思います。
発表内容を聞くだけなら後日公開されるアーカイブで十分です。
わざわざ時間とお金をかけて現地に行く意義は、リアルな場に集った多くの人と密に交わり、活発なコミュニケーションを通してdynamicな刺激を得られること にあります。
そしてさらに登壇することで、さまざまな交流が一層しやすくなり、本当に有意義な時間を過ごせました。
3. コミュニティに貢献できるよろこび
2年前の私は登壇者を雲の上の存在のように感じつつも、心を動かされていました。
その時の「受け取る側」から、今回の「届ける側」へ回れたこと。これは登壇をしたからこそ得られた体験です。
発表後に「参考になった」と声をかけていただいたとき、胸の奥がじんわりと熱くなりました。
自分の小さな経験でも、誰かの学びや勇気につながる。これこそ登壇の意義であり、コミュニティに還元するというよろこびなのだと感じています。
おわりに
エンジニア歴3年でKaigi on Railsの舞台に立てたのは、私にとって大きな節目でした。
この経験を通して感じたのは、特別な才能がなくても日々RubyやRailsと真摯に向き合い挑戦を続ければ、登壇のチャンスは誰にでも開かれているということです。
私自身もまだ未熟ですが、この経験を糧に次の挑戦へと一歩ずつ進んでいきたいと思います。
そしてこの記事が、誰か一人の一歩につながったなら、それ以上に嬉しいことはありません。
APEENDIX：
CFPを書く際の具体的なコツについては、実際に採択選考に携わっている運営メンバーである
が非常に参考になりますので、ぜひ読んでみてください。
関連する求人情報
