”採用フローが誠実だった” Findyにジョイン。爆速で走り抜けたマルチスタックエンジニアの軌跡

image
https://twitter.com/intent/tweet?text=採用フローが誠実だったFindyにジョイン。爆速で走り抜けたマルチスタックエンジニアの軌跡&url=https://careers.findy.co.jp/interviews/dev-toda-1
https://www.facebook.com/sharer/sharer.php?u=https://careers.findy.co.jp/interviews/dev-toda-1
https://b.hatena.ne.jp/entry/panel/?mode=confirm&title=採用フローが誠実だったFindyにジョイン。爆速で走り抜けたマルチスタックエンジニアの軌跡&url=https%3A%2F%2Fcareers.findy.co.jp%2Finterviews%2Fdev-toda-1

登場人物

戸田 さん

SIer、ベンチャー企業などを経てFindyに参画。 バックエンド、フロントエンド、インフラ、CIなど、領域に縛られることなく開発を行う マルチスタックエンジニア。圧倒的な行動量で、Findyのサービス全体を改善中。

ーFindyにジョインした経緯を教えてください。

前職を辞めるつもりはなかったのですが、コロナの影響でリモート勤務でのスカウトが増えてきていたのでチェックしていたんです。そこでFindyと縁がありました。前職には申し訳ない気持ちはありましたけど、しばらく副業で手伝ったりしつつ円満に退職しました。

Findyを選んだのは、率直に言うと採用フローが一番誠実だったからです。よくこの人はうちでやっていけるのか、というのを試されたりするんですけど、Findyはそういったものが一切なかったんです。技術の話など雑談していた感じで面談してて気付いたら内定だったみたいな感じです。あとは今までの経歴を振り返ると僕は大きい会社よりも小さいところの方が合ってると思います。Findyは組織の規模感というか、フェーズがちょうどよかったです。

ー戸田さんはFindyでどのようなことをやっているのでしょうか?

僕自身フロントエンドからバックエンドまでプロダクト開発は一通りのことをやってきたし、Findyの開発はフロントエンド・バックエンドの領域をまたいだ開発ができるため、一番人の手数が足りないところをやるという感じです。ちょっと前まではバックエンドやモノリス環境からの脱却がメインでしたが、落ち着いたので今はフロントエンドのリファクタリングをやっています。なので月々で僕のやることは変わります。

Findyではいろいろな部分で過去一番バランスよく働けているとは感じます。時間、仕事内容、給与などといった要素のバランスが今は取れています。前はどこかが必ず崩れていました。

得意なのはバックエンドですけど。
得意なのはバックエンドですけど。

ー戸田さんは福岡でフルリモートという形で働いています。リモートでの働き方について、どのように思いますか?

エンジニアのフルリモートには高い技術レベルが求められます。例えば、問題が起きる度に相談しに来るのではなく、何か起きても自分でどうにかできる人ですね。リモートが加速してエンジニアに求められるスキルレベルは上がったと思います。

ーこれまでプロダクト改善を主に進めてきたと伺っていますが、具体的にどのように進めてきたのでしょうか?

まず最初にテストを書きました。フロントエンドもバックエンドもテストがあまりなかったんです。ただ両方書くには時間かかるので、とりあえず絶対的にデータを守る必要があるということでバックエンドのテストから着手しました。実際僕が入った時はカバレッジが10%もなかったのですが、今は95%ほどになっています。これでアップデートする度に全部の動作確認をする必要がなくなり、CIが通ったらリリースOKという状態になりました。

あとはCIとビルドの高速化です。それに伴ってモノリス環境から移行したという感じです。

バックエンドとインフラ周りは一旦最低限のところまで一通りやったので、次に今やっているのがフロントエンドです。クラスコンポーネントを関数コンポーネントに移行するのをちょうどやっていて、それが終わったらTypeScriptを入れて、それからテストを書きます。

ーFindyの転職サービスがリリースして4年ほど経っているのでその分の負債が溜まっていたということでしょうか。

そうですね。サービス開発速度を優先させてきたツケが回ってきた状態でした。あと半年、1年早ければまた違ったと思います。以前はフロントエンドを1行修正してデプロイまで1時間とか、場合によっては半日かかっていましたからね。修正内容にもよりますけど、今はそれだけやるなら数分で本番環境にデプロイできます。

※インタビュワーはエンジニアで採用担当の大原さんが担当しました
※インタビュワーはエンジニアで採用担当の大原さんが担当しました

ーテストについてもう少し詳しく教えてください。

僕が書いたのはFindy Team+のテストです。幸い当時テストが本当にない状態で、ゼロから書けたのでそれはよかったです。中途半端にテストがあると逆に書きづらいものなんです。

あとはカバレッジをあまり意識せず、守るテストを書くようにしました。低すぎたら問題ありますが、カバレッジの数値は後から付いてくるものです。それよりもこのAPIはこうしたら挙動が変わる、というのを守る観点でテストを書いてました。正直カバレッジが95%になったのも結果的にそうなっただけです。それよりもちゃんとDependabotでバージョンが上がった時に大事なところ、欲しいところでコケてくれるかを重要視していました。

おかげで権限周りの複雑なところを除いて、Findy Team+のバックエンドのリリースは動作確認しないで済むようになりました。

ーCIの改善についてはどのようなことに取り組んだのでしょうか?

