hokkun blog

技術の話をメインに、たまに糖質制限の話とか色々したい予定。

新卒から6年半ソフトウェアエンジニアとして働いた会社を退職します

タイトルの通りです。しばらく長い文章を書いてなかったのでここまでのキャリアの振り返りでも書いてみよう。

就活

2014年冬から2015年春にかけて就活の時期だった。

当時の就活の資料を見てみると(Evernote に几帳面にしっかり残していた;今は Notion に移行したが)、企業を選ぶ基準としてこんな事を言っている。

問題解決を行う上でできるだけユーザの目線に立ちユーザの課題ベースでテクノロジーを駆使することを大事にしている企業

当時の自分は BtoC のテック企業を中心に応募をしていた。そういう意味では、技術はユーザのために使ってなんぼである、という考えは今も変わらないなと思う。現職もとい前職は当時すでに国内ユーザ数がかなりのところまで来ており、そういう意味では最高の選択のひとつだった。

当時はすべて合わせて8社にエントリーして4社から内定をもらっていた。すごい。

うち2社は外資系で、ソフトウェアエンジニアとしての採用ではなかったのでやめた。エントリー自体は勉強がてらしたが、やはりキャリアの最初はものづくりでスタートすべきだと考えたというところが大きい。

残る2社の中でこの会社を選んだ理由はいくつかあるが、成長度の傾きが急峻な方を選んだ、というのは一つ大きい。もう一つの内定先はある事業で当時安定した利益があり比較的運用フェーズのような感じに大学生の自分には映っており、どうせ数年で移り変わる業界に行くなら今はこっちだろう、ということである。まあ当然民間企業である以上利益を求める必要があり運用フェーズだけの会社なんてないことは後々気づくのだが、まあそれはそれで。

まああとは普通に待遇とかもあったけど、この辺は生々しいので飲み会とかで。。

研修

2016年春に新卒として入社した私を待っていたのは様々な研修であった。当時の新卒は全職種合わせて 30-40 人程度で割と仲のいい同期だったと思う(今も職種問わず交流がある)。

最初は全職種共通でビジネスマナーなんかを学んだあと、ハッカソン演習、そしてエンジニアだけの研修と進んだ。

テーマは「メッセージングアプリの実装」。当時は開発系のエンジニア同期は 10 人に満たなかったので、2 チームに分かれて演習が進められた。今とは少し趣が異なるが、HTTP 利用禁止で、TCP の上に独自のプロトコルを実装するという面白い制約があった。

当時の hokkun は R&D っぽい開発しかやっていないうえチーム開発も初めてだったので pull request なにそれおいしいの状態であった上、ウェブ開発やクライアントアプリの開発もほとんど素人だったのでここは非常に苦労した覚えがある。今でこそソフトウェアエンジニアで新卒入社を目指す大学生はみんなウェブ開発のアルバイトやインターンシップを経験している(イメージがある)が、当時は 2022 年の状況ほどではなかった(はず)。サーバ側の MVC/MVP といったアーキテクチャパターンやクライアントアプリの UI スレッドとその他のスレッドがイベントでやり取りするようなパターンなどなどなどのウェッブ技術は、main 関数にダ〜〜っと実験のコードが書かれているプログラムしか読み書きしていなかった私には青天の霹靂といった様相だった。周りの同期がとてもできてあまりに辛かったので当時人事に半泣きで相談に行ったのを覚えている(マジ)。

とはいえ、優秀な同期が設計をだいぶやってくれたので、それに従ってコードを書いていく作業自体は共同開発感があってとても楽しかった。

この研修でソフトウェアエンジニアといえども莫大な勉強しなければならない領域が広がっていることをよく知ることができた。下記は一年目の私が書き始めてすこーしずつ書き加えていた記事だが、序文から当時の辛さをうかがい知ることができる。

qiita.com

最初の三年半 - ゲームプラットフォーム

入社研修を終え、最初に配属されたのはゲームのプラットフォームを開発する部署である。ゲームと言うと Unity とかセッションサーバとか特殊な技術が必要な感じがするが、あくまで「プラットフォーム」なので、ゲームに必要な周辺機能を提供する、というところが正確なところか(最近では GBaaS*1 や MBaaS *2 という表現もある)。 なので、ここでは標準的なウェブ開発の一通りを体験したと思う。

この部署は比較的海外のメンバーが多いのもあってか、全社的な技術スタックから少しずれていたりしたのも面白かった。メインの DB には HBase が原則として使われており、メタ情報は Mongo をラップした独自のアプリにキャッシュしていたり(この辺は同僚のこの記事 に詳しい。)と少し癖のある感じだった。逆に RDBMS はあんまり利用していなかったので SQL をギョームで全然書いていなかったのはちょっと惜しい。

コミュニケーションとしては非常に面白いチームだった。日本のチームだけでも割と毎日のようにランチへでかけていたし、コロナ前から数拠点でのビデオ会議は当たり前で、出張も多くあった。外国への出張では現地の同僚に大量のお酒を飲まされでもてなされ、何度千鳥足になったことか・・。とはいえコロナ禍を迎えて久しい今思い返すと、あれがあったからこそ離れていてもいわゆる仕事の調整的な部分がうまく回っていたんだろう。今でもプライベートで当時のチームのメンバーとはやり取りをしているし、社会人としてのいろいろを学んだ。

在籍後半はリードとしての振る舞いも求められ、会議のファシリテーションモックアップの作成など幅広い業務を体験できたのは今思うと幸運だったかもしれない。

当時の私の仕事は以下のテックカンファレンスでの発表資料などで垣間見ることができる。

www.slideshare.net

