フルタイムのコミッターとして企業に属しながらオープンソースのプログラミング言語を開発するということ

• 転職活動の準備

更新日：2018.06.28

• 
• 
• 
• 
• 

卜部という名前で、マネーフォワードという会社でプログラミング言語Rubyの開発に携わっているものです。

実は、この文章を書き始めるまでにずいぶんと悩みました。というのも、これまでこのコラムに登場した他の人たちと違って、自分のキャリアというのは決して戦略的に積み重ねてきたものではないのです。そもそも初回の転職からして、やりたくて転職したわけではない。

思い返せば大学院から最初に就職した会社は、受託開発で忙しいながらも楽しく、社会人としてもプログラマとしても大きく成長させてくれた職場でした。何もなければそのまま一生そこで勤めて終わる、本当にそう思っていましたし、今でもやがては戻れたらいいなあと思います。しかし現実にはそうはならなかった。どこに行っても仕事がなく、開発者が余ってしょうがないみたいな時代があり、それが十年近く前ですけど、ありていに言えば放り出されてしまった。会社都合退職です。

しょうがないから職安に通うわけです。当時、調布に住んでいたのですが、所轄の職安が府中にあり、この府中の職安が駅から遠いんですね。調布の方向からだと。だから認定日にとぼとぼと駅から職安に歩いていくわけです。もちろん無職にタクシー乗る金はないですから。それで給付金がもらえるから、というのはそうですけれど、やはり何回もやりたいことじゃないですよ、あれは。職安に通って得た教訓なんて、「通わないで済むならそれに越したことはない」以外一つもない。

これ以上思い出しても鬱々としてくるだけですのでこのあたりにとどめておきますが、キャリアも戦略もへったくれもないところからのスタートなわけです。しゃあない。不景気だもん。年月がたち、雇用情勢も改善して、今では定職にありつけているというのは本当に幸運なことだと思っています。でも景気には循環というものがあり、不景気には雇用情勢は厳しくなるものです。遅かれ早かれその時はまた来るし、次はうまく立ち回るぞという決意ですね。現状のキャリア戦略と言えそうなものといえばそれかな。皆さんもいつか来る不景気に備えて、さまざまな準備をするといいんじゃないでしょうか。

とは言え、現職にしがみつけという主張ではない。そこは注意を要するポイントです。むしろ実体験としては、残念ながら、職にしがみついていれば職安通いを回避できたかというと、そんなことはないわけですよ。幸せなキャリアを維持するというのは、幸せなキャリアにロックアップされて身動きが取れなくなることとは趣を異にすると思います。一回達成された幸せは、そのままで放置しておいてOKという話ではなさそう。幸せを維持していくということを考えると、時にはキャリアチェンジを含め俎上（そじょう）に載せて考える必要は出てくるかと思います。

 

何でもしますが、できることに限りはあります

一方で、じゃあITがダメな時期になったら転職してアルピニストで食っていけるかというと、自分の場合に限って言うなら、これは無理なわけです。誰にでも適性というものはあり、まあ登山家は例として極端って話はあるにしてもですよ、それでもやはり自分にできることをして生きていくしかないという話は、どうしても不可避の面がありますよね。なので「糊口をしのぐためなので何でもします」ということと、「さりながらできることに限りがあります」ということは同時に満たされないといけない。ここから得られる推論として、極端に狭い領域の専門性を極めているとキャリア上のリスクが高い、という話はあるのではないかと思います。

この話が「プログラミング言語の開発」みたいな専門性の極み的な人物から発せられることに驚きがあるかもしれません。けれども、今たまたまそういう仕事をしているからといって、これまでずっと同じことをやってきているわけでもないわけですからね。およそ3年ごとに所属を変える典型的なジョブホッパーとして生きてきて、転職3回で現在都合4社目ですが、受託開発をやっていたころは短くて3カ月とか、標準的には半年とか、そういう周期でじゃんじゃん仕事が変わっていたわけです。思い返してみると、受託開発でいろいろなプロジェクトをやらせてもらったので、ある程度の勘所というか、新しいチームでどのように立ち回っていくかということが学べたのはあったなあと思います。ただまあ、これが5年ほど前に受託から自社開発の会社に転職すると、今度は一つのチームでもっと長期の仕事をするということがどういうものか分かってなかった、ということがあって、その点で学びがありました。

