こんにちは！ITANDI株式会社で、物件管理システムの開発をしている須田です！

23卒でITANDIに入社し、社会人・エンジニアともに2年目になります。物件管理システムでは、バックエンド（Rails）、最近はフロントエンド（TypeScript, React）で開発をしています。少しずつできることが増えてきていて、毎日楽しくエンジニアリングに向き合っています。

2025年1月18日に開催された東京Ruby会議12に参加してきました！

regional.rubykaigi.org

会場は満員で、チケットも全て売れていているようでした。スポンサーブースも多く出ており、講演がされるホールまで辿り着くのが大変なほど人が多く、大盛況でした！

Thank you all for joining Tokyo RubyKaigi 12! #tokyorubykaigi pic.twitter.com/GxIhi3arSX
— 東京Ruby会議12🕊️ (@tokyork12) 2025年1月23日

コンセプトは「Ruby と暮らす」でした。コンセプトの通り身近に感じられるテーマが多く、興味深い講演がたくさんありました。

今回のブログでは、特に印象に残った2つの講演について、それぞれの概要や自分が感じたことを書いていきます。

Scaling Ruby @GitHub（Keynote）

スライドが公開されていないため、GitHubの取り組みについての要点と参考になった事例を以下にまとめます。

登壇者

John Hawthorn さん
- RubyコミッターとRails Coreメンバーであり、GitHubにてパフォーマンスとスケーラビリティに取り組むスタッフエンジニア。

GitHubのスケーリング

スケーリングの課題と対応
- ユーザーのスケーリング: 顧客数やトラフィックの急増に対応するため、システムの負荷分散とパフォーマンス改善を実施
- チームのスケーリング: 開発者の増加に伴う効率的なコード管理やチーム間の調整を強化
GitHubの現状
- 世界中で1億5000万人以上の開発者をサポート
- 初期はRuby on Railsで構築されたシンプルなアプリケーションからスタートしており、現在もRuby on Railsの最先端を走っている

GitHubのRubyとRuby on Rails

Ruby
- 2007年設立当初はRuby 1.8を使用していた
- 現在はRuby 3.4.1を採用し、YJITを導入して最大20%のパフォーマンス向上を実現
Ruby on Rails
- 初期はRails 1.2、現在は未リリースのRails 8.1アルファ版を適用している
- 毎週のアップグレードを通じて、常に最新の機能とパフォーマンスを維持している

GitHubのモノリシックアプリケーション

特徴
- 400万行以上のコードベースのうち半分以上がテストコード
- 月間2500件以上のプルリクエストをデプロイし、1000人以上の開発者が関与している
具体的な課題解決の取り組み
- コードオーナーシップ: 各ファイルに担当チームを割り当て、適切なレビュー体制を確立
- エラー監視システム: バックトレース解析で問題箇所の担当チームを迅速に特定

OpenStructの削除事例

背景と課題
- OpenStructのパフォーマンス低下やYJITとの相性との相性が悪かった
- Ruby 3.5で標準Gemから削除予定
- 削除に際して大量のOpenStructコードがあり、テキストマッチの削除だけでは不十分だったため、以下のプロセスを踏む必要があった
解決プロセス
- 現状を維持し、新たな問題発生を防止する
- lintファイルを導入して新規使用をブロック
- チーム内でtestやlintを活用して対応策を周知
- 段階的な削除作業を経て、完全な移行を完了

まとめ

この講演を通じて、GitHubのような巨大なWebアプリケーションでも、驚くほど身近に感じることができました。特に、Rubocopを用いてコード継承を防ぐだけでなく、新規追加を防止するというアプローチには非常に感銘を受けました。この手法は、自身の開発でも積極的に採用していきたいと思います。

混沌とした例外処理とエラー監視に秩序をもたらす

登壇者

森弘一茂さん
- STORESのエンジニア
- 福岡のRubyコミュニティやRails Girlsでの活動にも力を入れている

講演内容

speakerdeck.com

まとめ

Expected/Accepted
Expected/UnAccepted
UnExpected

のどこに当てはまるかをまず考えるというのは、明確な基準になっておりとても勉強になりました。

また、Johnさんの講演同様、ルールの浸透は口頭だけでは限界があるので、そこは機械に頼っていこうというのはRubocopに限らず、まざまな場面で活かせる考え方だと思いました。

最後に

これらの講演を通じて、規模が大きくなるほど重要になるルールの統一や変更の難しさが明確になりました。ただ、方法は意外にもアプリケーション関係なく同様のものでした。 ITANDIのプロダクトもチームも今後さらに大きくなっていくので、今回の講演を参考にスケールしても早く安全に変更ができるような仕組みづくりをしていきたいと思います。

東京Ruby会議12に参加して改めて、Rubyの持つ魅力や可能性を感じるとともに、自分自身の技術スキルをさらに磨いていきたいというモチベーションが高まり、良い経験ができました。そして、いつかは自分もステージに立って講演できるように、日々の技術インプット・アウトプットを大切にしていきたいと思います。

また次回の開催を楽しみにしています。

この記事を書いた人