MoneyForward Meetupレポート「ワークOSSバランス」

広報の青木です。

最近マネーフォワードでは、気軽に遊びに来て頂ける場として、MoneyForward Meetupという交流会を開催しております。「OSSと仕事」をテーマに開催された今回は、OSS開発と縁の深い社員の卜部、金子、顧問の松田氏が登壇しました。その様子をご紹介いたします。

MoneyForward Meetup vol.6 (Ruby on Rails) – connpass

eyecatch

※第7回目は「エンジニア×個の力をForward」をテーマに開催予定です。お申し込みはこちらより受付中です。

まずは当社の越川より、「楽しみながらマネーフォワードのことを知ってください」というご挨拶と乾杯からスタートいたしました。

1

オープンソース開発者として働くということ

最初の発表は、フルタイムRubyコミッターの卜部より。

1

卜部は、今年2月にフルタイムRubyコミッターとして当社にジョインしています。

そんな卜部は「なぜ自分に給料が振り込まれるのか分からない」と話しますが、当社ではRuby言語を開発をすることでコミュニティに還元することを卜部のミッションのひとつとしています。

マネーフォワードでは数多くのオープンソースを活用してシステムを構築し事業を行っており、その事業はWebアプリケーションフレームであるRuby on Railsの上に成り立っています。Ruby on Railsは、Ruby言語で作られており、これら当社の事業を支えるオープンソースのエコシステムへ還元することは自然の流れであると考えています。

まずオープンソースを開発しよう

自分自身の環境を「運が良かった」と言う卜部は、「オープンソース開発者として働くには、まずオープンソースを開発すること」が大事だと話します。

卜部は元々オープンソース開発をしていましたが、転職して最も変わったのは、「プログラムを書く以外の時間が増えた」こと。具体的には、バグトリアージやドキュメント作成、Rubyの開発者会議などでのファシリテーション…といったタスクです。
いざオープンソース開発が本業になると、それらのプログラムを書く以外のことへ時間を使えるようになったということです。オープンソースへの貢献はプログラミングだけではないのです。

「なんらかの合意があってファシリテータなどをはじめたのか?」という問いに対しては、元々Ruby開発者会議などに出ており勝手がわかっていた部分もあり、人手不足であることを実感していたので、そこで貢献するようになったと回答しました。

次に大事なのは「発表」をすること

Pull Request、勉強会、GitHub、RubyKaigi、執筆などのあらゆる手段でチャレンジをして、発表をすることが大切だと伝えました。

最後に「仕事をオープンにする」こと

実際問題、フルタイムでオープンソースできるポジションの募集は大変少ないため、自らポジションを作りにいくという動きをとってみることも大事だとのこと。
自社製品をオープンソースにしたり、クライアントに配布するものをオープンソースで公開する、ハードウェアをオープンにするという手法もあると伝えました。

また、『チーム体制』に関しては、「会社では自分1人しかいないが、世界中にチームメンバーが居るという意識でやっており、違う会社の人とのコミュニケーションで思惑が一致しない場合もあるが、関与することで貢献できることもある。」と話します。

人事評価については、会場から当社CISOの市川より「当社として今も手探りだが、オープンソースへの恩返しがしたく、会社を代表してRubyにコミットしてもらったり、それをRubyKaigi等で発信してもらうことも評価の対象と考えている。」とお伝えしました。

まとめ

「運がよかった」と繰り返す卜部ですが、オープンソース開発者として働いている自分のスキルはそこまで高くないと言い、「どんな人にもチャンスはあり、自らそのポジションを作りに行ってはどうか」というお話でまとめました。

業務中にオープンソースについて考えること

続いて、『MFクラウド会計』チームのエンジニア金子より。

1

金子は元々メーカーで経理業務に携わっていましたが、『Ruby Hacking Guide』の影響を受け、エンジニアの道に進むことになったそうです。現在はRubyのコミッターでもあります。

まずはコードを読もう

「オープンソースに向き合うためには、オープンソースのコードを読むことが非常に重要だ」という話からはじまりました。

「業務中にオープンソースのコードを読まざるを得ないのは、バグを踏んだ時などに、ライブラリと自分のコードのどちらかに問題があるかの確認する時や、実装上のヒントを得たい時など。コードを読むことはプロダクトの開発に貢献するまでのスパンが短い事が利点で、短期的な時間軸でのリターンが狙える。」と話します。

