「転職が成功か失敗か決まるのは(退職|転職)エントリを書いた時じゃない、入社から半年経ってからだ」とうそぶきつつ大した振り返りもせず早2年…
というわけで Quipper に転職してちょうど2年が経過したので自身のことを中心に振り返ってみる。
2年前
思えばよく採用されたな…と思う、タイミングが良かった。現在は採用のハードルが上がっているので今の Quipper に2年前の俺が応募したら不採用になるだろうなと思う。これはチームの成長の証左でもあるので良いことだ。
転職まで
当時の俺はSIer (システムインテグレーター) に勤務する新卒3年目の SE (システムエンジニア) で、1年目はちょっとした Java の研修というトンネルを抜けるとそこはテスト仕様書と人力テストの国…。技術力を高めたいと主張して色々仕事を振ってもらってもコードを書く時間は半分も無かった。日曜プログラマとしてたまにコードは書いていたが自分の業務を少し助けるものか、ちょっとしたおもちゃを作ってばかりだった。原点…と呼べるかすら危ういこの環境、とても狭い世界で、小さなプログラムと大量の仕様書を書いていた。
学校という環境設計の中で生きていけないという諦念とともに教員の道を辞した人生をどこかで清算したいと思っており、こうした信念と実にマッチした Quipper と比肩する候補はその時は存在しなかった。今も存在しないかもしれない。
採用が決まってから
これまでの自分のスキルが全く通用しない世界に飛び込むのだと思ってとにかく焦った。
あまりに焦ったので「入社までに何を勉強すれば良いでしょうか」と正直に聞いた。その時に刺身さんが返してくれた内容は「これは報いないといけない」という思いともによく覚えている。
2015年の8月は業務をさっさと終わらせて家に帰ってはアドバイスに従って Quipper で使う予定のテクノロジーと英語をほぼ毎日勉強し、何かしら形にしておきたいとブログを書いていた。完全に忘れていたが2015夏タグが付けてあったので今でも読み返せる。
転職直後
絶対プルリクキメ太郎と気張っていった初日、"予習"の甲斐あってかなんとかキメられた。最初のpull requestが"要らなくなった機能の削除"だったのは不思議な気持ちだった。それまでコードをちゃんと消すチームでの開発をほとんどしてこなかったのだ。
このとき、GitHub flow も pull request ベースの開発もCIも staging app も何もかもが新しかった。
詳細は割愛するが入社してから暫くは受験サプリというプロダクトを Quipper のコードベース上に migrate する大掛かりな移行プロジェクトをやった。日本の web engineer は当時5人のみで、終わるかどうかとてもあやしい量のタスクがあった。2015年末頃には振り返れば炎上と言って差し支えないほど働いていた。
前職のデスマーチ案件よりは稼働時間は少なかったのと、とにかくコードを書くことだけに集中できたので当時はそれほど苦に感じなかった。土日に出勤してテスト項目をひたすら消化していた頃に比べれば何もかもが遥かに良かった。ただ、もう一度やれと言われたらやりたくはない。
このプロジェクトが終わってからは一度も休日出勤はしていない（はず）。
それから
あっさり2年が経ってしまった。
チームは数倍の大きさになり、その中で俺は今年度は Engineering Manager という役割を担うことになった。Quipper の Engineering Manager は世間一般でいうテックリードとも(プロジェクト|プロダクト)マネージャーとも違うところにあって、卓越した技術力とかずば抜けたマネジメント能力が求められるものではないと考えている。組織やプロダクトといった大きい主語の実存に対して物言いたい人が集まっている立場の気がする。
そう、Engineering Manager という役割につき、チームに貢献するメンバーとして一人前の自覚はありながらも、いちエンジニアとして俺はどんな奴なんだ？どうありたいんだ？と今でも問い続けている。
先月にメキシコの Engineering Manager が日本に訪れた際に俺のキャリアについて聞かれることがあった。その時に「実のところ俺が “real engineer” としてのキャリアをスタートしたのは Quipper に入ってから。つまりまだほんの2年前なんだ」という話をした。
いったい何が “real engineer” なのかは言った俺にもわからないのだが、確かに言えるのは前職の俺は “SE” であってエンジニア*1ではなかったということだ。今は自分が信じるエンジニア像に少しは近づいた…はず。
エンジニアとしてどう変わったか
この2年間は、かつて担当していた小さな業務システムでは深く考えなくてもそれなりにやれていたことを何回も何倍も真剣に見つめ直したし、数え切れないほど新しいことも獲得した。例えば…
チーム開発の基礎。GitHub flow とレビュー。レビューしてもらいやすい pull request とそうでないものの差異。誰かと一緒にあるいはチームでコードを書くということ。コードレビュー会。可読性。リファレンスの貼り方。Excel方眼紙ではないドキュメンテーション。
パフォーマンスのこと。N + 1 クエリがサービスに及ぼす影響、防ぐ方法、万一混入した場合でも見つけられるようなパフォーマンスモニタリング。データベースの特性とそれに応じた実装。富豪的計算をしすぎない。
キャッシュ。強いキャッシュと弱いキャッシュ、それぞれの実現方法。データの更新頻度、転送量の削減。
Single Page Applicationのこと。Backbone.js + Marionette.js に始まってReact.jsへの変化・移行。メリットとデメリット、選ぶべきときとそうでないとき。
デザイン。ユーザー目線とは。ビジュアルではなく体験にこだわること。どうやってデザイナーと協業するか。
API設計。SPAのバックエンドとして見た時の、REST・RPCそれぞれのメリット、デメリット。ステートレス。ページング。あるいはネイティブアプリのバックエンドAPI設計。後方互換性。
外部システムとの連携インタフェース設計。冪等性とリトライのこと。大量データの捌き方。
テスト。ユニットテストやフィーチャーテストがいかに開発に安心感を与えるか。E2Eテストの重要性と難しさ。テストは実装の最初の再利用、つまりテストが書きにくければ設計が悪いということ。
リリース。小さく繰り返すことの重要性。ユーザーの驚きを減らす。バグはすぐ直す。でかすぎる feature branch は作らない。コードの変更なしに feature toggle できると理想的。
データ分析。BigQuery や TreasureData のこと。イベント設計に失敗すると分析が活きない。イベントトラッキングの発火タイミングのコントロールに気をつける。データがあって初めて見えるユーザー像もある。A/Bテストの設計と実装、振り返り。
アーキテクチャ。複数アプリケーション、複数データベースがいかに複雑か。アプリケーション間の依存関係の整理がいかに大事か。web サーバとアプリケーションサーバでできること・できないこと。
採用のこと。自分たちのことをよく知らないとできない。短時間で候補者のことを最もよく知るための質問とは。コードテストの評価の仕方。
グローバル。英語。相変わらず今でも手こずっている。ハチャメチャでもひどい発音でも通じるが、それは相手の善意によってコミュニケーションが成り立っているから。リモートだからこそ気にすべきコミュニケーションのやりかた。マーケットの特性。localization、internationalization。
カスタマーサポート。日々ユーザーと直に接しているメンバーからプロダクトへのフィードバック。使いづらい機能やバグをリリースしてしまったときのゴメンナサイ感。
受託ではなく自社のプロダクトをやっていくということ。ユーザーフィードバックのありがたさとつらさ。競合への意識。
思いつきで書きなぐっただけでもこれだけのことを2年前の自分はほとんど知らなかった。
生活の変化
裁量労働制になり10時どころか11時出社も危うい体となってしまったがライフスタイルを自由に構築できるので、妻と京橋でランチしたり早く帰ってジムに行ったり銭湯に行ったり出社前に家で英会話レッスンを受けたり走ったり自宅近くでランチしたりできる。
福利厚生・給与
書籍購入やカンファレンス参加費を社費でまかなってもらえる。それぐらい当たり前、という風潮があるが前職ではまったくもって当たり前でなかったのでありがたい。
ダメ元で頼んだら会社に懸垂台と卓球台を置いてもらえたのもありがたい。
給与は転職時の1.8倍ぐらいになったのであまり不満はないが良ければもう一度1.8倍してほしい。
これから
勤続年数でいえば今のチームでは相対的に古株ぽくなってしまった。もろもろ聞かれたり答えたりするのは全然構わないのだが、ドメイン知識以外のところでもっと勝負したいとかいう気持ちがある。1つの技術や言語に精通している感覚が未だ持てていないことに強い課題意識を感じる。
Be the worst の精神を忘れたくない、技術系のコミュニティから刺激を受けたいという思いもある。直近では勉強会やカンファレンスでの登壇や週1~2での副業を積極的にやってみるというのも卑近な方法だろうか。
今年度になるまではサービスの基盤を作るためにやらなければならない山積みの仕事を終えた今、ようやくエンジニアとしてやりたいことを提案したり挑戦したりするフェーズが来ているなと感じている。だからこそインプットとアウトプットにこれまで貪欲になろうとしているのかもしれない。
中期的には日本国外に居住したり、教育以外の事業領域も体験してみたい。だが、最終的にはやはり最強の教育サービスを作ってみたい。
結論
冒頭で"転職が成功か失敗か"という表現をしたけれども、実際にはその2択ではなく「成功ぽい」「失敗ぽい」というようなグレーゾーンが大半を占めるはず。
俺にとってはどうだったのか諸々考えてみたけれど、2年前に戻ってやり直せるとしても同じ転職を選ぶんじゃないかなぁ…。これは限りなく成功に近い転職と言えるだろうか？
*1:ここでは"エンジニアリングに関する専門的な技術を持った実践者"という意味
