dely株式会社を退職しました

前回の退職エントリー引っ越しエントリーから約2年半になりますが、9月末をもってdely株式会社を退職しました。在籍期間は2年8か月です

この手の話が好きではない人・事実確認だけしたい人はブラウザバックしてどうぞ

入社したきっかけ

新卒で入社した会社(つまり1社目)は受託開発的な会社でした。そこでは何か月かごとにプロジェクトが変わるというのはよくあることで、気が付くと(アルバイト時代も含めて)約2年半勤めていました。そういう状況で次第に継続的な開発をしてみたいと思うようになり、転職を考えていたところ、会社の先輩兼大学の先輩に良さそうな会社あるよと紹介してもらったのがdelyでした

当時見ていた会社情報はこのスライドで¹、情報の透明性を頑張ってます！みたいなところに魅かれて応募して、そのまま面接に受かっていき、入社することになりました

ということで、delyは2社目でした

やってきたこと

delyではクラシルの開発にAndroidエンジニアとして関わってきました。関わってきた機能単位で申し上げると、チラシ・ログイン導線・レシピカード・保存機能²のあたりに関わりました

ここ半年は上述以外の開発に関わっていたのですが、そのうち日の目を見ることになると思います

Squad体制

自分が入社してすぐに頃はスクラム開発をしていたのですが、少しするとSquadという開発体制に移行しました

Squad体制ではチーム内に存在しない職種やタスクが山積みで忙しい人のロールの部分は自然とみんなで手伝っていくことになっていくのですが、開発の意思決定に重要なデータ分析をする人・できる人が少なく特定の人にタスクが集中してしまうことがよくありました

そういうこともあり、自分も簡単なデータ分析は巻き取ってやっていこうという感じでチャレンジしてみたのですが、最初に思ってたほど怖い作業でもなく、自分でSQLを書いてCTRやRR³などが出てくると次第に楽しくなっていき、在籍中の後半には結構データ分析で頼られる存在になってたんじゃないかなと思います。というわけで、データアナリスト的なこともやっていました

モバイルエンジニアがデータ分析(?)と思う方もいるかもしれませんが、自分が組み込んだトラッキングログの仕様に詳しいのはもちろん自分ですし、ユーザー行動が背景にありつつ常に開発をしているのでデータ分析の観点・精度でモバイルエンジニアがSQL書いてみるのは結構理にかなっています⁴。この記事を読んでるモバイルエンジニアの方はぜひ怖いもの見たさでデータ分析にチャレンジしてみてください

リライト

自分が入社して半年ぐらい経った頃だったかなと思うのですが、アプリの起動速度早くしたいよねという話になりました。元々何年も開発していたコードだったのでリアーキテクチャーしたいよねというのがあった中で起きた話題だったのでテックリードが便乗して説得してくれてリライトをすることになりました⁵

自分自身、何年も同じコードに向き合うというのは初めてだったのですが、その上に既存のコードを書き直すという体験ができたのはいい経験になったと思っています

どういう感じのアーキテクチャーになったかは↓の記事のあたりを読んでもらえればだいたい想像つくと思います。さらに気になるならカジュアル面談の応募をしてみてください(たぶんですが、いろいろと聞けると思います)

いろいろと基盤を作ったよ

去年の秋ごろからアプリの主要機能の開発に関わるようになりました。クラシルではUIだけではなくUXもちゃんと考えて開発を行っています。その上、CGM⁶といった領域に手を広げ、ユーザーが投稿したコンテンツをユーザーが閲覧するというアプリ体験が必要になっていきました

Twitterとかを想像してもらうとわかりやすいのですが、TLにあるツイートをタップしてユーザープロフィールに行き、そこでそのツイートをいいねしてTLに戻ると同じツイートもいいねされてる状態がユーザーとしては好ましいですよね。そのように画面間のデータの同期もちゃんとやらないといけない時期になってきていたのです

そういうこともあり、自分が関わった保存機能の開発では可能な限りユーザー体験を損ねないようなデータの同期をすることにしました