コードを読む際には普段は、pryのshow-sourceを利用しており、手軽に実行できる点がメリット。デメリットとして、コードの全体像が見えないという点はあるが、調査をするとっかかりとしては非常に良いとのこと。
手元にgit-cloneしたコードを読むことは、tagやbranchをcheckoutできる点、testを実行できる点がメリット。gemのバージョンアップなどで、デグレした時に利用するパターンが多いそうです。

情報収集に関しては、気になるレポジトリのIssueやMLを購読し、Hotな話題やプロジェクトの雰囲気、自分の興味の確認のためにも利用しているとのことです。

「書くこと」の重要性

とは言え、やはり「書くこと」が大事だと強調しました。「業務上必要ということ以外に、読むことに比べて中期的な時間軸でのリターンを狙い、結果的に自分が将来困らないためのアクションにもなる。」と言います。

そして、「自分がほしいと思った機能は誰かがほしかった機能なはずなのに、なぜ今までその機能がなかったかを考えることも大切だ。」と伝えました。

モンキーパッチは以後のメンテナンスも自社で行うことになるので、upstreamへパッチを送る方が世界中の人にメンテナンスをおまかせできて便利という話に納得です。

「オープンソースで遊ぶこと」について

これは単純に楽しめる部分であり、「当たれば儲け」という前向きな感覚で取り組む価値はあると話します。

例えば、金子は業務上Ruby以外にも最近はPythonも書くことがあり、新しい言語を学ぶ際に、オープンソースの開発に参加するという方法をとることがあるそうです。オープンソースソフトウェアの開発には、リアルな題材があるという価値があると考えます。各ライブラリには必ず達成したい課題があるのでそれに向かってパッチを当てるのは、新しいことを学ぶうえで理に適っているとお伝えしました。

最近は将来的な投資として、Rubyでデータフレームを扱うdaruに参加しているとのこと。「業務とオープンソースは地続きになっており、うまくいけば世界がコストを負担してくれる。自分の力で自分が使ってるオープンソースに貢献し、自分たちの力で改善したり安定させることに繋がる。」というお話でした。

仕事でOSS

最後に、当社技術顧問の松田氏より。

1

松田氏からは、「仕事とOSS」について、お話させていただきました。

松田氏は「当社の技術顧問」であり、業務プログラミング歴は15年程、VB、Java、.NET、PHP、Perlなどのプログラマーを経て、Rubyの仕事を始めたのは10年前くらいとのこと。
当時のRailsは少し使うとバグにぶち当たり、そんなところが「自分で改善できる余地もある」「というより、なんとかしてあげたくなった」と考え、「そこがRubyの面白さだと思った」と話します。

「10年戦えるフレームワーク」としての強みは、現場志向であること、開発者たちを巻き込みながら進化を続けるエコシステムが構築されているところ。そんなところが、Ruby/Railsの魅力であるとのことです。

コミュニティの地続き感とは

松田氏は、このエコシステムを「地続き感」だと話します。コードがいつでも読めることや、ライブラリの中の人のオープンマインドさも良い部分。

Ruby on Railsは、生産性を高めることを目的として書かれており、全てのソースコードが公開されているため、いろんな人が書いたコードを誰でも読むことができます。Rubyコミュニティは特にオン/オフライン両方で拠り所となるコミュニティの活動が活発なことも特徴で、週に1度以上のペースで世界のどこかでカンファレンスが開催されています。

現代のプログラマーの仕事は日々変化しており、業務機能を実装する能力だけではなく、どういったプラグインを選定し、システム全体を構築するかという部分のスキルが求められます。そのためには、コミュニティと付き合い、コミュニティの成果を取り入れながら開発を進めていく必要があります。そこで、単にコミュニティの成果に「ただ乗り」するのではなく、「自らがどう乗っていくかを把握して行動する必要がある」と話します。

「どうすればコントリビューターになれますか?」という問いに対しては、コントリビューターになること自体を目的化するのではなく、日々の開発をこなしながら自然にRailsも同時に開発していくことが大事だと強調しました。

「ワークOSSバランス」について