そういうわけですので、振り返ってみると自分のキャリアは、確かに何か積まれているように見えるのだけれど、決して目標に向かって着実に積み重ねてきているものではないんですよね。基本的に流されベースでやってきている……意図的にそう立ち回ってきたつもりはないですが、結果的には仕事の深さよりは幅をひろげる方向で動いてきたなと思います。で、その結果として現職があるかというと、そうでもないというのが人生の一筋縄でいかなさかとは思うのですけれども。

 

プログラミング言語Rubyの開発とはどのような仕事か

現職は、最初は完全に趣味としてやっていた活動に後から職がついてきた形ですので、それまでの仕事とは関連が薄いです。

Rubyの開発に関わり始めたのはもう15年も前になるでしょうか。最初はいちユーザーとして便利に使っていたのですが、やがてRubyに疑問点やバグを見つけだすと、本体の開発に参加するようになっていきました。その後、2006年ごろからリリースマネージャーという係を始めて、2013年ごろまでやっていました。そういった経験があったため、コミュニティに名前は知られていたかと思うのですが、リリースマネージャーから離れて以降は若干の燃え尽きに近い状態となり、しばらくはあまり趣味の活動としてRubyに参加していない状態だったんですね。ところがそこで、タイミングよく現職のお誘いがあり、フルタイムでコミッターをするというのは会社にとっても自分にとっても挑戦なので、面白そうだなと思って参加してみることになりました。

「プログラミング言語の開発って何やってるんですか？」ということを割とよく聞かれるので、疑問に思われている方も多いのだろうと思いますが、そこまで特別なことはやっていません。実は、プログラミング言語Rubyの開発というのは正確には、プログラミング言語Rubyの代表的な実装の一つであるオープンソースプロジェクトrubyの開発をやっているという話です*1。なので、究極的にはプログラムを開発しています。皆さんの普段の働き方とそう変わりません。少なくとも自分の経験としては、これまでの仕事と比べて、内容はともかく、働き方が大幅に変わったという意識はないです。プログラムのソースコードをチェックアウトしてきて、修正して、チェックインする。大筋はこれです。バグなどはRedmineで追跡されていてオンラインで議論が進行するというのも、まあ今風ではないのかもしれませんけれど、でもさほど珍しくはないでしょう。

もちろん、細部はいろいろと違います。現職になって一番の変わったところといえば、メール読んでいる時間が圧倒的に増えたことでしょうか。メールというのはRedmineの議論が転送されてくるメールのことですけれども、だいたいこれを読んで午前中が終わるという感じですね。なぜかというとRubyはアクティブな開発者こそ日米欧くらいしか現状いませんが、利用者は地理的にも分散した各所におり、さまざまなところからバグ報告がなされてきます。また将来の機能提案などもバグとさほど分離せずにRedmine上で議論されています（別に開発者でなくても議論に参加できるということでもあります）。しかもプロジェクトのゴールが、都度明確にしていかないと、最初からあるわけではない。なのでリモートワークに似ているという面があって、ともかく重要なのはコミュニケーションです。実際にはプログラムを作っている時間よりも、メールを読んだり書いたりしている時間の方が圧倒的に多い。これは、チームメンバーと対面で調整できるような場合とは違うところだなあと思います。

 

企業がOSSの開発に参加する意味とOSS開発者が企業に属することの意義

お気付きの通り、ここまでの内容は別に企業に所属しないとできない仕事ではないです。実際、Rubyのアクティブな開発者のおそらく過半数は趣味として参加しているかと思います。

じゃあ企業がRubyの開発に参加する意味は全然ないんですか、というと、そこはいろいろな理論武装があって、企業が参加して嬉しいことはある。例えば弊社の場合ですと、プログラミング言語Rubyを実際に使って事業を営んでいます。使うだけでいえば完全に無料で、特に制限もないので、各社自由に使ってもらえばいいと思います。一方で、誰でも自由に使えるということは、裏を返すと差別化に乏しいということでもあるわけです。そこで「Ruby自体を作っています」というのはかなりの差別化になっていて、仕様策定やパフォーマンスの最適化といった面で企業の意向が反映できる場面が多々あります。

