2017年の4月1日から、リクルート子会社のQuipperでWebエンジニアとして働いている。
なぜJoinすることにしたか
もともと新卒でリクルートホールディングスに入社し、新規事業開発の部署や海外投資を担当する部署でエンジニアとして4年ほど働いてきた。
会社では良い体験をたくさんさせてもらえたけれど、小さなチームを転々としたり、社外の組織にコンサル的に関わることが多かったので、もう少し成熟した組織・プロダクトに腰を据えて関わるということをしてみたかった。
そうしたなかでちょうど組織の再編があり、よいタイミングだと思ったので社内の転籍制度を利用してQuipperに応募をした。実際にはリクルートのなかだけでなく、転職エージェントに会ったりして外の会社も少し探ったりしたけれど、結局以下の3つを大事にした結果Quipperだった。
- 精神的にスタートアップである組織である
- グローバルで意義のある事業を展開している
- エンジニアとしてプロダクトを育てることのできる文化・裁量がある
Quipperについては会社のHandbookや、CTOの中野さんのブログを読むと少し前の状況がよくわかると思う。
短期連載Quipper CTOより 第1回: Quipperの今 - Masatomo Nakano Blog
入社のプロセス
社内の転籍制度を利用したけれど、レジュメは一応書いた。たぶんあんまり参考にされていないと思う。他にコードテストがあって、簡単なRailsアプリをシュッと書いた。
転籍の時期が悪く、コードテストの提出を急かされたので大変だったけど、フィードバックではそれなりの評価をもらえて通過できていたようなので良かった。あとそれは0から書いたけど、GitHubで検索すると過去の受験者のコードが見つかることは後から気づいた。まぁコピペはどうせバレる。
それとは別にWebエンジニアチームのマネージャー+リーダー、CTO、CEOと3度の面接をし、転籍となった。
入社してみた感想
グローバルなチーム？
知っている人は知っているが、リクルートの出しているスタディサプリの裏側はQuipperのメンバーが作っており、コードベースの大半もQuipperがグローバルで提供しているQuipper VideoやQuipper Schoolといった製品と共通になっている。
グローバルチーム、といいつつ、僕を含め東京の開発メンバーはほとんどがスタディサプリを作っているので、グローバルに向けたプロダクトを作っている、という感じは期待していたよりも少なかった。
といってもそれは主観的な話であって、全体としてはSlack上でのミーティングやGithubのPull Requestは英語が当然だし、タイムゾーンを意識した非同期なコミュニケーションが多い気がする。Quipperはそのへんのバランスがちょうどよくて、外資のように英語が話せないと死ぬというわけではない（むしろエンジニアで英語話すのは苦手、という人は多い）が、コミュニケーションに英語が混ざるのは当たり前だよね、という雰囲気がある。メンバーも外国人の開発者が増えつつあるので、今後、より英語での会話は増えそうな予感はする。
エンジニアリングと組織
QuipperはGithubの使い方が上手くて勉強になる。全ての開発タスクはGithubのIssueとして一つのリポジトリにまとめられていて、各プロジェクトごとにラベル付けされている。Github Projectsのカンバンで開発ステータスが管理されていて、プロジェクトごとにだいたい2~4人程度がアサインされる。Pull Requestは開発者同士でレビューしてからマージする。リリースはIssueについたマイルストーンをもとに週次で行われていて、リリースノートもGithub上でIssueとして公開される。全ての情報をGithub上にまとめることで、上手く回っているように見える。
これまで自分が開発するなかで、あまり”チームでやる”ということを意識したことはなかったけれど、Pull Requestをレビューしてもらえるのはとても勉強になるし、ポエムを書く場所や折々のKPTがあり、組織として振り返りをして改善していくという文化が根付いていると思う。個人としても、エンジニアリングマネージャーとの1on1でキャリアや直近の仕事の仕方について相談に乗ってもらえるのは非常にありがたい機会になっている。
Webのチームの周りを見ても、インフラを管理するSREチームはなにかあってもすぐ対応してくれるし、ネイティブエンジニアもすごい人ばかりで強いプロダクトを作るための基盤がしっかりしている印象を受ける。ビジネスとしても勢いを感じる。一方で、そうやってビジネスが伸びているからこそ、いわゆるProduct Managerと呼ばれる役割の人はまだ足りていないかもしれない。
個人的に良いな、と感じたのは、エンジニアがユーザの近くにいるということだ。この間は自分もユーザインタビューに同席させてもらった。自分が開発調査の必要なCS対応をすることもあるし、CSのチームから機能改善のフィードバックもされる。学校向けの開発をしているチームでは、エンジニアも希望すれば営業同行が可能で、実際の使われ方を見る機会がある。個人的に、過去こんな風にフィードバックを得られる機会はそれほど多くなかったし、エンジニアとして、ビジネスサイドと一緒にになってユーザにとっての正解を考えられるような文化・組織を求めてきたところがあったので、これについては満足だし、ひと安心といったところ。
プロダクトと技術的負債の辛さ
Wantedlyにもあるように、テクノロジースタックとしては以下のような言語・ツールを使っている。
- 言語: Ruby, JavaScript, etc.
- フレームワーク: Ruby on Rails, Backbone.js, Marionette.js, React.js etc.
- データベース: MongoDB, Redis, PostgreSQL
- インフラ: AWS, Heroku, GCP
QuipperもStudySapuriも、大きく分けて学校向けのプロダクトと学習者向けのプロダクトの2種類があるけれど、どちらもWebはサーバとフロントで分かれたSPAの構成になっている。
ある程度覚悟はしていたけれど、予想していたよりも歴史の詰まったプロダクト、という第一印象だった。もちろんテストはきちんと書かれているし、それなりにモジュール化されていて変更しやすいようにはなっているけれど、要求される仕様の複雑さに由来する辛さがあり、そこに時代的な背景で古くなったライブラリなどが乗っかった結果負債化している感じがする。
顧客への価値のデリバリーを止めて負債を一括返済しよう、と言うほど子供ではないし、言ったところで一人ではどうしようもないけれど、いずれはどうにかしないといけない。実はQuipperで見てみたかったことの一つが、こうした一人では全体を把握することも難しくなった大きなプロダクトの技術的負債に組織としてどうやって立ち向かっていくのかということだった。（あともう一つはグローバルなプロダクト開発をどうやって進めているか、だった。）なので、自分としてはちょうどよいケーススタディくらいに思うし、メンバーの一人として、こうした負債の返済は望むところだと思う。組織としては、20%ルールではないけれど、こうしたエンジニアリングをするチームがあるのが良いのかもしれない。
もう一つ苦労していることの一つに複雑な仕様の把握がある。とはいえまだ入社してたった2ヶ月なのでなんとも言えないけれど、周りを見てもそこに苦労して生産性が下がっている感じが否めないので、なんとかしていきたい。
個人的な生活の変化
Quipperはフレックスでとても働きやすい環境だと思う。MTGも多くないし、一日中コードを書く生活を送ることができている。
仕事でコードを書く生活をしていると、家に帰ってからもコードが書きやすいことに気づいた。たぶん使う脳のコンテキストをスイッチしなくて良くなったからだと思う。自分としては、Quipperにいるうちにきちんとエンジニアリングの素地を身に着けておきたいという思いがあるので、しばらくはがっつりコードを書く生活を楽しんでいたいと思う。
一方で、触れている技術については狭まった感がある。Railsも各種JavaScriptフレームワークもそれぞれ過去にそれなりに経験してきた技術で、それだけを生業とする生活に限界があるのではないかという漠然とした不安がある。巨大なコードベースや他の優秀なメンバーの書いたコードで勉強させてもらいつつ、個人としては技術の幅を広げるようなバランスをとっていきたい。
少し長くなったけど、世界中に教育を届けるためにがんばりたいという所存です。やっていくぞ。