そんな話を展開しつつ、松田氏からは「ワークOSSバランス」という言葉が飛び出しました。「仕事 vs OSS」ではなく、OSSはアプリケーションの大部分であり、自らメンテナンスに参加することが大事とのこと。視野を広く持って、目の前の仕様や要件を実装するコードだけを見るより、その先にあるソフトウェア、さらにそれを書いている人間を見ながら毎日の仕事に取り組んでみてはどうでしょう。

そのためのテクニックとしては、昨今は当たり前となった、Mac、GitHub、CI、チャットなどOSS開発と同じ道具を使って仕事をすること、利用するOSSのソースコードは全て手元に揃えておく、そしてコミットコメントは英語で書くなどして、 業務とOSS開発とのスイッチングコストを下げることを意識するのが重要とのこと。

コードだけではなく、人を見る

これについては、「他人が書いたコードを使うのは怖いこと」という認識を持ちつつ、「信用できるコードを書く人は信用できる、信用できる人が書いたコードは信用できるコード」という意識を持つ、という話を展開します。

松田氏は、なるべく友達・知り合いのプロダクトを使うようにしており、知らない人が作るプロダクトに関しても「良い」と思えば会いに行き、SNSでつながる、そんな「コミュニティ」を形成していくことで、「信用できる人」が増えていくと話します。

「コミュニティは大事」と繰り返す松田氏は、カンファレンスに行くなどしてコードを書いている人と話すことを推奨しています。
とは言え、世界のRubyのカンファレンスは公用語が英語であり、行っても「ぼっち」の可能性もあり、かと言って登壇は難易度が高い…などの問題もあります。だからこそ、「コードを書く」ことが重要であり、コミュニティに参加するため、パッチをコミットし、GitHubの「草を生やす」ことによってプレゼンスを作る。これ以上に有効な手段はないと強調します。

企業、開発者、コミュニティの関係

最後に「共存共栄を目指す」ということについて話した松田氏。
企業、開発者、コミュニティの関係については、「Give&Take」の関係が理想だと話しつつ、コミュニティと企業との関係性が論点だと言います。

コミュニティから企業への還元は、RubyKaigiなどのコミュニティイベントを通じて企業が開発者に出会う「場」の提供、その結果としての採用活動への貢献がそのひとつかもしれません。その逆に関しては深堀されていなかったり、「コミュニティに貢献、還元しよう」という考えが企業側にそこまで浸透していない可能性もあるようです。

やはり、コミュニティとの距離の近さこそがRubyの楽しみであり、社内にRubyコミッターがいることや、カンファレンスへの参加を業務扱いにするというのも歩み寄りの一歩かもしれません。OSSはタダで使うことができるわけですが、その分浮いたお金で単に人材採用にコストをかけるより、RubyKaigiへのスポンサーシップなども意味があるアクションのひとつかもしれません。

たとえば、マネーフォワードの場合は、松田氏の顧問就任卜部の採用などを含め、直近はコミュニティ内での信用レベルが上がっている可能性もあり、開発者、コミュニティとの良い関係構築例のひとつと言えるかもしれません。

しかし、やはりRubyやRailsのエコシステムに乗っかる以上、コードで貢献することが必要不可欠なコストと考えることを推奨しています。

まとめ

現代のRailsプログラマーの仕事はOSSと向き合わなければやっていけないが、OSSはコミュニティに繋がらないと継続ができないと伝えました。「OSSはコミュニティの活動の産物であり、コミュニティにコミットするにはコードを書くことが大事!とにかくコードを書くことが何よりも大事。」という言葉で締めくくりました。

パネルディスカッション

後半戦はアンケートで頂いた質問や、Twitter「#mf_meetup」でいただいた質問に応える形のパネルディスカッションを行い、ここからは当社Rubyエンジニアの澤田も参加させていただきました。

澤田は、趣味でRuby本体のバグトラッカーへ大量のチケットを投稿するなど、仕事で携わる前からRubyに関連した活動を行っており、Stack Overflowでは3,000アンサーを誇り、Ruby タグのついた回答者では世界のTop 4に入るRubyマニアです。

1

登壇者

  • 卜部昌平:フルタイムRubyコミッター
  • 金子雄一郎:『MFクラウド会計』担当 エンジニア
  • 澤田剛:Rubyエンジニア

モデレーター

  • 松田明氏:当社技術顧問