実装自体は今もあまり問題を起こさずに動いていて、他の機能でも同様の同期手法が使われているのでちゃんと作っておいてよかったなと自分は感じています(ただし、目を離していると木っ端微塵に同期ロジックが壊されてたので、自分が作ったものはずっと目をとがらせておく必要がありましたね)

他にはクラシルのアーキテクチャーに沿った感じにポップアップメニューを出せる仕組みであったり、ユーザー行動を収集する汎用的なトラッキング基盤であったり、細々としたものまでその当時できる最善と思われる設計で実装しました。もし、数年後とかにこの記事を読んだクラシルのAndroidエンジニアがいたら、このクソ基盤を作ったのはこいつか！！となるかもしれませんが、設計は常にアップデートしないと陳腐化するのでしょうがないですね⁷

学んだこと

クラシルでの開発は非常に多くのことが学べました。プロダクトファーストやユーザーファーストといったような開発であったり、継続的な開発であったり、身近に強い人がいたり

多様性大事

身近に強い人がいると影響を受けることが多いですが、一方で自分も他者になんらかの影響を与えることができたんじゃないかなと思います。自分の強い領域と他者の強い領域それぞれが噛み合ってさらに強く・良いプロダクト開発になれるということをしみじみと感じました⁸。スキルスタックの多様性はとても大事なことだと思います

一方で多様性というのはスキルスタックだけにとどまるものでもないですね。たとえば、自分はタップ領域やタップエフェクト⁹の方向でこだわっていますが、画像の画質にこだわる人やアニメーションにこだわる人など様々な方向性の人がいて、それぞれ納得する品質に仕上げることができたらアプリ体験としてはいいものになりますよね

ユーザーに価値を素早く届けるのが至上命題

至上命題というのは言い過ぎかもしれませんが、プロダクトの成長のためにいかに価値を素早く提供できるかということに焦点の当たった開発をしてきました

toCプロダクトはユーザーにプロダクト価値を感じてもらいより多くのユーザーに使ってもらえないといけません。しかし、計画通りに開発がうまくいくわけもなく、仮説や検証を通じて開発の方向性を調整する必要が生まれたりします

仮説がうまく行きそうなら実際に開発をすることになりますが、仮説がうまく行かない可能性があることを踏まえるとフルスペックでの機能実装というのはコスト(時間や機会損失)の問題が出てきます。エンジニア的にはプッシュ通知や画面に表示するデータを取得するAPIなどをちゃんと作って機能を実装したいという欲望に見舞われますが、不確実性を踏まえて最小ステップ(たとえばAPIを作らずに固定値を使うとか)で開発し、検証でうまく行ったら本実装するといった、いわゆるリーン開発のようなことを学びました

一方で機能開発だけに留まらず、職能チームのミーティングや1on1よりSquadのミーティングを優先するなど、フロー効率を求めた開発体制でした。ミーティング同士が被って時間の調整をしてもらうことも多々ありましたが、プロダクト開発に集中できるという点ではよかったところだなと思います

コトに向かうことの大切さと大変さ

入社してすぐぐらいの頃に開発カルチャーの言語化がなされました。その当時は教科書を読むときと同じように頭の中で理解したという感じでした。今になって振り返ると、今の実際の開発現場では重要視されてないもの・無意識でやっていること・意識的にやっていることという風にいろいろと考えどころのある内容だったりしますが、そういう中でも「人ではなくコトに向かおう」というのはとりわけ重要なことだなと思います

そう感じているのは経験則的なところもあります。ここ半年ほどまだ日の目を見ていない機能の開発をしていましたが、その開発を行っているSquadでは今までにないぐらいスピーディーかつ価値の創出ができていました¹⁰。なぜそのようになっていたのか、みんな優秀だったからという言葉で収められることでもなく、ことに向かって突き進んでいたから、変なしがらみもなく建設的な議論をしていたからということだからのように感じます

議論するからには当然意見のぶつかり合いみたいなことだったり、感情にそぐわないことだってあると思います。コトに向かうというのは話をしている側だけではなく、話を聞いてる側の受け止め方も備えてないと成り立ちません。そのように1人だけではなくみんな同じ思考を持っておく必要がある中で、そのSquadではコトに向かうというのができていたんじゃないかなと思います¹¹

