こんにちは。プロダクトエンジニアの@ymtdzzzです。2025年5月に社内版OSS Gate、「OSSミートアップチャレンジ」を開催しました。その結果、会の中で7本のPull Requestが作成され、すべてがマージされました。
この記事では、OSS貢献を促進するために構築したIssue収集の仕組みと、イベント当日の様子をご紹介します。
「OSSミートアップチャレンジ」とは
「OSSミートアップチャレンジ」は、「OSSやっていきの集い」が企画・開催した「OSS貢献の"入り口"をサポートする」社内イベントです（オンライン開催）。コンセプトからもわかる通り、OSS Gateから着想を得たイベントになります。
本家OSS Gateでは、OSS活動を始めたい人を「ビギナー」、OSS活動の経験があって他の人にある程度教えられる人を「サポーター」として役割を当て、ワークショップを行います。ワークショップではサポーターがビギナーを支援し、OSSへのフィードバックやパッチ送付をどう行えばいいかを一緒に学んでいきます。社内でもOSS Gateをアレンジしたイベントが開催されることがありました。
また「OSSやっていきの集い」は、社内のOSS貢献を後押しするための活動です。経緯や活動内容について知りたい方は下記の記事をご覧ください。
今回は対象者やコンセプトはOSS Gateを踏襲しつつも、以下のような要素を盛り込むことでより短時間でPull Request作成まで経験できるようなイベントを企画してみました。なお、時間を短めにしているのは開発業務の合間にも参加しやすくする意図もあります。
- 業務に関係するOSSを対象とする
- 予め目星を付けておいたIssueに取り組む
- 開催時間は1時間半とする
当日はOSS経験のある「メンター」と、OSS貢献にチャレンジしたい「ビギナー」が一人ずつペアになり、以下のような流れで作業を進めます。
- リポジトリのContributing Guideの確認
- Issueの読み込み、再現確認
- コード修正とPull Request作成
とはいえ、これを聞いた多くの方が、
「具体的にどうやって取り組むIssueを見つければいいの？」
「限られた時間で本当にPull Requestまで出せるの？」
といった疑問を抱くかもしれません。ここからは、そうした疑問に対するヒントとなるような、私たちが実際に行った取り組みをご紹介します。
「貢献できそうなIssueがない」問題を解決するための仕組み
OSS貢献を社内で推進する上での課題のひとつが、「興味はあるが、ちょうど良いIssueが見つからない」という点でした。 詳細なヒアリングを行ったわけではありませんが、エンジニアの多くはOSS貢献に対して前向きな姿勢を持っているものの、「良さそうなIssueがあれば挑戦したい」という声が多く聞かれました。そのことから、Issue探しのハードルが貢献への最大のボトルネックになっているという印象を持ちました。
そこで、貢献できそうなIssueを自動的に集めてくれる仕組みをGitHub Actionsを利用して構築しました。
これは、yaml形式でリポジトリとラベルを指定しておくことで、任意のタイミングで条件に合致するIssueを収集し、Markdown形式でコミットしてくれるActionです。
repositories: OpenTelemetry: - https://github.com/open-telemetry/opentelemetry-ruby - https://github.com/open-telemetry/opentelemetry-ruby-contrib Gem: - https://github.com/lostisland/faraday - https://github.com/fog/fog-google labels: - "help wanted" - "good first issue" # Issueに関する情報（タイトルや概要など）をコメントとして付与するためのフラグ # 主にLLMに読み込ませるために有効化することを想定している include_metadata: true
例えばこのような設定ファイルを用いて日次実行のWorkflowを組むことで、記載した4リポジトリでhelp wantedやgood first issueといったラベルが付与されたIssueをまとめてリストにしてくれます。
OSSミートアップチャレンジを開催するにあたり、プロダクトで利用しているGemとnpmパッケージのIssueが日々溜まっていくような仕組みを作ることで、業務で利用しているOSSプロダクトのIssueが勝手に集まってくる場所ができました。
LLMを活用した取り組みやすいIssueの選定プロセス
Issueのストックはできましたが、ラベルのみで機械的に抽出したIssueはノイズも多く、この中から人力で絞り込んでいくのは中々大変です。そのため、より取り組みやすそうなIssueを絞るためにLLMの力を借りることにしました。
先ほどの設定ファイルでinclude_metadata: trueにしたことで、抽出結果に次のようなtitleやbodyといったメタ情報が含まれるようになっています。
{ "title": "flowtype \"declare var module\" causes transform-flow-strip-types to transpile module to _module", "body": "Choose one: is this a bug report or feature request?\r\n**bug report**\r\n\r\n\u003c!--- Provide a general summary of the issue in the title above --\u003e\r\n\r\nWhen using flowtype's \r\n```js\r\ndeclare var module\r\n```\r\nin a file which uses module.exports, transform-flow-strip-types produces\r\n```js\r\n_module.exports\r\n```\r\ninstead of \r\n```js\r\n ...
これらの情報をLLMに渡して初心者向けのIssueを選ばせてみました（GPT-4.5 Deep Research）。LLMにIssueの選定を依頼する際のプロンプトは以下のように設計しました。
あなたは普段業務で利用しているライブラリに対してOSS貢献を推進するやっていきメンバーの一人です。OSS貢献経験が少ない人向けにおすすめのIssueをリストアップする役割です。 記載されているIssueリストから貢献しやすそうなIssueを探してください。基本的な条件としては以下の通りですが、他に良さそうな条件があったら適宜判断してください。
- 誰もアサインされていない
- 対応内容が明確で、追加の議論が必要なさそう
- 誰かが「やりたいです」と表明してから１，２ヶ月以上更新がなく、Pull Requestも紐付いていない
- ドキュメント修正やリファクタ、軽微な修正などインパクトがあまり大きくない
これらの条件を元に調べてもらいますが、記載の内容だけで判断できない場合、URLを辿って確認するようにしてください。また、リストはテーブル形式で出力し、選定理由と、対応する場合の想定タスクも記載してください。
リストアップの優先度としては対応が簡単なもの優先で、あまりに古いもの（数年前など）は優先度を下げてください。
Issueリストの注意事項は以下の通りです：
- 重複が含まれているため、重複は除外してください
- テーブルの下にjsonでmeta情報が含まれるため、そこからIssueの概要を確認できます。しかし、それだけで判断できない場合URLを確認してください
30件以上抽出してください。
こうして選ばれたIssue群をスプレッドシートに転記したものがこちらです（一部抜粋）。
メンターによるIssue選定
LLMを活用したことで、対応候補となるIssueの絞り込みは大きく効率化され、実際にそのまま着手・Pull Request作成までつながったものもありました。
一方で、抽出されたIssueの中には一見「対応できそう」に見えても、詳しく確認すると議論が必要だったり、ToBeの状態が曖昧だったりと、すぐには対応が難しいケースも見受けられました。そのため、メンターがあらかじめ「おすすめIssue」を選定し、参加者に提案する形を取りました。
最終的にいくつかおすすめをピックアップしつつ、参加者（ビギナー）の皆さんにも希望を入れてもらいました。
「OSSコントリビュート虎の巻」の作成
Issue選定と並行して、当日の作業をスムーズに進めるための「OSSコントリビュート虎の巻」を作成しました。この虎の巻には、リポジトリのContributing Guide（貢献者向けのドキュメント）の確認方法からPull Requestの作成方法、コミュニケーション時の例文まで、OSSコントリビュートの一連の流れを初心者でも迷わず進められるよう詳細なステップを記載しています。
当日の模様
最終的に、メンターを除く10名の方々にご参加いただきました。初めての開催だったため各回2~4名程に分割しての開催となりました。
ビギナーとメンターの皆さんそれぞれ時間を忘れるほど熱中し、OSSプロダクトのIssueに向き合っていました。私はRuboCopのドキュメントや既存ルールのenhancement（機能強化）に関連したIssueを選んだ参加者のメンターを担当しましたが、熱中しすぎてあっという間に時間が過ぎてしまいました。
開催結果
当日は時間の都合上draft（下書き）のPull Request作成までとしたケースもありましたが、参加者の皆さんがイベント後も自発的にレビュアーとのやりとりやフィードバック対応を進めてくださり、最終的に下記の7件のPull Requestがマージされました！
- newrelic/newrelic-ruby-agent
- rubocop/rubocop
- igorkasyanchuk/active_storage_validations
- ruby/reline
- ruby/prism
RuboCopなど、日頃の業務で活用しているOSSに貢献できたのは非常に意義深い成果でした。
開催後のアンケートの回答では次のような感想が寄せられました。
- 興味はありつつOSSへの心理的ハードルが高かったのですが、ミートアップチャレンジを通してハードルが下がった
- 普段からIssueリストがオープンになっていると、気軽にチャレンジできそうだなと思いました！
- めっちゃ楽しかったです！
OSS貢献へのハードルが下がっただけでなく、多くの参加者が「ただただ楽しかった」と感じてくれたことが何よりも嬉しい成果でした。
改善点
一方で、いくつか課題も明らかになりました。
メンターの負荷
LLMによるIssue選定は一定の成果があったものの、その中からさらにIssueを絞り込み、当日に向けて予習もしておく必要があったため全体的にメンターへの負荷が高かったです。また、Issue選定については開催日より前すぎると当日既にクローズされているケースがあり、良いIssueに取り組めなくなってしまう可能性から、メンターにとって心理的な負担も大きかった印象です。
今後はIssue自動選定の精度向上や、Issue選定方法の変更など改善していければと思います。
リポジトリやIssueの複雑さによって作業時間が大きく不足する
時間がかなり限られていたため、中にはdraft Pull Requestの作成までいかないケースもありました。特にStylelintのように大規模かつ貢献者向けドキュメントが充実しているリポジトリでは、前提として把握しておくべきルールや手順が多く、ドキュメントの読み込みとIssueの内容確認だけで時間が終わってしまう参加者もいました。
これもIssue選定の精度向上によって解決できる部分がありますが、代替案として時間枠の拡張も検討しています。例えば1時間半ではなく3時間程度の時間を確保し、前半をリポジトリの理解とIssue調査、後半をコーディングとPull Request作成に充てるなど、より余裕を持った時間配分も効果的かもしれません。
We Are Hiring!
SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！
OSS活動にも積極的に取り組んでいる環境で、技術的な挑戦をしたい方はぜひカジュアル面談でざっくばらんにお話ししましょう！