どういう道を歩み、今に至ったのでしょう?

  • 卜部:情報系の大学から元々興味があり、論文の読み方やソースコードを読んでPull Requestを投げるといったコミュニティとの関わり方に関しては大学時代で学んだことが大きく、今の働き方は研究者として働きたいという意図と似ています。
  • 澤田:元々言語学をずっと研究しており論文を書くためにTeXを扱っていました。TeXのプリプロセッサを書くための言語としてRubyに出会い、さわり始めたのが最初です。
  • 金子:プログラミングは高校生のときに少しだけ触りました。その後、Rubyを触るようになってプログラミングを理解するきっかけになりました。Rubyは常にプログラミングを勉強するための材料だと考えています。

マネーフォワードを選んだ理由は?(みんな松田氏の一本釣り…?)

  • 卜部:選択肢は殆どなく、他社に今のようなポジンションに空きがあればご相談したかもしれないが、たまたま自分のタイミングではポジションはありませんでしたね。
  • 松田:経緯としては僕が一本釣りした形なので、卜部さんがマネーフォワードを選んだわけではないんですけどね(笑)
  • 金子:僕自身も松田さんに一本釣りですね(笑) 元々経理をやっていた頃にExcelのVBAでやっていたような仕事を払拭できるという点で非常に良かったと思っています。
  • 松田:そうそう。金子さんはRails力があってお金関連の業務知識があるのでまさにマネーフォワードがピッタリ!ということで、(Asakusa.rbで)お声がけしました。
  • 澤田:僕も、とある人に一本釣りされ…(笑)
  • 松田:そうだった(笑)
  • 卜部:さっきの話にもなりますが、「信用できる人」が働いていたので選んだというのは理由のひとつにはなりますね。
  • 松田:そうですね、僕はみんなのオンラインでの活動を知っていて、能力や人柄を信用していたから紹介したわけですし、普段からコードを書いていると良いことが有りますよ、ということですね。

C言語についてどう思いますか?

  • 卜部:Rubyの開発はC言語で行われているので、C言語を使うこともあります。本格的に使いはじめたのは大学からですね。
  • 金子:僕はRubyのコミッターでもありますが、C言語はあまり使えません。とはいえ、Rubyのパッチを当てる際に、RubyのテストはRubyで書かれているし、ドキュメントは英語で書かれていますし、C言語もそれっぽく触れば触れたりするので。C言語はもっと下のレイヤーで機械語やらlinkerやらを理解していないといけない部分がありますよねよね。そういう勉強ってどうすれば良いんでしょう?
  • 卜部:GitHubをみると、Rubyのプロジェクト開発の言語は、Rubyになっているので、コードの行数はRubyの方が多いんだと思います。
  • 金子:C言語がわからなくても書けるというと語弊がありますが、既存のコードを参考にしつつ書くこともできますし。またC言語そのものというより、Rubyの世界でのお作法とかを学ぶ必要があるので、RHGを良く読んでみてください!
  • 松田:Rubyはチーム開発なので、全員がC言語得意じゃなくても、C言語がめちゃめちゃ喋れるパッチモンスターみたいな人がひとり居れば開発できるという部分もありますね。

OSSを仕事にしている海外事例はありますか?

  • 卜部:アメリカだとOracleでMySQL、Java。ヨーロッパのTravis CIもです。ロシアにもNginx作っている会社があったりして、海外だと開発者を会社で雇うというのは良くありますが、日本は遅れているんじゃないかと言う印象がありますね。
  • 金子:最近だとShopifyとかがRailsコミッター雇ってますよね。
  • 松田:昔のEngine Yardとか、Ralisコミッターをフルタイムで雇う動きは海外ではそれなりに盛んではありますね。Rubyに関してはやっぱりHerokuの存在が大きくて、日本ではやっとマネーフォワードがスタートしたところ。Linux開発者なんかは日本の会社でも居たりしますよね。

OSS開発者はメンタルが強そうなイメージなんだけど、本当のところどうなの?

  • 卜部:案外凹んでますよ。ふっかけて負けるパターンが多くて、凹むこともあります。喧嘩っぽいというのは口調がそうなのかもしれない。でも、「正しいことを正しい」と思って発言しているので、そこまで問題はないのかなって思っています。
  • 金子:僕はそんなにメンタルは強くないです!
  • 澤田:僕は…ネット上で喧嘩になったりすることもありますね。
  • 松田:澤田さんは、バグをつぶしているんじゃなくて機能提案をしていますよね。それってつまり、Matzを言い負かさないと目的が達成できないので、なかなか大変そうですね。がんばってください。

