Treasure Data を退職しました
約5年5か月働いたTreasure Dataを7/22に退職した。7/25からShopifyに入社し、RustでJITコンパイラを開発してRubyを高速化する仕事をする。
仕事としてやりたい分野が変わってきて自分は今回転職したけど、とても良い会社なので、この記事がTreasure Data (以下TD) で働くことに興味がある人の参考になれば良いと思っている。*1
やっていたこと
APIチーム
元々TDにはJavaで分散システムを書きたくて入社したのだが、TD入社前に特にそういう経験があるわけでもなく主にRailsをやっていたこともあり、Railsでプラットフォームを開発するチームに入った。基盤開発をやりたいと思いながらサービス開発者として最初働き、後に基盤開発チームにジョインするみたいな過去の経験があったので、今回もそういう感じでいけると考えていた。実際このチームには最初の1年だけ所属した後、次のチームに移った。
現状APIチームにいる人の誰よりもそのリポジトリにコミットしている程度にはその短い期間で色々書いたのだが、おそらく同僚の記憶に残っている仕事は、分散モノリスっぽい設計になっていたせいで障害の温床になっていたリポジトリのコンポーネント境界を動かし、適切にマイクロサービスとして独立させたことだと思う。この仕事についてはRailsDM 2018でも紹介した。
ちなみにTDはRails内からJavaScriptフロントエンドを扱わず、完全別リポジトリで別チームが開発する体制*2なのだが、自分は個人でReactやReduxを使っていたのもあり、自分で書いたAPIを呼ぶコンソールを自分で直しに行くこともあった。
TDは全然違うチームのプロジェクトに突発的に参加することも割と行なわれていて、例えば「来週からアメリカに飛んでこれ作ってきて」と当時CTOの太田さんに言われて弾丸で@mururururuさんとFluentd関連のGolang製プロダクトとそのUIを書いたり、@tagomorisさんがリードしていたJavaで分散システムを書くプロジェクトに入れていただいたりと、色々面白いことができた。
SREチーム
インフラが創業時からあまり変更されておらずデプロイ周りで開発効率があまりにも悪いことが入社時から気になっていて、そのあたりをどうにかする仕事も片手間にやっていたのだが、それを本格的にどうにかしてくれる人を採用できなさそうな雰囲気だったので、SREチームに1年だけ転籍して自分がどうにかすることになった。
元々どうなっていたかというと、cronで30分おきにChefが実行され、しかもランダムで失敗するので全台デプロイに最悪数時間かかり、各インスタンスにsshすることでデプロイ完了を確認するという感じだった。前の会社の基盤チームで開発していたデプロイ環境があまりにも快適だったため、あまりにも失望が大きく、これに近いものをTDにも作ろうと考えていた。
SREチームは元々AWS CodeDeployを使うための環境をローカルからAnsibleでプロビジョニングする感じで新ツールを作っていたのだが、使いやすさに色々不満があり僕がAWS Lambda上にそのスーパーセットとなるAPIをPythonで書き直した。これでSlackからもwebhookで呼び出せ、インフラの差分更新が細かくできるようにして、今日ではほとんどの開発者に利用されている。*3
基盤を整えた後はChefレシピをmitamae化するなどでせっせと新基盤に移行し、負荷が高いクラスタのオートスケールを実現したり、Ubuntuのバージョン上げたりDocker化したりした時にRailsアプリが遅くなったのをどうにかしたりとかした。
Backendチーム
3年目には、当初から入りたかったBackendチームに入ることができた。Backendには4つのサブチームがあり、そのうち主にPlazmaDBというTD内製のストレージレイヤーを開発するStorageチームに所属し、3年半くらい働いた。
TDではHadoop、Presto、FlinkなどのJava製フレームワークを扱うことが多く、そのためバックエンドではJVM互換言語が使われていることが多い。昔は大体Java、その後Scalaがクエリエンジンチームで流行り、僕がBackendチームに入るころにはKotlinが採用されていて、Backendが作ったサービスのほとんどは今ではKotlinになっている。
僕はTDのメインのRailsアプリからストレージ関係の機能をマイクロサービスとして切り出す仕事をした後、そのサービスをベースにカラムレベルのアクセスコントロールをプラットフォーム全体に適用可能にするプロジェクトを1年くらいリードし、あとはPlazmaDBのストレージを最適化するワーカーを書いたり、クエリを最適化するための統計を提供するような仕事をした。
APIチームでご飯を食べに行った時、@kamipoさんにBackendに移ったら何をやりたいか聞かれて、ストレージ周りをやりたいという話をした記憶があるが、実際その時想像していたような仕事が最後の方はやれていたように思う。
どんな会社なのか
OSSで活躍している人が多い
MessagePack, Fluentd, Embulk, Digdagを生み出した古橋さんを始めとして、GitHubで数百、数千のスターを集める人気リポジトリの作者が多い。Rubyはここ何年か@nalshさんがリリースマネージャをしているし、今もRubyコミッタは4人、Railsコミッタも1人いる。TDの人が作っている何らかのOSSにお世話になっている人は多いのではないだろうか。
僕も古橋さんみたいにTDの仕事をきっかけに広く使われるOSSを生み出したいという野望があったが、多分一番うまくいったのは、@tagomorisさんのプロジェクト下でJavaでサービスを書きながらRidgepoleのRuby DSLでスキーマ管理をしていたミスマッチ感から思いついたsqldefで、これはありがたいことにいろんな会社で使われている雰囲気を感じる。あとはrspec-openapiも仕事中に思いついたもので、これもちょっと使われていそう。
エンジニアがお金を稼ぎやすい
CEOの太田さんが元々エンジニアで技術力も高く、またTDのビジネスのコアに自社製、他社製問わずOSSが使われていることから、エンジニアリングの重要性や難しさを経営陣が深く理解している組織であると思う。その上、TDに入ったエンジニアを全員キャッシュリッチにしたいという話を太田さんは以前していた。
TDでは、普段良い仕事をしている人たちは、会社がうまくいった時にドカンとお金をもらえている雰囲気がある。TDがArmに買収されたころ短冊に一億円と書いたり、SoftBankの下で再出発となったころは二億円と書いたりしたが、CEOやCTOもこれを見て本気にしてくれるし、いずれもがんばれば現実となるような機会や裁量が与えられていた。転職でこのチャンスを逃すことは残念である。
大規模データの分散処理に挑戦できる
TDはエンタープライズなお客様にフォーカスしてプロダクトを作っているため、TD自体の会社のサイズは大きくなくとも、大規模なデータを持つお客様を何社も引き受けることになるので、それをマルチテナントで捌いて性能を出すことが求められる。
分散DBの性能でGoogleやAmazonと全面的に戦う、というような開発投資はしていないが、自分たちのお客様の用途に特化した性能改善は盛んに行なわれており、分散DBの最適化みたいな面白い仕事ができる。単に分散DBそのものを売るよりは、それを活用した周辺ツールとの統合的な体験で価値を生み出すビジネスをしているため、何を最適化するとどうビジネスにインパクトがあるかわかる面白さもある。
クックパッドのデータ活用基盤をTDからRedshiftに移行した青木峰郎さんが今はTDに所属しているおり、日々楽しそうな仕事をしていることも書いておきたい。
英語や海外移住に挑戦しやすい
日本人が多いので英語話者が日本人の英語アクセントに慣れているだけでなく、人数が多い分英語力も様々であるため、英会話を勉強中の人への許容度が高いように見える。もちろん入社面接では多少英語を話せる必要があるが、それさえ突破してしまうと、無料で英会話レッスンを受ける機会がよく設けられてるし、単純に英語ミーティングの機会が増えるとそのうち慣れる。
僕自身、東京オフィスからマウンテンビューオフィスに移籍した組なのだが、どうしても移住がビジネスに必要みたいな状況ではなくとも、タイムゾーン間のバランス調整や知見共有みたいな名目で希望者が時おり北米*4へ移住していたりする。その際のビザのサポートは会社がやってくれて、初めてのUSビザもグリーンカードも全てTDのサポートで取得させていただいた。
今後やりたいこと
言語処理系キャリアを築く
僕はこれまで分散システムと言語処理系の2つの技術に主に興味があった。学士論文も分散システムのモデル検査のための言語のコンパイラを書くものだったので両方に関係している。学部卒業後は仕事で分散システムの開発をしつつ、個人の時間で様々な言語処理系を書く形で両方の分野に常に触れていた。
社会人を続けながら大学院で勉強し、どちらに関しても複数の授業を取った結果、いずれも人並以上には好きそうだが、最もこだわりがあるのは言語処理系の方であることがわかってきた。その結果、子供が産まれてから仕事以外に使える時間が短くなって必然的に言語処理系に使える時間の比率が下がっていくことにややストレスを感じるようになり、一番興味のある言語処理系の方を仕事にしてそれ一本に集中するのが幸せなのではないかと思うようになり、転職した。
言語処理系の開発がそれ自体でお金を生むのは難しく、日本ではそういう仕事はかなり限られてそうに思うが、アメリカで求人を眺めているとまあまあ面白そうな選択肢があるし、特にシリコンバレー在住で採用してもらう場合は、日本に住んでたら考えられないような待遇が得られる*5。片働きで子供を養うことを考えると、これは僕にとっては実質シリコンバレーに来たことで可能になったキャリアと言える。今回のポジションを可能にしたShopifyにもとても感謝している。
3億円貯める
僕はアメリカに出稼ぎに来ていて、さっさと3億円貯めてリタイアしたいという話はRubyist Hotlinksでのインタビューで2年前から公言している。この意思は今も変わっていないのだが、妻も僕も主に食が理由でなるべく早く日本に帰りたいという気持ちがあり、あと10年くらい働いた後、子供の学校とかの区切りが良くなったタイミングで日本に帰ろうと思っている。
流石にここから10年で資産3億円に達する自信はないのだが、総資産が $2M (約2.7億円) 以上あるとグリーンカードを放棄する時に総資産の2割にあたる額を課税されるという話があり、$2M に達する前に帰った方がお得という感じもしており、まあなんか結構稼いだなみたいなところで帰ろうかなという感じ。
ICとして更に昇進する
仕事というのはお金を稼ぐためにやっていることなのでお金は大事だが、一方でそれだけを追求するとメンタルがやられて持続性がなくなるので、TDでは僕は50%の時間を会社の売上や自分の昇進に最適化し、残り50%を自分が技術的に興味のある仕事をやる方に最適化することでバランスを取りながら働いていた。
その前者の50%にあたる努力の過程で、昇進のために上司と相談した結果、上司は僕の技術的なスキルには特に不満がなく、かわりに大きなプロジェクトのリードや他チームとの調整をこなしたり他のエンジニアを成長させたりする能力を示すことが求められたため、ここ2年くらいは割とそのような業務の機会をいただくことが多くなった。自分のコミュニケーション能力は特に強みではないと思っているのだが、実際はやってみると周りからの評価が上がったように見えた。
これは、自分が得た技術的な知識を自分の仕事に活用するだけでは会社やビジネスに与えるインパクトに限りがあり、他の人も自分の能力を活用して仕事がしやすくなるようにすることで、低い労力で大きな成果を生み出すチャンスになるということだと考えている。少し前に@__gfx__さんのICに関する記事が話題になったが、僕はICというのは生涯現役でコードを書くという側面よりは、昇進するにつれむしろそれ以外のスキルが重要になるキャリアパスだと受け止めている。
ICとして昇進するというのは、つまり自分が会社に大きなインパクトを与える能力をつけることだと思っていて、たくさんの利益を生む大きな組織でもそれができるようになれば、仮に自分が直接売上を立てない部門にいても、いっぱいお金をもらう経営的妥当性ができるので収入に直結するため、さっさと3億円貯めて日本で自由に生きるためにもがんばっていきたいと思う。
*1:事実、自分の退職が確定してから退職するまでの間に、転職したがっている友人をリファラルでいれようかと試みたりした。自分にリファラルボーナスが入らなくてもおすすめしたいほど良い会社ということ。
*2:Railsのフロントエンド周りは常にわちゃわちゃしているので、それに影響を受けない設計であったのは何かと便利だったと思う
*3:一方で、これは短期的に目的を実現するために考えたアーキテクチャなので、長期的にはコンテナベースのデプロイに移行したりもっとコミュニティベースの実装を利用できるように変えた方が良さそうだなあと何度か声を上げていて、2022年の現在では本格的にサービスのデプロイをEKS移行するプロジェクトが動いている。
*4:アメリカのマウンテンビューか、カナダのバンクーバー。最近はバンクーバーに移住する人の方が多い。
*5:といっても、無からお金は生まれないので、自分がどのように会社やビジネスにインパクトを与えられているかは常に考え続ける必要があると思う。
