RubyKaigi 2026 でfreee Drink upを開催しました!
はじめに こんにちは！freee人事労務のエンジニアのkaseです。 RubyKaigi 2026が函館にて開催されました。 参加された方はいかがでしたか？私は初参加だったのですが、興味のある講演を聞きつつ、ハセガワストアのやきとり弁当やラッキーピエロといったローカルフードを満喫でき、大変満足でした!(少し食べすぎました) freeeは、GoldスポンサーとDrinkupスポンサーとして参加しており、三日目の夜にDrinkupを開催しました。 今回はその模様をレポートします! SweeeもDrinkupの参加者をお出迎え Drinkup当日の様子 Drinkupは、PREMIER HOTEL -CABIN PRESIDENT- HAKODATEにて開催されました。 Matzさんのkeynoteと、次回開催地が宮崎であるという発表をもってRubyKaigi 2026は閉幕。その余韻のなか、Drinkup会場には少しずつ参加者が集まり、乾杯が行われました。 円卓のオードブルを囲みながら、各テーブルで振り返りや会社の話に花を咲かせました。 会場全体は、落ち着いたトーンで、RubyKaigi最終日の夜にふさわしい空気でした。 ビンゴも盛り上がりました 食事が落ち着いてからは、ビンゴも開催されました! これはただのビンゴゲームではなく、RubyKaigiにちなんでRubyのメソッドをビンゴのマスとしたWebアプリを有志で企画し完成させたものです! 先ほどまでの落ち着いた空気から一転、みんな画面に集中して手元のビンゴと照らし合わせていました。 開発運営の私視点では、リーチからなかなかビンゴ達成者が出ず、バグがあるのではと非常にソワソワしました。 先着10名にfreeeオリジナルのノベルティを用意していたのですが、10人目と一瞬の差でビンゴを達成した方がいて……結局、11人にお渡ししました! 普段業務で扱わないメソッドも多く、「これは何だろう？」といったRuby自体への反応も生まれ、最後までRubyKaigiの空気を楽しめたのかなと思います。 出てくるRubyメソッドに一喜一憂 おわりに RubyKaigi、最高のイベントでした!改めて、Drinkupに参加してくださった方ありがとうございました! 来年もぜひ参加したいです!
- Ruby
SaaS管理ユニットはなぜモジュラーモノリスから始め、マイクロサービスへ移行しているのか
こんにちは。SmartHRの情シスソリューション開発部 SaaS管理ユニットでプロダクトエンジニアをしているnoriです。 先日、関ヶ原Ruby会議 01のスポンサーLTで「SmartHR情シス領域・立ち上げの裏側」というテーマで発表しました。発表では、SaaS管理ユニットが情シス領域のプロダクトをどのように立ち上げ、現在どのようなアーキテクチャ移行に取り組んでいるのかを紹介しました。 この記事では、LTの内容をもとに、SmartHRのSaaS管理ユニットがモジュラーモノリスで開発を始めた理由、その後に見えてきた課題、そしてマイクロサービスへ段階的に移行している現在の取り組みを紹介します。 SaaS管理ユニットって…… SmartHRは、人事労務領域だけでなく、情報システム部門向けのサービスにも取り組んでいます。 この領域への取り組みは、2023年10月にメタップス社から「メタップスクラウド」の事業譲渡を受けたことをきっかけに始まりました。SmartHRが情シス領域に取り組む背景については、「『人事が』使うサービスから、『HRのデータを』使うサービスへ。情シス領域進出の背景と、目指す未来」でも紹介しています。 SmartHRには、入退社や異動、所属・役職などの従業員データが集まります。この従業員データを活用することで、外部SaaSへのシングルサインオンや、SaaSアカウントの管理をより効率化できます。 たとえば、IdP（Identity Provider）機能ではSmartHRを起点に外部SaaSへログインできます。また、ID管理機能ではSmartHR上の従業員データをもとに、外部SaaSのアカウントを可視化したり、作成・削除したりできます。 SaaS管理ユニットは、こうした情報システム部門向けの価値を届けるために、IdP機能やID管理機能の開発に取り組んでいます。 立ち上げではモジュラーモノリスを選んだ SaaS管理ユニットは、情シス領域の立ち上げ時に、SmartHRの基本機能のモノリス内にモジュールを作る形で開発を始めました。 モジュラーモノリスアーキテクチャにすることで、新しくインフラを一から用意する必要がなく、既存の認証や権限、デプロイ基盤を利用できます。また、同じデータベース上で開発できるため、従業員データをActive Record経由で扱いやすく、SmartHR上の従業員データ・マスタデータをもとに、シングルサインオンできる従業員を制限したり、SaaSのアカウントの所有状況を可視化する、といった機能を容易に実現できました。 結果として、IdP機能は約半年でリリースできました。 モジュラーモノリスで課題も見えてきた モジュラーモノリスで始めたことで初速は出せましたが、プロダクトが成長するにつれて課題も見えてきました。 1つ目は、可用性の課題です。情シス向けの機能は、従業員が日々の業務で外部SaaSにアクセスするための入口になります。しかし、基本機能側がメンテナンスやインシデントの影響で止まると、IdP機能やID管理機能も止まってしまいます。 特にIdP機能は、利用者にとってログイン経路そのものです。年末調整のような労務機能のメンテナンスや、基本機能内の別プロダクトの障害によって、外部SaaSへのログイン体験に影響が出る構造は避けたいものでした。 2つ目は、パフォーマンスの課題です。SmartHRの従業員データは、過去・現在・未来の状態を扱うためにBitemporal Data Modelを採用しています。Bitemporal Data Modelは履歴データを正確に扱える一方で、従業員という大きなモデルを扱うため、関連するテーブルやカラムが多くなりやすい構造です。 SaaS管理ユニットの機能では、従業員データを参照しながら外部アカウントと突き合わせる処理が多くあります。しかし、情シス領域から見ると不要なテーブルやカラムがあっても、基本機能側のデータ構造の上に乗っている以上、用途に合わせて簡単に整理できるわけではありません。ユースケースに合わせてインデックスを追加したくても、情シス領域だけの都合で基本機能側のテーブルに多くのインデックスを増やす判断はしづらく、扱う従業員数が増えるほど難しさが大きくなっていきました。 3つ目は、開発体験の課題です。現在改善中ではありますが、大きなモノリスの中で開発しているため、CIに30分以上かかることがありました。デプロイは1日1回で、ステージング環境へ反映されるまでにも時間がかかります。ローカル開発でもrails sの起動に時間がかかり、フロントエンドからAPIを呼び出すだけでも数秒待つことがありました。 SaaS管理ユニットでは、AIも活用しながら、一人ひとりがフィーチャーを担当して一気に進める開発体制をとっています。そのため、小さく直してすぐ確かめたい場面が多く、CIや起動の待ち時間が積み重なると、開発の勢いを保ちづらくなっていました。 マイクロサービスへ段階的に移行している SaaS管理ユニットは、現在マイクロサービスへの段階的な移行を進めています。 移行で大切にしているのは、一気に切り離すのではなく、依存関係をほどきながら段階的に独立性を高めることです。すでにお客様が使っている機能を止めずに移行する必要があるため、リスクを小さく分けて進めています。 基本機能への依存を整理 最初のステップでは、Packwerkを使って基本機能への依存を整理しました。従業員マスタなど、基本機能側のデータに直接触っていた箇所を、Public APIを介したメソッド呼び出しへ寄せていきます。 この段階で得られたのは、切り離す前に境界を見えるようにできたことです。どこが基本機能に依存しているのか、どの呼び出しをサービス間のインターフェイスとして扱うべきなのかを、コード上で確認しやすくなりました。 依存をHTTP通信に置き換え 次のステップでは、その依存をHTTP通信に置き換えました。これにより、同じモノリス内のメソッド呼び出しではなく、サービス間通信に近い形で境界を扱えるようになります。 この段階では、レポジトリを分ける前に、通信の失敗やレスポンスの扱いを含めてサービス間通信の形に慣れることができました。まだ同じモノリス内にコードがある状態で、切り離した後のインターフェイスを先に育てられたのは大きかったです。 レポジトリの分離 現在は、レポジトリを分離した段階にいます。IdP機能やID管理機能のコードベースを基本機能から切り出し、あわせてインフラも新しく作って分離しました。 APIの移行では、既存のAPIを一度に置き換えるのではなく、ストラングラーパターンを使って段階的に移しています。既存の経路を残したまま、新しいサービス側へ処理を少しずつ移し、VPC内のHTTP通信を通じて必要なデータにアクセスする構成へ変えていきました。 一つの機能に新旧のAPIが共存する期間があるため、腐敗防止層を設けて差分を吸収しながら移行しています。すでにお客様が使っている機能を止めないように、置き換えられるところから少しずつ新しいサービス側へ寄せています。 レポジトリとインフラを分けたことで、CIやデプロイ、ローカル開発を対象サービスに閉じられるようになってきています。機能を届けるための待ち時間を減らし、SaaS管理ユニットの開発リズムに合った環境を作りやすくなっています。 今後の予定：データベースの移行 今後は、データベースの移行にも取り組む予定です。基本機能側の従業員データを直接参照するのではなく、バッチやWorkerによるデータ同期を通じて、SaaS管理ユニット側のサービスが必要なデータを持てるようにしていきます。 データベースを分けることで目指しているのは、可用性とパフォーマンスの面でも独立性を高めることです。必要なデータをSaaS管理ユニット側の用途に合わせて持てるようにし、基本機能側のデータ構造に直接依存し続ける状態から少しずつ離れていきます。 移行によって開発速度とパフォーマンスが改善してきた 移行はまだ完了していませんが、すでに効果が出始めています。 デプロイでは、1日1回という制限から解放されました。小さな修正や改善をモノリス全体のリリースサイクルに合わせる必要がなくなり、対象サービスの都合で届けやすくなっています。 CIも大きく改善しています。以前はモノリス全体のCIに30分以上かかることがありましたが、まだ移行途中ではありますが移行後のサービスでは約1分で終わるようになりました。AIを使って一人ひとりがフィーチャーを進める開発体制では、レビュー前に小さく直してすぐ確認できることが重要なので、この差はかなり大きいと感じています。 ローカル環境でも、rails sの起動が速くなりました。大きなモノリスを立ち上げるのではなく、対象サービスに閉じて開発できるため、画面を開いてAPIの挙動を確認するまでの待ち時間が短くなっています。 さらに、レポジトリを分けたことで、新しい開発基盤も取り入れやすくなりました。実際にRubyDex、Sorbet、Caddyなどを導入し、対象サービスに閉じた形で運用できています。モノリス全体へ一気に導入するには影響範囲が大きい技術でも、小さな単位で取り入れられるようになりました。 パフォーマンス面でも改善の兆しが見えています。たとえば、従業員に紐づく従業員テーブルを結合して取得する処理では、必要なデータをSaaS管理ユニット側の用途に合わせて持つことで、モノリス側の複雑なデータ構造に直接アクセスする回数を減らせます。まだ移行途中であり、厳密なベンチマークではありませんが、現時点で取得できている値を比較すると、次のような傾向がありました。 従業員データ数 移行前最遅 移行後最遅 速度比 1,000件 207ms 57.6ms 3.59倍 10,000件 2.30s 614ms 3.75倍 50,000件 13.7s 3.07s 4.46倍 従業員データテーブルの行サイズも約71%削減できました。必要なデータをサービス側の用途に合わせて持つことで、複雑な履歴データに都度アクセスする構造から少しずつ離れられています。 モジュラーモノリスで始めたから移行できた 今回の経験から、モジュラーモノリスで始めることと、マイクロサービスへ移行することは対立する選択肢ではないと感じています。 最初から別サービスとして作っていたら、インフラやデータ連携の準備に時間がかかり、IdP機能を今の速さで届けるのは難しかったはずです。立ち上げ時点では、既存の仕組みを使いながらプロダクトとして成立するところまで早く持っていくことが重要でした。その意味で、モジュラーモノリスは当時の状況に合った選択だったと思います。 一方で、モノリスの中でもモジュールとして境界を切っていたことで、後から見返したときに「ここまでは情シス領域の責務」と判断しやすい状態を作れていました。機能が育ってから分離を考え始めても、責務の境界がまったく見えていなければ、どこから手をつけるかを決めるだけでも時間がかかります。 Packwerkを導入していたことで、普段の開発でもモジュール間・サービス間の依存を意識しやすくなりました。 移行を進める場面でも、Packwerkで依存関係を見たときに、このメソッドは情シスモジュールからしか呼ばれていない、ここは基本機能に依存している、といったことが分かるのは助かりました。基本機能への依存が見えれば、Public API経由の呼び出しに置き換えながら少しずつ剥がしていけます。小さく確認しながら進められたことで、稼働中の機能への影響を抑えながら移行できました。 まとめ モジュラーモノリスは、立ち上げのための現実的な選択肢でした。そして、境界を意識して作っておくことで、後からマイクロサービスへ移行するための足場にもなりました。 今回の移行を通じて得た学びは、最初から完成形のアーキテクチャを選ぶことよりも、その時点で価値を届けやすい形を選びつつ、後で変えられる余地を残しておくことの大切さです。立ち上げ期にモジュラーモノリスで速く進み、成長に合わせて必要な独立性を高めていく進め方は、SaaS管理ユニットにとって自然な選択だったと感じています。 We Are Hiring! SmartHRでは一緒にSmartHRを作りあげていく仲間を募集中です！ SaaS管理ユニットでは、SmartHRの従業員データを活用しながら、情報システム部門の業務をより良くするプロダクトを作っています。情シス領域のプロダクト開発や、大きなシステムを段階的に分離していく取り組みに興味がある方は、ぜひカジュアル面談でお話ししましょう！ hello-world.smarthr.co.jp
- Ruby
- Rails
- マイクロサービス
関ケ原Ruby会議01の御大義に賛同いたし、後ろ盾となりて支えたり
拙者、SmartHR情シスソリューション開発部プロダクトエンジニアのnoriと申す者にござる。普段は大和国の居城より、遠隔にて勤めを果たしておる。 SmartHRは、令和8年5月30日に岐阜県不破郡関ケ原町の関ケ原ふれあいセンターで開かれし関ケ原Ruby会議01に協賛いたした。本稿では、SmartHRが協賛したこと、スポンサーLTで申したこと、そして会場にて感じたことを、関ケ原の地に敬意を込め、武将語にて記すものに候。 読みづらきことなど案ずるに及ばず。拙者は西軍の足軽に過ぎませぬが、本稿に限っては武将になりきり、戦国の世より筆を執る所存にござる。各々方、いざ参らん。 関ケ原Ruby会議01とは 関ケ原Ruby会議01は、天下分け目の地「関ケ原」で開催されし地域Ruby会議にござる。東軍・西軍に分かれし諸将が、それぞれの技と知略を携えて集い、Rubyの新たな歴史を刻むべく、関ケ原ふれあいセンターへ馳せ参じた。 この会議では、東西に分かれたトークセッション、RubyKajaの復活、合戦、宴など、関ケ原の地だからこそできる企てが数多く用意されておった。開催のきっかけや見どころは、SmartHR Tech Blogの運営インタビュー前後編にも詳しく記されているゆえ、戦の全容を知りたい御仁はぜひあわせて読まれよ。 tech.smarthr.jp tech.smarthr.jp 当社の者も登壇いたした SmartHRプロダクトエンジニアにして東軍の武将、kinoppyd殿が「Job戦国時代」と題し、Solid Queue vs Sidekiqの戦模様について口上を述べ申した。現実の戦場に即したベンチマークをもとに、Jobの特性によって採るべき布陣が変わることを示す、たいへん得るところ多き口上であった。 東軍の武将として壇上に出陣せしkinoppyd殿 また、東軍の武将でありながら、セッション開始直後に見事な謀反を起こし、西軍に味方する構えを見せ申した。西軍の足軽たる拙者にとって、これほど頼もしき援軍はござらぬ。 青き陣羽織、通称「小早川ビブス」を身にまとい、西軍の武将として壇上に馳せ参じるkinoppyd殿 スポンサーLTにて、情シス領域の開発につき口上を述べ申した 拙者はスポンサーLTにて、SmartHRの情シス領域の立ち上げと、モジュラーモノリスからマイクロサービスへ段階的に移行している話を申した。 題して「後援の御仁より賜りし、急の口上」。令和の世の言葉に直せば、スポンサーLTでござる。せっかく関ケ原の地で口上を述べるならば、ただの会社紹介では兵の士気も上がらぬと心得、武将語をまとって登壇いたした。 SmartHRと聞くと、「HRと名乗るからには、人事のための道具であろう」と思われる御仁もおられるやもしれぬ。しかし、SmartHRでは人事労務領域に加えて、情報システム部門を支えるIdPやID管理の機能も提供しておる。 スポンサーLTでは、この情シス領域をいかに立ち上げ、モジュラーモノリスにて初速を出し、その後マイクロサービスへ段階的に布陣を変えているのかを紹介いたした。詳しき戦記は、後日当社のブログにて改めて記す所存にござる。モジュラーモノリスとマイクロサービスの狭間で戦う諸将は、ぜひ続報をご覧くだされ。 スポンサーLTのタイトルスライドを背に、壇上に立つ拙者 ブースでも東西の陣を構え申した ブースでは、東西実行委員長のosyoyu殿、ydah殿による「あなたはどっち派？」の企てを実施いたした。結果は、赤がosyoyu殿、青がydah殿でござった。 お雑煮の餅で見破った御仁も多かったのう。多くの参陣者が家紋札を貼ってくださり、陣中はたいへん盛り上がっておった。参陣してくださった各々方、誠にかたじけなし。 関ケ原Ruby会議01に出展したSmartHRのスポンサーブース、もとい陣 「あなたはどっち派？」の結果発表で盛り上がるosyoyu殿とydah殿 最後に 関ケ原Ruby会議01では、スポンサーとして参陣するだけでなく、Rubyistの各々方と直に語らうことができた。地域Ruby会議には、その土地ならではの空気がある。関ケ原Ruby会議01も例外ではなく、会場全体に「この場を楽しもう」という熱が満ちており、技術の話を交わしながらも、陣中には祭りにも似た高揚が満ちておった。 スポンサーLTで武将語を使ったことで、SmartHRの取り組みを少しでも印象に残せていたなら幸いにござる。真面目な技術の話も、戦場の文脈に合わせて届け方を工夫することで、より楽しく伝えられるのだと学び申した。 SmartHRは、これからもRubyコミュニティへの感謝を忘れず、技術を通じてよりよいプロダクトづくりに励んでまいる。関ケ原Ruby会議01を支えし奉行衆の皆々様、壇上にて御口上を述べられし登壇諸将、そして天下分け目の地へ馳せ参じられしRubyの衆の皆々様に、心より御礼申し上げまする。次なる戦場、もとい次なるイベントでも、どこかで相まみえられれば幸いにござる。 関ケ原Ruby会議01に馳せ参じたSmartHRの諸将 相共に一味同心を以て、開発の御馳走を念じ奉り候 SmartHRでは、ともにプロダクトを磨き、ユーザーに価値を届ける仲間を募集中にござる。 SmartHRは、日の本の内であれば、居城の場所を問わず遠隔にて働ける会社にござる。 東西南北いずれの地におわすRubyの衆も、RubyやRuby on Railsをもってプロダクトを磨き上げることに志ある御仁は、ぜひ採用情報をご覧くだされ。 hello-world.smarthr.co.jp
- Ruby
- Rails
- マイクロサービス
TSKaigi 2026 に登壇者 & 運営スタッフとして参加してきました！
freee でエンジニア兼 Dev Branding をやっているけむりだま (@_kemuridama) です. TSKaigi では 2024 年の初回の開催から運営に参加し, 昨年からコアスタッフとして企画や運営にも携わっています. 2026/5/22-23 で東京の羽田で開催された TSKaigi 2026 で外部のカンファレンスへの初登壇を行ったので, 登壇者と運営の両輪で走り抜けた話を振り返っていこうかなと思います. TSKaigi 2026 に参加した freee のメンバー 登壇者として Day 1 に 「密結合なバックエンドから TypeScript のコードを生成する」 というタイトルで 10 分のセッションを行いました. speakerdeck.com 自分自身がエンジニアとして開発に携わっている freee会計で行っている Ruby のコードを元に TypeScript のコードを生成する取り組みについて話しました. リリースから 13 年が経っているプロダクトで密結合となっているバックエンドとフロントエンドにどうやって向きあっていくのか—— この話は実は 2024 年の Advent Calendar で書いた話 が元になっているのですが, なぜ freee会計では OpenAPI Schema などのスキーマ駆動開発ではなくバックエンドのコードを SSoT (Single Source of Truth) としてコードの生成を行っているのかという点について深堀って話すことができたんじゃないかなと思います. 今後も freee会計の開発生産性や品質の向上に向けて対象範囲を広げていければ良いなと思っています. セッションの最後で話した Sorbet の型アノテーションから TypeScript の型を生成する取り組みも絶賛検証を行っています. 発表後に X を眺めると「Node.js から Ruby の Parser (WebAssmbly) を呼ぶのは面白い」「密結合は決して悪ではない」といった反応がもらえて登壇してよかったなと思いました. 背中を押してくれた (?) 同じコアスタッフの yuta-ike には感謝してますｗ 運営スタッフとして TSKaigi ではスポンサーチームとして TSKaigi 2026 のスポンサープランの検討からスポンサー集め, スポンサーベネフィットの履行に向けたタスクなどを行っていました. 今年もありがたいことにたくさんのスポンサーの応募があり, 希望に添えないところがたくさんあり心苦しかったです. 実は freee もゴールドスポンサーとして応募をしていたのですが, 厳正な抽選に外れてしまってブロンズスポンサーとしての協賛となってしまいました. 登壇があったのでドキドキしていたんですが, 当日はいろいろな運営タスクに忙殺されていたので良い意味で登壇の緊張を和らげることができました. 昨年開催された TSKaigi Hokuriku 2025 に続き Day 2 の懇親会の冒頭挨拶もさせてもらっていい経験ができました. 2 日間フルで動きっぱなしだったので流石に疲れましたが, 無事に大盛況で TSKaigi 2026 を終えることができてよかったです. セッションをほとんど見られなかったので, 後日ゆっくりアーカイブで気になっていた発表をチェックしたいなと思っています. 最後に TSKaigi 2026 に参加してくれた方, 自分のセッションを見に来てくれた方, スポンサーをしてくれた企業の方々ありがとうございました. 次は 2026/11/1 に仙台で TSKaigi Sendai 2026 が予定されています. 開催に向けて引き続き企画や運営を頑張っていきたいと思いますので, また会場でお会いしましょう! 本日 19:00 から TSKaigi 2026 でスポンサーをした freee と M3 でアフターイベントを開催します. 直前のお知らせですが, ご都合が合う方は是非ご参加ください! freee の大崎本社での現地参加と YouTube Live でのオンライン参加の両方が可能です! freee.connpass.com
- TypeScript
- Ruby
- Rails
【イベントレポート】「RubyKaigi 2026 アフターイベント〜初参加LT・スポンサー4社のパネル〜」を開催しました！
はじめに こんにちは、Developer Engagementブロックの@wirohaです。5月13日に「RubyKaigi 2026 アフターイベント〜初参加LT・スポンサー4社のパネル〜」を開催しました。 株式会社ZOZO、株式会社リブセンス、株式会社TOKIUM、株式会社マイベストの4社共催で、RubyKaigi 2026を振り返るアフターイベントです。初参加エンジニアによるLTと、公募によるLT、各企業によるブース運営に関するパネルディスカッション、そして懇親会を行いました。 当日の雰囲気を含めてレポートします！ 登壇内容まとめ 発表タイトル 登壇者 ESP32 IoTを動かしながらメモリ使用量を観測してみた話 株式会社ZOZO もっちゃん Rubyはただの言語に非ず 株式会社リブセンス こりん Rubyの内側を意識し始めた日 株式会社マイベスト koki515 RubyKaigi Mapを作って出そうとした話 株式会社TOKIUM ikeda 公募LT - パネルディスカッション 各社スポンサー担当 ESP32 IoTを動かしながらメモリ使用量を観測してみた話 speakerdeck.com 株式会社ZOZOのもっちゃんからは、ESP32とPicoRubyを使ってIoTシステムを構築した話がありました。メモリ消費量の節約への努力が感じられました。 Rubyはただの言語に非ず speakerdeck.com 株式会社リブセンスのこりんさんは、Rubyはただの言語ではなく文化であるとお話していました。RubyKaigi初参加ながら、RubyKaraokeといった関連イベントにも積極的に参加していたことが印象的でした。 Rubyの内側を意識し始めた日 speakerdeck.com 株式会社マイベストのkoki515さんは、Rubyコミッターの話を聞くことで内部構造をもっと理解したいと思うようになったそうです。RubyKaigiの会場には本屋さんがありCRubyの本を購入して読み始めたとのことで、良い学びの流れができているなと感じました。 RubyKaigi Mapを作って出そうとした話 speakerdeck.com 株式会社TOKIUMのikedaさんは、RubyKaigiの開催地を地図上にマッピングした「RubyKaigi Map」について発表しました。地震により当日披露が叶わなかったシステムを見ることができました。 ここまで、25卒の4名の若手エンジニアによる発表を紹介しました。「発表に慣れていない、緊張する」と言っていた方々もいましたが、堂々と意欲あふれる発表をされていました。 Spinelに貢献した話 speakerdeck.com 公募によるLT枠では、note株式会社のsacckeyさんよりRubyのAOTコンパイラであるSpinelにコントリビュートしたという発表がされました。「Spinelでは失敗するがCRubyでは成功する5行のRubyコード」という指標がわかりやすく、挑戦してみたくなる内容でした。 飛び入りLT 公募枠が1枠余っていたため、マイベストのKoyaさんが飛び入りでLTをしてくださいました。「カンマは演算子ではない」をテーマに、Rubyの文法を深掘りした内容でした。急遽対応いただきありがとうございました！ パネルディスカッション 4社のスポンサー担当者による、ブース運営についてのパネルディスカッションを行いました。どんなブースを出して（出す予定で）いたか、その決め方や苦労などをお聞きできました。 当日見られなかったコンテンツを知ることができたり、SNSで話題になっていた投稿の裏側を知ることができたりと、興味深い内容が盛りだくさんでした。 最後に 発表の終了後には懇親会も行い、活発に交流する様子が見られました。ローカルオーガナイザーの方も参加してくださっていたため、参加者・運営・スポンサー企業といったさまざまな立場の方とのつながりが生まれていたように感じました。ご参加くださったみなさま、ありがとうございました！ 来年のRubyKaigi 2027は宮崎での開催です。ZOZOは宮崎にオフィスがあるため、何か企画ができないものかと話し合っています。また来年もたくさんのRubyistたちとお会いできることを楽しみにしています！ corp.zozo.com
- Ruby
- IoT
RubyKaigi 2026 のコード懇親会と RubyGems/Bundler チームの成果報告
こんにちは、Ruby コミッタの柴田です。RubyKaigi 2026 in 函館から1ヶ月が経ち、自宅のガーデニングではバラのシーズンが一段落して梅雨に入る前に剪定を...という手入れに移ったところです。 今回はRubyKaigi 2026 2日目の夜にアンドパッドが運営として関わったコード懇親会 (Code Party) と、私がホストを担当した RubyGems/Bundler チームから生まれた成果をまとめます。 コード懇親会の進め方 コード懇親会はクリアコードの須藤さんが提唱しているコンセプトで、お酒の代わりにコードで懇親する形式の懇親会です。今回はアンドパッドが函館市民会館で会場の設営とお弁当など運営を担当しました。 www.clear-code.com 今回からテーマを事前固定にしました。dRuby (咳さん)、Ruby 本体 (前田さん)、RubyGems/Bundler (私)、mruby/PicoRuby、Ruby × Rust (udzura さん) の5チームです。当日テーマを決める方式だと初心者が入りづらいので、ホストが事前に取り組めるイシューと環境構築の道筋を用意しておき、来てすぐコードを書ける状態にする狙いがありました。 RubyGems/Bundler チームの様子 私のテーブルには9名が集まり、多くは ruby/rubygems を fork してテストをどう実行するのか、という手探りなところからのスタートでした。最初に簡単に自己紹介をしてもらい取り組むイシューを選んだ後に、私が席を回りながら困ったことがないかの相談をしていました。普段使っているのに中身は読んだことがない、という状態から、当日中に PR を1本送れるところまで持っていくのが目標です。 OSS を使っていてメンテナと隣で話しながらコードを書ける機会は普段そう多くないと思います。参加者のフィードバックでも「issue に着手すべきか迷っていたところを直接相談できた」(nissyi-gh さん) という声があり、メンテナを物理的に隣に置くことの効果はやはり大きいと感じました。フィードバックは andpad-dev/code-party に全員分が公開されています。 なお私は RubyKaigi 2026 の期間中に 4.0.11 をリリースしようと作業をしていたのですが、どうしても時間をかけて取り組む必要があるテストの失敗に遭遇してしまい、コード懇親会当日のリリースは断念しました。「リリースを全力で自動化している」が Day 3 での私の発表テーマだったので、まだまだやることはある、ということを実感してしまいました。 rubykaigi-2026-day-3-ruby-releases-rubyfrom Hiroshi SHIBATA その日の PR がリリースに乗るまで 当日 RubyGems/Bundler チームから出た PR のうち、すでに公式リリースに含まれたものを紹介します。 rubygems/guides (当日マージ) rubygems/guides#458 (Yuhi-Sato さん): Gemfile ドキュメントの「master がデフォルトブランチ」記述を修正。 rubygems/guides#459 (otsuboa さん): ガイドのコードブロックにシンタックスハイライトを追加。 Bundler 4.0.11 (4月30日リリース) ruby/rubygems#9500 (nissyi-gh さん): newgem テンプレートの gem ガイド URL を現行の rubygems.org に更新。当日 PR、翌日マージ。 blog.rubygems.org Bundler 4.0.12 (5月20日リリース) ruby/rubygems#9502 (kurotaky さん): Bundler::LockfileParser が lockfile 以外の文字列を黙って受け取る挙動に deprecation 警告と valid? を追加。#8932 の解消。 ruby/rubygems#9505 (willnet さん): bundle config get が未設定キーで exit status 0 を返していたのを 1 に修正。#3215 の解消。 blog.rubygems.org 当日から1週間で 4.0.11、1ヶ月以内に 4.0.12 に乗っています。長年保留状態だった issue (#8932, #3215) が一晩で片付いたのは、メンテナがその場でレビューと方針判断を返せたからで、これがコード懇親会の最大の利点です。 エコシステムはこの積み上げでできている RubyGems と Bundler のコードベースは、私のような主担当メンテナが書いたものよりも、こうした「気になったから直す人」の PR が積み上がって今の形になっています。普段は GitHub 越しのレビューで進むこのループを、年に一度、物理的に同じ場所で回す機会がコード懇親会です。 参加者のフィードバックには「これからは気になったことがあれば issue や PR を送れそう」という声が複数ありました。当日リリースに乗った PR より、ここで contributor の母集団が一段広がったことのほうが、エコシステムへの貢献としては大きいと思っています。 おわりに グループのホストを引き受けてくださった皆さん、参加者の皆さん、会場準備に動いてくれたアンドパッドの同僚たちにお礼を伝えます。RubyKaigi に毎年行っているけど懇親会では話すきっかけがなかった、という方は、来年もたぶん開催するコード懇親会に参加してください。手元の OSS で気になっていることをひとつ持ってきてもらえれば、その場で pull request の作成、または Merge まで持っていけるかもしれません。 アンドパッドでは Ruby/Rails エコシステムをはじめとする、プロダクト開発に関わりたいエンジニアを募集しています。 hrmos.co
- Ruby
- OSS
「ルールルルルルRubyKaigi 2026事後勉強会 ── したっけ、東京で！」を開催しました
こんにちは！SmartHRで基本機能（人事マスタ関連）を開発しているhamadaです。 この記事では、2026年5月22日に東京・六本木のSmartHR Spaceで開催した「ルールルルルルRubyKaigi 2026事後勉強会 ── したっけ、東京で！」の様子をお届けします。 事後勉強会のアイキャッチ なお、「ルールルルルルRubyKaigi 2026事前勉強会 —— 初参加でもなまら歓迎！」については以下の記事でレポートしています。ぜひこちらも読んでいただけると嬉しいです。 tech.smarthr.jp 開催概要 SmartHRは、RubyKaigi 2026にHangout Sponsorとして協賛し、「ルールルルルルルビーカイギ」をテーマにさまざまな企画を行ってきました。会期前に開催した「ルールルルルルRubyKaigi 2026事前勉強会 —— 初参加でもなまら歓迎！」、会期中に実施したたまり場「五稜郭」、会期翌日に実施した「函館市電LT」に続く最後のイベントとして、この事後勉強会を開催しました。 事後勉強会は、「RubyKaigi 2026での出会いや学びを胸に、今度は東京でふたたび集まりましょう！」という思いを込めて、「したっけ、東京で！」と題しました。「したっけ」は北海道の方言で、「またね」という意味です。 事後勉強会では、事前勉強会に引き続きRubyKaigiチーフオーガナイザーの松田明さんも登壇してくださり、RubyKaigiの初参加者、RubyKaigi2回目以上の参加者、スピーカーやコミッターなど、さまざまな方からの熱いLTがありました。 開始前の様子 受付では、キュートな狐がイカを釣る事後勉強会限定のSmartHRの増えてくアクキーをお配りしました。 また、会場にたまり場「五稜郭」で好評だった「モルック」と「IKATSURUBY」を再現し、開始前に参加者に楽しんでいただきました。 こうして、お祭りムード満載でイベントがスタートしました。 RubyKaigi 2026限定アクキー（写真左）とRubyKaigi 2026事後勉強会限定アクキー（写真右） 函館と縁の深い競技「モルック」を楽しむ参加者 イカ釣りゲーム「IKATSURUBY」を楽しむ参加者 オープニング 司会進行を務めたのは、新卒2年目のSmartHRプロダクトエンジニアであるnoriさん。 自身も2回目のRubyKaigi参加となったnoriさんは、リラックスしたムードで「会場にどんな人が集まっているか」を確かめる挙手アンケートを実施。初参加の方からベテラン、さらにはRubyコミッターや運営スタッフまで、会場に集まった多くの参加者を巻き込みながら、イベントのスタートを温かく盛り上げてくれました。 参加者事前アンケートの結果を紹介するnoriさん 応援パネルで会場を盛り上げてくださる参加者の方々 ポストモーテム枠 最初のブロックは、ポストモーテム枠のLTです。 ドラ係は、RubyKaigi 2026で「Guide to getting started walking source codes of CRuby」を発表し、「CRuby quest 〜 Rubyのぼうけんのしょ」の著者でもあるyouchanさんでした。 ドラ係のyouchanさん yancyaさん：あのアレの”個人的な”振り返り 最初は、yancyaさんによる「あのアレの”個人的な”振り返り」という発表でした。 18時間かけて船で北海道へ渡るカスタムスポンサー企画「Rubyist Bulk Reload 2026」の直前に地震が発生し、その影響でイベントが中止・下船になり、にもかかわらず車やバイクは船に乗せたまま出航となった緊迫の舞台裏が語られました。乗船前の判断体制や指揮系統の明確化の重要性、旅行代理店への一任といったリアルで貴重な教訓を共有しました。 来年は「神戸〜宮崎」でのリベンジを誓うyancyaさんの姿に、このイベントに参加予定でバイクだけが旅をして戻ってきたというドラ係のyouchanさんからも、「面白い体験をさせてもらった」と温かい労いの言葉が贈られました。 ポストモーテムの形式であのアレを振り返るyancyaさん RubyKaigi 2026が初参加だった方によるLT 次のブロックは、RubyKaigi 2026が初参加だった方によるLTです。 ドラ係は、RubyKaigi 2026のスポンサーブースで「SNOW COLLECTORS」というゲームを披露していたkaibaさんでした。 ドラ係のkaibaさん a2cさん：Inspired By RubyKaigi (EN) 最初は、SmartHRのa2cさんによる「Inspired By RubyKaigi (EN)」という発表でした。 今回のRubyKaigi 2026が初参加だったというa2cさんは、HASUMIさんのPicoRubyセッションに強い刺激を受け、自身も「Kaigi Effect」によって新たなプロダクト開発に挑戦した、という内容を「全編英語のLT」で披露しました。JavaScriptを一切使わずにRubyとCSSだけで動くリアルタイム投票アプリを開発し、来年の宮崎で食べたいものをその場で投票してもらうデモを見事に成功させました。 10年前の自身の初参加時を思い出したというドラ係のkaibaさんからも、AI時代だからこそ自ら手を動かし、英語で挑戦する姿勢に刺激を受けたという熱い感想が寄せられました。 流暢な英語でプレゼンするa2cさん speakerdeck.com asanoさん：初めてのRubyKaigiはこう見えた 次は、asanoさんによる「初めてのRubyKaigiはこう見えた」という発表でした。 ギフティの新卒2年目エンジニアであるasanoさんは、今回が初のRubyKaigi、初の函館、そして本日が初のLT登壇という「初めて尽くし」の状態でステージに立ちました。RubyKaigi 2026参加前は社内外のベテランから「内容は難しいから2割分かればいい方」と言われて不安を抱えていたものの、いざ現地に飛び込むと会場に溢れる「Rubyへの愛と熱量」に深く感動したと語りました。特に「Ruby Committers and the World」ではコミッターたちの生議論に鳥肌が立ち、その感動から「Kaigi Effect」が発動。Webブラウザ上で人生初「Lチカ」をPicoRubyで実装した快挙が報告されました。 もっとRubyを愛したい、そして英語も勉強したいと語る初々しくも熱い姿に、会場全体が深く共感していました。 RubyKaigiの興奮とコミュニティへの感謝を伝えるasanoさん speakerdeck.com RubyKaigi 2026が2回目以上参加だった方によるLT 次のブロックは、RubyKaigi 2026が2回目以上参加だった方によるLTです。 ドラ係は、Asakusa-bashi.rbsなどのコミュニティ活動や、TypeProfなどのOSSにコントリビュートしているsinsokuさんでした。 ドラ係のsinsokuさん NGTさん：Kaigi Effect Effect 最初は、SmartHRのNGTさんによる「Kaigi Effect Effect」という発表でした。 SmartHRのフロントエンドエンジニアであるNGTさんは、2回目のRubyKaigi参加となる今年、カスタムスポンサ
- Ruby
- RubyKaigi
アンドパッド 技術イベントのご案内 2026 年 6 月
こんにちは、 id:sezemi です。 季節外れの台風に振り回されましたが、元気にやっております。 天候急変によるイベントのハンドリングは難しいですねぇ。 さて、アンドパッドでは、技術やプロダクト開発、組織に関するさまざまなカンファレンス・イベントでの登壇、開催や会場提供などを行っています。 今月もイベント情報をまとめてお知らせします。 ぜひご参加ください !! なお、開催状況により、満員となってしまっている場合、すでに受付を終了している場合がございます。 1. スポンサー情報 | 松江Ruby会議12 開催日時 : 2026年6月6日(土) 会場 : 興雲閣 主催 : Matsue.rb イベント概要 : Matsue.rb が主催する地域Ruby会議です。アンドパッドは本カンファレンスに スポンサー として協賛します。 申込方法 : カンファレンスの公式ページ からお願いいたします。 「興雲閣」は、松江城山公園内に建つ美しい歴史的な洋風建築です。 地域 Ruby 会議らしく、趣のある空間で開催されていて、建築好きの私には見逃せない楽しみです。 また、アンドパッドはブースを出展していますので、ぜひ遊びに来てください。 そして nagachika が「ruby.wasm で作る MIDI コントローラー」というタイトルで発表しますので、ご期待ください！ ちなみに、今回の "Kaigi" も音ネタが多いですね。 2. 登壇情報 | 食べログ x ANDPAD x Sansan モバイル勉強会 #4 開催日時 : 2026年6月17日(水) 会場 : Sansan株式会社 主催 : 食べログ、アンドパッド、Sansan イベント概要 : 食べログ、アンドパッド、Sansanの3社が共催するモバイルアプリ開発者向けの勉強会です。本イベントには、アンドパッドから 長堀 が登壇予定です。 申込方法 : イベントページ からお願いいたします。 今回はモバイルアプリ開発では対応が欠かせない "OS アップデート" がテーマです。 当たり前すぎて、実はなかなか知見がないテーマなので、発表された Tips は貴重なものになる予感です。 ぜひご参加ください！ 長堀 翔太 @nashcft 2023 年 6 月に Android アプリエンジニアとして入社。チャットアプリの開発に携わりつつ、チームビルディングや開発プロセス改善にも取り組んでいる。 長堀 翔太 のテックブログ執筆記事 - DroidKaigi 2024 参加レポート / 感想編 - ANDPAD Tech Blog - アンドパッドは DroidKaigi 2024 に協賛しています & 事前勉強会のお知らせ - ANDPAD Tech Blog 発表タイトル: OS アップデートの進め方がもっと共有されてほしい 3. 登壇・会場スポンサー | v-tokyo Meetup #25 開催日時 : 2026年6月16日(火) 会場 : 株式会社アンドパッド 主催 : v-tokyo イベント概要 : v-tokyoが主催するミートアップイベントです。本イベントに、アンドパッドは 会場スポンサー として協賛し、会場を提供するほか、アンドパッドから 羽馬（NaokiHaba）と 小泉 (@ykoizumi0903) が登壇予定です。 申込方法 : イベントページ からお願いいたします。 いま大注目の VoidZero 社が開発している Void / Vite+ がテーマのイベントです。 カンファレンス並みのゲストとトークが揃い、とても楽しみですね。 そしてアンドパッドのフロントエンドエンジニア陣を代表する二人、羽馬と小泉が登壇します。 ぜひ期待ください。 NaokiHaba @naokihaba 株式会社アンドパッド フロントエンドエンジニア。 Vite+ Team Member 発表タイトル: Vite+ 「The Unified Toolchain for the Web」 を掲げる Vite+ は、runtime や package management、build、さらには monorepo のタスクキャッシュに至るまで、あらゆる機能を一つの依存関係に統合しています。今回はこの Vite+ について、開発に携わるチームメンバーとしての視点から詳しくお話しします。 小泉 佑太郎 @ykoizumi0903 ANDPAD引合粗利管理や ANDPAD資料承認などのプロダクトや機能をテックリードとして開発しているフロントエンドエンジニア。 業務では Vue/Nuxt を中心に、Next や React Router を使った開発にも携わる。 Zenn で Vue や Nuxt に関する記事を ykoizumi0903 というユーザーネームで書いている。 小泉 佑太郎 のテックブログ執筆記事 (直近 2 記事を抜粋) - Nuxt の自動インポート機能、無効化しました - ANDPAD Tech Blog - 乗り換えるなら今！ Prettier から Oxfmt への移行を試してみた - ANDPAD Tech Blog 興味のあるイベントがございましたら、ぜひご参加ください !! アンドパッドでは技術コミュニティが大好きな採用広報を大歓迎しています。 広報の経験がない方でも Welcome です！ カジュアル面談やご応募、お待ちしております。 hrmos.co
- Ruby
- Android
- フロントエンド
アンドパッドは総勢 23 名で RubyKaigi 2026 を楽しんできました！
こんにちは、広報の id:sezemi です。 アンドパッドの広報の仕事のかたわら、 Rubyist Magazine 略して「るびま」の編集に携わっています。 ただ編集と言いながら、まだまだスッといい感じの文章が書けないなぁと るびま のチャンネルで呟いたところ、 kakutani さんから「Rubyist にはダジャレの訓練が求められる…(主語ﾃﾞｶ」 というアドバイスをもらい、道理で ruby-jp の Slack でみんな大喜利を (ry 。 精進します！ さて、アンドパッドからは RubyKaigi 2026 に採用チームも含め、総勢 23 名が参加しました。 この記事では、沢山の思い出を作ってきたアンドパッドの Rubyist たちが、参加したトークやイベント、函館や会期中の思い出、そしてブースで行った立ち読み喫茶などなどをテーマに、思い思いに書きました。 ぜひアンドパッドの Rubyist の KaigiEffect をご覧ください。 中林友弥(@borashisan) より トークで刺さったことや感想 Guide to getting started walking source codes of CRuby(@youchan) これまで「CRubyのソースコードを読む」ことに対して高いハードルを感じていたのですが、そのとっかかりとなる知識や、コードリーディング全般に役立つTipsを惜しみなく共有していただき、非常に実用的なセッションでした。 すっかり感化され、後述する同人誌『CRuby Quest』も購入したので、これからじっくりと読み倒してCRubyの世界を歩いてみたいと思います。 濃密すぎたLightning Talks LT枠とは思えないほど、通常のセッションとしてじっくり聴きたいトピックの連続でした。 Ruby on Bare Metal(@S.H.): 「mRubyを使えば簡単に動くからあえてCRubyをベアメタルで動かす」という気骨に痺れました。最低限の依存関係を特定して動かすアプローチが非常に面白かったです。 Is Ruby's Multi-Encoding Overhead Heavy?(@ima1zumi): RubyがCSI方式といういわば力技でマルチエンコーディングに対応していることを初めて知りました。「そんな無理をしてそうなのにオーバーヘッドがないのか？」という疑問に真っ向から切り込む調査が興味深かったです。 Pure Intonation on Browser(@nagachika) 純正律と平均律の話から始まり、「シャサフ式音楽理論」、さらにはそれを表現するための「シャサフ語」という言語まで存在していることを知り大変興味深かったです。 アコースティック楽器特有の制約を持たない電子音楽だからこそ、純正律や微分音を論理的に扱うルールが発展していくのだなと深く感動しました。 A Faster FFI(@tenderlove) 技術的な深さはもちろんのこと、アーロンさんによる流暢な日本語で、しかもユーモアたっぷりに発表されているプレゼン力に感銘を受けました。 Ruby Committers and the World(@rubylangorg) 毎年恒例のコミッター陣によるセッションです。「今やほとんどのコミッターがAIによるRuby開発を行っている」という実態や、多数決に頼らないコミュニティ運営の難しさなど、リアルな議論を聞くことができました。 技術的な話題では String#popcount の導入提案が印象的でした。最初は用途のイメージが湧きませんでしたが、調べてみるとハミング距離の計算や、在庫管理・予約枠をビット列で表現した際の高速な一括取得など、パフォーマンス改善に大きく寄与する可能性を知り、言語仕様が実務にどう活きるのかを考える良いきっかけになりました。 Matz Keynote(@yukihiro_matz) 今年のMatzさんのKeynoteは、AIを活用して開発したAOTコンパイラ「Spinel」についての内容でした。 (AOTコンパイラってなんだって思ったんですが、実行中にコンパイルされるJITコンパイラに対して、通常僕らがイメージする事前に実行されるコンパイラのことをこうやっていうんですね。) Rubyの構文でGo言語のようにシングルバイナリを生成できるようになる未来が提示され、とてもワクワクしました。 また、Matzさんご自身がClaude Codeを使って大きな桁の掛け算（カラツバ法）を最適化しようとした際、AIから「もっと良いアルゴリズムがある」と提案されてそれを採用したというエピソードには、 「MatzさんでもそういったAIとの協働があるんだ！」と大いに勇気づけられました。 余談ですが、デモ中のベンチマークとして「マンデルブロ集合」が用いられていたのが勉強になりました。数値演算のループや再帰が非常に高密度に行われるため、インタプリタやコンパイラの最適化能力が如実に現れるのですね。 これに感化され以前にバイブコーディングによりRubyで実装した純Lispで実際にマンデルブロ集合を描画して計測してみました。 参考までにScheme実装のGaucheと比較した結果です。 Lisp(Scheme)で記述したマンデルブロ集合を描画するコード (define SCALE 1000000) (define quotient (lambda (a b) (if (< a 0) (- 0 (quotient (- 0 a) b)) (if (< a b) 0 (if (< a (+ b b)) 1 ((lambda (q) (+ (+ q q) (quotient (- a (* (+ q q) b)) b))) (quotient a (+ b b)))))))) (define fix* (lambda (a b) (quotient (* a b) SCALE))) (define mandelbrot-iter (lambda (cr ci zr zi count max-iter) ((lambda (zr2 zi2 zri) (if (>= (+ zr2 zi2) (* 4 SCALE)) count (if (>= count max-iter) count (mandelbrot-iter cr ci (+ (- zr2 zi2) cr) (+ (* 2 zri) ci) (+ count 1) max-iter)))) (fix* zr zr) (fix* zi zi) (fix* zr zi)))) (define mandelbrot (lambda (cr ci max-iter) (mandelbrot-iter cr ci 0 0 0 max-iter))) (define char-for-count (lambda (count max-iter) ((lambda (q3) (cond ((eq? count max-iter) (quote @)) ((> count (+ q3 q3)) (quote *)) ((> count q3) (quote +)) (else (quote -)))) (quotient max-iter 3)))) (define print-row (lambda (x y x-end step max-iter) (if (> x x-end) (newline) ((lambda (_) (print-row (+ x step) y x-end step max-iter)) (display (char-for-count (mandelbrot x y max-iter) max-iter)))))) (define render (lambda (y y-end x-start x-end step max-iter) (if (> y y-end) (quote done) ((lambda (_) (render (+ y step) y-end x-start x-end step max-iter)) (print-row x-start y x-end step max-iter))))) (render -1000000 1000000 -2000000 500000 50000 30) マンデルブロ集合の描画実行計測比較 # Gauche(Scheme)での実行結果 (0.166 total) ❯ time gosh examples/mandelbrot.lisp -------------------------------------+-+@---------- (中略) -------------------------------------+-+@---------- gosh examples/mandelbrot.lisp 0.11s user 0.01s system 75% cpu 0.166 total # Ruby(YJIT)で実装した自作Lispインタプリタでの実行結果 (6.797 total) ❯ time ruby --yjit bin/repl.rb examples/mandelbrot.lisp -------------------------------------+-+@---------- (中略) -------------------------------------+-+@---------- ruby --yjit bin/repl.rb examples/mandelbrot.lisp 6.54s user 0.08s system 97% cpu 6.797 total # Ruby(ZJIT)で実装した自作Lispインタプリタでの実行結果 (9.045 total) ❯ time ruby --zjit bin/repl.rb examples/mandelbrot.lisp -------------------------------------+-+@---------- (中略) -------------------------------------+-+@---------- ruby --zjit bin/repl.rb examples/mandelbrot.lisp 8.72s user 0.10s system 97% cpu 9.045 total JITを有効にして、実行環境のオーバーヘッドを可能な限り減らした状態での計測ですが、 末尾再帰などの最適化は行なっていない素朴なLispインタプリタということもあり、 圧倒的な速度差を目の当たりにし、コンパイラやインタプリタの最適化の重要性を肌で感じることができました。 RubyKaigi 2026 の思い出 今回のRubyKaigiを通して強く感じたのは、「自分はRubyを『使う側』の人間なのだな」という事実です。 正直なところ、どのトークも技術的な難易度が高く、「当たり前だけれど、自分の知識の範囲内でしか理解できない」というもどかしさを感じました。 しかし、それは決してネガティブな感情ではなく、「何を知れば『Rubyを作る側の人間の話』が理解できるようになるんだろう？」という新たな好奇心の芽生えでもありました。 立ち読み喫茶での出会いと、来年に向けた冒険 「作る側の話」を理解するための第一歩として、弊社ブースの「立ち読み喫茶」で手に取ってみたり、 ブースに訪れたRubyistにおすすめいただいたりした中から、来年のRubyKaigiまでに絶対に読むべき本を心に決めました。 『CRuby Quest 〜Rubyのぼうけんのしょ〜』（自費出版 youchan 著） ParserからAST、ISeq、VMへと至るCRubyのレイヤーを素直に理解できそうだと感じて購入しました。ありがたいことに、著者のyouchanさんから直接サインをいただくことができました！ 『APIデザインケーススタディ』（技術評論社 刊 田中哲 著） 言語の中核となるAPI設計(Web APIじゃないよ)の考え方について、深く理解するための指針になると感じています。 『白と黒のとびら オートマトンと形式言語をめぐる冒険』（東京大学出版会 刊 川添愛 著） オートマトンの基礎を知ることで、言語の字句解析や構文解析の概念がよりクリアになることを期待して選びました。 また、Rubyの内部仕様だけでなく、自身の発信力を高めるために『技術記事を書く技術 ITエンジニアの価値を高めるアウトプットのすべて』（翔泳社刊 伊藤淳一 著）も購入し、 こちらもありがたいことに、いつも技術記事でお世話になっている伊藤淳一さんから直接サインをいただくことができました。 これらの知識が「作る側」になるための武器や経験値になることを信じて日々精進していきます。 大西晃平(@kOnsh) より RubyKaigi 2026 の思い出 Rubyが繋ぐ「人」の輪と、新たな一歩 私はこれまでフロントエンド開発が中心だったので、RubyKaigiは初めての参加でした。その中で一番心に残ったのは技術そのもの以上にRubyという言語を中心としたコミュニティの圧倒的な「厚み」でした。 会場には、名だたるエンジニアから、キャリアをスタートさせたばかりの方、さらには他の言語から飛び込んできた方まで、本当に幅広い層の人々が集まっていました。特に刺激的だったのは、SNSのアイコンでしか見たことのなかったエンジニアの方々と、セッションやDrinkupを通じて直接お話しできたことです。同じRubyistとして気さくにかつ情熱的に技術を語る姿を見て、「自分ももっと頑張ろう」と自然に気持ちが引き締まりました。 今回のもう一つの大きな思い出は、技術書が購入できる本屋さんのサイン会です。 先行販売していた『技術記事を書く技術 ITエンジニアの価値を高めるアウトプットのすべて』をその場で購入させていただきました。 サインをいただき、著者と直接お話したことで、「まずは個人でも少しずつ、アウトプットを増やしていこう」という具体的な目標ができました。 Rubyはこうした個々の熱量が集まることで、エコシステムが大きくなっていると肌で感じました。 自分にできることは小さいですが、今回の体験を経て「自分もこの素晴らしいエコシステムのために、何か少しでも貢献したい」という前向きな気持ちが芽生えています。 山田(@amymd) より トークで刺さったことや感想 Ruby Committers and the World(@rubylangorg) 私は今回のRubyKaigiが現地初参加でした。たくさんのトークがあってどれも面白かったのですが、特に印象に残ったのはRubyのコミッター陣によるトークセッションでした。毎年恒例のこのトークセッションでは、Rubyの開発プロセスやRubyの今後の展望についてコミッター陣でディスカッションするという貴重な機会となっており、今回初めて参加した私にとっては、Rubyの開発の裏側を垣間見ることができる非常に興味深いセッションでした。 当日議論されたテーマとしては、 Integer#popcount or String#popcount Rubyの開発にconclave processを導入するのはどうか Ruby開発におけるAIの活用 setjmp/longjmp Revisiting frozen_string_literal などがありました。 Rubyの言語仕様に関する議論だけでなく、conclave process導入の話など開発プロセスに関する話もあり、長く続く開発コミュニティならではの議論が聞けてとても面白かったです。 また、他のトークでもAI活用の話は多く出ていましたが、Ruby自体の開発でも当たり前にAIが活用されているという話も印象に残っています。会場でどのくらいコードをAIに書かせているのか挙手で聞いてみると、「半分以上書かせている」でほとんどの人が挙手していて、多くのRubyistがAIを活用していることに改めて驚きました。 コードを書かせるだけでなく、不具合の調査やエッジケースの洗い出しなどでもAIを活用していて便利だという話があり、まさに私自身もAIにテストコードを書かせることが多くその便利さを実感していたので、非常に共感しました。 AIの登場によってOSS開発への参加のハードルが下がったという話もあり、この後のMatzさんのKeynoteでも話に出てきましたが、これまでやりたくても時間やリソースの関係でできなかったことが、AIの活用によって誰でも実現できる世の中になってきたのだと改めて感じました。 そういった中でエンジニアとしてどのようにAIと向き合い、活用していくのか。このテーマは今後もますます注目されていくのだろうなと思います。 気が早いですが、来年のRubyKaigiのセッションも楽しみです。 RubyKaigi 2026 の思い出 セッションやブース担当以外の時間はスポンサーブースを回ったり、他の参加者の方と交流したりしていました。 各社いろんな工夫を凝らしたブース展示をしていて回っているだけでも楽しいですし、異なる業界のプロダクトの話が聞けるのもいつもとは違う刺激があって面白かったです。 ANDPADのロゴ入りTシャツを着て回っていたこともあって、弊社が提供していたローカルフードの話や前回のRubyKaigiでの弊社ブースの話を振っていただくことも多かったです。RubyKaigiは毎年参加している方も多いので、そういった話ができるのも例年開催しているイベントならではの特徴だなと感じました。 弊社ブースの「立ち読み喫茶」も運営として参加させていただきましたが、ブースを訪れた方に逆におすすめの本を教えていただいたりと、楽しい時間を過ごすことができました。 私は 「データモデリングでドメインを駆動する」（技術評論社 刊） という本を推薦しました。基幹系システムの中核にある「帳簿」のデザインの重要性やそのためのデータモデリングの考え方に関する本です。社内で輪読会を実施したところ非常に好評で、基幹系システムの開発に携わる人には特におすすめです。 小倉(@Ogura) より トークで刺さったことや感想 Ruby はこれまで、YARV、MJIT、YJIT と着実にパフォーマンス面での進化を続けてきました。そして去年の RubyKaigi で、YJIT のさらに上を目指す ZJIT が発表されて以来、現在どのような状況にあるのか強い関心を持っていました。 今回の RubyKaigi では、ZJIT については以下の2つのセッションがありました。 The design and implementation of ZJIT & the next five years (@tekknolagi) Lightning-Fast Method Calls with Ruby 4.1 ZJIT (@k0kubun) セッションを聞いていて特に印象に残ったのは、「最適化と実用性のバランス」についてです。 高度な最適化を行うと、例外発生時にスタックトレースを正しく生成するための情報が不足してしまう問題があるそうです。そのため、状況に応じて Deoptimization が必要になるとの解説がありました。 最適化を突き
- Ruby
- RubyKaigi
勤怠管理の開発チームに飛び込んでみた —— 入社半年のふりかえり
こんにちは！SmartHRでプロダクトエンジニアをしているTaiです。 2025年12月にSmartHRに入社し、勤怠管理の開発チームに所属しています。 前職ではフロントエンドエンジニアとしてOCR（光学文字認識）やSCM（サプライチェーン管理）のプロダクト開発に携わっていました。HR・労務ドメインのプロダクト開発は今回が初めてです。 入社から約半年が経ち、チームの中にいることが自然になってきた今だからこそ、ジョイン当初に感じた驚きや発見を残しておきたいと思いこの記事を書いています。 私たちが開発している勤怠プロダクトは、法令・制度・企業ごとの就業規則が複雑に交差するドメインで、入社直後は「これは一筋縄ではいかないな」と率直に感じました。しかし、チームにはその複雑さを乗り越えるためのサポート体制が想像以上に整っていました。会社のバリューがチーム文化に深く浸透していることにも驚かされます。 外から来た目線がまだ残っているうちに、チームの特徴を「文化」と「技術・開発体制」の2つの軸でお伝えしていきます。 チーム文化の特徴 「実装するだけ」の人間がいない 私たちのチームでは、エンジニア全員がユーザー目線を強く意識しています。何かを実装する前に、まず「ユーザーにとってなぜそれが必要なのか」というWhy（目的）を徹底的に掘り下げます。 How（手段）を詰める前にWhy（目的）を大事にする姿勢がチーム全体に根付いています。 そのために、仕様検討などを職種関係なくチームメンバー全員で決めていく形をとっており、エンジニアも要件や仕様の段階から主体的に参加し、「何を作るべきか」をチーム全員で考えます。 この体制は良い循環を生んでいます。仕様検討に関わることでドメイン理解が深まり、その理解が進むことでより良い設計判断ができるようになり、結果としてプロダクトの質が上がっていきます。 私が見てきた限りでは、「言われたものを作る」のではなく、メンバー一人ひとりがプロダクトに対してオーナーシップを持って開発に向き合っているチームです。 リモートでも距離を感じないコミュニケーション チームはフルリモートで開発を行っており、だからこそテキストコミュニケーションを大切にしています。Slackでのやり取りが盛んで、ミーティング中もスレッドで議論や補足が活発に飛び交います。 リモートワークでありがちな「聞きづらい」「様子がわからない」といった距離感は全く感じません。 新しく入ったメンバーへのサポートも手厚く整っています。勤怠プロダクトの開発組織内には複数のチームがありますが、チームを横断して話せる場が設けられています。 自分のチームに閉じず、チーム内外を問わず気軽に相談できるので、ジョイン直後の不安感はかなり和らぎました。 挑戦とフィードバックが日常にある雰囲気 チームには、質問や提案を安心して出せる雰囲気があります。その土台にあるのは、「光の速さでまず動く」というSmartHRが掲げている三つのバリューのうちの一つでしょう。「まずやってみる」を大切にし、挑戦を後押しする姿勢がチーム全体に根付いています。 挑戦が前提なので、間違いを恐れる空気がありません。仮にうまくいかなかったとしても、建設的なフィードバックが返ってきます。 挑戦とフィードバックがセットになっているからこそ、安心して新しいことに踏み出して成長できる環境になっていると思います。 何か気づいたことがあればすぐにチーム全体にフィードバックを求める姿勢があり、それは1on1やふりかえりに限らず、日常のSlackのやり取りの中でも自然に行われています。 フィードバックが特別なイベントではなく、日常の一部になっているチームです。 また、SmartHRにはバリューを表すSlackのスタンプが用意されていて、誰かのアクションに対して都度リアクションとして押されているのをよく目にします。 お互いの行動をバリューの観点から認め合う文化が、こうした小さな習慣を通じて自然と根付いているのだと思います。 認識の「ズレ埋め」文化 SmartHRには「ズレ埋め」という文化があります。認識のズレをそのままにせず、気づいた時点でお互いに指摘し合う文化です。ズレが小さいうちに修正できるので、一人で抱え込んで問題が大きくなるということが起きにくい環境になっています。 何かで連携をとる際にも、互いの認識を揃えてからスムーズに進行できるよう心がける姿勢がチーム全体に浸透しています。Slackには「ズレ埋め」の状況を伝えるためのSlackのスタンプも用意されていて、日常的に活用されています。 課題を一人で抱え込ませないサポート体制 入社直後は慣れない技術スタックやドメインに戸惑う場面もありました。そんなときありがたかったのは、チームが放置しなかったことです。自分が課題を整理する前に、チームが先回りして状況を確認し声をかけてくれて、すぐに「どうすれば改善・解決していけるか」を一緒に考えるフェーズに入りました。こまめに1on1を設けてもらい、自分の状態を定期的に言語化する場があったのですが、これがかなり効きました。掘り出し始めると課題がボロボロ出てきましたが、今まで顕在化していなかった問題を認知でき、良い取り組みになったと感じています。 また、そこからは毎週の振り返りで内省のサイクルを回すようにもしました。その週に何があって、自分はどう感じて、何がうまくいかなかったのかを細かく言語化する。地味ですが、これを続けることで自分の問題のパターンが見えてきます。やったことはシンプルで、問題を洗い出して、それぞれに対するアプローチをブレイクダウンしていっただけです。魔法みたいな解決策があったわけではなく、泥臭く一個ずつ潰していきました。 技術・開発体制の特徴 フロントエンド・バックエンドの垣根がない開発体制 私たちのチームでは、一つの機能をフロントエンドからバックエンドまで通して実装します。「フロントエンドエンジニア」「バックエンドエンジニア」という分業ではなく、プロダクトエンジニアとして機能全体に向き合うスタイルです。 私は前職ではフロントエンドを専門にしていたため、バックエンドは2〜3年まともに触っておらず、RubyもRailsもほぼ浦島太郎状態でした。「いけるでしょ」と思っていた矢先、いざ取り組んでみると思ったより読めないことに気が付きました。 これはまずいということで、チームメンバーにサポートを受けながらキャッチアップの日々が始まりました。SmartHRにはRubyやRails入門のためのカリキュラムも用意されており、体系的に学び直すことができて効率よくキャッチアップすることができました。おかげさまで、今ではかなり読み書きできる状態になっています。 特定の領域に閉じないことで、機能全体を見通した設計判断ができるようになります。フロントエンドだけを見ていた頃には気づけなかった観点が得られる実感があり、大変ではあるものの、エンジニアとしての幅が確実に広がっていると感じます。 大規模なコードベースと丁寧なコードレビュー SmartHRのコードベースは、前職のスタートアップと比べて規模が桁違いでした。前職では0→1の開発が中心で、コードベースは比較的コンパクトでした。改修時の影響範囲もだいたい把握できていて、「ここを変えたら何に影響するか」は感覚でわかることも多かったです。 一方、SmartHRでは影響範囲の調査だけでも結構な労力が必要です。ドメインの複雑さも相まって、一つの変更がどこに波及するのか丁寧に追っていかないと痛い目を見ます。実際に見ました。痛かった。 コードレビューもかなりしっかり行われており、コードに対する自分の理解が少しでも足りていないとすぐに顕在化します。裏を返せば、レビューを通じて理解の甘さに気づける機会でもあり、コードベースへの解像度を上げていく良い糧になっています。この大規模なコードベースに対して、AIをどう活用すれば効率良くキャッチアップできるかを考えることも、良いキッカケになっています。 ドメイン知識にアクセスしやすい環境 先述のとおり、勤怠ドメインは非常に複雑です。しかし、チームにはその複雑さに対応するための環境が揃っています。 まず、ドメインエキスパートへの質問はSlackで気軽にできます。「こういう場合はどうなるんですか？」といった疑問をその場で投げかけられるので、理解が曖昧なまま実装を進めてしまうリスクが減ります。 新機能の実装など、複雑なドメインが絡む場面ではドメインエキスパートによる共有会が開かれることもあり、チーム全体で認識を揃えてから開発に入れる体制になっています。 また、ドキュメントも充実しています。用語集、業務フロー、法令の解説など、ドメイン理解に必要な資料が体系的に整備されています。 入社直後、多数ある労働時間制の仕組み・違いが分からず戸惑いましたが、用語集などで基本概念を理解し、実装に必要な理解を得ることができました。こうした資料のおかげで、後からジョインしたメンバーでも自力でキャッチアップを進められます。 ドメインの複雑さそのものは変わりませんが、「わからないことをわからないままにしない」ための手段がチームとして整っていることが、大きな強みです。 AIを活用した開発文化 勤怠プロダクトの開発組織では、個人個人がAIを活用して開発業務に取り組んでいるのはもちろんのこと、組織としてもAI活用を推進する体制が整っています。その中の1つのチームは、AIネイティブな開発プロセスの実現を専門的に担っています。開発プロセスを可視化し、どの工程をAIネイティブ化できるかを検証したうえで、成果を他のチームへ横展開しています。すでに開発ライフサイクルにAIが組み込まれた業務フローもでき始めており、試行錯誤の段階から実運用のフェーズに移りつつあります。 AIと人間の役割をどこで分けるかについて、明確なルールがあるわけではありません。ただ、チームの基本的な考え方として「どうすればAIに一任できるか」を起点にしています。人間がやるべきことを先に決めてAIに残りを渡すのではなく、まずAIに任せることを前提に考え、人間の判断が本当に必要な部分を見極めていく。この発想の順序が、AI活用を自然に進められている要因の一つでしょう。 半年を振り返って 入社前、勤怠ドメインの理解にはかなり時間がかかるだろうと覚悟していました。法令・制度・就業規則が複雑に絡み合うドメインなので、一人前に議論できるようになるまで相当かかるだろうと思っていたのが正直なところです。 しかし、先述したドメインエキスパートへの相談のしやすさやドキュメントの充実など、チームのサポート体制のおかげで、想像していたよりもずっと早くキャッチアップが進みました。今では仕様検討の場でも自分の意見を出して議論に参加できており、入社前に抱いていた不安はすっかり解消されました。 ドメイン理解も技術面も、まだまだこれからではありますが、半年前には見えていなかった景色が見えるようになってきた実感があります。 まとめ 約半年このチームで過ごしてきて感じる魅力は、「複雑なドメインに対して、メンバーが主体的に向き合っているチーム」だということです。Whyを大事にする開発姿勢、フロントエンド・バックエンドの垣根を越えて機能全体に向き合うスタイル、ドメイン知識への投資、AI活用の推進。そのすべてに、一人ひとりが自分ごととして取り組む姿勢が貫かれています。 このチームで活躍しているメンバーに共通しているのは、主体性を持って動いていることです。 複雑なドメインを自ら理解しにいき、担当範囲を越えて機能全体に向き合う。そうした姿勢がチーム全体の推進力になっています。 勤怠ドメインという複雑で大きなプロダクトの開発を最前線で経験できる機会はなかなかありません。ドメインの奥深さ、チームの文化、技術的な挑戦、どれをとっても貴重な経験が得られる環境です。 私自身、この環境でもっと力をつけて、チームとプロダクトの成長に貢献していきたいと思います。 We Are Hiring! SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！ 少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！ hello-world.smarthr.co.jp
- Ruby
- Rails
- フロントエンド
- 生成AI
SmartHR の人給基幹は何を解いているのか ── 全体像と、いま向き合っていること
SmartHR で人給基幹プロダクト開発本部のエンジニアリングマネージャーをしている yuzuru です。 この記事では、社内で「人給基幹」と呼んでいる領域が、そもそも何を解こうとしているのか、どこに難しさがあって、いまどんな体制で何に投資しているのかを、一度まとめて書いておきたいと思います。このあと、フロントシステム・人事マスタ・勤怠管理・給与計算の各エリアのマネージャーが、自分の担当領域について順番に書いていくシリーズの1本目です。「SmartHR の人給基幹って、何をやっているところなんだっけ」という方、とくに採用候補として SmartHR を見てくれているエンジニアの方に、少しでも具体的なイメージを持ってもらえたら嬉しいです。 このドメインは、外から見ると「すでにやり方が決まっている業務をシステムに落とすだけ」に見えがちなのですが、いざ中に入ると、制度・例外・時間軸・連携の絡み方がかなり複雑で、そこに SaaS としての体験まで乗ってくるので、わりと骨太だなと感じます。 10分くらいで読める分量を目安にしたので、興味を持ってもらえたら、このあとのエリア別の記事も合わせて読んでもらえると嬉しいです。 筆者プロフィール yuzuru（秋山 譲） SmartHR 人給基幹プロダクト開発本部 / Engineering Manager エンジニア歴は約20年。大小様々な企業で EM を務め、2024年12月に SmartHRに入社。 現在は人給基幹全体Directorとして、組織全体の取り組みにも携わっています。 人給基幹が支えている業務 SmartHR が前提にしている社会課題は、人口減少と労働人口の縮小です。企業のバックオフィスは、人手で回すやり方からシステムで支えるやり方へ、もう戻れないところまで来ていると思います。 人給基幹は、そのど真ん中の領域です。具体的に扱っている業務を並べると、 従業員情報と組織情報の管理 入社・異動・昇降格・退職といった発令 勤怠の集計と締め 給与計算と支払い 各種申請の承認フロー 年末調整や社会保険といった帳票 あたりで、どれも「毎月の締め」に直結する業務です。つまり止まると困る業務ですし、法改正が来たから来月から対応します、というわけにもいかない。施行日までに、全顧客に対して当たり前に反映されている必要があります。 この「止められない」という性質が、システムとしての要件をかなりの部分まで決めていると感じます。正確性、監査性、履歴性、可用性、変更容易性。どれか一つでも欠けると、その時点でお客様の業務が止まります。人給基幹は、この水準を当たり前のラインに置いた上で、社会インフラ的な責務を背負っている領域だと思っています。 SmartHR の人給基幹が目指していること SmartHR は人事労務から始まり、タレントマネジメント、給与、勤怠、周辺プロダクトへと領域を広げてきました。その中で人給基幹は、人と組織に関するデータが最初に集まって、他のプロダクトへ流れていくハブ、という位置づけになっています。 ここで常に意識しているのは、個別プロダクトとしての最適と、人給基幹システム全体としての最適の両立です。単体で便利なだけだとお客様の業務は回らないので、プロダクト間の連携やデータの統合性を踏まえた上で、個別のプロダクトを進化させていく必要があります。 人給基幹はすでに多くのエンタープライズ企業で、毎月の業務の中心として使われています。一つの変更が、顧客企業の給与支払いそのものに影響しうる規模で運用しています。新規プロダクトをゼロから立ち上げるときとは、設計制約がまるで違います。「すでにある整合性」を崩さずに進化させる設計力が、日々試されている感覚があります。 中長期では、SaaS の強みを活かした新しい人給基幹システムを作ろうとしています。既存のオンプレ型を単に置き換えるのではなく、 法改正が、施行日までに当たり前に全顧客に反映されている 業務に即した形で、プロダクト間をデータが自然に流れる 共通モデルの上にデータが集約されていて、活用前提の品質が保たれている 連携性と拡張性が高く、標準を保ったまま多様な要件に応えられる 「変わり続ける」前提で進化するので、老朽化しにくい あたりを目指したいと考えています。そしてこれを、既存のオンプレより低い価格帯で提供する。これがもうひとつのテーマです。体力のある大企業にしか届かない品質ではなくて、中小企業まで含めて使える基幹システムを SaaS で作り直す、というところに中長期で投資しています。 なぜ難しいのか ── 制度・時間軸・スキーマ・外部接続 「給与や人事のシステム」と聞くと、法令や業務要件が先にあり、満たすべき処理を正確に実装していく領域だと見られがちです。たしかに、やらなければならないことは多くの場合すでに決まっていて、各社が同じ必須要件に向き合っているようにも見えます。 でも、実際に担当プロダクトを見ていくと、差が生まれる余地はむしろそこに残っていると感じました。同じ制度・同じ業務を扱うからこそ、どこまで迷わず使えるか、AIをどの場面で自然に効かせるか、情報をどう整理して提示するか、アクセシビリティまで含めて誰にとっても扱いやすくできるかが、プロダクトの価値を大きく左右します。 決まった業務をただコードに落とすのではなく、制約の多い領域の中で「どうすれば他社にはない使いやすさを作れるか」を考え続けられる。そこに、この領域の面白さがあると感じています。 制度と例外が重なり続ける 法改正、業界ごとの慣習、会社ごとの就業規則、手当体系、締め日。このあたりが毎年のように動きます。そのうえに、雇用形態、休職、兼務、遡及、差分支給、手作業補正、といった例外が、いくらでも組み合わさってきます。 「4月1日付で休職に入った正社員に、休職中に昇給の遡及適用があって、社会保険の等級変更も重なって……」という話が、ごく日常的に出てきます。こういうものをハードコードではなく仕組みで解けるようにする、というのがこの領域の一つ目の難しさです。 時間軸が複数ある 人給の世界では、「いつ適用されるか（valid time）」と「いつ記録されたか（transaction time）」が普通にズレます。未来日変更（予約）と遡及修正が同じシステムに同居していて、場合によっては同じ従業員のデータに対して同時に走ります。 さらに、「過去のある時点で、この従業員はどう見えていたか」という履歴の視点も重要になってきます。「今の状態」だけを持つデータモデルだと、すぐに破綻する世界です。人事マスタまわりでは、この二つの時間軸を両立させるために、bitemporal なデータモデルを土台にしています。有効日と記録日の両方をキーにして履歴を引ける設計にしておき、予約・遡及・監査といった要求を同じ仕組みで受け止める、というイメージです。どこまでこの仕組みに寄せて、どこは各プロダクト固有の履歴として持つのか。この切り分けは、いまも日々の設計判断の中心にあります。 スキーマが進化し続ける 従業員、組織、雇用、手当。どれも項目が増え続けて、意味も変わり続けていく領域です。新しい手当が生まれ、組織定義が変わり、グループ企業が加わり、入社経路が多様化する。そのたびに、表示・入力・検索・権限・連携のすべてにコストが乗ってきます。 スキーマを柔らかくしすぎると一貫性が壊れて他プロダクトとの連携が崩れるし、硬くしすぎると運用でお客様が困る。どこまで構造化して、どこからユーザー定義に開くか、というラインの引き方は、正直なところ一番難しい部分のひとつです。 外との接続が広い 会計、社労士、勤怠端末、マイナンバー、銀行振込、各社 SaaS、API、CSV。挙げ始めるとキリがないくらい、人給基幹は外の世界とつながっています。それぞれが独自のフォーマットと業務タイミングとバージョン管理を持っている世界です。 全部の連携先に、全部の進化を同じ速度で届ける、というのは現実的ではないので、どの連携をどの優先度で維持・進化させるかを、常に選び続けている状況です。 いま取り組んでいること ── 変更に強い設計と正しさの担保 ここからは、その難しさに対していまどう手を入れているか、の話です。解けるテーマが残っている分だけ、面白さも残っている領域だと感じています。 変更に強い設計へ寄せていく 長年積み上げてきたコアサービスは、制度変更の影響範囲が読みにくくなっている部分が実際にあります。「一見小さな要件のはずが、調べてみると影響先が複数プロダクトに跨っていた」という話も珍しくありません。 ここに対しては、レガシー基盤からの段階的な脱却と、モジュラーモノリス化を進めています。ドメインの境界を定義して、モジュール間の依存方向を静的解析で監視しながら、逸脱を一つずつほどいていく、という地味な進め方です。一気にマイクロサービスに分割するのではなくて、依存を先にほどいてから動かす、という順序を大切にしています。境界の切り方そのものを検証するために、Ruby の動的解析ツールを自作してモジュール境界を探索している話も、テックブログで公開しています。 正しさの担保 給与計算は「1円のズレも許されない」とよく言われます。人給基幹全体でも、計算結果・履歴・監査の説明可能性が、品質の根っこにあります。 「なぜその金額になったのか」を後から完全に再現できること。「いつ、誰が、何を変更したのか」が監査できること。bitemporal な履歴設計と、計算過程のトレーサビリティを、運用コストと見合う形でどこまで作り込むか。ここは一度作って終わり、とはならなくて、継続的に磨き続けている領域です。 体験の一貫性 人給基幹のユーザーは、労務担当者、従業員、管理者、経理、社労士と、立場がかなり違います。それぞれに対して、設定のわかりやすさと、機能の充足性を両立させないといけない、というのがこの領域特有の難しさです。 同じ「申請」でも、従業員から見るとちょっとした変更届に見えて、労務担当から見ると複数プロダクトに波及する重要業務になっている、ということがよくあります。この両面を同じ画面、同じ設定体系の中でどう整理するかは、いまも試行錯誤している最中です。 スケールとパフォーマンス エンタープライズ企業では、数万人規模の従業員を毎月締める処理が走ります。繁忙期には処理が集中するので、ピーク時の負荷は平時とはまったく別物です。 単にスケールアップで殴るのではなく、ドメインに根ざした指標（締め処理のリードタイム、計算時間、検索応答時間など）を定義して、SLO を設定して、異常を「お客様からの問い合わせで発覚する」前に検知する。そこまで踏み込むフェーズに入っています。 基盤としての拡張性 人給基幹は、他プロダクト、他エリアが依存する土台でもあります。ここを動かすときは、外部への波及を最小化しながら、内部のデータモデルは進化させ続ける、という両立が常に求められます。 安定稼働を保ったまま、中身を漸進的に進化させる。このバランスは個人の技術力だけでは持ちきれなくて、チームとしての意思決定プロセスそのものが問われる部分だと感じています。 どんな体制で取り組んでいるか ── 2つの本部と4つのエリア 人給基幹は、大きく2つの本部で動いています。 人給基幹開発本部の体制図 人給基幹プロダクト開発本部 ユーザー価値の最大化をミッションに、エンタープライズ企業に選ばれる人給基幹を作っていく本部です。フロントシステム、人事マスタ、勤怠管理、給与計算の4つのエリアに分かれていて、それぞれが自律したチーム群として動きながら、全体としての整合性も意識しています。 各エリアの中はさらに複数のスクラムチームで構成されていて、チーム単位では自律的に動きます。エリアをまたぐ意思決定や、全体の優先順位調整は、エリア EM とエリア PO が連携しながら進めています。 この4エリアに加えて、本部内にはCRE部（Customer Reliability Engineering）も置かれています。お客様からの問い合わせ対応や不具合改修、Customer Observability の整備を横断で担っていて、プロダクトの信頼性を現場目線で日々支えてくれているチームです。 人給基幹プロダクト基盤開発本部 ── 中長期の土台を育てる本部 人給基幹の各プロダクトが共通して依存する「土台」を育てている本部です。先ほどの章で挙げた技術テーマ、bitemporal データモデルの進化、モジュラーモノリス化、業務指標に紐づく SLO・メトリクス設計、そして止められないサービスの裏側での本番データ移行、あたりを、個別プロダクトのロードマップとは独立した時間軸で担います。 本部内にはスケーラビリティエンジニアリングユニットも置かれていて、先ほど触れた SLO・パフォーマンスまわりを中心に、大規模テナントでの処理性能と可観測性を専門に扱っています。基盤本部の取り組みの中でも、特に「お客様の業務をスケール側から止めない」ためのチームです。 プロダクト本部と基盤本部を分けているのは、機能開発と土台の進化とで、時間軸も意思決定の粒度もかなり違うからです。分けておくことで、短期のユーザー価値提供と、中長期の土台作りを、それぞれのリズムで進められる体制にしています。 基盤本部の取り組みは、テックブログでも個別にまとめています。「履歴の適用日を日付化しました」「自作の Ruby の動的解析ツールを使って、モジュラーモノリスの境界を試行錯誤している話」あたりが、具体を知るのにちょうどいい入口だと思います。 チームの動き方 全社的にスクラムを採用していて、人給基幹でも Scrum@Scale で複数チームの協働を運営しています。レビュー、テスト、リリース、モニタリングは各チームが責任を持ちつつ、データモデルや観測性、SLO といった横断テーマは、エリアや本部をまたいだ場で持ち寄って議論しています。 マネージャーとしての正直な感覚を書いておくと、このドメインは「一人の天才が全部を解く」タイプの問題にはなっていません。ドメインに詳しい人、設計に強い人、運用に強い人、CRE としてお客様の声を持ち帰る人。それぞれが専門性を持ち寄って、ようやく前に進むタイプの領域だと思います。入る側から見れば、自分の強みを複数方向から活かしやすい環境なんじゃないか、といまは感じています。 次回以降の予告 1本目としては、いったんここで筆を置きます。2本目以降は、各エリアのマネージャー自身が、自分の担当領域について書いていく予定です。 2本目：給与計算 3本目：フロントシステム 4本目：人事マスタ 5本目：勤怠管理 人給基幹は、外から見えているよりもずっと複雑で、その分だけ解きごたえが残っている領域だと思っています。このシリーズを通して、「ここで自分が何を解くのか」が少しでも具体的に想像してもらえたら嬉しいです。 SmartHR では、この領域を一緒に解いていく仲間を募集しています。気になった方は、ぜひカジュアル面談でお話ししましょう。次回以降の記事もお楽しみに。
- Ruby
- モジュラーモノリス
- システム設計
【RubyKaigi 2026】採用担当が振り返るアンドパッドブースの3日間
こんにちは！開発本部 組織開発部で、エンジニア採用・育成を担当している磯崎と中野です。 アンドパッドがRubyスポンサーとして参加した「RubyKaigi 2026」。今回は、初参加で現地を全力で駆け抜けた磯崎のレポートと、5回目の参加となるマネージャー中野の視点の2つの軸で、熱気あふれる3日間の様子をお届けします。 まずは、大盛況だった現地のブースの様子から振り返ります！ はじめに 開発本部 組織開発部で、エンジニア採用・育成を担当している磯崎です。 私は普段、開発本部付の人事として、日々素晴らしいエンジニアの方々と出会うべく採用活動に奮闘しています。 そんな中、今回はエンジニア採用活動の重要な一環として、北海道・函館で開催された「RubyKaigi 2026」に参加してきました！ RubyKaigiは、エンジニアの皆さんが技術の深い議論に熱狂する特別な場です。 今回、私たちアンドパッドもスポンサーとしてブースを出展しました。 私自身もブースに立ち、全国から集まった多くのRubyistの皆さんと直接お話しさせていただきました。 「現場でどんな技術が使われているの？」「アンドパッドの開発文化って実際どうなの？」といった生の声に触れながら、 少しでも多くの方にアンドパッドという会社、そして私たちのプロダクトの面白さを知っていただく「機会の創出」に一役買いたい！ そんな熱い想いを胸に駆け抜けた3日間をレポートします。 23名のメンバーで盛り上げた、アンドパッドブース 今回、アンドパッドは 「Ruby Sponsor」としてRubyKaigi 2026を協賛させていただきました。 現地に駆けつけたメンバーは、エンジニア16名、広報・採用担当7名の計23名という、弊社としてもかなり大規模な布陣です！ 技術カンファレンスであるRubyKaigiに、なぜ私たち人事や広報といった非エンジニアのメンバーがこれほど多く参加したのか。それは、アンドパッドの魅力をエンジニアの視点だけでなく、組織やカルチャーを支える非エンジニアの多角的な目線からも発信したいという強い想いがあったからです。 当日のブースでは、事前にお知らせしていた通り「技術への深い関心」と「ホスピタリティ」の両面からアプローチを試みました。 📘 エンジニアによる「立ち読み喫茶」 アンドパッドのエンジニアたちが厳選した技術書をずらりと並べ、その場で自由に読みながら交流できるスペースを提供しました。 単なる一方的な会社説明の場にするのではなく、本をきっかけに「この技術、実務ではどう使ってる？」「うちのチームだとこう工夫していて……」といったディープな技術談義が至る所で発生！ 技術へのリスペクトと探究心にあふれる、まさにRubyKaigiらしい熱気あふれる光景が広がっていました。 ☕ 広報・採用担当による「おもてなしコーナー」 私たち広報・採用チームは、ランチ（お弁当）の配布や函館のご当地ドリンク、そしてアンケートコーナーを担当しました。 開催期間中の函館は少し冷える風が吹いていましたが、ブースに立ち寄ってくださった皆さんにホッと一息ついていただけるよう、笑顔と温かいおもてなしで運営。 アンケートコーナーにも多くの方に足を止めていただき、アンドパッドに対するリアルで貴重なフィードバックを直接伺うことができました。 🤝 過去と現在が繋がった、印象的なエピソード 3日間ブースに立った中で、特に心に残っているエピソードがあります。 ブースを訪れてくださった方の中に、現在アンドパッドで活躍している社員と、前職で一緒に働かれていたという方がいらっしゃいました。 その方から「今のアンドパッドってどんな事業に挑戦しているの？」「実際の技術スタックはどうなっているの？」と、非常に熱心にご質問をいただく場面がありました。そこから会話が弾み、現在の私たちの開発体制や、これから目指していく組織のビジョンについてディープにお話しする中で、さらに新しい交流へと発展していきました。 単に「懐かしい再会」や「情報交換」に留まらず、最終的には「アンドパッドの選考フローがどうなっているのか」という具体的なステップにまで興味を持ってご確認いただくことができました。最先端の技術を追う場所であると同時に、「過去の繋がりや、人と人とのコミュニティの交流の大切さ」を肌で感じられたことは、カンファレンスならではの忘れられない瞬間です。それと同時に、私たちのミッションである「アンドパッドの仲間を増やしていく」という究極の目的に一歩近づくような、採用担当としてこれ以上ないほど手応えのある、素晴らしい交流を生み出すことができました。 🚀 全てのコンテンツが大盛況！現場で感じた「アンドパッドらしさ」 おかげさまで、どのコーナーも3日間を通して大盛況のまま終了することができました！ 「アンドパッドのTechBlog、いつも読んでます！」「エンジニアの皆さんとこんなに深く技術の話ができると思わなかった」といった温かい声を直接いただけたことは、採用担当としてこれ以上ない喜びでした。 今回、23名という大所帯のメンバーが職種や役割の垣根を越えて連携し、来場者の皆さんに「最高の体験」を提供しようと奮闘する姿は、まさに弊社のバリューである Professional を体現していました。 エンジニアが技術の楽しさと奥深さを全力で伝え、私たちが人事・広報としてその環境や文化をサポートする。 この両輪が揃ってこそ、アンドパッドという組織の魅力が真っ直ぐに社外へ伝わるのだと確信した、本当に濃密で素晴らしい3日間でした。 【番外編】函館の食と景色を満喫！ 今回のRubyKaigiは、歴史情緒あふれる函館での開催でした。 ブース運営の合間には、函館ならではの景色や食に触れ、チームメンバー同士の親睦を深める貴重な時間となりました。 満開の桜と五稜郭 ： ちょうど見頃を迎えた五稜郭公園。満開の桜の下で、リフレッシュすることができました。 函館の味覚 ： ジンギスカンや海鮮など、地元の食を囲んでエンジニアと採用チームの連携をより強めることができたと感じています。 こうしたオフラインならではの体験が、最終日のブース運営まで走り抜けるエネルギーに繋がりました！ アンドパッドとRuby、これまでの歩みとこれから ここからは、採用・育成チームでマネージャーをしている中野がお送りします。 磯崎のレポートにもあった通り、今回のRubyKaigi 2026はメンバー全員が職種の垣根を超えて一丸となり、本当にいいブース展開ができたなと感じています。 私自身は、今回で5回目の参加でした。 毎年思うことですが、あの独特のあたたかい空気感と、会場全体に満ちている「技術へのワクワク感」は、何度来ても心地いいですね。この空間に一緒にいられることが、純粋に嬉しいなと感じる時間でした。 言葉で説明できない「あの感じ」を共有したくて 今回は、初参加の人事メンバーも連れていきました。 普段、社内で「Rubyコミュニティはすごいんだよ」といくら言葉で説明しても、あの現地の熱気だけは伝わりきらないんですよね。実際に足を運んでみて、「あ、こういうことか！」という発見や、参加する楽しさを少しでも感じてくれていたら嬉しいです。 それにしても、RubyKaigiって本当に不思議な場だなと思います。 私のような非エンジニアに対しても、Matzさんや松田さんがラフに話しかけてくださったりして。そんな懐の深さに触れるたび、「自分たちもこのコミュニティの一員なんだな」と実感できて、すごくありがたいなと思います。この素晴らしいコミュニティが続くよう、アンドパッドとしても支援していきたいし、私たちが企業として成長していくこと自体が、コミュニティへの一番の恩返しになるのかもしれないといつも思っています。 2019年から続く、アンドパッドとRubyコミュニティのつながり 今回アンドパッドが「Rubyスポンサー（※ 広瀬のブログ にある通り、気合を入れて様々な企画を準備しました！）」を務めている背景には、実はちょっとした思い入れがあります。 きっかけは2019年に初めてスポンサーをした時まで遡ります。 当時は社名もロゴも今とは違っていて、まさにこれから組織を大きくしていくぞ！というタイミングでした。あの時、RubyKaigiを通じてたくさんの素晴らしいエンジニアと出会えたことが、今の私たちの成長に繋がっています。 あれから、お陰様でリリース10周年を迎え、ARRも100億円を突破しました。この成長を支えてくれたRubyやコミュニティに対して、今度は私たちがスポンサーという形で盛り上げるお手伝いができるのは、とても感慨深いです。 もちろん、私たちの挑戦はまだまだ続きます。 「幸せを築く人を、幸せに。」このミッションの下、ARR300億円というさらに大きな目標に向けて、AI活用も含めてやりたいことは山積みです。そのためには、もっともっと新しい仲間が必要です。このRubyKaigi 2026での色々な出会いが、次の10年を一緒に歩むきっかけになればいいな、と願っています。 次は、宮崎で！ 色々な出会いに感謝、そして今回しか味わえない最高のカンファレンスに参加させてくれた会社にもありがとう、ですね。 来年の宮崎でも、また胸を張って皆さんとお会いできるよう、明日からまたエンジニアが活躍できる環境づくりを頑張っていきます。 おわりに 「幸せを築く人を、幸せに。」 このミッションを支える技術の力を信じて、これからもアンドパッドの魅力を発信し続けていきたいと思います。 今回の記事で少しでもアンドパッドに興味を持っていただけたなら、ぜひカジュアルにお話ししましょう！函館の思い出話から、私たちが目指す組織の話まで、皆さんからのご連絡をお待ちしています。 ▼ アンドパッドでは、一緒に働く仲間を募集しています！ カジュアル面談はこちら 採用情報・求人一覧
- Ruby
- 採用
- 技術広報
第91回 Ruby関西 勉強会レポート
こんにちは、ydahです。普段はSmartHRでプロダクトエンジニアとして外部サービス連携基盤の開発をしています。大阪に住んでいてKyobashi.rbの主催や関西Ruby会議09のチーフオーガナイザーをしています。 2026年5月22日（金）に、第91回 Ruby関西 勉強会が開催されました。SmartHRは本イベントに会場提供という形で協賛し、グランフロント大阪タワーAの34階にあるSmartHR大阪オフィスを会場として提供しました。 rubykansai.doorkeeper.jp この記事では、当日の様子をお届けします。 第91回 Ruby関西 勉強会の会場の様子 目次 目次 開催概要 スポンサートーク: やっていき2026 Rubyの配布パッケージの変遷 BareRuby ～VMの殻を破る～ bundler に cooldown 機能ほしい Fiberを理解したい2026春 関西Rubyコミュニティ紹介 関西Ruby会議09 アナウンス おわりに We Are Hiring! 開催概要 第91回 Ruby関西 勉強会は、3年ぶりに開催されたRuby関西の勉強会です。Ruby関西代表のおごもりさんとも話していたのですが、ずっと関西Ruby会議や関西のRubyコミュニティで会っていたので全然気づかず、気づけば前回開催から3年が経っていました。時が過ぎるのは早いですね。会場はSmartHR大阪オフィスで、RubyKaigiで学んだことやRubyに関する話題を持ち寄る会として開催されました。 スポンサートーク: やっていき2026 最初は、私のスポンサートーク「やっていき2026」でした。SmartHR社内でOSS活動や技術イベントへの登壇を後押しする「OSSやっていきの集い」について、ミートアップやプロポーザル支援の取り組みを紹介しました。 「やっていき2026」を発表する ydah Rubyの配布パッケージの変遷 @znzさんによる「Rubyの配布パッケージの変遷」では、Rubyのリリース時に配布されるアーカイブ形式の歴史が紹介されました。最初は tar.gz のみだったものが、tar.bz2 や zip、その後 tar.xz に対応し、最終的に tar.bz2 が削除されるまでの流れを、リリース作業や外部ツールへの影響も交えて解説されていました。 Rubyの配布パッケージの変遷について話す znz さん BareRuby ～VMの殻を破る～ すぎうり（@uproad3）さんによる「BareRuby ～VMの殻を破る～」では、マイコン上でRubyらしい書き心地を保ちながら、より軽量に動かすための構想が紹介されました。PicoRubyで感じたVMの処理時間の課題を出発点に、GCや例外、動的な機能を削り、AOTコンパイルやレジスタアクセスなどマイコン向けの機能を足す「BareRuby」のアイデアが語られていました。 BareRubyの構想について語る すぎうり さん bundler に cooldown 機能ほしい @k-yoshidaさんによる「bundler に cooldown 機能ほしい」では、公開直後のgem versionをすぐにinstallしないためのBundler plugin、bundler_plugin_cooldown の話が紹介されました。アカウントの乗っ取りなどで悪意あるgemがpublishされた場合に、即時に取り込まれる事故を緩和するため、公開から一定期間が経過していないgemのinstallを止めるPoC実装について話していました。 Bundlerのcooldown機能について話す k-yoshida さん Fiberを理解したい2026春 私は「Fiberを理解したい2026春」という話をしました。Fiberを非同期I/Oの仕組みとしてではなく、1スレッド内で制御フローを手動で切り替えるコルーチンとして整理しました。Fiberの理解を深めるために作ったfibrioというストリーミングパーサーを題材に、Fiber#resume と Fiber.yield で1レコードずつ処理を進める実装を紹介しました。 「Fiberを理解したい2026春」を発表する ydah 関西Rubyコミュニティ紹介 おごもり（@ogom）さんによる「関西Rubyコミュニティ紹介」では、関西圏にあるRubyコミュニティがまとめて紹介されました。資料では20のコミュニティのうち、活動中が13箇所、休止中が7箇所と整理されており、Ruby関西をはじめ、AKASHI.rb、Kyobashi.rb、Kyoto.rb、naniwa.rb、Ruby Tuesdayなど、各地域のコミュニティやその特徴が紹介されていました。 関西のRubyコミュニティを紹介する おごもり さん 関西Ruby会議09 アナウンス 最後に、チーフオーガナイザーを務める私から関西Ruby会議09のアナウンスをしました。2026年7月18日に大津市伝統芸能会館で開催されることや、関西のRubyコミュニティが集まる地域Ruby会議として準備が進んでいることを紹介しました。 regional.rubykaigi.org おわりに 久しぶりのRuby関西勉強会をSmartHRの大阪オフィスで開催できて本当に嬉しく思います。 共催を快諾していただいたRuby関西のおごもりさん、ご登壇いただいた皆さん、ご参加いただいた皆さん本当にありがとうございました。 <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/smarthr/20260528/20260528100029.png" alt="勉強会の参&#
- Ruby
- コミュニティ
清聴御礼! RubyKaigi 2026 でアンドパッドから 4 名登壇 + 1 名司会 + 1 名スポンサーセッションを行いました
こんにちは、採用広報の id:sezemi です。 RubyKaigi 2026 が終わって、はや 1 か月、興奮冷めやらぬまま、次は地域 Ruby 会議がやってきますね。 アンドパッドは 6/6 開催の 松江 Ruby 会議12 に協賛しており、当日はブースも出展しますので、また Rubyist の皆さんに会えることを、とても楽しみにしています！ さて、その RubyKaigi 2026 ではアンドパッドから合計 6 名が登壇しました。 この記事では、登壇の裏話、補足、思い出などなどを登壇者に語ってもらいました。 なお、登壇者の一人 hsbt は別エントリで記事を出しますので、ぜひそちらもご覧ください。 Hasumikin 話したこと・伝えきれなかったこと PicoRubyをWASMビルドしたPicoRuby.wasmと、その上につくったFunicularというブラウザアプリフレームワークの話をしました。最近なぜかPicoRubyのトークをする人が増えたので、ハードウェアのトピックは彼等に任せ、わたしはちょっと趣向を変えてみようと思った、というわけです。 なのですが、どうにもガマンしきれずに、「PicoRubyで動くキーボードにWebSocketサーバを建て、ブラウザのPicoRuby.wasmクライアントとdRubyで通信してLEDを光らせる」といういつものマイコン芸人仕草を30分のトークに詰め込んでしまいました。ですからFunicularの詳しい話はあまりできませんでした。この続きは、ことしのKaigi on Rails 2026でお届けします（プロポーザルが通ったら）。よろしくお願いします。 hasumi の登壇の模様 by hsbt 発表で大変だったこと 初日の午前中の発表だったため、プレッシャーからあっというまに解放されました。まことにありがたいことです。 Funicular: A Browser App Framework Powered by PicoRuby.WASM RubyKaigi 2026 の思い出 やんちゃハウスという宿泊イベント（？）を利用しました。Kaigi会場至近だし1階にラーメンバーがあるし、道路を渡れば日帰り温泉があり、完璧な宿泊体験でした。 Kaigi後にはレンタカーに乗って、小樽や余市や支笏湖やディープな温泉を旅しました。小樽ではぬかるみで滑って転んでiPhoneを壊してしまいましたので、急遽札幌の電器店へ行き、新しいiPhoneを購入しました。同道のポーランド人は、このトラブルに乗じてポケモンセンターサッポロへ寄ることができて大満足な様子でした。 Youchan 話したこと・伝えきれなかったこと 「Guide to getting started walking source codes of CRuby」というタイトルでCRubyのソースコードを読むためのTipsを紹介しました。 CRubyに限らないジェネリックなソースコードの読み方からCRubyに特有のことなどをなるべく実際のソースコードを参照しながら解説しました。 また、AIを活用してソースコードを読むという方法も紹介しました。 CRubyの内部に関しては伝えたいことが沢山ありましたが、本トークではなるべく読み方にフォーカスして話しました。 伝えられなかったことは、同人誌として執筆した「CRuby Quest ～Rubyのぼうけんのしょ～」に書いたのでRubyKaigiの会場で購入されたかたはそちらも参考にしてほしいです。 youchan の登壇の模様 by hsbt 発表で大変だったこと 発表自体よりも前述の同人誌の執筆が大変でした。 発表は同人誌の執筆による副産物のようなものでしたが、苦労して本を書いたのでトークの内容も自信を持って話せるものになったと思います。 Guide to getting started walking source codes of CRuby 左右キー(← →)でページ送りできます RubyKaigi 2026 の思い出 自分のトークの後は休み時間はだいたい本屋さんにいて、ずっとサインをしていたように思います。 売れっ子の作家になった気分で楽しかったです。 あとはコード懇親会でPicoPicoRuby(コミュニティ)のみなさんとワイワイできたのがよかったです。 Day 2 で bento プレゼンターをした様子 nagachika 話したこと・伝えきれなかったこと 「Pure Intonation on Browser: Building a Sequencer with Ruby」というタイトルで ruby.wasm と Web Audio API を利用してブラウザ上で動作するシンセサイザー/シーケンサーを開発した話をしました。 最近の RubyKaigi で音声まわりに関する発表が多かったことに触発されて以前からやりたかったシンセサイザー開発+最近興味を持った音楽理論の実現をやってみたというものです。ruby.wasm については ledsun さんのセッションも類似のテーマとなりそうだったのでトークの半分くらいは元にした音楽理論についての話に割くという RubyKaigi っぽくない内容になって個人的には良かったかと思います。 開発しているシーケンサーはさらに MIDI コントロールも可能にしていて、専用の MIDI コントローラーをこれまたブラウザで動かすものを開発しています。これについては松江Ruby会議12で発表させていただく予定です。 nagachika の登壇の様子 by hsbt 発表で大変だったこと 大きなカンファレンスでのトークはとても久し振りだったこともあり、資料の発表者ノートも入念に書き上げ(RubyKaigi では日→英の同時通訳が行なわれ、日本語での発表者は翻訳者の方に事前に資料を提供する必要があるのでそのためという側面もあります)練習もしていました。本番では逆にそれにひきずられて台本を読み上げることに集中してしまって普段通りのトークができなかったなという反省があります。次の機会ではもうすこしリラックスして発表できるようにしたいです。 RubyKaigi 2026 の思い出 アンドパッドのランチ提供の3日目のやきとり弁当を手渡す係をやらせていただいたのですが、大量のお弁当が次々と配られていくのを目の当たりにして不思議な充実感を覚えました。なんというか人間には食事を提供して人々の腹を満たすということに快感を覚える本能があるのではないでしょうか。 また会期後の Day 4 には函館市電に乗って LT 大会をするというイベントに参加して紙芝居形式の LT をするというはじめての経験もしました。他の方の LT もユニークなものばかりで楽しかったです。 Leo 話したこと・伝えきれなかったこと RubyKaigiの定番企画「Ruby Committers and the World」の司会を務めさせていただきました。RubyKaigiに参加しているRubyコミッター全員をステージに集めて、観客の前でRuby開発者会議を開催し、ワイワイと楽しく議論していただくことがコンセプトです。トピックは事前にコミッターたちから集めて、いい感じに議論できるように選定しました。今年は特にRubyの開発におけるAI活用の話が盛り上がりました。去年の同セッションでAIの活用のトピックもありましたが、懐疑的な意見が多かった。一方、今年はRuby開発で本格的に使っているコミッターが目立っていました。中でも、Matzが他のコミッターよりも積極的に活用していたのは驚きでしたが、同日のMatzキーノートで「これまでヒューマンインテリジェンス(コミッタの方々)に頼んでいたことが、AIに頼むようになっただけ」と語っていて、なるほどと納得しました。 発表で大変だったこと このセッションの司会になったのは、RubyKaigi 2024直前にRuby Committers SponsorのShopify Engineeringに声を掛けて頂いたことがきっかけでした。毎回、トピックの選定が難しいです。トピックはShopify所属のRubyコミッターと相談しながら選定しますが、普段意識しないレイヤーの話題が多くて、トピックの下調べが必要です。トピックの背景を理解するために、Ruby開発者会議の議事録やRuby本体のRedmineイシューを漁って予習をしました。 きゃー、 Leo さーん #rubykaigi pic.twitter.com/QO6fKDJ59q— ANDPAD (アンドパッド)開発部 (@andpad_dev) April 24, 2026 RubyKaigi 2026 の思い出 RubyKaigiの初回開催は2006年でした。数え方によっては、RubyKaigi 2026は20回目の開催となります。そういう背景もあり、2日目のheadius氏のKeynot「Twenty Years of JRuby」が印象に残りました。20年の積み重ねは偉大！ kei-s 話したこと・伝えきれなかったこと 3日目の Matz キーノート直前に、アンドパッドとしてのスポンサーLTに登壇しました。 今回の発表では、「帰り道に建設現場を見たら、その現場を動かす Ruby のことを思い出してほしい」というメッセージを軸に、アンドパッドの現在と未来をお話ししました。今年3月にサービス開始10周年を迎え、ARR100億円を突破して次なる300億円へ挑む私たちのプロダクトを支えているのは、まぎれもなくRubyの力です。 今年は4名のスピーカー登壇に加え、セッションの司会、ブース出展、ランチやドリンクの提供、そして総勢23名の参加とアンドパッドの存在感が高かったので、それを最後に聴衆の印象に残せるよう目指しました。 kei-s の登壇の様子 by hsbt 発表で大変だったこと 「3分」というタイトな尺の中に、どうやって伝えたい内容を込めるかというタイムマネジメントに注力しました。 全体の構成や大枠自体は会期前に完成していたのですが、函館の名の由来が室町時代の「館（建物）」にあることや、初日のキーノートで語られた「Box Building」の文脈など、現地で得たトピックをどうしても盛り込みたくなり、会期中に急遽内容をアップデートしたのです。限られた時間の中で、追加したストーリーとビジネス・組織のファクトを綺麗に繋ぎ、かつ3分ピシャリに収めるための推敲とトーク練習は、登壇直前のギリギリまで繰り返し行いました。現地での熱量を生で取り込んだからこそ、ライブ感のある最高のアピールができたと思っています。 RubyKaigi 2026 の思い出 アンドパッドが提供したランチは非常に人気で行列ができたのですが、列形成が少しスムーズにいっていないのを見て、勝手に責任を感じて当日スタッフのように列の整理を手伝ったりしていました。 また、2日目夜に開催したアンドパッド主催のコード懇親会には、実はこれといった役割を決めずにぶらっと参加していました。しかし会場に着くと、気がつけば雑務をこなしたり、参加者の皆さんに積極的に声をかけて、お互いにまだ知らない隣の人同士を繋げたりしていました。それが、個人的にとても楽しかったです。 まとめ アンドパッドの Speaker の面々、 5 名に発表のふりかえりと舞台裏などを語ってもらいました！ Ruby のコアなところからブラウザアプリケーション、そして多くの反響を生んだ Ruby Committers and the World での司会進行、そして建設現場の話まで、アンドパッドからの幅広い発表をご清聴いただき、ありがとうございました。 これからも Kaigi on Rails や地域 Ruby 会議などでの今後の発表をお見逃しなく！ そして、建設現場をみてアンドパッドを思い出した方はぜひお話しましょう！ カジュアル面談やポジションへのご応募お待ちしております。 <iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fhrmos.co%2Fpages%2Fandpad%
- Ruby
RubyKaigi 2026 アンドパッドブースで実施したアンケート結果から見える Ruby コミュニティの現在地
こんにちは、Ruby コミッタの柴田 (hsbt) です。最近はプレイするゲームに NTE を追加してしまい、いよいよ早起きする時間を30分繰り上げないとプレイしているゲーム全てのデイリークエの消化が追いつかなくなってきました。 先日の RubyKaigi 2026 では、例年通りアンドパッドはスポンサーとしてブースを出展し、ご当地ランチやドリンクを提供しました。たくさんの方から「これが食べたかった」という声を聞いて、選んだ当事者としては大満足です。 今回のアンドパッドのブースでは、参加者の皆さんに普段の Ruby 開発環境について 7 つの質問に答えていただくアンケートを実施しました。この記事では、その結果を順番に紹介しながら、Rubyist の現在地と、Ruby と Ruby のエコシステムのメンテナとして私見をあわせてお伝えします。 なお、Q1 と Q2 は単一回答ですが、Q3 以降は複数回答可の設問になっています。ユニークな回答者数は 350〜400 名前後ですが、グラフの棒の長さは「その選択肢を採用している人の絶対数」を表しており、「シェア」ではないことに注意して読んでいただければと思います。 RubyKaigi はその性質上、回答者は日本を中心としつつ、来日した Rubyist も多く含まれます。グローバルな Stack Overflow Developer Survey などとは母集団が大きく違うので、「Ruby を現役で書いている、カンファレンスに足を運ぶようなアクティブな開発者」のスナップショットとして読んでいただくのが良いかなと思います。 Q1. Ruby の使用歴は何年ですか？ 1 問目は Ruby 歴です。回答の分布はおおよそ以下の通りでした。 0 年〜2 年: 約 115 3 年〜5 年: 約 95 6 年〜9 年: 約 65 10 年以上: 約 100 「0 年〜2 年」が最多で、「10 年以上」がほぼ同数で続く U 字型の分布になりました。Ruby は登場から 30 年を超えた言語ですが、新しく Ruby を書き始めた層と、長年メインで使ってきた層が両方厚いというのは、コミュニティの世代交代と継続性が両立しているサインだと受け止めています。 世界的にも、AI coding を活用して少人数チームでも「もう一度 Rails で作ってみよう」という機運が高まっている一方で Shopify や GitHub のような大規模事例も継続的にアップデートされています。ブースに来ていただいた方からも「最近 Ruby を書き始めました」という声を聞く機会が増えてきたのと、このアンケート結果の手触りは一致しています。 Q2. 業務プロジェクトのメインとなる Ruby のバージョンは何ですか？ 業務で使用している Ruby のバージョンについての結果は以下の通りです。 Ruby 3.2 以前: 約 60 Ruby 3.3: 約 50 Ruby 3.4: 約 145 Ruby 4.0 (Stable): 約 140 Ruby 4.1 以上 (master/dev): 約 15 私が一番驚いたのはこの結果です。Ruby 4.0 は 2025 年 12 月 25 日にリリースされたばかりですが、半年も経たないうちに業務プロジェクトのメインバージョンとして Ruby 3.4 と肩を並べる規模になっています。Ruby 4.0 はメジャーバージョンアップながら互換性を強く意識して設計されており、3.x からの移行コストが小さいことを開発チームとして意識してきました。各種 Gem の対応も急速に整い、CI で 4.0 を主要バージョンに切り替えるプロジェクトが増えているのは、その設計判断が報われた結果だと感じています。 3.3 以前を引き続き使っている層がそれなりにいる点も、長期運用しているサービスの実情として現実的な数字です。3.2 系はすでにEOL、3.3 系も 2026 年 3 月で通常メンテナンスを終了しているので、セキュリティメンテナンス期間のうちに 3.4 系か 4.0 系へのアップデートを計画していただきたいところです。アップデートの障壁になっている点があればメンテナとしてフィードバックは歓迎します。 Q3. 業務でメインに使用しているエディタは何ですか？ エディタの回答分布は以下の通りです (複数回答可)。 VS Code: 約 200 Cursor: 約 110 Neovim / Vim: 約 70 RubyMine: 約 45 Zed: 約 15 Emacs: 約 10 Sublime / Cmux / Antigravity / Helix: 各数件 その他: 約 10 ここから複数回答可能な設問です。そのため、「業務で使っているエディタを複数選んだ」結果と読むのが妥当です。VS Code 利用者の一定数が Cursor も併用していたり、Neovim / Vim を日常使いつつ補完目的で VS Code も入れている、といった重なりが含まれているとして、それでも VS Code が約 200 名で圧倒的トップ、Cursor が約 110 名で 2 位という勢力図は明確です。 世界的にも JetBrains の State of Developer Ecosystem や Stack Overflow Developer Survey で VS Code は数年来トップですが、それに加えて Cursor や Zed などの増加を見ると、LSP (ruby-lsp )やAI アシスト機能の質で決まるフェーズに入ったことが、この結果に表れています。 Q4. 業務に導入・活用しているコーディングエージェントは何ですか？ ここは今回のアンケートの中で最も結果が偏った質問でした (複数回答可)。 Claude Code: 約 325 GitHub Copilot (Chat / Autocomplete): 約 85 GitHub Copilot Workspace: 約 55 Codex: 約 25 会社規定により使用不可・使用していない: 約 10 Devin: 約 10 Amazon Q Developer / Cline / Roo Code / Gemini / その他: 各数件 注目すべきは、Claude Code が約 325 名で、回答者全体の 8〜9 割を占めている点です。「Coding Agent を使っているなら、その中に Claude Code が含まれている確率がきわめて高い」という事実が示されており、Ruby 開発者のあいだで Claude Code が事実上の標準採用になっていると言えます。 「会社規定により使用不可・使用していない」が一定数あるのは現実問題として重要なポイントです。コードや顧客データを LLM に送信する経路の整理、ベンダーロックインの懸念、契約上の取り扱いなど、企業として整理すべき論点はまだ多く残っています。こうした「ツールを使えるようにする側」の地道な仕事も含めて、これからの開発組織の競争力に直結する領域だと感じています。 Q5. Coding Agent を使って何を作っていますか？ Coding Agent の用途の分布は以下の通りです (複数回答可)。 業務のプロダクト: 約 320 趣味のソフトウェア: 約 165 業務の間接ツール: 約 160 プロダクトで使っている OSS: 約 50 その他 OSS 全般: 約 35 その他: 約 5 合計票数は約 735 と 1 人あたり平均 2 つの用途で Coding Agent を活用していることが分かります。「業務のプロダクト」が約 320 名で回答者のほぼ全員が業務プロダクトに Coding Agent を導入しているのは予想通りですが、特に注目したいのは「趣味のソフトウェア」と「業務の間接ツール」がそれぞれ 160 名前後と、業務プロダクトの半分の規模で並んでいる点です。私自身、Ruby の周辺ツール (all-ruby) やリリース/パッケージングスクリプトなどのメンテナンスを Claude Code に任せられるようになってから、自分の手で書く量は減ったのに進められる仕事は増えるという状態になっています。 「プロダクトで使っている OSS」(50) と「その他 OSS 全般」(35) を合わせると、85 名前後が OSS の改善にも Coding Agent を活用していると回答しています。重複を考慮しても、回答者の 2 割程度が OSS のメンテナンスに Coding Agent を持ち込んでいる計算で、これは昨年なら考えにくかった結果です。Ruby の OSS エコシステムにとっても、Coding Agent はメンテナの負荷を下げる方向に作用していくはずで、私自身も RubyGems や Bundler のメンテナンスでその効果を実感しています。 Q6. プロジェクトのパッケージ・バージョン管理には何を使用していますか？ Ruby とその関連ツールのバージョン管理の分布は以下の通りです (複数回答可)。 rbenv など Ruby 専用のツール: 約 200 mise / asdf: 約 145 Homebrew (Project local): 約 140 Dev Containers: 約 60 Nix 系のツール (nix / devbox など): 約 5 その他: 約 10 私もメンテナの一人である rbenv 系を選んだ人が依然として最大の勢力ですが、mise / asdf のような汎用バージョンマネージャもそれに迫る規模に育っています。Node.js や Python、Go など複数言語を行き来する開発が当たり前になってきた今、「言語ごとに専用のバージョンマネージャを入れる」アプローチから「一つのツールで全部を管理する」アプローチへの移行が Ruby コミュニティでも確実に進んでおり、rbenv ユーザーの一部が mise への併用・移行を始めている過渡期と読むこともできそうです。 Homebrew (Project local) が mise などと同じ数なのは Docker やリモート開発環境で業務プロジェクトごとの Ruby を実行している人が増え、「ローカルマシン上で複数バージョンを切り替える必要がそもそも無くなった」結果ではないかと推測しています。 Q7. 業務プロジェクトのローカル実行環境はどう構築していますか？ ローカル実行環境の分布は以下の通りです (複数回答可)。 Docker Compose: 約 295 Native (macOS / Linux): 約 65 Lima / Colima: 約 35 OrbStack: 約 30 Kamal (Local Runner): 約 5 Codespaces / Cloud IDE: 約 5 Podman Desktop: 約 5 その他: 約 5 Docker Compose を選んだ人は約 295 名で、回答者の 8 割近くが日常的に Docker Compose を立ち上げている計算になります。Rails アプリケーションの開発では、Web サーバ・データベース・Redis・ジョブキューなどを Docker Compose でまとめて立ち上げるのが事実上の標準形になっているようです。 今回の結果では Lima / Colima が 35、OrbStack が 30 と拮抗しています。Apple Silicon 上での Linux コンテナの動作については、macOS 26 で導入された Apple 公式の container コマンド がどう普及してくるかも個人的には気になっています。Native (macOS / Linux) が 65 と一定数あるのは、Ruby / PostgreSQL / Redis などは macOS や Linux 上でそのまま動かすことができ、コンテナ経由よりもネイティブ実行の方が単純に速いから、というのが推測です。私もこの方法で開発することが多いです。 アンケート結果から見えてくる Ruby コミュニティの現在地 7 つの質問の結果を通して見えてくるのは、Ruby コミュニティが「成熟しつつも、ツーリングの面では非常に動的なフェーズにある」という姿です。 Ruby 4.0 への移行が予想以上に早く進んでいること、エディタは VS Code / Cursor のような AI 連携の強いものに集約されていること、Coding Agent は Claude Code が突出していること、バージョン管理は rbenv 一強から mise / asdf へ
- Ruby
- Docker
- 生成AI
関ケ原Ruby会議01運営インタビュー ── 【後編】RubyKaja、東西の武将、合戦、そして宴へ
2026年5月30日に、関ケ原Ruby会議01が開催されます。SmartHRは本イベントにRubyスポンサーとして協賛しています。 今回は、SmartHRに所属する関ケ原Ruby会議01の実行委員に、イベントの魅力について聞きました。 前編では、開催のきっかけやコンセプト、会場、関ケ原という土地の魅力について紹介しました。後編では、当日の見どころを掘り下げます。トークセッション、RubyKajaの復活、「合戦」や「宴」、関連イベントまで、関ケ原Ruby会議01ならではの企画について聞きました。 regional.rubykaigi.org tech.smarthr.jp 目次 目次 RubyKajaの復活 東軍・西軍に分かれたトークセッション 合戦 宴、前夜祭、イベント 参加登録の状況 関ケ原や岐阜の観光とグルメ 参加者へのメッセージ RubyKajaの復活 ── 関ケ原Ruby会議01では、RubyKajaも実施されますよね。 わいだー：やります。これはかなりやりたかった企画ですね。 おしょうゆ：これは年末ぐらいに持ち上がった企画でしたね。楽しみです。 ── RubyKajaとは何か、あらためて教えてください。 わいだー：RubyKajaは、各地域のRubyコミュニティで活動しているRubyistを、それぞれのコミュニティから推薦して、みんなで褒め称える取り組みです。身近なところでコミュニティを支えている人たちに光を当てる場、というふうに捉えています。もともとは、2012年3月10日に開催されたYokohama.rb #18で、nagachikaさんによって提案されたRubyist Awardsでした。 コンセプトは、「自分の近くの優れたRubyistを皆で褒め称えたい」というものです。遠くのすごい人だけではなく、自分たちの近くで場を支えてくれている人に感謝を伝える。そこに、RubyKajaが大切にしてきた考え方があると思っています。 なっちゃん：わたしも地域のRubyコミュニティにたまに参加するのですが、継続して場をつくってくれている人たちがいるから、ふらっと参加できるんですよね。そういう人たちがいてくれるのは本当にありがたいなと思います。 www.youtube.com ── Kajaはどういう意味ですか？ おしょうゆ：能や狂言の「太郎冠者」から取った言葉らしいです。若手の筆頭、という意味ですね。近くの、新進気鋭のRubyistを称えたい、という願いが詰まった名前です。詳しくは「RubyKajaのご紹介」（Rubyist Magazine）を読んでもらえると。 ── 「近くのRubyistを褒め称える」という考え方が大事なんですね。 わいだー：そうですね。Ruby Prizeのように、Rubyコミュニティにおける顕著な活動実績や功績を称える賞はもちろん大切です。一方で、地域Rubyコミュニティには、もっと日々の営みのような活動があります。 たとえば、毎月、地域.rbの会場を取ってくれる人、毎回来てくれる人、初参加の人に話しかけてくれる人、発表して場を盛り上げてくれる人、イベントの裏側で受付や片付けを支えてくれる人。 そうる：初参加の人に話しかけてくれる人がいるだけで、その場の入りやすさはかなり変わりますよね。 わいだー：そうなんです。そういう活動って、続いているコミュニティの中では当たり前に見えるかもしれません。でも、全然当たり前ではないんですよね。RubyKajaでは、そういう場が続いていくために欠かせない活動にも光を当てたいと思っています。 ── RubyKajaは10年以上ぶりですね。RubyKaja 2026は、どういう位置づけなのでしょうか？ わいだー：RubyKajaは、RubyKaja 2014を最後にしばらく開催されていませんでした。ただ、コロナ禍を経て、今また地域Rubyコミュニティの活動が活発になってきています。地域Ruby会議も各地で開催されるようになってきています。だからこそ、このタイミングでRubyKajaを復活させたいと思いました。 おしょうゆ：新たに地域.rbや地域Ruby会議をオーガナイズする人もたくさん増えてますしね。 わいだー：そうですね。各地で活動しているRubyistがいて、その人たちが日々のコミュニティを支えている。そういう人たちに光を当てて、みんなで「ありがとう」と言える場があるといいなと思っています。 RubyKaja公式サイト ── 関ケ原Ruby会議01でRubyKajaをやることには、どんな意味があると思っていますか？ わいだー：関ケ原Ruby会議01は、岐阜で開催する地域Ruby会議ではありますが、同時に、東西のコミュニティの人たちが集まる場でもあります。東の人も、西の人も、東海の人も、いろんな地域のRubyistが関ケ原に集まる。そういう場でRubyKajaを復活させることに意味があると思っています。各地の「ありがとう」を持ち寄る場にしたいですね。 ── 当日の45分の枠では、何をする予定ですか？ そうる：まず、RubyKajaの趣旨をあらためて紹介したうえで、各地域コミュニティから推薦されたノミネート者を紹介します。そして、ノミネート者の中から選定された5名の方に特別賞として、受賞の証となる品を贈呈します。また、特別賞を受賞された方には、3分程度のプレゼンテーションをしていただく予定です。 ── 参加者には、RubyKajaを通じて何を感じてほしいですか？ わいだー：まずは、ノミネートされた人たちのことを知ってほしいです。「この地域には、こういう人がいるんだ」「このコミュニティは、こういう人に支えられているんだ」と感じてもらえたらうれしいですね。でも、それだけではなくて、自分の近くのRubyistのことも思い浮かべてほしいです。 なっちゃん：参加する人それぞれの中に、「あの人のおかげで続いているな」と思える人が自然と浮かんできそうです。ノミネートされた方を称えるだけでなく、自分の近くにいるRubyistへの感謝にも気づける場になるのが、とてもいいなと思います。 わいだー：ですよね！ RubyKajaは「あの人を褒め称えたい」と思うこと。その理由を言葉にすること。そして、それを読んだ誰かが「自分の近くにも、そういう人がいる」と気づくこと。そこまで含めてRubyKajaなんじゃないかなと思っています。そういう場にしたいと思っています。 Roppongi.rbとOmotesando.rbの合同開催の様子。こうした場も、Rubyコミュニティの日々の営みのひとつ 東軍・西軍に分かれたトークセッション ── セッションについても聞かせてください。 おしょうゆ：今回のタイムテーブルはこんな具合です。 西軍東軍 先鋒 拙者、『型は欲しいが型は書きたくない』者たちとの和睦を結び、るびぃにおける型の領地安堵を実現せんと欲す者也森塚三矢大阪守真年 Sorbetの型がRailsのMVC全てを貫通するまでkazzix14 次鋒 Termfront: Ruby標準ライブラリだけで作るFPS S.H. 気づいたらRubyで100作品 ー クリエイティブコーディングが生活の一部になるまでchobishiba 中堅 New "Type" system on PicoRuby Masataka Pocke Kuwabara Play Music on Ruby ── PicoRubyで作るMIDIオーケストレーションツールToshio Maki 副将 PicoRubyに於けるRefinementsの再解釈 hasumikin Job戦国時代kinoppyd 関ケ原Ruby会議01では、東西のRubyistによる熱い技術トークが繰り広げられます。写真は、RubyKaigi 2026で登壇するわいだーさん ── 先鋒、次鋒、中堅、副将というのは？ おしょうゆ：なにせ関ケ原なので、Rubyコミュニティの中でも議論が分かれそうなテーマを中心にタイムテーブルを組んでみています（笑）。全部の枠が真っ向対決！ というわけではないのですが、似たテーマについて同じRubyで取り組んでも、これだけの世界の違いが生まれるのか！ という驚きがありそうなタイムテーブルになった気はしています。参加者のみなさんも、こういったテーマに対して自分なりの意見を持ってきてもらえると楽しいかもしれません。 ── たとえば、先鋒は型に関するトーク同士なんですね。 なっちゃん：東軍の「Sorbetの型がRailsのMVC全てを貫通するまで」と、西軍の「拙者、『型は欲しいが型は書きたくない』者たちとの和睦を結び、るびぃにおける型の領地安堵を実現せんと欲す者也」は、どちらもRubyと型に関するトークです。ただ、タイトルからして雰囲気がかなり違いますよね。Rails全体に型を通していく話と、「型は欲しいが型は書きたくない」という話で、同じ型の話でもぜんぜん違う角度から楽しめそうです。 ── 次鋒は、Rubyで何かを作る楽しさが見えそうです。 そうる：そうですね。「気づいたらRubyで100作品」と「Ruby標準ライブラリだけで作るFPS」は、どちらもRubyで作ることの楽しさや広がりが感じられそうです。RubyはWebアプリケーションだけではなく、クリエイティブコーディングやゲームのような領域でも使える。そういう懐の深さが見えるカードになりそうです。 ── 中堅はPicoRubyに関するトークが並んでいます。 おしょうゆ：はい。「Play Music on Ruby ── PicoRubyで作るMIDIオーケストレーションツール」と「New "Type" system on PicoRuby」ですね。今年のRubyKaigiでもPicoRubyの話は多かったですが、それとはまた一味違った話かも、と思ってます。音が出るのっていいんですよね。 ── 副将は「Job戦国時代」と「PicoRubyに於けるRefinementsの再解釈」。 わいだー：ここも濃いですね。ジョブシステムやRefinementsのように、Rubyを使っている人の間でも考え方が分かれやすいテーマが並んでいます。聞くだけで終わるというより、会場の中で「自分ならどう考えるか」を持ち帰れるセッションになるのではないかと思っていま
- Ruby
- 地域Ruby会議
Lightning Talks on Hakodate Tram at RubyKaigi 2026 —— 函館市電を1両まるごと貸し切ってLT大会を開催しました！
こんにちは。プロダクト基盤開発本部の@ydahです。 2026年4月22日（水）〜24日（金）に、北海道・函館で RubyKaigi 2026 が開催されました。参加された皆さん、登壇された皆さん、運営の皆さん、本当におつかれさまでした！ SmartHRは RubyKaigi 2026 を盛り上げるべく、本編翌日の4月25日（土）に、少し変わった関連イベントを開催しました。その名も、「Lightning Talks on Hakodate Tram at RubyKaigi 2026」（以下、市電LT）です。LT（Lightning Talks）は1人あたり数分の持ち時間で次々と発表していく、技術コミュニティで親しまれている発表形式です。 smarthr.connpass.com 函館市電1両を貸し切ったLT大会 市電LTは、函館市内を走る路面電車・函館市電を1両まるごと貸し切り、走行中の車内でLTを行うイベントです。 RubyKaigi本編を終えた翌朝、参加者の皆さんには函館市電「駒場車庫前」停留場に集まっていただきました。 今回貸し切りにした函館市電の車両 当日は多くの方にご参加・ご登壇いただきました。ありがとうございました！ 当日の流れ 当日のタイムテーブルは以下の通りです。 時間 内容 9:30〜9:50 受付 9:50〜10:00 主催者挨拶・出発 10:00〜 各停留場間でLT発表 途中 谷地頭停留場付近で小休止 12:00 駒場車庫前にて解散 通常のLT大会では1人5分のように時間で区切ることが多いですが、今回の市電LTでは時間ではなく、2〜3区間を1枠として進行しました。発表の区切りを示すのは、時計ではなく指定の停留場です。 信号や停車時間によって発表時間が少し伸び縮みすることもあり、発表者は車内放送や停留場への到着タイミングを意識しながら話します。通常のLightning Talksでは味わえないライブ感がありました。 車内でLTをするudzuraさん 市電という発表環境の魅力 函館市電の車内には、カンファレンス会場のようなプロジェクターや大きなスクリーンはありません。 そのため、発表スタイルもさまざまでした。大きめの文字で作られたスライドをタブレットで見せる方、紙芝居のように資料をめくりながら話す方、手元のデバイスを見せながら話す方。限られた環境だからこそ、発表者それぞれの工夫が見えるLT大会になりました。こうした工夫が見えるのも、電車の中でLTをする面白さの一つです。 紙資料をめくりながら発表する様子 手元のノートPCのスライドを見せつつ発表する金子さん ※ydahは聞いていないのではなくて、必死で次の停留所の位置をGoogle Mapで調べています 自作ソフトウェア楽器「ぴことん」のデモの様子 突然始まるRubyKaigiクイズもRubyKaigiのイベントならでは 車内は揺れ、外の音が聞こえ、信号待ちもあります。こうした要素を含めて、市電の中でLTをするという体験が成り立っています。 発表はもちろん、車窓から見える景色、車内の揺れ。その全部がイベントの一部になっており、実際に体験してみないとわからない魅力があります。 RubyKaigi Day 4らしいLTの数々 RubyKaigi本編の翌日ということもあり、LTの内容はとてもRubyKaigi Day 4らしいものになりました。 RubyKaigiのセッションをきっかけに試してみたこと、函館での体験、Rubyや周辺技術の話、mrubyから派生した組込み向けRuby処理系であるPicoRubyや登壇にあたって作ったデバイスについての話、まつもとゆきひろ氏が開発するRuby AOTコンパイラSpinelの話、Ruby以外の言語とつないでみた話など、バラエティ豊かなLTが続きました。 RubyKaigiで得た刺激を、まだ熱いうちに聞けるのはとてもよい体験でした。RubyKaigiの余韻を楽しめるLT大会になったと感じています。 函館市電LTの系譜 今回の市電LTは、突然思いついた企画ではありません。技術コミュニティがいつもの会議室やホールを飛び出して、交通機関そのものを会場にしてきた流れの先にあるイベントです。 技術イベントと鉄道の組み合わせという意味では、2013年に都電荒川線を貸し切って、Googleが開発するプログラミング言語Goのハッカソンを行う「電車でGo! 都電荒川線編」という企画がありました。 gocon.connpass.com 「電車でGo! 都電荒川線編」はLT大会ではありませんが、技術コミュニティが貸切電車をイベント会場として使う先行例として、とても印象的な企画です。 今回のイベントに直接つながる電車内LTという文脈で大きな起点になったのは、函館で開催されている技術カンファレンスMariners' Conferenceの「函館市電LT大会」です。 mariconf.connpass.com 函館市電を貸し切り、走行中の車内でLTを行う。単に時間を計るだけでなく、停留場や区間を意識して進行する。 そして、車内の限られた設備を前提に、登壇者がそれぞれ工夫を凝らす。こうした文化は、今の電車LTにも色濃く受け継がれています。 その後、2024年にはYAPC（Yet Another Perl Conference）の函館開催であるYAPC::Hakodate 2024のアフターイベントとして「YAPC函館市電LT」も開催され、函館における電車LTの系譜はさらに広がっていきました。 connpass.com そして、わたし自身がチーフオーガナイザーを務めた関西Ruby会議08では、アフターパーティーとして京都の叡山電車を貸し切った「叡電LT」を開催しました。叡電LTはまさに、函館で開催されてきた市電LTを大いに参考にして企画したものです。 ruby-tuesday.doorkeeper.jp 叡山電車の1両を貸し切り、2〜3区間を1枠として、Rubyistが次々にLTをしていく。 車内放送用マイク、紙資料、iPad、モバイルモニターなどを使いながら進行するLTは、いつものLT会とはまったく違う感覚があり、実際に体験してみないと得られない、とてもよい時間でした。 その体験が本当に素晴らしかったからこそ、RubyKaigi 2026の開催地が函館に決まったとき、「かつて参考にした原点の地で、もう一度やりたい」と強く思いました。 Mariners' ConferenceやYAPCで開催された、函館市電LT。それらを元にして京都で開催した、叡電LT。 そして今回、RubyKaigi 2026 Day 4の函館市電LTとして、ふたたび原点の地・函館へ。 今回の市電LTは、そうした電車LTのバトンを、RubyKaigiで函館に戻すイベントでもありました。 かつて大いに参考にした原点の地に帰り、開催できたことは本当に嬉しく、個人的にも感慨深い時間でした。 参加・登壇いただいた皆さまへ ご参加いただいた皆さん、LT登壇してくださった皆さん、ありがとうございました。 また、開催にあたってご協力いただいた函館市電の皆さま、RubyKaigi 2026の関係者の皆さま、本当にありがとうございました。 RubyKaigi 2026の3日間を終えた翌朝に、函館市電を貸し切ってRubyistがLTをする。 少し変わった企画でしたが、函館という開催地だからこそできた、RubyKaigiの余韻を楽しむ良いDay 4イベントになったと思います。 <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/smarthr/20260521/20260521120019.png" alt="&
- Ruby
- RubyKaigi
EightのエンジニアでRubyKaigi 2026に参加してきました！
こんにちは。名刺アプリ「Eight」でエンジニアをしている鳥山（@pvcresin）です。 4月に函館で行われたRubyKaigi 2026に、Eightのエンジニア数名で参加してきました！ 参加したメンバー 今回は、それぞれの視点から感想や印象に残ったセッションをご紹介します。 目次 鳥山 平石 間瀬 まとめ 鳥山 RubyKaigiへの思い RubyKaigi参加は、沖縄・松山に続き今回で3回目です。Rubyの今後の方向性や最新トレンドを多角的に学びたいと思い、参加しました。特にRubyの型やRailsのView層、WebAssemblyに関心があるため、関連トークを中心に聴いてきました。 気になったセッション Blazing-fast Code Indexing for Smarter Ruby Tools RubyのLSPやドキュメント生成、型チェックツールなどがそれぞれ持つ「コード理解の仕組み」を統一的に扱うために、RubydexというCode Indexerを開発したという話でした。既にRuby LSPやTapioca、Spoomとの統合で高速化やメモリ削減の成果が出ており、パフォーマンスやメンテナンスの観点でとてもよいツールだと思いました。EightでもRuby LSPやSorbetを利用しているため、開発者体験が良くなりそうでうれしいです。 HTML-Aware ERB: The Path to Reactive Rendering HTML用のERBを単なる文字列生成ではなく、構造を持ったテンプレートとして扱うという話でした。その上で、リアクティブなレンダリングや開発支援を提供するReActionViewというツールが紹介されました。ベースとなっているのは同じ作者のHerbというHTML用のERBパーサーで、フォーマッターやリンターの機能も備えている万能なツールなので、以前から注目していました。今回の発表ではReactのような画面の差分更新を実現する仕組みの説明やデモもあり、Rails Viewの新しい開発スタイルを感じさせる内容でワクワクしました。 全体の感想 RubyKaigiに参加して、Rubyのエコシステムがどんどん前進していくのを肌で感じました。個人的には、ここ最近コミットしていたTypeProfという型推論ツールに関するトークで、作者のmameさんに発表の中で褒めていただいたことがとてもうれしかったです。また、海外の開発者ともツールの仕様や今後の動向について議論ができたことに少しだけ自身の成長を感じられました。そのほかの時間も、温泉や桜が満開の五稜郭など、函館を満喫できてよかったです。 タワーから眺めた五稜郭 平石 RubyKaigiへの思い 昨年に続き、今年で3回目の参加でした。RubyKaigiの一番の楽しみは、さまざまなエンジニアの方々と交流できることです。今回は、普段の業務に持ち帰れそうな学びを中心にセッションを聴いてきました。 気になったセッション Back to the roots of date Rubyのdateライブラリは、長らくメンテナンス体制が不安定で、timeライブラリへの統合案も議論されてきました。そんな中で、dateライブラリをPure Rubyで書き換え、持続可能にしていく取り組みについての発表でした。Cで書かれた実装をRubyに置き換えていく過程で、AIの活用についても触れられていました。特に印象に残ったのが、「AIは強力なパートナーではあるが、我々の主ではない。我々は構築したものに対して責任を持ち続けなければいけない」という言葉でした。AIが急速に進化する今、たとえAIが優れたコードを生成できたとしても、それが長期的に保守できるかを判断し、責任を負うのは人間のエンジニアだと改めて感じました。 Matz Keynote 毎年恒例のMatz Keynoteですが、今年はMatzさんがAIをフル活用して、作りたいものを次々に作っているという話が印象的でした。中でもSpinelというRubyのAOTコンパイラの話が中心でした。最近は、どのカンファレンスでも「AI時代のエンジニアの働き方」に関する発表が多い印象があります。そんな中で、Matzさんが本当に楽しそうに作ったものを披露していたのがとても印象的でした。「この人はものづくりが大好きなんだな」と感じると同時に、自分もAIをうまく活用して、作りたいものを形にしていきたいと思いました。 全体の感想 毎年のことですが、今年も改めてRubyコミュニティーの熱量に触れ、大いに刺激を受けた3日間でした。企業ブースや本編後のDrinkupで、各社のエンジニアの方々と意見交換できるのもRubyKaigiの良さだなと改めて思いました。また3日間とも天気に恵まれ、桜や夜景、海鮮など函館も満喫できたのがとても良かったです！ 函館山からの夜景 間瀬 RubyKaigiへの思い 今回が初参加です。普段はインフラ／SRE寄りの領域を軸にしつつ、チームのマネジメントにも関わっています。昨年のKaigi on Railsに続いて、Rubyコミュニティーの熱量を肌で感じたいと思い参加しました。Ruby言語そのもののカンファレンスと聞いていたので、会場の雰囲気やセッションのレベル感を知りたいと思っていました。 気になったセッション The Journey of Box Building Ruby 4.0で導入された実験的機能であるRuby::Boxについて紹介するキーノートでした。仕組みの概要だけでなく、アイデアが形になるまでの経緯もあわせて語られていて、全体像が掴みやすかったです。特に「なぜ今この仕組みが必要なのか／どんな場面で役立ちそうか」といった背景まで触れられていたのが印象に残りました。 Pure Ruby Apache Arrow reader/writer Apache Arrowのreader/writerをPure Rubyで実装する取り組みの発表です。導入のハードルを下げつつ、Rubyでも扱えるデータ入出力の選択肢を増やしていく、という狙いが分かりやすく面白かったです。ちなみに、登壇者のSutouさん目当てで聴いたセッションでもあります。 全体の感想 RubyKaigiはセッション（本編）と、Drinkupなどのコミュニティー活動がセットになっていて、全体として体験の密度が高いイベントだと感じました。学びと交流のバランスがよく、参加して良かったです。 美味しかった塩ラーメン まとめ 桜の咲いている函館、最高でした。 来年は宮崎での開催ということで、今年よりも暖かそうですね。 来年の会場が発表される様子 より深い議論ができるようにこれからもRubyやRailsを追いかけていきたいと思います！ Sansan技術本部ではカジュアル面談を実施しています Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
- Ruby
- Rails
RubyKaigi 2026でたまり場「五稜郭」を実施しました！
こんにちは、SmartHRの新卒2年目プロダクトエンジニアのnoriです。 SmartHRは、RubyKaigi 2026にカスタムスポンサーとして協賛し、3日間にわたってメインアリーナでたまり場「五稜郭」を実施しました。この記事では、その模様を紹介します。 たまり場「五稜郭」を一望 たまり場「五稜郭」は休憩と交流の拠点です たまり場「五稜郭」は、来場者がふらっと立ち寄り、休憩したり、作業したり、近くにいる人と話したりできるハングアウトスペースです。RubyKaigiの会場で一息つきながら、来場者同士が自然に交流できる場所として企画しました。 函館開催にちなんで「五稜郭」と名付け、作業スペースである「たまり場」と、交流のきっかけとなる5つの郭（コーナー）を用意しました。「たまり場」では、テーブルや電源、北海道銘菓をご用意するとともに、Afternoon Breakでは函館らしさのあるお菓子としてイカようかんを配布しました。5つの郭は、SmartHRが作成したイカ釣りゲームをプレイできる「SmartHR郭」、函館ゆかりのスポーツで体を動かす「モルック郭」、5つのイベントを行う「ステージ郭」、制作物を展示できる「Ruby Showcase郭」、プリントシールを撮影できる「プリントシール郭」です。 会期中は、休憩や作業などそれぞれの目的で来場者が集まり、もくもく作業をする人、知り合いと話す人、初めて会った人と会話する人など、立ち寄った人同士のさまざまな交流が生まれていました。 たまり場で参加者が集まっている様子 Matzがイカようかんを切っている様子 SmartHR郭 —— イカ釣りゲーム「IKATSURUBY」をプレイ！ SmartHR郭は、ゲームや増えてくアクキーの配布を通じてSmartHRを知ってもらうきっかけをつくるスペースです。SmartHRのプロダクトエンジニアのNGTが制作したイカ釣りゲーム「IKATSURUBY」の体験コーナーを設け、函館らしいモチーフとRubyKaigiらしい遊びを組み合わせたゲームを多くの方にプレイしていただきました。 イカ釣りゲーム「IKATSURUBY」をプレイしている様子 モルック郭 —— 函館ゆかりのスポーツで体を動かす モルック郭では、来場者が気軽に体を動かせる企画としてモルックを用意しました。函館では2024年にモルックの世界大会が開催されており、開催地ならではの要素を取り入れた企画です。 モルックは短い時間でも参加しやすく、休憩中の気分転換にも向いています。セッションの合間に立ち寄ってくださった方々に楽しんでいただけました。 モルックを楽しむ様子 ステージ郭 —— 休憩のたびに変わる5つの企画 ステージ郭では、3日間の休憩時間に合わせて5つの企画を実施しました。登壇者の裏話を聞けるトークから、Rubyで音を鳴らすデモ、ゲーム大会まで、休憩ごとに違う企画を楽しめる場所でした。 Wednesday Speaker Showdown Day 1のLunch Breakでは、Wednesday Speaker Showdownを開催しました。SmartHRからRubyKaigi 2026に登壇したメンバーに加え、会場にいたスピーカーの方々にも登場いただき、発表の裏話やRubyKaigiならではの話題で盛り上がりました。 Wednesday Speaker Showdownの様子 このコンピュータ書がすごい！RubyKaigi出張版 Day 2のLunch Breakでは、「このコンピュータ書がすごい！RubyKaigi出張版」を実施しました。日本Rubyの会の高橋会長にお越しいただき、会場の本屋さんで手に取れる本を紹介していただきました。 このコンピュータ書がすごい！RubyKaigi出張版の様子 HR Music Arena Day 2のAfternoon Breakでは、HR Music Arenaを実施しました。Rubyで音を鳴らすデモや演奏を行いました。 HR Music Arenaの様子 IKATSURUBY Championship 2026 Day 3のLunch Breakでは、SmartHR郭で提供していたイカ釣りゲーム「IKATSURUBY」の大会「IKATSURUBY Championship 2026」を開催しました。開発者や参加者による対戦が続き、ステージの前には観戦する人の輪ができていました。 IKATSURUBY Championship 2026の様子 チーム対抗八の字巻き選手権 Day 3のAfternoon Breakでは、RubyKaigiのネットワークを支えるNOCチームと、会場の音響を支えるSOUNDCREWによるチーム対抗八の字巻き選手権を開催しました。 八の字巻き選手権の様子 結果はこの通り、SOUNDCREWの勝利となりました！それにしても、SOUNDCREWは早かったです！ 八の字巻き選手権のスコア Ruby Showcase郭 —— 制作物をきっかけに会話が生まれる展示 Ruby Showcase郭では、Rubyで作られたものを展示し、制作者と参加者が話せるスペースを用意しました。セッションでは見せきれなかったデモを紹介したり、展示を見た参加者から質問が出たりと、制作物をきっかけにした会話が生まれていました。 展示は、コードやプロダクトそのものだけでなく、作った人の考えや工夫に触れられる場でもあります。RubyKaigiのようにRubyistが集まる場だからこそ、こうした近い距離でのやり取りが印象的でした。 Ruby Showcase郭で質問や議論が盛り上がっている様子 プリントシール郭 —— 3日間の思い出をシールに残す プリントシール郭では、来場者が自由に撮影できるプリントシール企画を実施しました。RubyKaigiで再会した人、初めて話した人、同じ会社やコミュニティの仲間など、さまざまな組み合わせで撮影していただきました。 会場内のボードには、撮影したプリントシールが少しずつ増えていきました。 プリントシールを貼るボード プリントシール郭では、撮影した画像を会場のスクリーンに表示する試みも行いました。スクリーンに流れることで企画の存在が伝わり、プリントシールを撮りに来てくださる方が増えるきっかけにもなりました。 <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/smarthr/20260520/20260520135956.jpg" alt="プリントシールがスクリーンに表示されている様子" width="1024" height="768" loading="lazy" title="" class=
- Ruby
- イベント
関ケ原Ruby会議01運営インタビュー ── 【前編】Rubyの衆、何ゆえ“天下分け目の地”へ馳せ参ずるや
2026年5月30日に、関ケ原Ruby会議01が開催されます。SmartHRは本イベントにRubyスポンサーとして協賛しています。 今回は、SmartHRに所属する関ケ原Ruby会議01の実行委員に、イベントの見どころや開催への思いについて聞きました。 前後編に分けてお届けします。前編では、開催のきっかけやコンセプト、会場、そして関ケ原という土地の魅力について紹介します。後編では、トークセッション、RubyKajaの復活、「合戦」や「宴」など、当日の見どころを掘り下げます。 regional.rubykaigi.org 目次 目次 自己紹介 関ケ原Ruby会議01はどう始まったのか 天下分け目の地域Ruby会議 武将語 会場 実際に歩いて感じた、関ケ原町の魅力 自己紹介 ── 本日はよろしくお願いします。まずは、自己紹介をお願いします。 おしょうゆ：関ケ原Ruby会議01の「東」の実行委員長のおしょうゆ（osyoyu）です。生まれも育ちもだいたい関東、横浜市歌ならお任せあれ。バッチリ東の気持ちです。2025年の頭に開催した東京Ruby会議12の実行委員長でもありました。SmartHRではDeveloper Productivityの仕事をしています。またの名を北条有友相模守計量大輔。 わいだー：わいだー（ydah）です。「西」の実行委員長をしています。大阪生まれ、大阪育ち、大阪の京橋の地域RubyコミュニティのKyobashi.rbのCo-Founder。ということで圧倒的に西です。大阪Ruby会議04、関西Ruby会議08、関西Ruby会議09の実行委員長をしています。Rubyコミッタ、Lramaコミッタで構文解析に少しだけ気持ちがあります。SmartHRではプロダクト基盤を開発しています。またの名を平髙田河内守構文解析丸雄大。 なっちゃん：実行委員のなっちゃん（pndcat）です。沖縄出身なので西の気持ちもあるのですが、おしょうゆと一緒に東京Ruby会議12をやったので、関ケ原では東寄りの立場です。普段は、SmartHRの労務基本機能を開発しています。またの名を源名渡山武蔵守熊猫猫丸夏子。 そうる：実行委員のそうるです。SNSではex_SOULといった名前をよく使っています。関ケ原町の隣町である垂井町に住んでいます。生まれが九州ということもあり関ケ原Ruby会議では少し西の立場です。SmartHRでは労務基本機能の開発をしています。またの名を橘江崎不破関守魂之丞宗瑠。 わいだー：他には「中」である岐阜の実行委員長のころちゃん（corocn）、関西Ruby会議の実行委員でもあるぱすたけさん（pastak）、そしてデザイナーのあつみさん（attsumi）を加え、7人で準備を進めています。 ── 実行委員の7人中4人がSmartHRのメンバーなのですね。 おしょうゆ：これは完全に偶然で、そもそも関ケ原Ruby会議01をやるぞ！ となったタイミングでは私とわいだーさんはSmartHRにいないどころか、入社を検討すらしていなかったです。 とはいえ、今は4人がSmartHRにいるわけだし、「関ケ原Ruby会議01は何をするのか」「なぜ関ケ原でやるのか」あたりをインタビュー形式で公開できるといいねと思って、SmartHR Tech Blogに掲載する運びとなりました。東京Ruby会議12のときも、なっちゃんがSmartHRにいたので似たことをしてましたね（前編、後編）。 Rubyリリース30周年記念パーティーで撮影した、東西実行委員の対峙ショット。左から、そうるさん、わいだーさん、ころちゃんさん、おしょうゆさん、なっちゃんさん 関ケ原Ruby会議01はどう始まったのか ── 今回の地域Ruby会議を開催しようと思ったきっかけを教えてください。 おしょうゆ：関ケ原Ruby会議01の始まりと言えば、やはり昨年の夏の関西Ruby会議08のオフィシャルパーティーですよね。 わいだー：そうですね。私の認識でも、あそこが始まりやと思っています。オフィシャルパーティーでおしょうゆさんと、「次の東京Ruby会議はやらないんですか？」みたいな話をしたんですよ。 おしょうゆ：そうですね。実のところ、自分がやりたかった会議をやり切れて、わりと燃え尽きていた時期ではありました。いろんな人に「東京13はやらないんですか？」と聞かれても、はっきり「やりません」と言い切るぐらいには次をやるつもりはなかったです。 わいだー：で、オフィシャルパーティーの中で次の東京はやらないとしても、「今年、東で東京Ruby会議12、西で関西Ruby会議08をやったんやから、次は東西戦とかどうですか」みたいな話をしたんです。 おしょうゆ：これは唸りました。そういう対決モノは大好きな性分なので、これはやってみたいな……と。 なっちゃん：わたしもその場にいたのですが、東京13はやらないと言っていたのに、東西戦は興味あると言っているおしょうゆはおもしろいな〜と思っていました（笑）。 わいだー：東西が集まる場所を作るのはやってみたいことの一つとしてあったから、だいぶ気持ちも入っていて、「やろう！」と言った記憶があります。 おしょうゆ：その場にはぷぽさんもいて、熱く背中を押してもらいました。いいじゃん！ やりなよ！ 私は見たいです！ みたいな勢いで（笑）。 懇親会は声を張りすぎてたいへん疲れて、後半はずっと入り口の方にたむろっていたけれど、何かの機運が生まれた瞬間に立ち会いました。機運はなんぼあってもいいですからね！ @ydah_@osyoyu 👀あとは話したかった人と話せたのもよかったです😌 #kanrk08 関わってくださった全ての人に感謝🙏 pic.twitter.com/r18DoUWDFm— ぷぽ (@pupupopo88) 2025年6月29日 ── 開催地や会場もそのときに決まったのですか？ おしょうゆ：実は、最初から関ケ原で開催することが決まっていたわけではなかったんですよね。 わいだー：そうですね。関西と関東で同じ日に別々の会場を用意して、オンライン中継でつなぐような案もありました。 おしょうゆ：「東京」と「関西」の文脈をまるごと汲めるし、それはそれでおもしろそうとは思いつつも、一ヶ所に物理的に集まることのおもしろさも捨てがたく、どう実現したものかかなり迷っていました。オフィシャルパーティーで「やるか！」という気持ちが高まったものの、具体的な構想にはまだつながっていなかったです。 ── 「関ケ原」が出てきたのは、あとの話なんですね。 わいだー：そうそう。翌日、東西戦のことをあらためて考えていたときに、「えっ、東西戦やったら関ケ原では？ 岐阜やん！」と思いつき、気持ちが高まって「真面目な話、関ケ原Ruby会議で東西戦したくない？」というポストをしたところ、ころちゃんが返信をくれたんですよね。 真面目な話でやるならスタッフがんばります。ｗ— ころちゃん (@corocn) June 29, 2025 おしょうゆ：名前としても良いですよね。「関ケ原」ってついてるだけで、急におもしろそうな気がしちゃいますね。 わいだー：そうですね。「東西戦やるなら関ケ原やん」ってなった瞬間に、急に全部が噛み合った感じがありました。岐阜に住まれているころちゃんとそうるさんがいるからこそ、ただ東西戦をやるのではなく、岐阜・関ケ原の土地でやる「地域Ruby会議」になったな、と思っています。 おしょうゆ：関ケ原町にうってつけのホールもあることもわかって。 わいだー：そうですね。ただ、そこからしばらく期間が空いてしまったのですが。本格的に動き出したきっかけは、ころちゃんが実行委員長をしていた昨年9月のながらRuby会議01の開催でしたっけ？ おしょうゆ：でしたね。ながら01に参加したことであらためて気持ちが高まっただけじゃなくて、ビアホールで飲んでたら、関ケ原町で催される東西対決コンテンツのフライヤーに出会ってしまったんです。これを見て、「やはり関ケ原か」と盛り上がってました。ころちゃんに声をかけたのもちょうどこの時でしたね。 ながらRuby会議01にて訪れたビアホールにあった、関ケ原で執り行われる対決コンテンツ。これを見ておしょうゆさんは「は〜 やはり関ケ原か〜」と思ったという ── こうして「東西対決」を実現する3人の実行委員長が揃ったわけですね。 わいだー：はい。そのあと、東西中の他のメンバーも加わって最終的には7人で準備を進めています。 関西Ruby会議08オフィシャルパーティーのころちゃんさん、ぱすたけさん、わいだーさん 天下分け目の地域Ruby会議 ── 関ケ原Ruby会議01はどんな会になりそうですか？ おしょうゆ：関ケ原は地域Ruby会議の中でも一風変わったものになりそうです。「天下分け目の地域Ruby会議」という題目を掲げ、参加者とスピーカー……いや、「武将」を東西に振り分け、関ケ原の合戦さながらに対決が執り行われます。そして、東西それぞれの大将に笹田耕一さんと前田修吾さんをお迎えしました。 ── 大将はどのように選ばれたのでしょう？ わいだー：東西をそれぞれ代表するようなRubyistに大将に就いていただきたいと考え、Rubyリリース30周年記念パーティーの場やオンラインでコミュニティの皆さんに投票してもらいました。おふたりとも実力派のRubyistなので、たくさんの支持があったことは納得です。 note.com <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/smarthr/20260514/20260514153007.jpg" alt="Rubyリリース30周年Š
- Ruby
- 地域Ruby会議
RubyKaigi 2026 に参加しました
はじめに こんにちは、ゲームサービス事業本部開発運営統括部第三技術部サーバーグループ所属の Kawaguchi です。 4/22(水) ~ 4/24(金)に函館で RubyKaigi2026 が開催されました。 DeNA からエンジニア3人と内定者1人の計4人で参加してきました。私自身、今回がRubyKaigiへの初参加でした。この記事ではセッションやブースについて取り上げます。 RubyKaigi とは RubyKaigi とは、毎年開催されている Ruby の国際カンファレンスです。 世界最大規模のRuby開発者の集まりであり、世界中のRubyistが参加するイベントです。
- Ruby
- FFI
- YJIT
- PicoRuby
RubyKaigi 2026 協賛&参加レポート
Developer Engagementブロックの@ikkouです。2026年4月22日から24日の3日間にわたり北海道は函館市の函館サーモン・まるなまアリーナで「RubyKaigi 2026」が開催されました。 日本Rubyの会「RubyKaigi 2026」特別ライトアップ 今回の函館開催にあわせ、通常の白色のみの五稜郭タワーのライトアップが、Rubyをイメージした特別色のレッドにライトアップされていました。 ZOZOは今年もプラチナスポンサーとして協賛し、スポンサーブースを出展しました。 technote.zozo.com 本記事では、前半はWEARのバックエンドエンジニアが気になったセッションを紹介します。後半では、ZOZOの協賛ブースの様子と各社のブースにおけるコーディネートを写真中心に報告します。 ZOZOとWEARとRubyKaigi WEARのバックエンドエンジニアが気になったセッション A Faster FFI そもそもFFIとは？ 現状のFFIの課題 なぜFFIは遅いのか？ 改善1 改善2 FFXの仕組み 最終的なパフォーマンス ruby.wasm can also enable JavaScript to call Ruby libraries. The Less-Told Story of Socket Timeouts なぜopen_timeoutが必要だったのか net/httpのtimeoutライブラリ依存問題 resolv_timeout + connect_timeoutでは代替できない open_timeoutのAPI仕様 試してみる Ruby 3.4: fast_fallback ON Ruby 3.4: fast_fallback OFF Ruby 4.0: open_timeout fast_fallback ON + open_timeout fast_fallback OFF + open_timeout 同時指定はエラー 全体の対比 おわりに Autoresearching Ruby Performance with LLMs Autoresearchとは なぜ「ループ」が重要なのか 4つのループパターン Ralphループ Autoresearchループ Factoryループ Sidekiqでの実証実験 実験の背景 "マージされないコードを生成することの意味" PRレビューとは何か？ 4つのレッスン Lesson 1: 「自動調査」であって「自動変更」ではない Lesson 2: 自分がオーナーで Architect でないものに Autoresearch を適用しない Lesson 3: ループはビター・レッスンを実践する Lesson 4: 人間のゲートをソフトウェアゲートに変換する Software Factory とその課題 まとめ おわりに Exploring RuboCop with MCP The Journey of Box Building Ruby Boxとは何か Ruby Boxの仕組み Ruby Boxが生まれた歴史 おわりに ZOZOブースの紹介 協賛企業ブースのコーディネートまとめ RubyKaigi 2026 アフターイベント〜初参加LT・スポンサー4社のパネル〜を開催します おわりに ZOZOとWEARとRubyKaigi 私たちが運営するファッションコーディネートアプリ「WEAR by ZOZO」のバックエンドはRuby on Railsで開発されています。2013年にVBScriptで構築されたシステムでしたが、2020年頃からコードフリーズし、Rubyへのリプレイスを開始しました。現在もリプレイスを進めながら、新規の機能もRubyで開発しています。また、Matzさんを技術顧問としてお迎えし、毎月Matz MTGと称したオンラインミーティングを実施しています。 ZOZOとRubyKaigiの関係は、ZOZOの前身であるVASILY時代のRubyKaigi 2017に遡ります。コロナ禍を経て再開したRubyKaigi 2022からはWEARのバックエンド開発を担うチームが中心となって協賛とスポンサーブースの出展を続けています。 RubyKaigi2017参加レポート(全日分)とスライドまとめ RubyKaigi2018参加レポート RubyKaigi 2019参加レポート〜sonots登壇セッション & エンジニア8名による厳選セッション RubyKaigi 2022参加レポート 〜エンジニアによるセッション紹介〜 RubyKaigi 2023参加レポート 〜エンジニアによるセッション紹介〜 RubyKaigi 2024 参加レポート RubyKaigi 2025 協賛&参加レポート WEARのバックエンドエンジニアが気になったセッション 今年はWEARチームから6名のバックエンドエンジニアがRubyKaigiに参加しました。本パートでは各エンジニアが特に気になったセッションを個々の視点で紹介します。 A Faster FFI chikaです。私からはAaron Patterson（@tenderlove）氏の「A Faster FFI」を紹介します。 このセッションでは、「RubyはC言語より速くなるか？」という問いからスタートし、具体的にはRubyのFFIを高速化し、ネイティブのC言語（C拡張）よりもRubyを速く実行できるか？ というのがメインの議題でした。 余談ですが、Aaron氏はRubyKaigi 2026の外国人登壇者の中でおそらく唯一日本語でスピーチする方です。流暢な日本語に加えて時折ジョークも交え、大変ユニークなセッションであり毎年楽しみに拝聴しています（最初の挨拶では「外国人みたいな名前ですが、外国人です」と日本語でジョークを言っていて面白かったです）。 そもそもFFIとは？ FFIとはForeign Function Interfaceの略称で、一般的にはRubyのような高水準言語からC言語やRust, Zigなどで書かれた外部の関数を呼び出すための「概念」のことを指します（FFI自体は、あるプログラミング言語から他のプログラミング言語で定義された関数などを利用するための機構）。 Rubyでは主にlibffiというライブラリやfiddle gemを介して利用され、プラットフォームごとの呼び出し規則の違いを吸収してくれます。 例：FFIを使ったhello world #include <stdio.h> void hello(void) { printf("Hello, World from C!\n"); } require 'ffi' module Hello extend FFI::Library ffi_lib File.expand_path('libhello.dylib', __dir__) attach_function :hello
- Ruby
- FFI
- Wasm
- Socket
- パフォーマンス
「ルールルルルルRubyKaigi 2026事前勉強会 —— 初参加でもなまら歓迎！」を開催しました
こんにちは。SmartHRの課金基盤を開発しているプロダクトエンジニアのshimojuです。 2026年4月10日に、「ルールルルルルRubyKaigi 2026事前勉強会 —— 初参加でもなまら歓迎！」を開催しました！ この記事では、イベントの模様と登壇内容についてレポートします。 目次 目次 開催概要 オープニング ルールルルルルRubyの中身の予備知識 ── RubyKaigiの前に予習しなイカ？ Into the Arena ルールルルルル私的函館観光ガイド ── 函館の街はイクラでも楽しめる！ YJITとZJITにはイカなる違いがあるのか？ RubyKaigi参加ルールルルルル策定ガイド ── どんぶり勘定をサケよう！ RubyKaigiを楽しく休む方法 写真撮影 懇親会 おわりに We Are Hiring! 開催概要 このイベントはSmartHRが主催する、RubyKaigi初参加の方の手引きとなる事前勉強会です。会場は六本木のSmartHR Spaceです。 2024年、2025年の事前勉強会が好評だったことを受け、今年も開催する運びとなりました。 今年もたくさんの方からのお申し込みをいただきました。登壇者・参加者のみなさま、ありがとうございました！ smarthr.connpass.com オープニング 司会・進行はSmartHRの16bit_idolさんです。 RubyKaigi 2026の会場は北海道函館市です。北海道といえば、「ルールルルルル……」というあのフレーズで知られる「北の国から」。ということで、SmartHRは「ルールルルルルルビーカイギ」をテーマに、さまざまな企画を行うことを紹介しました。 司会・進行の16bit_idolさん ルールルルルルRubyの中身の予備知識 ── RubyKaigiの前に予習しなイカ？ 最初の発表は、SmartHRのydahさんによる「ルールルルルルRubyの中身の予備知識 ── RubyKaigiの前に予習しなイカ？」でした。 RubyKaigiでは、Rubyの言語実装に関するトークが数多くあります。「Rubyの中身の予備知識」と題して、Rubyが実行されるまでの一連の流れと、RubyにおけるJIT実装（MJIT/YJIT/RJIT/ZJIT）、とくにZJITがどのような課題を解決しようとしているのかを説明していました。 Ruby 4.0の新機能であるRuby::Boxや、JRubyをはじめとするさまざまなRuby実装の紹介もあり、盛りだくさんの発表でした。 発表するydahさん speakerdeck.com Into the Arena 次はゲストの松田明さんによる「Into the Arena」でした。 今年のRubyKaigiは函館アリーナ・函館市民会館の2会場を使って開催される、過去最大規模のRubyKaigiでした。 この会場を選定するに至った経緯や、チーフオーガナイザーとしての思いなど、ここでしか聞けないお話をしていただきました。 ちなみに発表タイトルの「Into the Arena」は、楽曲の名前と今年の会場がアリーナであることをかけた命名で、Puma 8.0.0のコードネームにもなっています。 松田さん、ご登壇いただき本当にありがとうございました！ 発表する松田さん ルールルルルル私的函館観光ガイド ── 函館の街はイクラでも楽しめる！ ここからはLTです。 最初のLTは、SmartHRのnomusonさんによる「ルールルルルル私的函館観光ガイド ── 函館の街はイクラでも楽しめる！」でした。 学生時代に函館に住んでいた経験をもとに、函館の観光名所や飲食店を紹介していました。函館のミスタードーナツが安い（現在は価格高騰により変わっているそうですが）という意外な情報もありました。 発表するnomusonさん speakerdeck.com YJITとZJITにはイカなる違いがあるのか？ 次のLTは、yamanaoさんによる「YJITとZJITにはイカなる違いがあるのか？」でした。 YJITとZJITの違いについて、テスト勉強のたとえを用いて「過去問を入手して対策するのがYJIT」、「試験範囲の教科書を読むのがZJIT」と説明していました。 2つの設計の違いが直感的にわかる発表でした。 発表するyamanaoさん speakerdeck.com RubyKaigi参加ルールルルルル策定ガイド ── どんぶり勘定をサケよう！ 3番目のLTは、SmartHRのsakoさんによる「RubyKaigi参加ルールルルルル策定ガイド ── どんぶり勘定をサケよう！」でした。 社内でRubyKaigi参加予算を策定する立場から、概算費用を算出した上で、どのような基準で参加ルールを作ったかを説明していました。 発表するsakoさん speakerdeck.com RubyKaigiを楽しく休む方法 最後のLTは、三谷昌平さんによる「RubyKaigiを楽しく休む方法」でした。 RubyKaigiの会期中は、Drinkupやワークショップ、さらにはランニングやゴルフなど体を動かすものまで、さまざまなイベントが行われます。 これらのイベントを通してリフレッシュする方法を紹介していました。 発表する三谷さん <iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdocs.google.com%2Fpresentation%2Fd%2F1PXiUWdvHsYoD7WjSnGCmv4l-_MO4vU1mQg8qdOs2jjY%2Fedit%3Fusp%3Dsharing" title="RubyKaigiを楽しく休む方法" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-
- Ruby
- RubyKaigi
RubyKaigi 2026 に登壇しました
こんにちは。株式会社タイミーのバックエンドエンジニアの神山(@dak2)です。 2026/4/22 から 24 まで函館で開催された RubyKaigi 2026 に参加し、Day 2 に登壇しました。 タイミーでは、世界中で開催される技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度を活用し、8名が現地でカンファレンスに参加してきました。 登壇内容や参加セッションで得た学びは各レポートにまとめています。気になった方はご覧いただけると幸いです。読者の皆様の今後の学びの参考になれば嬉しいです。 tech.timee.co.jp tech.timee.co.jp tech.timee.co.jp Road To RubyKaigi 2026 地震や飛行機の遅延などもありましたね。皆様の中にも、移動に戸惑った方いらっしゃったのではないでしょうか。 色々大変でしたが、参加者の方々が無事到着されたのを X（旧Twitter）で見て、一安心したのを覚えています。 印象に残ったセッション A Faster FFI rubykaigi.org 自分が作っている gem で Ruby と Rust を使っており、FFI 周りが気になっていたので聞きました。 FFIは、引数の数の確認や型変換（アンボックス）を実行時に行う必要があるため、C拡張に比べてオーバーヘッドが大きいようです。また、ピュアなRubyで書かれたJITコンパイラのFJITはC拡張より速いものの、CRubyの内部データ構造に強く依存していました。そのため仕様変更に弱く、実用的ではなかったとのことです。 FJIT これですね。fjit.rb · GitHub これに加え、アーロンは hacks gem というものを作っていて、そこから CRuby の 構造体を引っ張ってきて FJIT で使っているみたい。AST をダンプして構造体の名前を元にデータ構造を抽出、メモリのレイアウト情報を計算して Ruby のハッシュに格納して返してるみたいですね。 面白いなー。すごい力技だw FJIT はこのハッシュに依存しているから実用的ではなかったとのこと。 新たな解決策として ffx という gem を作ったみたいです。 Ruby の値を C に変換してネイティブ関数を呼ぶ impl 関数と、実際のコードへジャンプするトランポリン関数を生成。トランポリン関数を生成する際に、アセンブリに impl 関数への jump 命令を書いておき、その次のメモリ領域にマジックマーカーや型情報、パラメータなどのメタデータを書き込んでおく。 通常の実行時には impl 関数へ jump するので、型情報などは読み込まれないけど、ZJIT でのコンパイル時にはマジックマーカーを検知してメタデータを読み取って最適化に使うとのこと。 このハックは単純にすごいなと思いました。感心しながら聞いていたのを覚えています。勉強になります。個人的に印象に残るセッションでした。 Lightning-Fast Method Calls with Ruby 4.1 ZJIT rubykaigi.org speakerdeck.com 行く末が気になる ZJIT ですね。速さは正義ということで、とても期待しています。そこで、このセッションを聞きに行きました。 今の ZJIT はメソッド呼び出し時に全てのパラメータを一度メモリにロードしてしまう課題があるみたいですね。 バックトレースや例外処理、ローカル変数読み込みなどでスタック上に正確なメタデータを残しておく必要があるためとのこと。 これに対し、Lightweight Frames が提案されていました。 メタデータの書き込みを遅延させ、書き込むフィールドを「JIT Return」の1つなど最小限に限定しつつ、メソッドコール時のメモリライトを削減すると。ただ、ローカル変数の処理や例外時の longjmp などをどうにかしていかないといけないみたいですね。帰ってきてから ZJIT の内部を読んでみています。 Matz Keynote なんか Matz が一番楽しそうだったなあと思う Keynote でした。Ruby という言語を作ってなお、まだ作りたいものがある。AI と一緒に作った Spinel を発表している Matz が楽しそうだった。AI Slop とか色々ありますが、作りたいものを作るって最高ですよね。最高にクールでした。非常にインスピレーションを受けた Keynote でした。 matz リツイート 登壇 登壇時の写真 special thanks to @ginkouno rubykaigi.org speakerdeck.com AI 時代の Ruby では、NoMethodError を静的に解析できたら良いのではないか、という内容で登壇しました。登壇は想像していた何倍も得るものがありました。 きっかけは「日常の疑問」だった このトークの種は、普段の業務で感じた引っかかりでした。型アノテーション付きの Ruby とそうでない Ruby を行き来していると、どうしても型チェックの遅さが気になります。一方で、AI Agent のコーディング能力が一気に上がったことで、「そもそも型をちゃんと書いていく ROI ってどうなんだっけ？」という疑問が、頭の片隅から離れませんでした。 この「気になり」を寝かせていたところ、CFP が1週間延長になった当日、サウナで急に像を結びました。よく「サウナで整うと閃く」と言いますが、実際は逆で、普段から問題意識を温めていたからこそ、たまたま緩んだ瞬間に繋がったのかなと思っています。整うどころではなくなり、速攻で帰りました。その後、寝る間も惜しんでアイディアを形にし、CFP を提出したのが懐かしいです。 「型ありの Ruby と型なしの Ruby、両方を日常的に書いている自分だからこそ立てられる問い」だと思えたことが、提出のモチベーションになりました。自分の業務の中の違和感は、思っている以上にトークの種になるんだなと。 gem を作って「持論」を形にした セッション内で発表した Method-Ray という gem は、コアロジックに Rust を用いています。命名は X-Ray から着想を得ていて、個人的にも気に入っています。「こうすればできるのでは」という仮説をもとに設計し、最小限で動くものを形にし、gem として公開しました。僕の持論やスタンスを gem に込めた上で CFP を提出しました。 株式会社mov の @pjocprac さんが型関連のセッション内容をまとめてくださっており、僕の発表内容にも触れてくださっているので、詳細に興味があればぜひご覧ください。 RubyKaigiで型まわりの内容をまとめたブログ書きました！RubyKaigi 2026 型まわり4セッション聴講メモ — AI コーディング時代の Ruby の型#RubyKaigi https://t.co/HZB5PJW7z0— Takeshi Watanabe (@pjocprac) 2026年4月27日 登壇して初めて得られた3つのもの 発表後、いろんな方に声をかけていただきました。「ここの型解析どうしてる？」「なんでそう思ったんですか？」「英語話せるんですか？」などたくさんお声がけいただき嬉しかったです。 自分の盲点を埋めるフィードバック 質問内容を受けて「自分の gem もこう直さないといけないな」と気づきが連鎖的に出てきました。一人だと気づきにくい視点に気づかせてくれるというのは良い機会だなと。 自分のスタンスを認識する 今回はスタンスを取った発表をしたのですが、それに対していろんな意見をもらえました。賛否両論あると思いますし、いろんな意見があると思いますが、同時に自分の立ち位置もはっきりしました。スタンスを取った発表をして良かったなと思っています。 アイデアの昇華 @okuramasafumi さんとは、いわゆる廊下の話で、「テストが十分速ければ AI が PDCA を回しやすくなって、それは型解析の近似になっているのでは」という方向性を議論しました。登壇内容を、登壇の外で次のテーマへと押し進めてもらえる感覚があり、これは登壇したからこそ発生した会話なんだと思うと、良い機会に恵まれたなと嬉しく思いました。 次にやりたいこと 今後は、Method-Ray の解析範囲を広げたいのと、RBS の Rust crate の利便性を高めたいですね。自分の gem で RBS のロードを Rust crate から行いたいなと思っています。また、廊下での会話の流れもあって、高速化にも気持ちが出てきています。登壇を経て、自分の中の「次にやること」のリストが、行く前より大きくなっています。 終わりに 今年の Kaigi も最高でした。運営の方々、本当に素敵な機会をありがとうございました。いろんな方と知り合えましたし、思考を深められました。ぼんやりと次にやりたいことが見えてきました。<a href="https://rubykaigi.o
- Ruby
- Rust
- 静的解析
- JIT