Techouse Developers Blog

テックハウス開発者ブログ|マルチプロダクト型スタートアップ|エンジニアによる技術情報を発信|SaaS、求人プラットフォーム、DX推進

OSS Gate ワークショップ 2024

ogp

はじめに

こんにちは、Techouseに2023年に新卒入社し、ジョブハウスでバックエンドエンジニアをしているozachunです。

Techouseでは、エンジニアとしてより高みを目指すための刺激を与えることを目的に、新卒向けの研修を実施しております。本記事では、その一環として2024年4月に開催した『OSS Gate ワークショップ』について紹介させていただきます。

OSS Gate ワークショップは、OSS Gateが主催する、OSS開発に参加する「入り口」を提供するワークショップで、株式会社クリアコード様を講師としてお招きしました。

当日は、「OSSとは?」「なぜOSS開発のワークショップを行うのか?」といった座学から、どうやってOSSにIssueやPull Requestを提出すれば良いのかなど具体的な手順まで丁寧にご指導いただきました。

OSS Gate ワークショップの流れ

当日のワークショップは、以下の流れで進行しました。

  1. ワークショップの説明
  2. コミットしたいOSSを選び、改善点がないか探す
  3. 改善点を見つけたら、IssueやPull Request(Merge Request)を作る
  4. ワークショップの振り返り

ワークショップの説明

ワークショップの様子

今回のワークショップでは、まず、気になるソフトフェアがOSI Approved Licensesに登録されているLicenseを使用しているかを確認し、その後、そのソフトフェアに対して、何かしらのIssueやPull Request(Merge Request)を提出することを目標としました。

私は、OSS開発未経験で、「いきなりOSSに貢献できることなんてあるのか?」「OSSは、スーパーエンジニアが作った完璧なもので自分が参加する余地はない」と、OSS開発は別世界のように感じていました。

ただ、講師の方からは、OSS開発者はユーザーからのバグ報告や機能追加の提案を歓迎していること、そして、開発者は忙しい場面も多いので、フィードバックとともに自分にできることがあれば何か手伝います!と伝えると、OSS開発者側から具体的な作業を依頼される場合もあると教えていただきました。

コミットしたいOSSを選び、改善点がないか探す

私は、当日のワークショップで下記のように進めました。

  1. OSSを選択する
    業務や個人開発で使用しているOSSを選びました。特に、大規模なプロジェクトや有名なプロジェクトは、すでに多くの人が関わっており、すぐに見付かる改善が必要な点は改善済みであることが多いため、小規模プロジェクトや個人のプロジェクトの方が改善点を見つけやすいと感じました。
  2. 選択したOSSのLicenseがOSI Approved Licensesに登録されているかを確認する
  3. 選択したOSSのREADMEや公式のドキュメントを読む
    READMEや公式ドキュメントを参照しながら、ローカルで環境構築の手順を実行し、詰まるところはないかを確認しました。
  4. 改善点がないか探す
    先入観を持たずに、ドキュメントを読み進め改善点を探しました。

ここで重要なポイントとして、自分の知識やQiitaなどの情報で補完せずに、公式ドキュメントだけを読み、手順を通りに動作することを確認することが大切です。

普段は、公式ドキュメント以外の情報で補完して深追いせずに次のタスクに移ることも多いと思いますが、もし公式ドキュメントだけの手順で詰まるところがあれば、それはOSSのコミットチャンスです!

実際私は、業務の中で、Sidekiq-Cronで日時指定する機会があり、Sidekiq-Cronの文字解析に使用しているFugitというOSSのドキュメントを読み実装を行ったがうまく動作しなかったという経験がありました。

当時の私は、ここでOSSコミットチャンスと思わずに別の方法でこの問題を対処しました。しかし、ワークショップで当時を振り返ると、OSSに関わるチャンスを逃していることに気づき、Fugitを選択しました。

また、当日のワークショップでは、自分が行ったアクションに対して作業ログをとりながら進めました。
具体的には下記のような作業ログを取りました。私が作成した作業ログはこちら

作業ログ1:Sidekiq-Cronで日時指定したいという要件が過去あったので、調査してみる
作業ログ2:まずは、SidekiqのREADMEを見てみる
作業ログ3:Sidekiq-Cronの文字解析にはFugitというOSSが使われているようだ (リンクはこれ)
作業ログ4:FugitのREADMEを読み進める
作業ログ5:・・・

かなり細かい単位で記載しているのがわかるかと思いますが、この作業ログを取ることで、自分がどこまで調査したのか、どこで詰まったのかが明確で、講師の方からもフィードバックをもらいやすかったです。

