RuboCopコミッターが語る、"Write Code Every Day"を5年間実践するための工夫と得られたもの

株式会社永和システムマネジメント ディスティングイッシュト・エンジニア
伊藤 浩一
エンタープライズアプリケーションの開発やオブジェクト指向設計技法の講師などを経て、2004年に株式会社永和システムマネジメントに入社。アジャイルソフトウェア開発手法を背景にRuby on RailsをもちいたWebアプリケーションの開発ならびにプロジェクト運営に多く携わってきており、実践と理論に基づいたソフトウェアエンジニアリングとチームリーディングへの造詣に深い。近年はRubyの静的解析ツールであるRuboCopコアチームの開発者として世界中のプログラマーたちとのオープンソースソフトウェア活動にも関わっている。
Twitter:https://twitter.com/koic
GitHub:https://github.com/koic

「『芯の強いパッチ』は他のエンジニアから見てもわかるし、そういうパッチは信頼を生む」と話すのは、RubpCopのコアチームの開発者である伊藤さん(@koic) 。このように思い始めた背景には、5年間毎日コミットしてきた積み重ねがあるそうです。今回は、伊藤さんに毎日OSSでコードを書くためのコツやメリットを、RuboCopでの経験を交えつつ紹介いただきます。

Offers」は、時代の変化や環境にあわせてスキルを磨きたい、そんな人にぴったりのサービスです。「副業・複業」で、本業では経験できない、新しい環境/開発スタイルを経験しよう!

→「Offers」をもっと詳しくみる!

OSS活動を始めたきっかけは"Write Code Every Day"を知ったこと

エンジニア界隈では「GitHubに草を生やす」という言葉があります。GitHubに草を生やすとはどういうことか?また草を生やし続けるコツ、草を生やし続けた先の世界観を自身のOSS開発のキャリアをふりかえりつつ紹介します。

私と”Write Code Every Day"との出会いは、とちぎテストの会議03の休憩時間でのこと。毎日コードを書くことを実践している話をt-wadaさんから聞いたのがきっかけだったと思います。

すごい人の真似をすればすごい人に近づけるだろう、という単純な発想から始めましたが、"Write Code Every Day"のオリジナルのルールは「真夜中にコードを書かない」など、私には厳しいものでした。

そのため、教科書的に進めようとしてスタートで挫折するより良かろうと、自分でできそうな形にカスタマイズで実践してきています。ルールは単純でGitHubに毎日草を生やすというものです。

▲2020年の活動(GitHubより)

なにごとも最初はできることが限られています。"Write Code Every Day"で記されていることと反している部分はありますが、シンプルで分かりやすい「草を生やす」という1点ルールが私のスタート地点でした。

毎日コードを書くことを継続していく中で、私が最初に獲得できた最も大きな変化は仕事以外の日常でも頻繁にGitHubのOSSリポジトリを見に行く習慣が身についたことです。

OSSで気をつけること