www.slideshare.net

最後の三年 - Data Management Platform

2019 年の秋に DMP の開発チームに異動した。社内異動が比較的に自由にできるようになる制度が始まっていたので、スムーズに異動できた。DMP とは Data Management Platform の略で、広告を始めとする BtoB 向けサービスにおけるデータの利活用を行う機能の集合体、的な存在である。

いわゆるクリックやコンバージョンの計測に関するパイプラインや、カスタムオーディエンスと言われるターゲティングのための機能開発を行っていた。データドリブンな仕事なのでウェブの API や画面を開発するというよりは Kafka のコンシューマをゴリゴリ書いてつないでいく、というような仕事がメインだった。

この部署では比較的全社共通スタックを用いていて、MySQL/Redis を中心に大きなデータは HBase を併用していた。また、前述の通りデータパイプライン的な側面の強いコンポーネントの集合なので、Kafka はヘビーに使っていた。しかし、会社に専門の Kafka 運用をやっているチームがいたので割と安心して気軽に使えたという側面は大きい (この辺は この記事 が面白いだろう)。

このチームでの面白さとしてはやはり、数分でも止めれば大きな利益損失につながるなどちょっとしたミスが大きな事故につながる可能性がある緊迫感を体験できたということが挙げられる。なので比較的あらゆる変更を本番にデプロイする際はできるだけ安全サイドに倒していく試みを少しずつ取り入れていった。CI/CD 周りは改善点も大きかったため、自分の在籍時には少しずつ潰すような改善を取り入れていった。長期的に発露する問題も多く、アラートの対応周りもある程度システマティックに対応できるような仕組みを構築するようにしていた(今別の同僚によってさらに進化もとい深化をしているところだ)。

もう一点、法律や業界の動向について常にアンテナを貼っておく必要があったのも面白かった。個人情報保護法は最近大きな改正があった*3し、Apple の ITP や Google の Privacy Sandbox など、広告や B2B プロダクト周りはエンジニアが追っておくべき方面が(技術以外にも)とても多い。

詳しくは、以前採用イベントで話した資料をおいておく。

logmi.jp

転職活動

2022 年に入ってから少しずつ社会勉強がてら転職活動を始めた。

今の会社をやめるぞ!という意思があったわけではなく、文字通り経験のためというところが大きかった。なので、ヘッドハンターに連絡をしてみたり、いろんな転職サイトに片っ端から登録してみたりした。最初の就職活動時の BtoC をやるぞ!という夢がなぜか最初の会社では叶わなかった(もちろん自分の選択によるところも大きいのだが)ので、事業会社かつ toC のサービスを展開している会社を中心にアプライした。事業のドメインも非常に重要で、自分がユーザ目線であんまり興味ないサービスを開発していると割とすぐ飽きるというのは経験として感じていた。

また、ソフトウェアエンジニアリング一本では飽きそう&より上のレベルの人たちに勝てないと思った*4ので、機械学習をやっている会社の話を聞いたり、ソリューションアーキテクトと呼ばれるようなお客さん相手にシステム設計のお手伝いをするような役職の話を聞いたりもしていた。とはいえ、まだ若い(はずな)ので一旦はまだコードを書く仕事をしたい、サービスを作りたいと思い、プロダクトコードを書くソフトウェアエンジニアの仕事を続ける方針で探した。また、コミュニケーションの不自由さをなくしたいという気持ちとエンジニアリング以外でなにか尖ったのものがほしいという気持ちもあり、グローバルな職場を求めて英語環境の会社5つにエントリーした。実際は外資系(かそれに近い環境)かつアプリのバックエンドエンジニア職となると、あまり選択肢がなかったというのが正直なところである。

いわゆる外資テック系の面接の準備は一通りやった。中でもこのサイトにはかなりお世話になった。

www.techinterviewhandbook.org

以下は箇条書きでインタビューの感想。

  • コーディング試験対策は自分では結構やったつもりだったが、やはりまだまだ LeetCode の Middle を割とスラスラ解けないと厳しいかな、というのが率直なところ。アルゴリズムの勉強はもっと早めにやっても良かった。
  • コーディング試験でも結局 naive な solution から英語でコミュニケーションを取りながら optimize する能力を求められているので、そこも英語力は割といるなと思った。よって次機会があれば mock interview を必ず受けようと思っている。 こんなサイトこんなサイトがある。
  • 大学生の就活活動と違って平日は仕事があるので、割と何社も受けてると普通にきつい。本当に行きたい会社数社に絞ったほうがいいかも。
  • 久々に基本的なデータ構造とかアルゴリズムをガッツリ復習してると、ギョームの時も前より時間計算量や空間計算量に気をつけるようになったのでいい影響があった(気がする)。
  • 大手外資系やメガベンチャーをメインで受けていくなら基本的には(少なくとも日本の)ヘッドハンターにお願いするのは不要かなと思った。自分の知らない会社を知る、とかなら意味がありそう。
  • どこいってもいわゆる behavioral interview がある。過去の経験を英語で simple かつ effective に話す必要があるので、事前準備は必須。いわゆる STAR メソッド*5で整理しておくと良い。この辺 Amazon の採用サイトの情報量がすごいのでぜひ読んでほしい。

www.amazon.jobs

あとこんな感じで色々諸々整理したりしてた。えらい。

最後に

ということで、欲しい物リストです。

www.amazon.jp

*1:Game Back-end as a Service

*2:Mobile Back-end as a Service

*3:https://www.ppc.go.jp/news/kaiseihou_feature/

*4:この辺の話もなんか込み入ってくるので飲み会とかで...

*5:Situation, task, action, result - Wikipedia