通常業務とオープンソース開発を両立する「ワークOSSバランス」って何だ？Rubyコミッターを雇うマネーフォワードに聞く

2016.10.31 転職

昨今のWeb開発において、オープンソースソフトウエアを業務で利用することは決して特別なことではなくなった。しかし、一般的には「使う側」にいる人が圧倒的多数であり、オープンソース開発を生業にしている人はほとんどいないだろう。

ただ、自動家計簿・資産管理サービス『マネーフォワード』やビジネス向けクラウドサービス『MFクラウドシリーズ』を展開しているマネーフォワードの開発チームは少し事情が異なる。同社が開発で用いている言語Rubyのコミュニティに貢献していくことを前提に、Rubyコミッターを社員として雇用しているのだ。

10月26日に行われた『MoneyForward Meetup vol.6』では、今年2月にフルタイムのRubyコミッターとして採用された卜部昌平氏や、同社エンジニアで同じくRubyコミッターである金子雄一郎氏、そして技術顧問として関わっている松田明氏らが登壇し、「企業での開発業務とOSSの関係」についてそれぞれの持論と経験談を明かした。

そこで出てきたのは、ワーク・ライフ・バランスならぬ「ワークOSSバランス」というキーワードだ。彼らはどうやって、業務とオープンソース開発の両立を図っているのか。当日のプレゼン内容を紹介しよう。

フルタイムのRubyコミッターを雇っている意義とは？

企業勤めのエンジニアとしては珍しく、「フルタイムRubyコミッター」として働く卜部昌平氏

最初に登壇したのは、マネーフォワードの開発推進本部に所属する卜部昌平氏。既述のように、彼はフルタイムRubyコミッターでありながらマネーフォワード社員として働いている稀有な存在である。
　　
「なぜ自分に給料が振り込まれているか分からない」と笑う卜部氏は、障害発生時などで人手が欲しい時などはプロダクト開発のチームをサポートしているというが、それ以外の時間は「1人部門」として文字通りフルタイムでRubyコミュニティに関わっている。

なぜ、卜部氏のような働き方が成立するのか。最も大きいのは「会社の理解があること」（卜部氏）。オープンソース開発そのものが商売につながるわけではないため、「正直、このようなポジションで働ける会社はほとんどないので運が大きいと思っている」と話す。

では、日々の“業務”として期待されていることは何なのか。それはひとえに、マネーフォワードが開発に用いているRubyそのものを発展させ、その取り組みの成果をコミュニティに還元していくことで、さらに良いOSSにしていくことにある。

「ただ、僕の場合、マネーフォワードに転職する前と後で、コミットの頻度はそれほど変わっていないんです。なぜなら、プログラムを書くことだけがOSSへの貢献ではないから。コードを書くこと以外でも、いろんな貢献の仕方があります」

実際、卜部氏が普段の業務時間内に最も多くの時間を割いているのがバグトリアージだという。

「僕がマネーフォワードに転職してから一番変わったのが、『プログラムを書く時間じゃない時間』が取れるようになったことなんです」

他にも、ドキュメントを作ることやリリースエンジニアリング、コミュニティ内でのファシリテーションなど、コミットする方法はたくさんある。また、「既存のミドルウエアやライブラリの発展に貢献していくこともアリだと思う」と卜部氏は語る。

「会社としてRubyコミュニティへ積極的に関与していくことで、本来は中立的であるオープンソース開発が『自分たちのやりたい方向』に進んでいく可能性もあります。それが、今の僕の立場で最も具体的な社内貢献になるのかな？と思っています」

プロダクト開発とオープンソース開発の「垣根」を低くする取り組み

マネーフォワードの技術顧問である松田明氏（写真右）と、Rubyコミッターの金子雄一郎氏（写真中央） — マネーフォワードの技術顧問である松田明氏（左側の写真）と、Rubyコミッターの金子雄一郎氏（右側の写真左）

とはいえ、卜部氏も認めるように、普段の業務時間のほぼ全てをコミュニティ活動に費やすことのできるエンジニアは非常に限られる。一般的な開発業務に携わるエンジニアが、オープンソース開発に入っていくにはどうすればいいのか？

そのヒントを、『MFクラウド』の開発エンジニアであるRubyコミッターの金子雄一郎氏はこう語る。いわく、【1】コードを読むこと、【2】パッチを書くことの2つに関しては、通常業務の一環として行っても有益であるとのことだ。

「読むことについては、リファレンスに載っていないことを調べるためであったり、バグを踏んだ時の切り分けをどうやるかなど、実際のサービス開発にも役立つことが多々あります。機能追加や実装のヒントを得るためにコードを読むのであれば、その学習の結果がプロダクトにも還元されやすい。なので、業務中にやっても見返りは十分あると思うんです」（金子氏）

金子氏の場合、例えばgit cloneしたコードを読むとtagやブランチをcheckoutできたりtest codeなども開くことができるため、デグレした時などにコードを読むようにしているという。こうやって、「通常時は業務9割で、パッチを書く作業が1割くらいですが、バグを見つけたりした時は週4日くらいコミットしたりもしている」そうだ。

そして、金子氏が業務時間の約1割を充てているように、【2】で挙げたパッチを書くこともオススメだと言う。

「将来のプロダクト開発で困らないためにも、そして自分自身の勉強のためにも、パッチを書く作業は大事。Rubyだと、Monkeypatchなどを自社プロダクトにも組み込んでおけば、その後は世界中の人がコミュニティ内でメンテナンスをしてくれることにもなるわけです。これはコスパとしても非常に良い。視野を大きくして見れば、業務とオープンソース開発は『地続き』になり得るんです」（金子氏）

金子氏のプレゼン後に登壇した松田明氏は、これを「アップストリームに送って身軽になる行為」と話す。

「現代のWeb開発では『巨人の肩に乗る』能力こそが大事なわけで、OSSを利用するからにはコントローラブルなようにコミットすべきだと思っています。アプリ開発のついでにRubyも開発するような気持ちでコミットしてくれる人が増えるといいですね」（松田氏）

まさにこの「アプリ開発のついでにRubyも開発するような気持ちでコミット」することを、同氏はワークOSSバランスと表現する。

「もちろん、企業勤めの傍らでワークOSSバランスを実践するには、いろんな工夫が必要になります。プロダクト開発とオープンソース開発では頭の切り替えをすることが求められるので、日ごろからスイッチングコストを下げておくことが大事でしょう。そのためにも、Mac(Linux)、GitHub、CI、チャットなどなど、OSS開発の時と同じような“道具”を使って日々の仕事ができる環境づくりが大切になります」（松田氏）

では、こうした開発環境を作り、ワークOSSバランスを許容していく上で企業側のメリットは何になるのか。

「開発者・コミュニティ・企業の3者間でギブ＆テイクの関係が成り立つもので、一番分かりやすいのが採用になるんだと思います。オープンソース開発を企業としてサポートしていると、支援しているコミュニティのエンジニアに認知され、そこから徐々に良いエンジニアが興味を持ってくれるというサイクルが回るようになっていきます。その結果、良いプロダクトが作れるようにもなるんじゃないかと」（松田氏）

エンジニア採用に苦戦しているWeb企業は、大手・ベンチャーを問わずたくさんある。この課題を解消する一つのやり方として、マネーフォワードの事例は参考になるだろう。