速度がとにかく遅かったのでそこに着手しました。Findy中途サービスだけで運用していた頃はよかったのですが、Findy Team+の開発が進むにつれて同時実行のキュー数が増え、便秘のように詰まった状態になり、全然進まないという状態が起きていました。

GitHub Actionを導入したことでリポジトリ単位での上限数になり、全部そちらに移行することにしました。費用的にも安いですしね。あとはGitHubのマーケットプレイスのエコシステムを使えるようになり、CIを作ったり、効率化をする時もやりやすいです。

ーモノリス環境からの脱却についてはどのような経緯があったのでしょうか?

こちらも単純にリリースのビルドがとにかく遅いという問題がありました。開発自体が早くても、結局ユーザーに提供するスピードが遅すぎたので環境は分けた方がいいという判断です。

以前はフロントエンドとバックエンドを同じリポジトリで管理していたので、プルリクエストも溜まりがちだったんですよ。また、フロントエンドとバックエンドを同時に修正していたため、1回のプルリクエストが大きくてレビューする側も嫌になってしまいます。

そうなるとレビューが後回しになり、プルリクエストが残っていき、その期間が長くなるとコンフリクトが起きやすくなるんですよね。

だからプルリクエストの単位も開発の運用も小さく、シンプルにしたかったというのがモノリス環境からの脱却の狙いです。

リポジトリはそのままでビルドやリリースだけを分けるというやり方もできなくはないのですが、ここは勇気を持って動作環境も含めて一気に分割することにしました。

そのおかげでプルリクエストを作ってからマージされるまで、前は1週間かかっていたところを今は丸1日あればできるようになっています。リリースも前は週1回やるのもしんどかったですけど、今は毎日やっていて、Findy転職サービスの方は1日に2~3回は行っていますね。どんどん出しておけば、万が一何か問題が起きても切り戻ししやすいんです。

以前は動作環境が一緒だったのでフロントエンドを直したのに、バックエンドにも他の修正が入って結局リリースができないということがありました。そのタイミングでデグレが発生したらまずいですからね。今はそういうこともありません。ユーザーに対する提供スピードは段違いに上がったと思います。

ーモノリス環境からの脱却で苦労したことがあれば教えてください。

認証周りは結構しんどかったです。ログインだけだったら簡単なのですが中途サービスの特性上、GitHubやTwitter、Qiita、LINEなどの認証が必要だったので、その辺りをすべてやるとなると大変です。しかも既存のユーザーの認証を消さないで移行しなければなりませんでした。それ以外は量の問題で、手数さえあれば終わることでした。

ー直近次に戸田さんがFindyで取り組んでいきたいことはどの辺りですか?

とにかくフロントエンド、バックエンドのユニットテストをちゃんと意味のあるものに強化したいです。それができればとりあえずはサービス開発に注力していいと思います。

一点、APIの設計が現状のサービス規模に耐えられる状態ではなくなっておりそこを再精査したいです。次はGraphQLを使おうと思っています。 そうすればフロントエンドに簡単に情報を提供したり、取ったりできます。バックエンドとしてもいらないエンドポイントが増えないで済みます。検証は必要ですけど、おそらくうちのサービスとの相性はいいと思います。少なくともREST APIの実行速度が遅くなっている今の状態は何とかしたいです。

ー採用にあたって、どのような人に入ってきてほしいですか?

僕らは遊びでやっていないですし、本気でプロダクトを良くしようと思っています。

本当に本気で真面目にやっているので、そこにちゃんとついて来られる人に来て欲しいです。技術力が高いメンバーを見て、真似して分からなかったら聞くような、自分からアクションを起こせる人を求めています。伸びてきているエンジニアは、人から教えてもらうのを待ってる人ではなく、ちゃんと次のアクションをどうすべきかを自分で考えて聞いてくると感じています。

ーこのハードルを乗り越えた猛者に集まってきてほしいということですね!

僕らのスピードについて来ようとする意思の強さを持った人を求めています。そういう人には手を差し延べます。スピードを早くした結果、失敗してバグを出してもいいんです。

ー最後に戸田さんのキャリアへの向き合い方を教えてください。

今、20代の時に思い描いた30代を過ごせていると思っています。僕はプロダクトに対して全部やるというのが一番合っています。自分がやりたいことよりもプロダクトに今重要なものを考えて、すべきことが決まったのならそれに合わせて何でもする、というのが僕のスタンスだからです。

https://twitter.com/intent/tweet?text=採用フローが誠実だったFindyにジョイン。爆速で走り抜けたマルチスタックエンジニアの軌跡&url=https://careers.findy.co.jp/interviews/dev-toda-1
https://www.facebook.com/sharer/sharer.php?u=https://careers.findy.co.jp/interviews/dev-toda-1
https://b.hatena.ne.jp/entry/panel/?mode=confirm&title=採用フローが誠実だったFindyにジョイン。爆速で走り抜けたマルチスタックエンジニアの軌跡&url=https%3A%2F%2Fcareers.findy.co.jp%2Finterviews%2Fdev-toda

←社員インタビューへ戻る

Findyで一緒に働きませんか?

まずは気軽にカジュアル面談も可能です。少しでも興味お持ちいただけましたらぜひご連絡ください!

【エンジニア組織全体】

【Findy 転職】

【Findy Team+】