はじめに
こんにちは、ギフティでエンジニアをしている shimizu です。法人向け eギフトサービス giftee for Business のプロダクト開発をしています。
2026年8月5日（水）に開催された Ruby エコシステム開発入門ワークショップに参加してきました。
OSS 開発経験の浅い僕でも、この日だけで factory_bot に PR を2本出すことができました。ワークショップ開催中に PR がマージされた人もいました。
当日の雰囲気と共に、自分の中で「OSS にコントリビュートするということ」の解像度がどう上がったのかご紹介します。
Ruby エコシステム開発入門ワークショップとは
Ruby エコシステム開発入門ワークショップは Ruby アソシエーションさんが主催する、「Ruby エコシステムの開発に参加する」を実際に体験できるワークショップです。
特徴的なのは、ただの勉強会ではなく、その日のうちに手を動かして、実際に OSS 開発に参加するところまでを体験できる点です。
参加者のロールは明確に分かれており、「ビギナー」と、それを支える経験者の「サポーター」が共に一日を過ごす形式です。「いつか OSS にコントリビュートしてみたい」という人にも「少しやったことはあるけれど自信がない」という人にも間口が開かれています。
今回は弊社が会場を提供し、総勢20名以上の方に参加いただきました。お越しいただいた皆様、ありがとうございました。
会場提供の背景については、以下の記事もあわせてご覧ください。 tech.giftee.co.jp
動かして、気づきを整理して報告する
ワークショップの流れは比較的シンプルな構成です。
「OSS をユーザとして実際に動かし、気づいた点を整理し、開発元に報告する。」
以下、僕がこの流れをどう辿ったのかをご紹介します。
対象プロダクトを決める
最初にやるのは、対象プロダクトを決めることです。Ruby 本体や普段自分が使っている gem などから選びます。
僕は factory_bot を選びました。テストデータをシンプルに組み立てられるライブラリで、テストコードを書く際にお世話になっている gem です。
選ぶ時点では「有名な gem に手を出して大丈夫だろうか」という気持ちがありました。でもワークショップでは「難易度は気にしなくていい、サポーターがサポートするから」という心強いメッセージに背中を押していただきました。
作業メモを書きながら進める
対象プロダクトが決まったら、いよいよ手を動かします。ここでワークショップの中核となるルールが出てきます。
「なにかする毎に作業メモを書く。」
コマンドを打ったら書く。エラーが出たら書く。ドキュメントを読んだら書く。 ワークショップ用のリポジトリの issue に書き残していく形で進めました。
この作業メモが後半で効いてきます。作業メモに書いた内容は、サポーターへの情報共有に使ったり、開発元に報告する際の貴重な情報源になったりします。
気づいたのは「セットアップの詰まり」
セットアップ時に、2つの「詰まり」に出会いました。
factory_bot を clone して bin/setup を実行し、開発用のコンソールを bin/console で立ち上げようとした最初の一歩で、いきなり止まりました。
$ bin/console bin/console:12: warning: irb used to be loaded from the standard library, but is not part of the default gems since Ruby 4.0.0. You can add irb to your Gemfile or gemspec to fix this error. .../bundled_gems.rb:60:in 'Kernel.require': cannot load such file -- irb (LoadError)
原因は、Ruby 4.0.0 から irb が default gems から外れたこと。bin/console は irb を require しているので、gemspec で宣言されていないと開発用コンソールが起動しないという状態でした。手元が Ruby 4.0.5 という比較的新しい環境だったからこそ踏んだ問題でした。
もう一つは、テストを流したときです。テストは通るのですが、出力に RSpec の deprecation warning が1件混ざっていました。
The implicit block expectation syntax is deprecated, you should pass a block rather than an argument to `expect` to use the provided block expectation matcher or the matcher must implement `supports_value_expectations?`. e.g `expect { value }.to raise FactoryBot::AssociationDefinitionError with "Unexpected block passed to 'author' association in 'user' factory"`not `expect(value).to raise FactoryBot::AssociationDefinitionError with "Unexpected block passed to 'author' association in 'user' factory"`
ブロック期待値を渡すべき箇所に Proc を渡している、という警告です。同じファイルの中に正しい書き方をしている箇所が既にあり、そこだけ書き方が揃っていませんでした。
どちらも、機能そのものの不具合ではないです。「動かそうとしたら動かなかった」「動かしたら警告が出た」という、素朴な気づきです。
整理して、編集して、報告する
気づいたことをそのままにはせず、開発元に報告します。ワークショップで教わる報告の仕方は以下の3ステップです。
- 整理する：自分が読んで理解できる文章にまとめる
- 編集する：相手が読んでわかるように書き直す
- 報告する：issue や PR として投げる
ベースにあるのは「自分が理解できていないことは開発者にも伝えられない」という考え方です。そして「整理する」と「編集する」が別のステップとして分かれているのがポイントです。
自分のためのメモと、相手に届ける文章は別物。これは普段の仕事と同じことですね。
最終的に、2本の PR を出しました。
作業メモが報告文になる
一日を通して特に腹に落ちたのは、報告する際の文章を編集するときの原則です。
「報告の内容は省略しない。」
理由はシンプルで、「相手は私を知らない。省略すると想像しないといけない。その想像はだいたい外れる。」ということ。自分の環境も、実行したコマンドも、期待していた結果も、相手は何ひとつ知らない。省略された部分は、レビュアーが推測で埋めるしかないし、無駄なコミュニケーションが発生します。
省略せずに書くのは例えば以下です。
- 実行したコマンドと、その実行結果
- 期待していた結果
- やったこと、やっていないこと
そして、ここで作業メモが活きます。実行したコマンドも、そのときの出力も、期待していた結果も、すべて手元のログに残っています。
実際に僕が出した PR の本文には、コマンド実行結果の Before / After の出力をそのまま貼りました。コマンド実行結果を後から思い出したり、ターミナルの履歴を追うのは手間です。小まめに書いていた作業メモが、そのまま報告文の材料になりました。
報告のハードルは「書く力」だと思っていました。書く作業は AI に任せれば良いので、大事なのはもっと手前にある「ありのままを記録していたかどうか」だと感じました。
初心者もコントリビュートできる
今回のワークショップは、初心者に優しく、初心者だからこそ易しいです。
支えてくれる仕組みがある
セットアップで詰まっていたとき、サポーターの方は一緒にドキュメントを読んでアドバイスをくれました。作業メモから、OSS にコントリビュートするための種を拾ってくれました。それでいて、最後に手を動かすのは常に自分。「体験を奪わない適度なサポート」でした。
このワークショップが終わった後でも、ruby-jp という Ruby プログラマー同士の交流を目的とした Slack ワークスペースでサポートいただけるみたいです。なんと手厚いことか...。
失敗への恐れについても、繰り返し説明がありました。「新規開発者は基本的に Welcome である。リジェクトは失敗として認識されない。」この前提が共有されているだけで、手を動かす心理的なコストは大きく変わります。 今回出した2本の PR に関しても、仮にリジェクトされても、無視されても、僕の気持ちは折れないです（実際にリジェクトされたら少し落ち込むと思いますが 笑）。
むしろ、詳しくない人にしか見つけられない
この日の意外な学びは、「セットアップの段階こそ、改善余地の宝庫」という点です。
理由を聞いて納得しました。その OSS に慣れている開発者は、開発環境がすでに手元にあるのでセットアップをしない。だから、セットアップ手順が壊れていても気づきにくい。
僕が見つけた bin/console の問題は、まさにそれでした。その日初めて clone した人間で、かつ Ruby 4.0 系を使っていたから踏んだ問題。詳しいから見つけられたのではなく、知らないから、そして初めて通ったから見つけられた問題でした。
そのプロダクトに詳しくないと貢献できない、とどこかで思い込んでいました。実際は違っており、詳しくない人の視点でしか通らない道があり、そこにしか落ちていないものがあります。
そしてそのセットアップの段階を改善することで、「その OSS 開発の新規参入のハードルが下がり、より OSS が活発になる」という好循環が生まれるわけです。
OSS と生成 AI
OSS と生成 AI の扱いについても説明の時間がありました。自分の中でも整理がついていなかった部分なので、印象に残っています。
前提としてあるのは、「生成 AI の受け入れ方は gem ごとに違う」ということ。
その上で、共通する注意点として挙げられたのが以下です。
- 生成された報告は冗長になりがちで、無用な冗長さはレビュアーを疲弊させる
- 報告する前に、報告者自身がレビューする。開発者に聞かれたら自分で答えられる状態にしておく
- ライセンスの確認も含め、生成物の責任は PR の作成者が持つ
- コミットメッセージに
Generated-Byを残すなど、生成 AI を使ったことを明示する
これらを貫いていたのが「自分も開発チームの1人」という考え方です。
作成者が理解していないものを投げれば、レビュアーの時間を奪うだけで、知識の共有も進まないです。ツールが変わっても、OSS 開発が人と人のやりとりであることは、今なお変わらないということです。
なぜ、OSS にコントリビュートするのか
僕が今回のワークショップに参加した目的のひとつは、 OSS 開発のモチベーションを探るためでした。
OSS 開発のモチベーションは人それぞれです。「その OSS が好き」「技術的に成長できる」「社会貢献感がある」など、金銭以外にも様々なやりがいがあると思います。
今回のワークショップを通じて、自分の中で腑に落ちる考え方が2つ見つかりました。
元を直す方がコスパが良い
振り返りの時間に出た参加者の意見の中で、特に印象に残ったものがあります。
「元を直す方がコスパが良い。」
ギフティのプロダクトは、Ruby エコシステムの上で動いています。もし見つけた問題を自分たちのコードの中だけで回避していたら、直るのはギフティの中だけです。
同じ gem を使っている世界中の他のプロダクトは、同じところで同じように詰まり続けます。元を直せば、その解決が同じ gem を使っている全員に届く。
暫定の回避策を講じるより、元を直した方がコスパが良いのは、自分の中で腑に落ちました。
使っているスキルは、すでに手元にある
もうひとつ気づいたのは、OSS へのコントリビュートに必要なスキルは、実は特別なものではないということです。
自分たちが開発しているシステムでも、環境構築で詰まった点を README にフィードバックすることがあります。今回 factory_bot でやったこと（詰まりに気づき、整理し、報告する）は、この構造とまったく同じでした。対象が社内のリポジトリか OSS かという違いしかありません。
OSS へのコントリビュートを、業務とは別に新しく身につける活動だとどこかで捉えていました。実際には、「普段の仕事で使っているスキルを、対象を変えて使っただけ」です。
だからこそ、次に何かに気づいたときも、わざわざ気合いを入れずに、業務の延長のような感覚で手を動かせると思います。
おわりに
弊社にはエンジニアバリューのひとつとして「知見を贈り合う」という考え方があります。ギフトの会社として、技術コミュニティへギフト（知見）を返したいという想いから設定されたバリューです。
一日を終えて思うのは、贈り合いはもっと小さな単位から始められるということ。今回僕が贈ったのは、たった数行の変更です。それでも、それは確かに次に来る誰かへのギフトになり得ます。そうして生まれたつながりが、より良い社会のきっかけになっていきます。そう考えると、あの数行にもちゃんと意味があるのだと思えます。
ハードルは、想像していたよりずっと低いところにありました。「いつかコントリビュートしたい」でもなく、「手元だけで暫定回避する」でもなく、情報を整理して開発元に報告する。それが、この一日で手に入った一番の変化です。
このような機会を作ってくださった Ruby アソシエーションさん、株式会社クリアコードの須藤さんに、心よりお礼申し上げます。そして、一日サポートしてくださったサポーターの皆様、ありがとうございました。
ギフティでは、OSS 開発のような「社会とのつながり」と向き合うソフトウェア開発に興味のある仲間を大募集しています。興味のある方は、ぜひカジュアル面談からお気軽にお声がけください！
