※この記事は、2022 Speee Advent Calendar13日目の記事です。昨日の記事はこちら

こんにちは、デジタルトランスフォーメーション(DX)事業本部でエンジニアをしています。21 卒の染谷です。
皆さんは OSS 活動をしたことはありますか？OSS 活動を始める以前は「私が OSS に貢献できることなんてあるのか？」と OSS 活動をすることに抵抗がありました。
そんな私ですが、最終的に RuboCop(Ruby の Linter)にロジック修正の PR を出すことができるようになりました！

この記事では、OSS 活動怖くないぞ！人の作りしものなのでバグはあるし貢献できることたくさんあるぞ！を伝える記事です。
OSS 活動に興味はあるけれど、何からやれば良いのか悩んでいる人は是非読んでください。

OSS 活動を始める前の印象と始めたきっかけ

つよつよエンジニアがすごいことやってるな〜というのが OSS 活動を始める前の印象でした。
twitter でつよつよエンジニアが OSS 活動をしているところをよく見かけたからでしょうか。そんな印象だったので「私に何ができるんだろう」「なに書いてるか全然コードを理解できないし、技術力高い人しか OSS 活動やってなさそう」と怖気づいていました。
なので OSS 活動に興味はあったけれども実際に活動するのはもっと経験積んでからの話で、私なんかがコードいじって修正 PR 出すなんでできないよなぁと思って何も行動せず仕舞いでした。

Speee ではクリアコードの須藤さんと結城さんにOSS 活動をサポートしてもらっています。
入社して 1 年経たないくらいで声をかけてもらい、興味あるから話聞いてみようレベルで軽く参加したのがきっかけで OSS 活動を始めました。
こういった機会がなければ怖気づいたまま挑戦しなかったので、とてもありがたい取り組みです。
具体的な取り組みとして、私は結城さんと週 1 回 1 時間、サポプロをやっています。
サポプロについての具体的な紹介はこちらの記事を御覧ください。

tech.speee.jp

OSS 活動で感じた壁の話/壁を乗り越えた話

ここでは私が感じた OSS 活動をする上で壁になった話と、それをどうやって乗り越えて OSS 活動をしているのか話します。

第一の壁: どの OSS に貢献するのか問題

第一の壁は、そもそもどの OSS に対して貢献したら良いのか分からない問題です。
普段使っていて困ったことがあればフィードバックすれば良いとよく言われるのですが、特に困ったことがありません。もしかしたら環境構築やとあるメソッドでつまずいたことがあるかもしれませんが覚えていません。そもそも私のコードの書き方がダメなだけでフレームワークやライブラリは悪くないんじゃ、、、と思ってします。
Speee の業務だと Ruby on Rails をよく使うのですが、Rails は貢献するには巨大で複雑過ぎて無理！と思いました。あんな有名で完成された(と個人的に思っている)コードに私ができることなんてないだろう。バグがあっても難しいものばかりで技術力足りないだろうと思っていました。
そうした正直な気持ちを結城さんに伝えたところ大きなアプリケーションのことだけを考えるのではなく、身の回りの小さなアプリケーションのことにも目を向けるようにアドバイスをもらいました。このアドバイスを元に少し視野を広げて業務関係なく私が使っているものとして Chrome 拡張機能が良さそうとなり vimium という、ブラウザを vim ライクにコマンドで操作できるアプリケーションを OSS 活動の対象としました。

また、業務では Rails を扱っているので Ruby で書かれた OSS に貢献したいなぁと思っていました。その方がコードリーディングしやすいのと、業務へ経験を活かしやすいと考えたからです。
なにかないかなと検索していると Github に good first issue (最初に貢献するのに適した issue だと思うものにつけるラベル)という Labels を付けている OSS のリポジトリを表示してくれるサイトを見つけました。

goodfirstissue.dev

Ruby の Linter でいつもお世話になってる RuboCop を発見したので、 vimium の次は RuboCop に OSS 活動をしようと決めました。

第二の壁: どうやって貢献するか問題

第二の壁は、私に何ができるの問題です。「OSS は難しいコードだらけで貢献できる気がしない」「小さなバグなら誰かが issue 上げて PR まで出ているだろう」「多くの時間を OSS 活動に割けないのでやれることあるのだろうか」と私は思っていました。
第一の壁と同じくこの課題感を結城さんに相談したところ、「README に書いてある通りに環境構築をしてみて、その通りに動作させて動かなかったらどこでつまったかをコメントすることでも OSS に貢献できる」とアドバイスを貰い、それくらいならと思ってやってみました。

vimium では、何をしてどこで詰まったのか分かるように逐次記録を取りながら README の通りにセットアップを進めていきました。インストールするとブラウザ操作の権限が求められるのでその権限は本当に妥当なのか確認します。チュートリアルの動画を見てねと README に書いてあるので動画を見ながら(英語なので字幕を付けながら視聴)動作させると自動翻訳の間違えで u とすべきところが you になっていて誤解を招いていたのを発見しました。
そのような些細なことをissue としてフィードバックしたり、同様の issue が立っていないか確認するために issue を漁っていたところ、別件ですでに修正されていてclose にすべきと思える issue があったのでコメントしてみたりと小さなことから OSS 活動を始めていました。