また、最終的に提出するIssueやPull Requestを作成する時も、自分が行った作業ログを振り返ることで、自分が見つけた問題に対して調査できた範囲はどこで、逆にどこが調査できていないのかを明確にすることができました。

改善点を見つけたら、IssueやPull Request(Merge Request)を作る

FugitのREADMEを読み進める中で、Sidekiqは最新バージョンをサポートしています。という趣旨のことが書かれており、これが原因で自分が業務の中で私のバージョンではうまく実行できないのではないかと思いました。

そのため、最新のバージョンと記載するよりは、利用可能な具体的なバージョンを記載した方が良いのではないか?という方向性でIssueを提出することにしました。

当日はまず日本語でIssueを作成し、メンターの方に添削、問題なければ英語でIssueを作成し、改めてメンターに確認をもらってから、こちらのIssueを提出しました。

提出したIssue github.com

他の参加者の方々も、業務で使っているOSSに対してIssueやPull Requestを提出していたので併せて紹介します。

mechanizeのリンク切れの修正提案とgimeiの一部機能の改修 (izumitomoさん)

ワークショップ当日は、mechanizeのREADME内のドキュメントのリンクが切れていたことを見つけてIssueを提出したとのことでした。
私が後日この話を聞いたとき、単純なミスが含まれたまま公開されることがあるんだなと思うのと同時に、OSSは完璧なものではなく、みんなで改善していくものなんだなと改めて実感しました。

さらに、izumitomoさんは、追加で何かしらコードの修正を行うために、業務でテストデータを作成するために使用している、gimeiというOSSのドキュメントの調査を始めました。
(gimeiは、日本人の名前や、住所をランダムに返すライブラリー。fakerにはない名前のふりがなにも対応しています。)

izumitomoさん曰く、「gimeiのREADMEは日本語で書かれており、取り掛かりやすかった」とのこと、READMEや公式ドキュメントを読み込み、改善できる点を探したようです。

その調査過程で、一部の機能が使えない不具合があることを発見しました。その問題を修正するPull Requestを作成し、Mergeされました。その結果、gimeiのバージョンのアップデートに繋がったようです!

github.com

test-profの日本語のドキュメント提供 (nodematerialさん)

nodematerialさんのチームでは、業務でRSpecの実行速度を改善するために、test-profというOSSを使用しています。そのOSSの中で何か改善点はないかということで、test-profのドキュメントや公式サイトの調査を行ったようです。

ワークショップ当日は、日本語のドキュメントが存在しないことに疑問を感じ、GitHubのDiscussionsでOSSの開発者へ直接相談するとともに、「もし自分に手伝えることがあれば、日本語ドキュメントの作成も手伝います。」と依頼したとのこと。

後日、開発者から日本語ドキュメントを作成してほしいとのことから、日本語ドキュメントを作成し、こちらのPull Requestを提出し、Mergeされました。

github.com

nodematerialさんが作成したtest-profの日本語ドキュメントはこちらから見ることができます。

さらに、後日談として、RubyKaigi 2024のスピーカーとして参加した開発者(Vladimir Dementyev さん)と直接お会いし、写真と開発者執筆の本に直筆のサインをもらったとのこと!!

nodematerialさんがもらったサイン

2人とも、OSS開発は初参加ということでしたが、Pull RequestがMergeされるという結果を出すことができました!!

ワークショップの振り返り

当日のワークショップでは、参加者全員がOSSに対してIssueやPull Requestを提出することができました!!

当日のOSS初参加の方々からも、OSS開発は本当に誰でもできる!今度は自分のPull RequestがMergeされるところまでやりたい!という感想が多く聞かれました。

私自身もワークショップの後に、OSS開発者から自分が上げたIssueやPull Requestに対してフィードバックをもらうことができ、こんなに簡単に開発者とコミュニケーションが取れるんだ!という驚きと同時に、OSS開発することへの自信にも繋がりました。

まとめ

今回OSS Gate ワークショップに参加し、OSS開発に対する考え方が大きく変わりました。

  • OSSは、完璧なものではなく、みんなが見つけた問題が改善されることで、日々改良されていくもの
  • OSS開発は、自分たちの事業にも貢献する活動であること

今後も業務で使っているOSSに対して、何かおかしいのではないか?と思ったら、OSS開発のチャンスと捉え、個人としても開発チームとしても、歓迎する風土を積極的に作っていきたいと思いました。

文末にはなりましたが、今回のワークショップ当日の運営や開催のための準備をしていただいた方々に改めて感謝申し上げます。


Techouseでは、社会課題の解決に一緒に取り組むエンジニアを募集しております。 ご応募お待ちしております。

jp.techouse.com