一方で振り返ってみると今までの自分の行動すべてがコトに向かっていたのかと自問自答すると、必ずしもできていたわけじゃないと思ってます。気の乗らないタスクは後回しにする癖があったりしますし、エンジニア的な思考で突き進もうとしてたこともありますし、人間の行動を機械的に統一するというのは難しいのかもしれないですが、ここ半年の開発を経てコトに向かうことの大切さを実感したので今後もコトに向かっていく感じに頑張ろうと思います

最終出社日の振り返り会では今まで一緒に働いてきた人の中で一番コトに向かってましたみたいなことを言われたりして嬉しかったりしました¹²

退職理由

お待たせしました、みんなが一番読みたいのは退職理由なんじゃないかなと思います

理由やきっかけなど挙げると複雑な感じになってしまうのですが、一文でまとめると**「コロナによっていろんな企業がフルリモートや居住地自由などの制度に変わっていく中でエンジニアの採用競争力の強そうなところで働いてみたくなった」**というところですね

前提から話すと、自分が入社したのは2020年2月のことで、そのころはまだ中国でやばそうなのが広がってるぐらいの認識だった人がほとんどじゃないかなと思います。なので自分が入社した時は出社が当たり前でしたし、自分自身、出社やリモートワークについてはなんとも思ってなかったです。その後すぐにリモート体制になったり、感染状況によってリモート体制が解除されたりと¹³していきました。そうこうしてると自分としては生産性あまり変わらないしリモートワークでいいじゃんと思い始めたり、世間でもフルリモートの会社が増えてきたりしました

世の中が大きく変動してる中で、世の中の多くの人と同じようにコロナによって価値観が変わったというのも大きな要因になんじゃないかなと思います

一方で、プロダクト開発のリソースという面やスキルスタックの多様性という面でもエンジニアが多い環境・採用競争力のある環境というのに惹かれ始めました。より多くのエンジニアリソースがあればよりよいプロダクトを作れるんじゃないかという感覚¹⁴になっていったのです。その感覚が正しいかはわかりませんが、リソースがあればもっとできたという場面やリソースがないからできなかったという場面がありました

会社としては前述の通り出社寄りの考えで、出社のほうが生産性がいいと信じています。自分はエンジニアを採用できてるならぶっちゃけなんでもいいと思うのですが¹⁵、世間ではフルリモートな企業の勢いを見せつけられるようになってきました¹⁶。フルリモートで全国各地から強い人を集めて、たとえ生産性が少し下がろうが総生産量を上げたほうがいいんじゃないのかと自分は次第に信じ始めたのです。俗に言う音楽性の違いというやつでしょうか¹⁷

元々、転職するときに2年は絶対に働こうと決めていたのですが、2年経ち、今年になってから居住地自由化に踏み切る会社がたびたび出てきたり、他にもきっかけみたいなことは何個かあったりしたのですが、ちょうどいい頃合いだし今自分が採用競争力ありそうだなぁと思ってる会社は実際にどうなんだろうと思うこともあり退職するに至りました

結局のところは入社時期が悪く結果的にミスマッチだったということに尽きるかもしれません¹⁸。ですが、入社して良くなかったのかというわけでもなく、学ぶことは多くあったので入社したのは良かったと思ってます。出社してプロダクト開発に向き合うのが好き・やってみたいという方には、たぶんですがとてもいい会社だと思います¹⁹

採用競争力ってフルリモートとか居住地自由とかだけじゃないでしょ？

その通り！

人がある企業を魅力的だなと感じるところはいろんなベクトルがあると思います。働き方であったり、福利厚生であったり、給料であったり、事業であったり、名の知れた企業であったり。複合的な要因だからこそ定量的に測れずに定性的な考えで採用施策をやっていくしかないところでもあります

