こんにちは。@junk0612 です。
9/5(土)にオンラインとオンサイトのハイブリッド開催される XP 祭り 2026 に、オンラインで登壇します。
『Tidy First?』を読んだとき、最初に感じた感想は「なんかこう、すごくよかったなあ」だったのですが、もう少し言語化を頑張ってみると、もっとも心を動かされたのは「コードとは、プログラマのシステムに対する理解を実行可能な形でテキストにしたものである」という考え方でした。この部分をとっかかりに、Kent Beck が述べたかったことや自分が感じ取れたことなどを交えてお話しする予定です。
参加登録はこちらからどうぞ。
なお、弊社からはほかに @amapyon さん、@iepyon さん、@freedomcat さんも登壇予定です。いずれも現地登壇でキャンセル待ちになっているようなのですが、ぜひお楽しみに。
現地参加、ワークショップは、以下から参加登録いただけます。
2026年9月の Rails / OSS パッチ会を 9月3日(木)に Discord でオンライン開催します。
この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS について、upstream にパッチを送る会です。
会には Ruby と Rails のコミッターで、RubyKaigi のチーフオーガナイザーでもある顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。
開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。
Discord の Rails/OSS パッチ会サーバーへの招待 URL は以下です。
直近で開催の、各種 Ruby カンファレンスの話題などあると思います。
これからパッチ会に参加してみたいという方、OSS 開発者間の会話に興味があるので聞いてみたいという方もお気軽にどうぞ。
永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
こんにちは。@junk0612 です。
いま社内で「永和道場」という取り組みを始めています。ジュニアエンジニアの基礎を鍛えるための、日々の稽古の場です。
始めたばかりでまだ手探りですが、始めるにあたって考えていたことは社外の人にも共有する価値があるかもしれないので、書いてみます。
AI がコーディングを代替するようになって、今までにない新たな問題 (や実はそうでもない問題) がさまざまに脚光を浴びるようになりました。個々の問題に対する解決策は数多ありますが、それらを身近な問題に当てはめたり、安定的に運用していったりするには、エンジニアの足腰とでもいうべき基礎知識が必要です。
2026年現在のエンジニア界隈において身につけるべき知識には2種類あると個人的には考えていて、ひとつは出てきたものを受け入れるか判断するために必要なプログラミングの原理原則、もうひとつはまだ AI がまだ苦手としている要件定義や設計などです。
ひとつめはわかりやすいと思いますが、ふたつめのほうが、今はもっと差が出るところかもしれません。AI はコードは書いてくれますが、業務をどのように表現するか、その概念にどんな名前をつけるか、実装案を比較してどれを選ぶかといった部分は、こちらが決めて渡さないといけません。曖昧な要求を構造に落とす仕事は、まだ人間の担当です。
今のジュニアエンジニアがこれから仕事をしていくために、その土台になる基礎を鍛えてあるときっと役立つと思って始めたのが永和道場です。
いまは「RDBMS 基礎」として、3人の門下生と稽古をしています。
最初の題材に RDBMS を選んだのは、SQL が Web+DB を主戦場にする我々にとって生命線であること、実装だけでなく設計分野にも学ぶ範囲がまたがること、クエリからコードを考えられるようになってほしいこと、などの理由からです。
現在はミックさんの『SQL緊急救命室』を教科書に、主に僕が講義をするスタイルでやっています。本を読むだけでは人間がやる意味がないので、過去の現場で見聞きした内容を織り交ぜながら話をしています。
現時点では社内の取り組みですが、同じような課題感を持っている人は社外にもいるのではないかと思っています。AI で開発が速くなった一方で、若手にどう基礎を積んでもらうか悩んでいるという話はよく見かけますし、現代ではいかにもありそうです。
もし「うちの若手も参加させてみたい」「自分の基礎を固め直したい」という興味のある方がいたら、気軽に声をかけていただけると嬉しいです。イベントなどで僕を見かけた際は直接お声がけいただいてもいいですし、事業部HPのお問い合わせからでも大丈夫です。
今のところは社外からの参加を受け付ける専用の窓口はまだなく、進め方も含めて手探りの段階です。なので、まずは「こんなことを考えている」というお話から、ぜひ課題感を共有させてください。
題材は RDBMS 以外にも広げていきたいので、「こういう道場があったら参加したい」という意見もぜひいただけると幸いです。
2026年8月の Rails / OSS パッチ会を 8月7日(金)に Discord でオンライン開催します。
この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS について、upstream にパッチを送る会です。
会には Ruby と Rails のコミッターで、RubyKaigi のチーフオーガナイザーでもある顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。
開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。
Discord の Rails/OSS パッチ会サーバーへの招待 URL は以下です。
直近で開催の、各種 Ruby カンファレンスの話題などあると思います。
これからパッチ会に参加してみたいという方、OSS 開発者間の会話に興味があるので聞いてみたいという方もお気軽にどうぞ。
永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
こんにちは、wai-doi です。 本記事では、Rails Console で Gemfile に書かれていない gem を使いたくなったときの困りごとの共有と、その解決方法をご紹介します。
Rails Console で Active Record のコードを書くことがよくあります。 そのとき、チームで共有する Gemfile に書くほどではないけれど、自分だけは使いたい gem が出てきました。
pp_sql はログに出力される SQL を整形して見やすく表示してくれる gem です。
GitHub - kvokka/pp_sql: Rails ActiveRecord SQL queries log beautifier · GitHub
この gem を Rails Console で使いたいと考えました。しかし、Rails Console は Bundler を使用しているため通常は Gemfile 内にある gem しか利用できません。
本記事では簡単な例として、tapp という gem を使えるようにすることを目指します。
GitHub - esminc/tapp: tap { pp self } · GitHub
実際に require すると以下のような LoadError が発生します。
$ bin/rails c Loading development environment (Rails 8.1.3) >> require 'tapp' (rails-sample-app):1:in '<main>': cannot load such file -- tapp (LoadError)
そのため、Gemfile に書かれていない gem を Rails Console で使えるようにしてみました。
Rails 内で呼び出す require は以下のような順番で再定義されています。
CRuby の Kernel#require ↓ RubyGems の Kernel#require ↓ Bootsnap の Kernel#require ↓ Zeitwerk の Kernel#require
Zeitwerk は autoload のため、Bootsnap はライブラリのパスをハッシュに持つことで最適化するために、それぞれ require を再定義しています。このうち、Gemfile にない gem を require できるかに関わってくるのは RubyGems の require です。
ただし Rails では、この RubyGems による gem の探索が Bundler によって無効化されています。詳しくは後述します。
例えば、gem install tapp している状態で、通常の Ruby で require をすると成功します。
$ ruby -e 'p require "tapp"' true
通常の Ruby では RubyGems の Kernel#require が呼び出されます。以下のような実装になっています。
rubygems/lib/rubygems/core_ext/kernel_require.rb at v4.0.10 · ruby/rubygems · GitHub
def require(path) return gem_original_require(path) unless Gem.discover_gems_on_require # 省略 begin gem_original_require(path) # まず普通に $LOAD_PATH から探す rescue LoadError => load_error # 見つからなかったら if load_error.path == path && RUBYGEMS_ACTIVATION_MONITOR.synchronize { Gem.try_activate(path) } return gem_original_require(path) # activate 後にリトライ end raise load_error end end
まず最初に discover_gems_on_require を判定します。false であれば元の require を呼び出して activate は行われません。
true の場合は、まず元の require を試し、$LOAD_PATH から見つからず LoadError になったときに、インストール済みの gem の中から探して activate ($LOAD_PATH に追加) し、あらためて require します。そのため require が成功するようになっています。
こちらが元の require のリファレンス。
Kernel?.require (Ruby 4.0 リファレンスマニュアル)
こちらが RubyGems で拡張された require のリファレンス。
Kernel#require (Ruby 4.0 リファレンスマニュアル)
Rails では config/boot.rb 中で require "bundler/setup" が呼ばれると、Bundler を使う準備が行われます。
その準備の中で、discover_gems_on_require が false に切り替わり、利用する gem が Gemfile の gem だけに固定されるようになるため、上記の $LOAD_PATH の追加が行われなくなっています。
これは Rails に限った話ではなく、bundle exec 経由で Ruby を実行した場合も同様です。
以上のことから、Rails でも自分で $LOAD_PATH へ gem のパスを追加すれば、Gemfile にない gem を require できるということがわかります。
方針として、自分のローカル環境だけに影響するよう、~/.irbrc にやりたいことを実現するコードを書くことにしました。~/.irbrc に書くことで、どの Rails プロジェクトでも共通して利用できます。
以下が今回 ~/.irbrc に書いたコードです。
# ~/.irbrc module GlobalGemLoader module_function def require!(gem_name, require_path = gem_name) add_load_paths(gem_name) require require_path end def add_load_paths(gem_name) spec = find_spec(gem_name) raise LoadError, "#{gem_name} gem is not installed" unless spec lib_path = File.join(spec.full_gem_path, "lib") return if $LOAD_PATH.include?(lib_path) $LOAD_PATH.unshift(lib_path) spec.runtime_dependencies.each { |dep| add_load_paths(dep.name) } end def find_spec(gem_name) spec = Gem::Specification.find_all_by_name(gem_name).max_by(&:version) return spec if spec Gem::Specification.dirs .flat_map { |dir| Dir.glob(File.join(dir, "#{gem_name}-*.gemspec")) } .map { |path| Gem::Specification.load(path) } .select { |s| s.name == gem_name } .max_by(&:version) end private_class_method :add_load_paths, :find_spec end
処理の流れは以下のようになっています。
require! を呼び出すlib ディレクトリのパスを $LOAD_PATH に追加lib ディレクトリのパスを $LOAD_PATH に追加find_spec メソッドは、require したい gem の gemspec オブジェクトを返すメソッドです。Gem::Specification.find_all_by_name で探しますが、Bundler は利用できる gem を Gemfile の中だけに固定するため、Gemfile にない gem はここでは見つかりません。その場合は、インストールした gem の gemspec ファイルが集められている specifications ディレクトリを探します。
add_load_paths メソッドは、find_spec で見つかった gem の lib ディレクトリを $LOAD_PATH へ追加していきます。
依存 gem がある場合はそれらも再帰的に find_spec して $LOAD_PATH へ追加しています。
使い方は GlobalGemLoader.require! 'tapp' を実行するだけです。
$ bin/rails c Loading development environment (Rails 8.1.3) >> GlobalGemLoader.require! 'tapp' => true
これを ~/.irbrc に書いておくと Rails Console を起動するだけで自動的に使えるようになるので便利です。
Gemfile に書かれていない gem を Rails Console で使えるようにするため、GlobalGemLoader.require! を実装して使ってみました。
今回の調査で何気なく使っていた require が再定義されていたり、require がどういうときに成功し、どういうときに失敗するのかなど、深いところまで知ることができたのが良かったです。
株式会社永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
はじめまして。2026年7月に中途入社しました Ryoと申します。 入社エントリとして、これまでの経緯と入社して感じたことを書いてみます。ご一読いただけると幸いです。
1990年生まれの福岡県民です。新卒で入社した会社では、建設業の施工管理部・営業部を経験しています。 キャリアチェンジのきっかけは、業務でExcelのマクロを扱う機会があり、そこでプログラミングの楽しさを知ったことです。この経験から、本格的に勉強しようと決意しました。
初めはJavaのオンラインプログラミングスクールで学習を始めました。しかし、すべての課題をクリアしても実務をこなせる自信は全く持てませんでした。その後、紆余曲折を経てフィヨルドブートキャンプに入会しました。
仕事と育児をこなしながらの学習だったため卒業までに3年弱かかりましたが、無事キャリアチェンジを果たしました。
入社前は、フルリモートでコミュニケーションを取るのは難しいのではないか、と不安に思っていましたが、その心配はすぐに解消されました。
マネージャーとの1on1や、勉強会・読書会が頻繁に開催されており、入社してすぐこんなにカレンダーが埋まるのか、と驚いたほどです。技術的な話はもちろんですが、ざっくばらんにお話しする機会もあり、すごく居心地が良いと感じています。
また、OSSやデータベースなどに深い知識を持つメンバーが活発に意見交換を交わしています。自分はまだ議論について行けない部分もありますが、そのやり取りを聞くだけでも学びが多く、毎日いい刺激をもらっています。
「和」を重んじる会社だからこそ、リモートだと感じさせない環境が実現しているのだと実感しました。
コミュニティへの支援が手厚いと感じています。
入社してすぐ、Kaigi on Railsのプロポーザルに挑戦する機会をいただきました。内容や文章構成のブラッシュアップまでミーティング形式で相談させてもらい、入念にレビューしていただけました。入社1ヶ月の自分にここまで時間を使ってもらえるのかと驚きました。
また、地域Ruby会議を含めコミュニティや勉強会にも積極的に参加することが可能です。参加費や交通費などの補助もあります。おかげで、以前は自費で参加をためらっていた遠方の勉強会にも足を運べるようになりました。
これは事業部長の「Rubyで食べさせてもらっているので、コミュニティを盛り上げたい」という想いが、組織に浸透している表れだと思います。
入社して僅かですが、技術への熱量が高い人が多く、早く一人前になりたい、と思う気持ちが高まっています。
勉強会に参加する中で、まだまだ知識が不足していると感じているため、特にコンピュータサイエンスやデータベース(SQL)の知識を深めていきたいと考えています。 まずは業務と並行して、「基本情報技術者」の資格取得を目指し、その後データベースに関しても知識を深めていき、より専門的な資格にも挑戦していきたいです。
最後までお読みいただきありがとうございます。 これからよろしくお願いいたします!
株式会社永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
2026年7月18日(土) に大津市伝統芸能会館で開催される関西Ruby会議09に、永和システムマネジメントから haruguchi が関西LT保安協会 (とは？) に登壇します。
ここでは、登壇者から LT 内容について軽く紹介をします。
「滋賀県観光保安協会だより」をお届けします。全国から滋賀へお越しになるRubyistの皆さまの安全と観光満足度を守るため、当協会が琵琶湖のほとりから選りすぐりの滋賀情報をRubyとともにご案内する5分間です。旅のしおり代わりにぜひご覧ください。協会一同、湖畔でお待ちしております。
LT の時間は 16:30 から 17:20 です。
また、永和システムマネジメントは Gold Sponsor として協賛しており、当日は koic と ham-cap も参加予定です。
それでは滋賀県の大津市伝統芸能会館でお会いしましょう。
永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