生産性を高めていくためにOSSを活用する意義については腹落ちしたのですが、開発者としてOSS開発に携わることによって、普段の業務での「プロダクト」をより良くするという意味での能力やクリエイティビティを高めていくことにつながる面はありますか?

  • 金子:僕は業務でプログラムを書いていますが、学校で勉強したわけではないです。エンジニアになる前は、「OSSでパッチを当てて否定されること」がプログラムを学ぶ手段でした。でも、そういう人間に対してもきちんとコミュニケーションをとってくれるので、そこでパッチを直したりしながら学んでいます。そんな風にして引出しが増えていくことは、プロダクトの改善につながっていると思います。
  • 松田:OSS活動に参加することで、開発者同士が出会ったり友だちになったりしてコミュニケーションが生まれて色々アドバイスを貰ったりして、それが結果的にはプロダクトに還元されることはありますよね。あれですよ、「OSS開発者同士はひかれ合う」んですよ!
  • 卜部:プロダクトを良くしていくことは最低限のことだと思っていて、プロダクトを良くしないOSSの開発は意味がないと考えています。ただ、色々やっていく中で自分の手元で直してしまって終わり!にするか、皆が見るOSSみたいなところで公開しておくか、の違いではないかと。後々、オープンソースにしておくことで、メンテナンスコストを低くすることはできるのではないでしょうか。

OSS開発をサポートする企業を増やすためのアイデアはありますか?

  • (会場から)当社取締役の瀧:最終的には採用で相性の良い人たちが来るようになるみたいな説得をすると良いかもしれませんし、当社の場合は実際にそうなっています。普通に社内でなんでも聞ける人がいるというのは非常に恵まれているし、確実にそれはアプローチになる。大きな企業において取り組むことも非常に価値があるというのが所感です。
  • (会場から)当社CISOの市川:入り口は採用が良いと思いますが、スポンサーなどでも点々とやってみることで線になり、形になることはあるかもしれません。僕らの場合、会社でオープンソースを使おうと思っていて、その場合はきちんと対価をお支払いしなくちゃいけないなという考えで今活動しています。
  • 卜部:まず、オープンソースへの最初の貢献として、オープンソースを「使う」というのはとても大事だと思っていて、「とりあえず使う」、次にきちんとフィードバックをしていく。そうすると、次第に無視できなくなっていくと思います。
  • 松田:確かに、「あなたが書いたプロダクトを使ってます!」って言われたりすると嬉しいですよね。

OSSへの参加がない企業内で、参加を始めるコツとかありますか?

  • 松田:まず会社選びが間違ってんじゃないの?(笑)
  • 金子:確かに今の会社は良い環境ですが、そんなことより基本自分で決めてやるかやらないかしかない!周りは気にせずとにかくやりましょう。

最後にひとことお願いします!

  • 卜部:普段オープンソースを使っていると思いますが、一歩踏み出して、Stack Overflowを読むとかコミュニティに関わっていく、パッチを書く、みたいなことでコミュニティに参加してもらえると良いかなと思います。
  • 澤田:私自身は、Rubyを使うことによってテスターしての役割を果たしていると考えています。開発に関わらなくても、そういう貢献の仕方もあると思います。また、会社がコミッターを雇うと、そのソフトウェアの関係者が会社内に集まってきてコミュニティができ、会社にとっても利益になると思います。私自身の体験でも、卜部さんが居るのは魅力のひとつでした。
  • 金子:Rubyの開発者が言っていた浮力という言葉を意識しています。使っている人が10万人とか100万人とかいる中で、どの位置でやるのが楽しいかを考えながらやっていくのが良いと思います。

最後に

懇親会では、今回も多くの方にご参加いただきました。当社のエンジニアメンバーなども参加させていただき、各々Rubyやサービス開発への想いなどに関して意見交換が交わされていました。解散後も一部の皆さんで議論は深まり…夜は更けていきました。

1

マネーフォワードでは、Rubyをforwardしたいエンジニアを募集しています。

今回のmeetupの記事を読んでご興味を持たれた方は是非お話を聞きに来て下さい。

それ以外にも、様々な職種で一緒に働く仲間を募集しています。
ご応募お待ちしています。

【採用サイト】

Pocket