エンジニアなら技術ブログや登壇やOSS活動などがエンジニアとしてコントロールできる領域ですね。自分も技術ブログなどは会社として盛り上げようと頑張ろうとしましたがいろいろありモチベーションを維持できませんでした。エンジニアを巻き込みながら採用施策を継続的に続けられている会社はすごいと思います

なんで2年は絶対に働こうと決めていたの？

良いか悪いかはともかく、合わないと感じたら辞めるという選択肢があるのはたしかです。エンジニア界隈だと早いと半年とかで転職するという方もいたりするのを観測します。自分の入社経緯としては継続的な開発をやってみたいということも1つの理由でした。すぐに辞めてしまっては継続的な開発になってないということもあり、エンジニア界隈のよくある転職スパンを基準に2年は絶対に働こうと決めていたのです

なんだかんだで2年が経ち、あと少しで3年というところまで働いていたのは最高のチームメンバーに囲まれて、開発も楽しく面白くできていて、上司にもよくしてもらっていたというのが大きかったです。そんな中で社内的にも市場的にも枯渇しているAndroidエンジニアの自分が辞めづらさを感じていたのもあります

2年は絶対に働くという目標が正しかったのかはわかりませんが、いちおう目標達成したのでめでたしめでたしですかね(?)

2023/2/7更新

フルリモートに舵を切ったようです。自分の記事を鵜呑みにするとフェアじゃないのでリンク張っておきます。最新の事情はカジュアル面談とか面接で聞いてみてください

更新ここまで

最後に

次もAndroidエンジニアをしていきます。採用競争力のありそうなリモートワーク中心の会社に絞って転職活動をしていたのですが、delyのようにユーザーやプロダクトのことにちゃんと向き合っていそうな会社が拾ってくれました。delyで学んだことを活かしてこれからも働いていきたいと思います。また、delyでお世話になった皆さん・転職活動でお世話になった皆さん・相談に乗ってくれた友人たちありがとうございました

あと居住地自由らしいので来年には神奈川か千葉のあたりに引っ越すつもりなので第2回引っ越しエントリーも楽しみにしておいてください²⁰

最後に最近読んだ本の中からおすすめ本を貼っておきます

Footnotes

1. 編集されていて当時とは少し変わってますね ↩

2. 昔はお気に入りという名称でした ↩

3. リテンションレート、簡単に言うと今日使ってくれたユーザーが明日や明後日にどれぐらい使ってくれるかみたいな感じ ↩

4. もちろん本職の人には負けると思いますが ↩

5. 社内ではリアーキテクチャーとか呼ばれたりしたけど、リポジトリーを新規に作り、コードのほとんどすべてを書き直したのでリライトです ↩

6. Consumer Generated Media、簡単に言うとYouTubeやTikTokみたいな感じにユーザーがコンテンツを投稿する ↩

7. 未来を見通す力がなくてごめんね ↩

8. 特に長期的な視点が必要な大事な技術選定では特にそう思います ↩

9. AndroidだとRippleですね ↩

10. 効果測定みたいなことはやっていたということ、なので日の目は微妙に見てると言えるかも ↩

11. 自分がそう思ってるだけで、そう思ってない人もいたかもしれないですが、きっとみんな似たようなことは思っていると思います ↩

12. お世辞かもしれないけど、嬉しいものは嬉しい ↩

13. この記事を書いてる段階では週2リモート週3出社の体制です ↩

14. そのような環境を経験したわけでもないので、今のところは感覚に近いですね ↩

15. 感情的な考え方もいいですが、自分は合理的な考えを重視してるのでエンジニアを採用できてるならフル出社でもいいと考えてます。その上で感情にマッチしていたらなお良し ↩

16. つい先日もYahooが発表してましたね ↩

17. もはや出社派とリモート派というイデオロギー的な違いかもしれませんね ↩

18. 仲良くしてくれたチームメンバーや上司には申し訳ない気持ちでいっぱいですが、コロナによる変革には抗えませんでしたね ↩

19. 特にクラシルAndroidは比較的コードの治安が維持されてる方だと思うのでピンポイントでおすすめします、お世辞抜きに ↩

20. 神奈川か千葉だったら居住地自由は関係なくね感もありますねｗ ↩