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
- マイクロサービス
「ルールルルルル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
勤怠管理の開発チームに飛び込んでみた —— 入社半年のふりかえり
こんにちは！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
- モジュラーモノリス
- システム設計
第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
- コミュニティ
関ケ原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
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事前勉強会 —— 初参加でもなまら歓迎！」を開催しました
こんにちは。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参加レポート —— 2026年新卒エンジニアが体験したセッション・ブース・市電LT
こんにちは！SmartHRに2026年新卒として入社し、プロダクトエンジニアをしている@itojumです！ 先日、函館で開催されたRubyKaigi 2026に参加してきました。 RubyKaigiは2回目の参加でしたが、SmartHRの一員としては初参加で、新鮮な気持ちでした！セッションや社内外のRubyistとの交流など、参加して得た経験をご紹介します。 会場でピース 印象に残ったセッション RubyKaigi 2026では、特に2つのセッションが印象に残りました。 The Journey of Box Building @tagomoris 初日のキーノートであるtagomorisさんの「The Journey of Box Building」では、Ruby 4.0に実験的に導入された機能「Ruby Box」の基本機能や実装、開発のエピソードなどを発表していました。 このセッションで特に印象に残ったのは、Ruby Box開発のきっかけでした。RubyKaigi 2023 Day 2のセッション「Multiverse Ruby」に刺激を受けてRuby Boxの開発が始まったという話は、聞いていてワクワクしました。 自分にとっての「Multiverse Ruby」に出会えるかもしれないとワクワクさせてくれたこのセッションは、RubyKaigi 2026の最初のキーノートとしてこれ以上ない最高なセッションでした。 Funicular: A Browser App Framework Powered by PicoRuby.WASM @hasumikin hasumikinさんの「Funicular: A Browser App Framework Powered by PicoRuby.WASM」では、PicoRuby.WASM上で動作するWebアプリケーションフレームワーク「Funicular」について発表されていました。 初心者向けにPicoRuby.WASMの基本情報から丁寧に説明されていたので、発表内容をスムーズに理解できました！ このセッションで特に衝撃だったのはbinding.irbが動作していたことです。これができるとPicoRuby.WASMでのフロントエンド開発時のデバッグがしやすくなるので、ぜひ試したいと思いました。 初めてのブース運営 SmartHRは、今年のRubyKaigiでたまり場「五稜郭」というスペースを提供していました。スペースで提供していたIKATSURUBY（Rubyで作られたイカを釣り上げるゲーム）は大人気で、多くの方に来ていただきました。 私にとって初めての企業側としてのカンファレンス参加で、新鮮な経験でした。 大盛況だったIKATSURUBY 4月1日入社でのRubyKaigi参加ということもあり、あまり企画に携われなかったので、来年は企画から参加してRubyKaigiを盛り上げていきたいです！ 函館市電LTでの登壇 Day 4にSmartHRで開催した「Lightning Talks on Hakodate Tram at RubyKaigi 2026」に、LT登壇枠で参加してきました！ RubyKaigi 2026に参加することで受けた影響を各々の形で発表していて、私自身もセッションで気になった技術を試してみたいという気持ちになりました！ 私のLTではVRChat.rbというコミュニティのオーガーナイザーを始めたという内容で発表しました。VRChat.rbのコミュニティにちなんで、VR機器であるMeta Quest3で資料を見ながら発表しました！ 函館市電LTで発表している様子 おわりに RubyKaigi 2026は、新しい技術へのワクワクとRubyコミュニティの熱量を直接感じられた、充実した時間でした！ この刺激を糧に、日々のインプットやアウトプット、開発に励んでいきます！ 函館公園の桜が満開で綺麗だった！ We Are Hiring! SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！ RubyKaigiを始めとしたカンファレンスや勉強会に行きやすい環境も整っているので、ここまで読んでいただいたあなたに超おすすめです！ まずはカジュアル面談にぜひ！ hello-world.smarthr.co.jp 新卒採用もやっております！興味のある学生の方はこちらをどうぞ！！ recruit.smarthr.co.jp
- Ruby