現職ではrubyコマンドの処理高速化に取り組んでいますが、これは弊社に転職した当初に当時CTOだった浅野*2と相談し、弊社の場合WebバックエンドはまだメモリよりもCPUが最適化された方が嬉しい、という話になったためにこのジャンルで取り組んでいるという経緯があります。もしメモリの方が貴重でという話であれば省メモリ関連の機能を開発していたことでしょう。Rubyに限らず、改善の余地がないプロジェクトというものはほとんど存在しないと思いますので、このように社内に開発者を抱えるというのは、そうでない他の企業に対する強いアドバンテージです。このあたりの話は、まつもとりーさんがより一般的に「企業におけるエンジニアリングと研究開発※GeekOutはサービス終了いたしました。」という題で書いているので参照すると良いでしょう。

逆に、プログラマーが趣味ではなく仕事でオープンソースに関わる利点ですが、実際に関わり方が趣味から仕事に変わり、意外にも大きな変化だなと思ったこととして、「自分の外に目標がある」という点があります。趣味の場合、どうしても自分の納得するところがゴールなので、初期の目標をあまり達成しなくても、「自分の中で納得できた」あるいは「飽きがきた」などの理由で、途中のところで手が止まってしまう。そういうことが、自分としてはありがちでした。これが、前述の通り実際に社内のニーズを背景に、プロジェクトに仕事として関わることになってくると、モチベーションの面で励みになります。もちろん趣味でコツコツと最後まで作業を続けられる人もいて、それは本当に尊敬できることです。でも自分はそういうタイプではなかったんだなということが、関わり方の変化でよく分かりました。

さはさりながら、現職が弊社にとって直接の収益事業になっているかというと、それはないわけですね。それに、プロジェクト全体ではチームで作業していますけれど、弊社からフルタイムでRubyの開発に参加しているのは現状では自分一人だけです。ややもすれば、なぜか給料だけは振り込まれているが、会社に所属している意味がいまいち分からないという事態にもなりかねない。

そこで、現職で働き方として重視しているのがプレゼンスです。つまり出社しているということですね。弊社はリモートワークの制度もありますが、自分はあえて使わないことにしています。裁量労働なので全員が集まるコアタイム的なものこそありませんが、それでも現職になってからは朝出社して夕方退社するという生活を意図的に行っています。そして社内のコミュニケーションは意図的にとるようにしています。

弊社もIT企業なので社内でSlackなどのチャットツールが利用されており、そういったところを積極的に巡回していたりします。ただ、プルリクエストのレビューなどは、呼ばれたら出て行く程度で、ほとんどやっていません。さらに弊社の場合ですと、ビジネスロジックとはすなわち会計なのであって、これは専門性が高い領域ですので、とても素人が横から口を出せるようなものではありません。一方でGemfileが古いだとかインデントがどうとかそういう話は機械的にチェックされているため、それはそれで出番がありません。どちらかというとコード以前の設計段階で抜けていそうな視点を確認しに行くとか、逆にデプロイ後に急に負荷が高くなったときに追跡するところで一緒に悩むとかですね。仕事内容がリモートワークに近いものがある反面というか、だからこそ、働き方は企業に所属することの意義を意図的に拾っていっていると言えるかもしれません。このあたりは、企業に所属することの意義を重く捉えるかどうかと関係してくると思います。

 

幸せな職業人生のために何を優先するのか

自分の働き方が正解だと言うつもりはありません。上にも書きましたが、自分のキャリアは必ずしも最適を意図して積み上がってきたものではないのです。たまたま自分はこのように生きていますけれど、フリーランスや一人親方で問題なく生きていけている人も多々おられるわけです。それは、一つ一つの人生はミクロに見るといろいろな話があるわけですけれど、「いろいろな話がある」ということ自体を全体的に見ればいいことのはずです。皆さんがそれぞれの職業人生の中で、幸せなキャリアを維持していくために、何を優先していくかというのは、それぞれに違っていいし、皆さん独自のコアな価値観を、それぞれに維持していってもらえればいいのではと思います。

自分の人生はさほど成功した人生とは言えないわけですが、それでもともかく柳に風でつらいときでも生きてこれたという意味では、まあ一定のよかったところもあるのかな。皆さんの人生にもこれからも山や谷の一つや二つはあると思いますので、乗り切っていきましょう。

卜部昌平（うらべ・しょうへい） @shyouhei / shyouhei