これからの社会を担う世代を対象にした Ruby のプログラミングコンテスト『中高生国際Rubyプログラミングコンテスト2025』に Gold PARTNER として協賛します。
今年度も引き続き、最終審査会に弊社メンバーも参加する予定です。
アジャイルと Ruby が実現するソフトウェア開発は、開発者が「楽しさ」を感じられる開発であり、そこにはきっとビジネス価値がある――私たちはそう信じて行動を続けています。同じように、プログラミングを楽しくする Ruby を通じて実現される、中高生の作品を楽しみにしています！
株式会社永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと共生しながら成長したいエンジニアを絶賛募集しています。
2025年8月の Rails / OSS パッチ会を 8月29日(金)に Discord でオンライン開催します。
この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS について、upstream にパッチを送る会です。
会には Ruby と Rails のコミッターである顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。
開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。
Discord の Rails/OSS パッチ会サーバーへの招待 URL は以下です。
年内に控えている「ながらRuby会議01」「Kaigi on Rails 2025」「RubyWorld Conference 2025」「北陸Ruby会議01」といったカンファレンスに関する話題などあると思います。
これからパッチ会に参加してみたいという方、OSS 開発者間の会話に興味があるので聞いてみたいという方もお気軽にどうぞ。
永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
こんにちは！@maimuです。
アジャイル事業部は普段はフルリモートで仕事をしていますが、1年に1度を目安に事業部全体で集合するイベントとして「アジャイル事業部ギャザリング」を開催しています。 例年は本社がある福井県で開催をしていたのですが、事業部メンバーの勤務地も日本全国に広がりつつあり、集まりやすそうな場所として大阪で開催することになりました。
ギャザリング運営メンバーの一人として私も企画に携わったのですが、準備はなかなか大変だったものの当日はとても楽しい時間を過ごすことができました。簡単ではありますが、どんな取り組みをしたのかをこちらの記事でご紹介します！
今年のアジャイル事業部ギャザリング (以下、ギャザリング) の運営はグループ混合で4名で取り組みました。さらりとグループと書きましたが、アジャイル事業部は Ruby x Agile グループとアジャイルコンサルティンググループに加えて、Scrum Inc. Japan に出向しているメンバーによって構成されています。 ちなみにエンジニアである私は Ruby x Agile グループの所属です。
ギャザリングの企画開始当初は楽しく過ごせる取り組みは何かを考え、電子工作、AIハッカソン、バーベキュー、大阪散策など色々な案を検討していました。しかし、定例を重ねる中で今のアジャイル事業部で私がやっておきたいこととして、「メンバーとその仕事をもっと知りたい」、「所属しているアジャイル事業部についてみんなで考えたい」という気持ちが強くなり、運営チームで相談しながらギャザリングで取り組む内容を決めていきました。
このような気持ちが生まれた背景として、本記事の冒頭にも書いた通りアジャイル事業部は普段はフルリモートで仕事をしていることが挙げられます。フルリモートの場合、プロジェクトが同じだったりカンファレンスの参加時などで頻繁に顔をあわせるメンバーもいれば、関わりが薄くほとんど会ったり話す時間が取れないメンバーもいたりします。 気がつくと、各メンバーがどんな仕事をしているのかやどんな気持ちで働いているのか、これから何をしたいのかなどが分からなくなっていってしまい、みんなが所属しているアジャイル事業部はどんな事業部なんだっけ？というのがぼんやりしてきていました。そこで、このタイミングで一度お互いを知ってアジャイル事業部で働くことを考えてみるのは良い機会になるのではないかと考えました。
運営チームの定例で議論を重ねて最終的に決まったワークショップの内容は、
の2つです。
ワークショップの内容は決まりましたが、いざ言葉にしてみるとちょっと堅い感じもしますね...。そこで、なぜこのワークショップを行うのかを分かりやすく伝える方法としてギャザリング開催スローガンを考えました。
「つながる、わかる、また会いたくなる」
ストレートに想いが伝わるお気に入りのスローガンです。 当日も複数回このスローガンを共有しながら、ワークショップを進めていきました。
初日は夕方から大阪に集合し、アジャイル事業部メンバーで懇親会をしました。
美味しい料理を囲みながら、仕事の困りごとの相談をしたり、Ruby について話したり、コミュニティの話をしたり、最近見たアニメの話をしたり・・・たくさん話して楽しい時間を過ごすことができました。二次会ではカラオケに行ったり、ラーメンを食べに行ったり各々が大阪で過ごす時間を楽しんでいたようです。
2日目はいよいよ企画をしていたワークショップに取り組んでいきます。
前半はスローガンに掲げた「つながる、わかる」の一環として、 Ruby x Agile グループ、アジャイルコンサルティンググループ、Scrum Inc. Japanごとに分かれて、普段どんな取り組みをしているかを共有しあうワークを行いました。
一緒に運営に取り組んだアジャイルコンサルティンググループのメンバーが会話が生まれやすいワークショップの構成を考えてくれました。
グループ単位でチームに分かれて写真のように模造紙に内容をまとめて、メンバー間で共有しました。それぞれのグループの強みや悩みの共有もあり、多岐にわたる会話ができたなと思います。
メンバーの居住エリアのおやつを持ってきてもらい、ワークショップの合間にはおやつ紹介タイムもありました。
色々な場所からメンバーが集まっているため、持ち寄られたおやつもたくさんあり、適宜甘いもの補給をしながらワークショップを進めることができました。
仕事についての共有の次は、メンバー同士の相互理解を深めていく時間をとりました。今回は事前にメンバーに依頼して「偏愛マップ」を用意してもらいました。このワークで面白かったのは偏愛マップで自己紹介をした後に、さらに他己紹介をしたことです。自己紹介を聞いて終わりではなく、他己紹介として別のメンバーに伝えることで、その後の深掘り時間の会話がより盛り上がりました。
ワークショップの後半はいよいよ2つのテーマについて考える時間です。
テーマに沿って意見交換をして発表に向けたアウトプットを作ってもらうことはもちろんワークショップの目的ではあるのですが、それ以上に大切にしたいことがあり、運営からのメッセージを共有してからスタートしました。
今回のワークショップテーマは私から提案しておきながら、当日盛り上がるのかが実は少し不安でした。ただ、なぜこのテーマでワークショップをすることにしたのかはアジャイル事業部についてをみんなで考えることで自分たち自身の現在の姿やこれからやってみたいことを考えたり動き出すきっかけにできるのではないかという想いがあったためです。それをスライドのメッセージに込めてみました。
ワークショップ開始直後は不安もありつつ様子を見ていると各チームで面白いチーム名を考案して一体感が生まれていたり、前半のワークショップのおかげでみんなでワイワイしながら後半に挑むことができていて、大丈夫だなと安心したりしていました。
写真のように各チームで会話した内容を模造紙にまとめて共有したのですが、アジャイル事業部の代名詞や理想の働き方としてメンバーが考えていることの共通点を知れたり、新たな視点を得ることができました。以下はその例です。
前半後半ともにワークショップが終わった後はギャザリングのふりかえりをチーム毎に行いました。
Fun Done Learn というフレームワークを使って、ギャザリング全体をふりかえると楽しかったことや集まれてよかったこと、今回をきっかけにやってみたいことなどを気持ちが熱いうちにみんなで共有することができて締めくくりに最適でした。
普段はグループ単位で仕事に取り組んでいて、さらにそこからプロジェクトに細分化されて働いているアジャイル事業部ですが、今回大阪に集合してグループの垣根を越えて一緒に準備やワークショップに取り組んだことで、メンバーの理解とその延長にあるアジャイル事業部自体についてを楽しく真剣に考えることができました。
課題ももちろんありますが、メンバーみんながアジャイル事業部を大好きなことも再認識でき、もっと色々やっていき！な気持ちが高まっています。
今後も今回のような事業部としての取り組みをブログを通じてご紹介できたらと思います。
永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
2025年7月の Rails / OSS パッチ会を 7月25日(金)に Discord でオンライン開催します。
この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS について、upstream にパッチを送る会です。
会には Ruby と Rails のコミッターである顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。
開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。
Discord の Rails/OSS パッチ会サーバーへの招待 URL は以下です。
先月開催された「関西Ruby会議08」や、今後に控えている「ながらRuby会議01」や「Kaigi on Rails 2025」といったカンファレンスに関する話題などあると思います。
これからパッチ会に参加してみたいという方、OSS 開発者間の会話に興味があるので聞いてみたいという方もお気軽にどうぞ。
永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
2025年9月6日(土) に開催される ながらRuby会議01 に永和システムマネジメントから @haruguchi-yuma と @koic の2人が登壇します。
ここでは、それぞれの登壇者から講演内容について軽く紹介をします。
@haruguchi です。今回『Ruby Mini Language 〜ハンズオンで学ぶインタプリタの世界〜』というタイトルで発表します。
2025年のRubyKaigiが終わった後、パーサーやコンパイラの話がわかるようになりたいと強く思うようになりました。「小さいインタプリタづくりなら自分でもできるのでは？」という思いから、普段参加しているテーマ別モブプロ勉強会でインタプリタを作ることにしました。
どういう順番で作るか、そもそもどうやって実装すれば良いのか？を調べながら、FizzBuzzプログラムを書くことを目標に10のSTEPに分けてハンズオン形式にまとめました。実際に手を動かして実装したことで、知識ではなく体験として「自分で考えた文法を実装に落とし込む面白さと難しさ」を語ることができると思います。
私自身、低レイヤのバックグラウンドがなく初心者でした。だからこそ、同じようにRubyKaigiなどで処理系の話を聞いて「難しいけど、わかるようになりたい」と思った方の後押しになるような講演ができると考えています。どうぞお楽しみに。
@koic です。今回は『365日のOSS開発を続ける舞台裏』というタイトルで日々の OSS 活動に基づいた話をします。
私は 2015 年から Write Code Every Day の習慣化をはじめて、今年でちょうど10年になります。 John Resig のようなストイックなルールで行っているわけではないですが、10年継続していることでそれなりに溜まっている知見を今回お届けします。
取り上げる内容は、Ruby エコシステムへのパッチの元となるイシューの管理から、送り方とコミュニケーション、またその開発環境の自分なりの工夫など取り上げることになります。
OSS 開発としては RuboCop コミッターとしてのコントリビューションが圧倒的に多いため、そこでの知見がベースラインにあるもの、ある程度 Ruby エコシステム全般に適用できる考え方についてもピックアップする予定です。GitHub リポジトリで見えることは「成果」をベースとしたものですが、そこに至るまでの舞台裏の話として楽しんでもらえるよう準備中です。
また、OSS は現場のお仕事プロジェクトと地繋がりであることから、そこからのフィードバックへのきっかけや足場づくりについても取り上げる予定です。お楽しみに。
ながらRuby会議01は、2025年7月18日(金) 12:00 より参加受付されるようです。
それでは岐阜県の長良川うかいミュージアムの会場でお会いしましょう。
永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。
こんにちは、wai-doiです。
今回は、開発中の Rails アプリケーションで bin/rails generate model を実行した際に ActiveRecord::PendingMigrationError が発生したため、その原因と対処法を調べました。
そのアプリケーションでは、テーブルとモデルを追加するために bin/rails generate model コマンドを実行すると、ActiveRecord::PendingMigrationError のエラーが出ていました。
以下はそのときのエラーメッセージの抜粋です。
# bin/rails g model foo
invoke active_record
create db/migrate/20250703164951_create_foos.rb
create app/models/foo.rb
invoke rspec
Failure/Error: ActiveRecord::Migration.maintain_test_schema!
ActiveRecord::PendingMigrationError:
Migrations are pending. To resolve this issue, run:
bin/rails db:migrate
You have 1 pending migration:
db/migrate/20250630023046_create_foos.rb
エラーは spec/rails_helper.rb 内の次の行で発生していました。
ActiveRecord::Migration.maintain_test_schema!
ここでは未実行のマイグレーションがあれば ActiveRecord::PendingMigrationError が発生します。
ここでエラーが発生することにより、処理が終了してしまうため、以降の model spec のファイルが自動的に作成されません。
これまでの経験上、他の Rails アプリケーションでこのエラーは出ていなかったので不思議に思いました。
そもそもなぜ bin/rails generate model コマンドを実行すると、 rails_helper.rb が読み込まれるかを調べました。
Gemfile に rspec-rails を追加していました。そのため、bin/rails generate model コマンドを実行すると model spec のファイルを生成してくれます。
調査するために、新しい別のアプリケーションを用意して、同じように rspec-rails を入れた構成にしました。こちらの方では、上記のエラーは発生しませんでした。
どこが異なっているかをよく確認すると、.rspec ファイルが異なっていることがわかりました。
rspec-rails で rails generate rspec:install を実行すると生成される .rspec は以下のようになっています。
--require spec_helper
しかし、今回のアプリケーションの .rspec は以下のように rails_helper.rb を読み込むように書き変えられていました。
--require rails_helper
これによって bin/rails generate model コマンドを実行すると、rails_helper.rb が読み込まれていました。
次に、rails_helper.rb の違いを確認してみました。
すると新しく生成した rails_helper.rb の場合は、以下のようなコメントが記述されていました。
# Uncomment the line below in case you have `--require rails_helper` in the `.rspec` file # that will avoid rails generators crashing because migrations haven't been run yet # return unless Rails.env.test?
これは、.rspec に --require rails_helper を記述する場合は、rails_helper.rb 内で return unless Rails.env.test? をコメントアウトして有効にするようにと書かれています。
このコメントは rspec-rails の このPR で追加されています。
この変更が入ったのが rspec-rails のバージョン7.0 なので、それ以前に rails_helper.rb を生成していると記述されていないものでした。
エラーが発生していた rails_helper.rb の今回問題になっている箇所を、最新の rails_helper.rb が生成されたときの内容に合わせ、return unless Rails.env.test? をコメントアウトしました。
return unless Rails.env.test?
これによりテスト環境以外で ActiveRecord::Migration.maintain_test_schema! が実行されなくなり、エラーが発生しなくなりました。
今回の問題は、最新の rails_helper.rb の内容に更新できていれば、早い段階で原因に気づき、防ぐことができました。そのため、rspec-rails のバージョンを上げたタイミングで、 rails generate rspec:install を実行し、生成されたrails_helper.rb などの設定ファイルと既存の設定ファイルを比較し、必要な差分を取り込んでおくのが良いと思いました。
本記事では、bin/rails generate model コマンドを実行すると、rails_helper.rb の ActiveRecord::Migration.maintain_test_schema! で PendingMigrationError が発生していたため、それを解決しました。
今回のように、rspec-rails のような設定ファイルを生成する gem をバージョンアップした場合、生成したファイルの内容が変わる可能性があります。そのため、以前に生成したファイルも必要に応じて新しい内容を取り込むのが重要だと思いました。
2025年7月18日(金) から 19日(土) にかけて開催される Scrum Fest Osaka 2025 に永和システムマネジメントから@koic が登壇します。
2025年7月19日(土) に登壇するスケジュールとタイトルは以下です。
今回は、マーチン・ファウラーの Bliki の翻訳サイトである Bliki (ja) を扱ったお話です。
日本のアジャイル黎明期における、マーチン・ファウラーと Bliki (ja) の歴史から始まり、組織での Bliki (ja) のユーザー活用事例として、現代の AI 社会を加味した読書会を題材に話します。さらに 『伽藍とバザール』を背景に、Bliki (ja) プロジェクトへの参加と舞台裏まで取りあげます。
アジャイルソフトウェア開発について20年以上に渡って記されてきた Bliki とその翻訳プロジェクトについて取り上げる、ちょっと変わり種 (?) のとてもいい話をします。
現地チケットはすでに売り切れとなっておりますが、オンラインチケットは販売中です。お時間のあう方はぜひ遊びに来てください。
株式会社永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと共生しながら成長したいエンジニアを絶賛募集しています。
