いわたんち

いわたんちは概念となりました

退職エントリ2021

f:id:iwata_n:20210714132338p:plain

様式美の写真がコロナ禍で撮れなかったのでMacで代用。お気持ちを残しておくためにも退職エントリを書いておく。

2018年8月にDeNAに入って2020年4月に事業承継でMobility Technologiesに転籍になりましたが、 2021年7月15日を最終勤務日にして1.5ヶ月ほど有給消化をした後に9月1日から新しいところで働きます。 結局コロナ禍で、オフィス移転してから1度も出社せずに退職です。

次の会社は入社後にオープンにしようかなと。次もAndroidエンジニアをやる予定です。(多分)

TL;DL

他人の退職エントリ、読んでも面白くないものもないので3行でのまとめ

  • 最高の同僚だったけども、音楽性の違いで辞めるよ!
  • 転職活動はリファラルで低コスト戦略が当たったよ!
  • 引き継ぎをピンポイントでやるためにコミットログ分析するツール書いたよ!

所感

通算で3年ほどでしたが、DeNAではオートモーティブ領域や転籍だったり、最高な同僚にも恵まれ、色々と楽しい体験出来ていい会社でした。 仕事内容でもフルリモート下での市場不具合解析、ログ分析とか中々出来ない体験も出来て面白かったです。 入社時に考えてた自分の持っているスキルセットや経歴を活かせそうという思いは間違ってなかったかなと思います。

辞める理由は一言で言えば、音楽性の違いってやつです。

俺はヘビメタバンドやってるつもりだったけども、マネージャーはクラシックオーケストラを作ろうとしてた、みたいな感じです。 それぞれはそれぞれで良い事があると思うので、音楽性の違いだなぁと思いました。 この感じた違いは、色々と個人的にふりかえりしたり、同僚とワイワイして話ができて良かったです。 マジ同僚最高。色々と得た知見は次で活かせそうです。

事業内容の方向性にも違いを感じて、自分は自家用車を持ってるしタクシー配車アプリをほぼ使わないし、地元の親も自家用車移動でタクシーに乗らないといった状況で、 もっと自分や自分の子供や周りの人が使うサービスに関わりたくなり、今の事業内容では音楽性が違うなと思い転職します。

転職活動

自分の現状分析やチーム、事業、会社へ求めるものを整理し、育児中の自分が転職活動で取れるコストや音楽性の違いがある現状を考え、以下のような戦略で進めました。

  • リファラル採用をメインで書類選考パスし選考期間を短縮する
  • ビズリーチWantedly、転職ドラフトは良いタイミングでメッセージが来たら確認する
  • 同時並行は2社程度までにする

リファラルメインで活動したので自分のやりたい領域をやってる会社の知人や、声をかけてくれた友人とカジュアル面談を3社ほどやり、 希望度合いの高い順に1社ずつ攻めていく一本足打法戦略で進めていきました。

結果としては活動を初めて1ヶ月ほどで第一希望だった1社目でゴール出来ました。

振り返ってみてよかった点としては

  • 普段から転職サービスに登録してて職務経歴書とかが比較的最新な状態を保てていたので準備が楽だった
  • コロナ前から勉強会参加やカンファレンス運営スタッフをやっていたおかげで友人に恵まれていた

結果としては普段から用意をしておくことが大事だったってことかもしれません。

失敗したなと思った点としては

  • 知人にカジュアル面談をお願いしてたので断りを入れるのが中々悲しい気持ちにもなった(一緒に働けたらそれはそれで楽しいだろうな)

といった感じです。

引き継ぎ

引き継ぎの際にリポジトリマイニングを行って、自分しか触っていないコードを調べて、そこを重点的に引き継ぎ資料を書いたりコメント追記したりして、引き継ぎをしました。

github.com

Gitリポジトリのコミットログをガーッと見ていって、ファイルごとのコミット数やAuthorを集めてきてくれるgitのサブコマンドを作りました。 本当は他にもコミット回数やAuthorの多さから不具合の可能性が高いファイルを可視化しようとしてPythonで書いてたけども、 せっかくなのでgitのサブコマンドとして使えるようにGoで書き直してbrewでインストールが出来るようにしました。 brewでインストールしたら git analyze が使えるようになって、 対象になるリポジトリディレクトリで git analyze -search-only-target-author -author=iwata-n って感じで実行すれば 以下のようなコミット回数順でソートされた指定された人だけが触っているコードが出力されます。

git analyze -search-only-target-author -author=iwata-n
searchOnlyTargetAuthor
commit count, path, authors
6, git-analyze.go, [iwata-n]
3, .gitignore, [iwata-n]
3, args.go, [iwata-n]
3, logger.go, [iwata-n]
2, .goreleaser.yml, [iwata-n]
2, README.md, [iwata-n]
2, analyzer.go, [iwata-n]
2, commit_file.go, [iwata-n]
2, error.go, [iwata-n]
2, go.mod, [iwata-n]
2, go.sum, [iwata-n]
2, parser.go, [iwata-n]
1, LICENSE, [iwata-n]
1, sort.go, [iwata-n]

ただ、コミット数が多いリポジトリを解析するとすごく時間がかかります(手元のMBP16インチで2500コミットを解析するので5分ぐらい) git analyze -parse-file=result.json と指定すれば1度解析した中間ファイルをresult.jsonとして出力してくれて、次からは git analyze -parse-file=result.json -skip-parse -search-only-target-author -author=iwata-n と実行すればOKです。 今の所は分析が特定の人だけが触っているコードを調べるってことしか出来ないのであまり意味がないですが、今後出来ること増やしたときとかに役立つかなって思ってます。(本質的には解析の速度をあげるほうが良さそうですが)


最後に干し芋です

www.amazon.co.jp