コードを修正するだけでなく、コメントすることでも OSS に貢献できます。実際には解消済みの問題なのに issue が Open なままだとどの issue が未着手なのか分からないですからね。
まずはフィードバックすることが大切で、そのフィードバックを受け入れるかは OSS のオーナー次第と責務を切り分けて考えることで気が楽になりました。それならどんどんコメントしないと！と思えるようになりました。
第一の壁にも関わりますが、環境構築だけをするのであれば何でも良いな〜と思えました。なのでとにかくやってみることが大切です。

このように、知らなかっただけで様々なことで実は貢献できる、したいと思える OSS はたくさんあることに、視野を広げることで気がつくことができました。
「実力不足で無理だろうな」とか「OSS 活動したいものがないのでいいや」と一人だと諦めていたと思います。サポプロがあったことで挑戦する背中を押してもらえたなと感じています。

第三の壁: 英語でコミュニケーション取るのが怖い問題

第三の壁は、英語で上手く説明ができずにコメント返すの大変問題です。
ただでさえつよつよエンジニアがたくさん居て「こんなコメントで良いのかなぁ」「こんなこと聞いて良いのかなぁ」とコメントするのに怖気づいているのに、そこに英語が加わったらもう大変です。
翻訳サイトを使えばなんとかなりますが「Do you understand? って失礼なんだっけ？」のように本当にこの英文で良いのかなとコメントするのを躊躇してしまいます。
そう思っていたので英文を書くときに結城さんに教えてもらいながら英語を書いていました。誰かと一緒に英文を考えるのはとても心強いです。
また、英文を書いている中で「すべてを英語で説明しなくても良い」とアドバイスを貰いました。
これは、変更前と変更後のコードを貼り付けて This code should be changed like this. としても意図が伝わるはずなので英語で詳細を伝えなくてもよくなるということです。
実際にこんなコメントをしました。

github.com

英文を書かなくなる訳ではないですが、コードを提示することで難しい英語を避けることができるので、こちらも気が楽になりました。
また、英語に関しては結城さんが書いたこちらの記事が参考になります。

www.clear-code.com

ロジック修正の PR を出すまで

ここでは実際に RuboCop にロジック修正の PR を出すまでにやったことを書きます。

good first issue で良さげなものがないかなと調べてこの issue に取り組むことにしました。

github.com

まずは issue 起票者の言っていることが正しいのか、英語を読み解きつつ実際に実行してみます。
bad と good と書かれているのでわかりやすいですね。どうやら bad と good で挙動がことなってしまうようです。RuboCop は Linter なので同じ挙動を担保したまま、より可読性が高いコードに変更してくれます。そんな RuboCop が同じ挙動を担保できないのは致命的なバグですね。

# bad
if something
  foo || raise('exception')
else
  ok
end

# good
foo || raise('exception') if something
ok

実際に動かしてみると something が true かつ foo が true のときに挙動が変わってしまいます。
bad だと foo が返り、good だと ok が返ってしまします。

issue 起票者の言っていることは正しいと思ったのでコード修正に入ります。
実際に RuboCop を動作させると code inside a conditional expression. という固定文字っぽいエラー文が出力されたので全文検索して見ます。見つけました！ファイル名もガード節に関してなのでこのファイルに該当のコードがありそうです。
処理が通っていそうな場所に p 'メッセージ' のような標準出力や binding.irb を仕込んでもう一度動作させます。このようにあたりを付けて該当コードを絞りました。
次に、正常系と異常系を試してどこが本質的に問題なのかを探り、発見したら意図通りになるように修正してみます。
修正が終わったら今回の issue で指摘されていた問題の修正後の動作自体のテストを新しくつくり、既存のテストが落ちないか試します。
あとはテスト駆動開発の要領で少しずつ修正していけば修正完了！
こんな感じに PR が出せます。

github.com

OSS 活動をやってみての感想

楽しい。普段業務で触っているコードとは全く違う思想で書かれているので新鮮です。
標準出力を仕込んでどんな挙動をしているのか、何故バグとなる挙動をしているのかと解明していくのが楽しいです。
RuboCop は巨大プロジェクトですし、普段バグに遭遇しないしなぁと思っていたのですが、ロジックを見てみると意外と考慮漏れがあったりします。OSS でもやはり人の作りしものなのでバグはあるんだなぁ。完璧ではないんだなぁ。というのが大きな学びです。
特に考慮漏れを見つけてからは OSS 活動するハードルが下がりました。業務で開発しているものと同じアプリケーションなんだなと。そりゃ改善し続けないとです。
あと commit すると Github のプロフィールに RuboCop が出るようになります。これめちゃくちゃ嬉しいです！