シェア
はてブ
プロジェクト内にあるRubyのコードが、コーディング規約を遵守しているかをチェックしてくれるRuboCop。Rubyでの開発においては広く使われている静的コード解析ツールであり、大部分のRubyエンジニアはRuboCopを利用したことがあるのではないでしょうか。
このツールのGitHubリポジトリを見ると、ある日本人のコミット数が最多であることがわかります。その方とは、伊藤浩一さん。Ruby関連のシステム開発に長年携わり、RuboCopのみならずActive Record Oracle enhanced adapterやParser、Fakerなど各種の有名ツールのコミッターを務めています。OSS関連の活動について、伊藤さんに振り返っていただきました。
永和システムマネジメントに転職し、初めて業務でRubyを書いた
――伊藤さんがRubyやRuby on Railsに触れた経緯からお聞きします。
最初に入社した会社では、官公庁向けの案件でCOBOLを書くことからスタートしました。モダンな技術への憧れは持ちつつも、業務で触れる機会はなかったんですね。転職後に働いた先で出会ったベテランのプログラマーがSmalltalkという言語を使っていまして、そこでオブジェクト指向という概念と出会いました。
私もオブジェクト指向プログラミング言語を使ってみたいと思ったのですが、同じようにSmalltalkをやっても面白くないので調べてみたところ、Rubyが出てきたんです。『オブジェクト指向スクリプト言語 Ruby』という本が出版された後くらいで、興味を引かれてRubyに触れるようになりました。
その後、現在所属している永和システムマネジメントに転職し、しばらくした後に「チームかくたに」を角谷信太郎さんから他のメンバーが引き継いだプロジェクトに参画しました。「チームかくたに」はモダンな技術や開発手法を積極的に取り入れるチームでした。会社が受託していたのはJavaの開発案件だったものの、ランタイム環境に影響しない自動化のためのスクリプトの一部でRubyが使われていたんですよ。これが、最初に仕事のリポジトリでRubyのコードを取り扱ったタイミングでした。
そんなチームがある組織なので、爆発的にRuby on Railsがはやる前の段階からこのフレームワークについて有志で学習していたんですね。そして、角谷さんがRubyについてコミュニティへの発信を積極的にしていたので、徐々にRuby on Railsの案件をもらうようになって、業務でRubyを書く機会が増えていきました。その後にRuby on Railsが世界中で大流行して、日本でもRuby on Railsの案件が多くなっていきました。
コミッターの方々からの叱咤激励が、コントリビューションの原動力に
――GitHub上での伊藤さんの活動履歴を拝見すると、2015年頃から毎日草を生やす*1ようになっています。何か考え方の変化があったのでしょうか？
もともと、jQueryの作者John Resigの「Write Code Every Day」という言葉に共感していたものの、行動には移していなかったんですよ。OSS開発への参画について何が決定打だったかと言うと、RubyとRuby on Railsのコミッターである松田明さんの言葉ですね。彼とお酒を飲んでいるときに「koicさん、お酒ばかり飲んでいるんじゃなくて、もっとオープンなコードを書かなきゃ駄目ですよ」と言われまして。それが、心に刺さりました。
心を入れ替えて、毎日業務以外でのコードも書こうと思いました。とはいえ急にハードルの高いことはできないので、まずは趣味でgemを作ることから始めたんです。そこから、徐々に仕事での困りごとを解決するためのgemを開発するようになりました。ただ、この時点では他の人も使うリポジトリへのコントリビューションはそれほどしておらず、もっぱら個人用のリポジトリをメンテナンスするのみでしたね。
――他の方も使うリポジトリへのコントリビューションはいつからですか？
これも、実は現在Ruby on RailsのコミッターをされているOSS開発者からの当時の言葉がきっかけでした。私は当時、業務でOracleのデータベースを使っていたんですが、Ruby on Railsのバージョンを上げるとOracle関連の処理でうまくいかない箇所があり、それを解消するためにモンキーパッチを当てるgemを個人で開発していました。
ですが、RubyKaigi 2016の会場でActive Record Oracle enhanced adapterの開発者である本多康夫さんに「どうしてモンキーパッチを書く力があるのに、それをupstreamに還元しないのか」とご指摘いただきまして。確かにその通りだなと思って、Active Record Oracle enhanced adapterの開発に携わるようになったんですよね。
さらに、もう1人Ruby on Railsのコミッターつながりで言えば、Active Recordの人として知られるkamipoさんの影響も大きいです。Active Record Oracle enhanced adapterはActive Recordとの関連が強いので、kamipoさんは私の活動を知ってくれていました。それを機に仲良くなり、よく一緒にお酒を飲むようになったんですね。そしてkamipoさんからも飲みの席で、折に触れてオープンソース関連の叱咤激励を受けました。
kamipoさんはとにかく毎日圧倒的にコミットをし続けて、OSSコミュニティでの信頼を獲得していました。それを見習って、私も欠かさずに活動を続けるようになったんですね。そして、毎日コードを読み書きしていると、理解が深まって直すべき部分もたくさん見えてくるので、どんどんコントリビューションの幅が広くなりました。
ライフワークとも言える、RuboCopとの出会い
――伊藤さんは静的コード解析ツールRuboCop関連の活動が最も有名ですが、このツールへのコントリビューションは何をきっかけに？
これは友人である、はてなのonkさんの発言や行動がきっかけでした。かつてRuboCopのLayout/LineLength（1行あたりの最大文字数）のデフォルトは80文字だったんですが、「現代的なコーディングスタイルだと、80文字は少な過ぎる」という声がユーザーから上がっていました。
そこで、onkさんは世の中にある各種ツールの設定値関連の情報を集めてRuboCopの開発者を説得しようとしていましたが、私は「RuboCopへの圧倒的なコミットを続ければ信頼を獲得できるだろうから、そのときにLineLengthの設定変更を相談しよう」と考えたんですね。そうしてRuboCop関連の活動を始めたところすごく面白くて、のめり込んでいきました。実際にその設定を変えるまでには3年半ほどの歳月がかかりましたが、実現できたときは感慨深いものがありました。
Layout/LineLengthを変更した伊藤さんのPull Request
――RuboCopのコントリビューターを続けたからこそ磨かれた力はありますか？
RuboCopは構文解析を行うツールですから、Rubyを普通に仕事で利用していたらまず見かけないような、ありとあらゆるRubyの記法と出くわすんですよ。「え、こんなコーディングスタイルのところもあるの！？」とか「確かに、こう書けるけれど、まさか実際にやる人がいるとは」と思うような、文法のレアケースをたくさん目にします。その過程でRubyの文法について知識の幅が広がりました。
それから、多くの人たちからさまざまな意見が寄せられるなかでRuboCopの機能や設定値を考えていくので、プロダクトの方向性を決める力や各ステークホルダーの意見の落とし所を探る力なども身に付きました。Ruby on Railsの実践知とコーディング規約に特化したRuboCop Railsのメンテナンスを続ける過程で、Ruby on Railsについても新たな側面を知る機会が増えましたね。
――そうした活動を続けていると、世界中のRubyistたちとコミュニケーションを取る機会も増えそうですね。
そうなんです。Rubyには「Programmer’s Best Friend（プログラマーにとっての親友である）」という言葉がありますよね。この言葉に関して松田さんが「プログラマーの友達であるRubyを介して、プログラマー同士も友達としてつながっていく」と、すごく良いことを言っていたんですね。
GitHub上での議論で親しくなるだけではなく、RubyKaigiなどのイベントで実際に会って、親睦を深められるのも良い点です。特に面白いのは、イベントの休憩時間での雑談やイベント後の飲み会ですよね。みんなやはりRubyが好きなので、そうした場での議論はRubyのかなりディープな話になっていくんですよ。
私が今年のRubyKaigi 2024で話した「RuboCop: LSP and Prism」というプレゼンテーションは、昨年のRubyKaigi 2023での雑談がもとになっています。イベントから帰る際に、アメリカのRubyistであるJustin Searlsと松本駅でばったり会ったんですね。
彼はStandard Rubyの作者であり、このツールにはLSPがビルドインで組み込まれています。彼と「これをRuboCopにも入れると便利かもしれないね」という旨の会話をしたことが、その後の活動や今年の発表につながりました。
OSS活動を始めたい人は、何から取り組むべき？
――この記事を読む方のなかにも「OSS活動を始めたいけれど、何から取り組むべきだろうか」と悩んでいる人がいるはずです。伊藤さんのおすすめはありますか？
いきなり、Ruby on Railsのような有名なツールへのコントリビューションは難しいかもしれません。最初は仕事で使っているgemなど、規模の小さなライブラリを選ぶことをおすすめします。
たとえば、そのライブラリを最新の開発バージョンのRubyで動かしてみて不具合がないかを試すとか、ドキュメントの整備、不足しているCIの設定やテストコードなどの追加といったことから挑戦してみると良さそうです。最初から華々しいデビューをするのは難しいので、まずは地道な活動から始めましょう。できることを増やしながら、それをくり返すと、徐々に量が質に転化していきます。
――他にも、OSS活動にある程度取り組んだ人が直面する壁として、いわゆる「燃え尽き」という問題がありますよね。この対策はありますか？
人間にはバイオリズムがあるので、毎日同じようなモチベーションで活動に取り組めるわけではありません。私も「疲れたから今日はゆっくり寝ていたい」とか「お酒を飲んだからこの後はコードを書けない」という日は当然あるんですね。そんな日のために「すぐに対応できるタスク」を手元にストックしています。あまり活動に身が入らないときは、それをやって小規模にでも日々のコミットを積むようにしています。
それから、あるタイミングでPull Requestを出して次の日にマージをすることで、実態としては「マージボタンを押しただけ」なんだけれど、それによって草を生やすことを途切らせないようにもしています。セコい技術なんですが、他の人に迷惑をかけない範囲で適度に手を抜くのも、有効な燃え尽き対策ですね。
また手を抜くのとは逆に、ゲームで言うところの「縛りゲー」のようなことをして、毎日の活動に変化をつけるパターンもあります。たとえば、「⚪︎⚪︎のリポジトリで草を生やし続けること」といったルールを設けるという感じです。こうやって遊びの要素を取り入れて楽しむことで、活動を無理なく続けられます。
「貢献」ではなく「楽しむ」というマインドで
――OSS活動を長く続けたことで、ご自身のキャリアにとってどのようなプラスがありましたか？
コードと向き合う時間が増えたので、その分コードを読み書きする力や課題解決する力が強くなりました。確実に、プログラマーとしてのスキルは向上したはずです。それから、こうした活動を続けたことによって、他の人たちからも自分のことを認知してもらえるようになりました。今回のようなインタビューの機会も、活動を続けたからこそ生まれたものだと思います。また私の所属する永和システムマネジメントでは社員のOSS活動を応援しているので、その意味でもキャリアにはプラスになりました。
――この記事が掲載される「Findy Engineer Lab」は「エンジニアがより良いキャリアを送ること」を重要なテーマとしているのですが、読者の方々に向けて伊藤さんから伝えたいことはあるでしょうか？
これは、松田明さんたちともよく話すことなんですが、コントリビューションは「貢献」と訳されるので、「自己犠牲」のような考え方をしてしまう傾向を見かけることがあります。でも、本来ならば「自分が楽しいからやっていることが巡り巡って他の人の役に立つ」くらいの気持ちでいたほうがいいんですね。だから、まずは自分が楽しんで「自己実現」できる領域を見つけるといいんじゃないでしょうか。
余談ですが、金子雄一郎さんというRubyコミッターがLALRパーサージェネレーターを開発されています。彼のRubyKaigi 2023の発表に影響を受けて、同僚の小林純一がパーサージェネレーターへのコントリビューションをするようになりました。他にもパーサーに興味を持っている同僚内で、余暇の時間などにパーサー関連の議論をしています。
どこに、どんなきっかけがあるかわかりません。私にとって実際に手を動かしているOSS開発者からの叱咤激励が活動のモチベーションになったように、Rubyコミュニティとの出会いが背中を押してくれる可能性もあります。だからこそ、書いたコードを持って、コミュニティやイベントなどに足を運んでみることも、新しい道を切り拓いてくれるかもしれませんね。
取材・執筆：中薗昴
撮影：山辺恵美子
*1:特定のリポジトリでコミットを積む、IssueやPull RequestへのコメントをするなどGitHub上での活動を行うと、行動履歴の緑色が濃くなる。そのため、GitHub上でコントリビューションを行うことを「草を生やす」と形容する。