▲RubyKaigiでの登壇(提供:RubyKaigi 2018

OSSにパッチを送るにあたり「このクオリティのコードでパッチを出して良いかわからない」と耳にすることがあります。

私自身、とりあえず期待どおりに動くパッチは手元で書けているけれど、それが正しい直し方か分からないため、OSSリポジトリにパッチを出せないでいたことがありました。ここではそんなパッチに対する考え方の変化について話します。

最初は自信がないパッチだろうと出すことが大切

仕事で踏んだOSSのバグの修正について「正しい直し方かどうか分からないのでOSSに出せない」ことがあったのですが、RubyKaigi 2016で、OSSメンテナーのyahondaさんから「自分だってどう直したら正しいかは知らない(けど直しているんだ)よ」と言われ、目から鱗が落ちる体験をしました。

以来、大きく気持ちが変わり、たとえベターでも問題解決されるコードには価値があると私は思って、自分なりのベストを目指しつつ書いたパッチをOSSに出しています。実はこれ勤務先での価値としているエクストリームプログラミングにも出てくる「完璧な設計はないが完璧にやることはできる」という姿勢を、OSSから学び直した形になるんですよね。

OSSというとハイスキルによった綺麗で完璧なコードが難しいやりとりと共に飛び交っているというイメージがあるかもしれませんが、どこもかしこもそういったパッチだけで成り立っている訳ではありませんし、そのとき学んだようにコミッターだから常に唯一の解を持っているというものでもありません。

OSSコミュニティは優しい

また、OSSコミュニティというものは新規参入者にはとりわけ優しく接しようという傾向にある世界なので、やる気の次は一歩を踏み出す勇気を持って自分なりのコードを出すことが大事なのではと思っています。

ソーシャルコーディングの足回りが整っている現代では、Pull Requestをマージするために必要なことがあれば、関心を引かれたレビュアーがコメントをしますので、時差と言語という面を除けばそのフィードバックスタイルは仕事とだいたい同じかもしれませんね。仕事と繋がったスキルでできることと思うと、ちょっとハードルが落ちた気がしませんか?

 

次第に『芯の強いパッチ』を意識すること

さて、OSSを始めるにあたって、仕事でOSSのバグを踏めばそれを直すことをスタート地点できますが、仕事でそうそうバグを踏み続けられるものではないと思いますし、もし仕事で使っているOSSでそんなバグばかり踏むようですと「そもそもの技術選定に問題があるのでは?」となってしまいそうです。

そんな中でOSSを始めるには、どこから始めたら良いかわからないという、『とっつきにくさ』があると、OSSに参入したい人たちの声を耳にすることがあります。まずパッチと言ってもいろいろな幅があります。

簡単なところでは誤植修正やCIで使われているRubyのバージョンの更新といったものがあり、私もOSSに参入した頃はそういったパッチをちょくちょく出していました。ただ、本人がそれで良ければ良いのですが、それだけを続けていると『そういったパッチを出しているだけの人』みたいなラベリングがされるかもしれません。

せっかくOSSに対して興味を持って時間を割いているのであれば、実際の仕事で困るような問題や、OSSに開かれた既存のイシューの解決によって、自分を含む実際に困っている誰かの問題を解決していけると、おそらく世間がイメージするようなOSS開発者の振る舞いに近づいている感じがしますし、コミュニティでの覚えがよくなりそうですね。

そういった『芯の強いパッチ』を書く人のPull Reqeustは、その背景もあってOSSメンテナーからの目にも止まりやすいと感じており、それはOSSコミュニティでの活動のしやすさに繋がってくると思います。

毎日コミットするための工夫

私もそうなのですが、OSS開発者の多くは仕事とプライベートそれぞれの時間を持っていて、人生という有限の時間の中をうまく『やりくり』しながらOSS活動をしています。毎日のコミットを継続するには相応の時間を割き続けることになるため、プライベートや食事、睡眠といった時間や質とのバランス作りが大事になってきます。ここではそんなテクニックを紹介します。

難しいモチベーションの継続

GitHubでの草を継続できていくと、今度は草が途切れた時「ぷっつり」とモチベーションが切れてしまったりします。そんなときは、気を取り直すための気持ちの立て直しが必要です。

反対に、毎日OSSへのコードを書いてコミットし続けるのは、プログラミング能力や問題解決力といった技量への糧になる一方で、バーンアウトのリスクも持っています。バーンアウトとはいわゆる燃え尽き症候群で、この場合、OSS開発疲れによるOSS開発からの離脱を指します。好きで始めたことのはずなのに、疲れが理由でやめることになったら悲しいですね。

いつでも可能なパッチのストックをいかに増やせるか

GitHubで毎日草を生やし続けるひとつのテクニックのひとつに、余裕のある時にストックのパッチを用意しておくという方法があります。何年かのOSS活動によって特定のOSSプロダクトを読み親しんでくると、コードリーディングの積み重ねを通して既存コードやプロダクトデザインへの解像度が上がり、パッチにできそうなポイントが大小見えてくるようになります。

例えば、あらかじめOSS活動に時間を割けなさそうだとわかっている場合は、予めいつ直しても良いようなものを手元に持っておき、草を生やすだけならいつでもできるような状態にしておくと気持ちの面でも楽になります。若干、手段と目的を入れ替えるような部分はありますが、気にしないことにしています。

実際の話、好きなこととはいえ多くのプライベート時間を削って行われているOSS開発では持続可能なモチベーションが最も重要な要素です。自身のモチベーションとライフスタイルにあわせた持続可能なやり方を、レベルにあわせてハックしていきましょう。

続けていれば自然と幅は広がっていく

古くから「継続は力なり」といいますが、これはOSSでも同様のことが言えます。ここまでの話のとおり、自分の場合は何をどうやって草を生やすかというスタートでしたが、いまはネタは無限にあるのでどんなコンテンツで草を生やすかに志向が傾いています。

特にコアチームをやっているRuboCopに関しては、開かれたイシューを直したり、OSSや仕事で関わっているいくつものリポジトリで、RuboCopを実行して問題になった箇所を直していったりしています。その過程で多くの既存コードを読みましたし、それによってプロダクトへの理解を深めていきました。

ただ、振り返ってみると、理解を深める過程にはあまり近道はなかったようで、地道に続けていった感じです。そんな中でもあえて近道をあげるとすると、OSSコミュニティの人たちと会うことです。オンラインで開催されている地域Rubyコミュニティもありますので、OSS開発者と会話してみるとその考え方を直接知る機会になって面白いでしょう。

そういった感じでアクティビティを絶やさない活動を、とりわけRuboCopコミュニティで続けていたら、RuboCopの作者であるBozhidar Batsovにもアイコンと活動内容を紐づけて覚えてもらっていて「こいつは信用できる」とRuboCopへのコミット権をもらいました。熱意は国境を越えて伝わります。

以降は、イシューのトリアージ、コードレビューからのマージに至る一連の作業をGitHub上の権限で行えるようになったり、プロダクトの抽象的な方針についてコミッターのみで構成されるディスカッションの場で関わる機会を得られたりしました。この頃には草を生やすことに困ることはほとんどありませんでした。

5年間のOSS活動で得られたもの

GitHubはソースコードを触媒にしたSNSと言われています。この章では、OSSコミュニティとの関係や得られたものについてご紹介します。背景には、"Write Code Every Day"による習慣の変化が呼び水になり、GitHubでの活動の量が質に変わっていったということがありました。

OSSコミュニティとの関係を作る

"Write Code Every Day"を始めてから、かなりの時間をRuboCopの開発に注ぎ込んでいて、コードとしてその成果の多くはRuboCop 1.0に現れています。個人的な目玉は『LineLengthのデフォルトを80から120にした』といったものです。

これはRuboCopにパッチを送るようになったきっかけのひとつで、2016年ごろに友人のonkさんと「RuboCopのLineLengthのデフォルトが80なのは時代にあわない」問題について話題になったことがありました。

onkさんは統計からの根拠による説得を試みようとして、私はパッチの実績を積み重ねての信頼からの説得を試みようとしました。途中にメトリックスの解析に分類されていたMetrics/LineLengthを、レイアウトの解析に分類されているLayout/LineLengthに移動する破壊的変更を伏線に貼ったりしつつ、3年半くらいかけたサーガとしてデフォルトを80から120にすることができました。

コントリビュータ時代からかなりのアクティビティでパッチを送ったりレビューをしている上で実現できたことだと思うので、RuboCopコミュニティとの関係を構築できた結果によるOSS活動での働きかけによる代表作になっていると自分では思っています。

本業以外の知識

私は、本業ではRuby on Railsを用いたアジャイルなアプリケーション開発ですが、私がOSSで注力しているのはリンターや構文解析という、異なる専門知識を要するものです。そのため、RubyRailsでの使い方について本業で得られないような知識を得られることがあります。

OSSで獲得した視点やスキルを併せ持つことで、現場のプロジェクトでの問題解決の範囲も広がっていきます。富山Ruby会議01ではOSSで得た知識を業務で活用する具体例を話しました。よければご覧ください。

 

本業のプロジェクト業務に必要な技術は業務を行う中で身に付いていきますが、OSSには本業でのプロジェクトを超えたユースケースが集まってきます。世界中の人のフィードバックや考えから多角的な視点を本業に加えて獲得することができます。とりわけ歴戦の開発者たちは高い視野視座を持っていることが多く、センスを背中から学ぶ宝庫です。

コミュニティでの人脈や信頼

Rubyコミュニティではカンファレンスや地域コミュニティの活動が活発に行われています。カンファレンスは話を聞きに行くだけよりも、休憩時間や懇親会などでの登壇者や他の参加者との交流がある方が何倍も楽しめる可能性があります。

中でも「ふだんからコードを書いたことをカンファレンスで会う人たちと話す」のは、発表で聞いた知見をどのように実践に役立てるかといった話や、最近の動向との比較など、カンファレンスでのあらゆる会話は有機的に繋がっていくのでおすすめです。

OSS活動を続けていると、いずれコミュニティの人たちから認識されるアイコンに変わっていきます。積み重ねた時間に比例して、発言への信頼と知識のバックグラウンドが構築されていくのです。スーパーハッカーだったらスッとできることかもしれませんが、そうではなくてもモチベーションを持ってやっていることへの「継続」はできるので、私はそういった地道なレベルアップを試みています。コードに接した時間は裏切らない、そう思います。

OSSは自分を成長させてくれる成長機会

日中の業務で携わった内容は、知識や経験として成長機会を得ることができます。もちろんそこで完結するのはそれで一つの形かもしれませんが、できることを増やせた方が仕事での選択肢や提案の幅も広くなっていきますし、それはきっと仕事を楽しくしていける力になります。

世界中のプログラマーが参加しているOSSでは、有名ライブラリや言語処理系の開発者から直接フィードバックを得ることができます。アジャイルサムライで伝えられている「君は学ぶことが心から好きだ」という開発者としての姿勢に則ると、コミュニティですごいと思っているその道の人たちからどれだけ学べるかというのは、ひとつの大きな成長機会になります。

ビジネスの開発シーンで使われることの多いRubyは、コミュニティ/仕事関係なく人と関わる機会を得ることができます。また、OSSは様々なプロジェクトで使われていることもあり、アプリケーション開発のスキルは地繋がりの部分が多くあります。OSSは、そんな土壌でコミュニティと共生する触媒になり、きっとあなたのスキルと人脈を広げるきっかけになるでしょう。

OSSへの関わり方には開発への参加以外にもバグレポート、コミュニティやカンファレンスの運営、金銭面でのサポート、そして何よりも使って広めるといった多様なアプローチがあります。そんな中で、私の勤務先の株式会社永和システムマネジメントでは、OSS開発者の定常的なミートアップの場として毎月Rails/OSSパッチ会というイベントを開催しており、私個人のTwitterアカウントでも情報発信しています。よければ本記事のリアルワールド版としてご活用ください。

OSSは自分を成長させてくれる成長機会になります。Let's keep hacking!

P.S. このようなOSS開発への活動を支援していただけるスポンサーを募集しています。こちらのGitHub Sponsorsで応援などしてもらえるとモチベーションがあがります :-)

Become a sponsor to Koichi ITO | GitHub

Offers」は、時代の変化や環境にあわせてスキルを磨きたい、そんな人にぴったりのサービスです。

いくつもの転職媒体を使って、企業を探し回るのはもう終わり。「副業」から始まる新しい働き方を実現します!

本業では経験できない、新しい環境/開発スタイルを経験しよう!



この記事をシェア

関連記事


副業・フリーランス

プログラミング

デザイン

インタビュー

お金

採用・組織

グルメ