こんにちは、ファインディでFindy Team+の開発をしている古田(ryu-f)です。この記事はFindy Advent Calendar 2024 15日目の記事です。
ファインディでは主にバックエンド領域の開発を担当していますが、エンジニアのキャリアのスタート地点は実はフロントエンドでした。ファインディにジョインするまではバックエンドの経験は皆無です。
今回はそんな私がなぜバックエンドに挑戦したのか？どのような過程を歩んできたのか？実際に他職種を経験してみてどうだったのか？などファインディにジョインしてからの約4年間をふりかえりながらお話出来ればと思います。
なぜバックエンドに挑戦したのか？
最初にお伝えした通り私のエンジニアのキャリアのスタートはフロントエンドです。
前職で私が配属された部署はいわゆるフロントエンド専門チーム。業務についても完全分業だったのでバックエンドのエンジニアとコミュニケーションを取る機会はあっても開発する機会は在籍した約5年間で一度もありませんでした。
今でもフロントエンドは好きですし当時もまだフロントエンドを続けたい気持ちはありましたが、ある1つの理由からバックエンドの経験も積みたいと考えていました。
それは「プロダクトのドメインともっと距離が近い開発をしてみたい」からです。
フロントエンドがドメインから遠いとは全く思いませんが、プロダクトのドメインの核となるビジネスロジックやデータベースに触れるのはバックエンドがほとんどです。
多くの開発を経験する中でも前述した要素の知識がないためプロダクトに関する議論に参加出来ないもしくは建設的な意見を出せない場面が度々ありました。
そんな悔しさから「バックエンドにも挑戦してみたい！」という気持ちが芽生えてきたのがバックエンドに挑戦するきっかけでした。
その後ご縁があってファインディにジョインし、バックエンドの領域に挑戦しますが気持ち1つではなかなか厳しいところもあり...。
この詳細は次節の中で触れられればと思います。
バックエンドに挑戦したことで得た学び
バックエンドに挑戦するなかで様々なトライをしてきて多種多様な学びを得ることが出来ました。本節ではそんな中で特に重要と感じた学びのいくつかを共有出来ればと思います。
やらないことを決める
「バックエンドをやるぞ！」と意気揚々に宣言してファインディにジョインしましたが、実は最初はバックエンドに全く専念していませんでした...。
バックエンドのタスクも沢山あり会社からもバックエンドに挑戦するための間口は用意してもらいましたが、私がジョインした2020年はまだエンジニアの数も少なくフロントエンドの課題も沢山あったことから「課題解決せねば...」というのを言い訳に得意分野のフロントエンドのタスクに逃げてしまっていました。
そんな状況で半年間過ごしたところに当時の上長から「別の部署に異動してバックエンド一本に専念してみたら？」という提案がありました。自分自身も「たしかにこのままではやりたかったバックエンドのスキルが一向に伸びない...!」と危機感を抱いていたので二つ返事で異動の提案を受け入れました。
異動後、バックエンドの学習量が増え、徐々に開発ができるようになりました。
しかしバックエンド一本と言いつつもこっそりフロントエンドの改善実装をしていたり、他のフロントエンドメンバーのレビューを積極的に引き受けていたりプライドのようなものが働いて完全にバックエンドには専念できていませんでした。
そういったどっちつかずな態度は結果にも表れ、またも成果目標に届かない事態となりました。
ふりかえると何故そんなにフロントエンドにこだわるの？と感じますが、得意分野を全て捨てたら自分の存在価値がなくなるのではないか？という恐怖心があったのかもしれません。
当時のメンターもやはりフロントエンドのタスクの影響を察知しており「バックエンドに専念し、成果へ繋がるアクションを取ること」を1on1で提案していただき、それを受け入れて改めてバックエンドに専念しました。
最初は「周りのサポートを受けながら成果が出ないタスクにひたすら取り組むことの罪悪感」のようなものを感じていましたが、バックエンド一本に専念してから格段に開発スピードも速くなり、学習量も増えて基本的なバックエンドの業務なら数ヶ月で自走出来るレベルに達しました。
この時の経験から得た学びが本項の見出しの「やらないことを決める」です。
ふりかえるとファインディにジョインして約2年程度でやっとバックエンドの開発にも自信を持って取り組めるようになったと感じますが、初期の段階でバックエンドに専念していたらこの期間はより短かったと今なら確信して言えます。
この学びに関しては自分からというより周りの働きかけによって気付けたことなので当時のマネージャー・メンター・チームの皆さんには感謝しています。
未知の領域に本気で取り組むために「やること」だけではなく「やらないこと」もしっかり決めることはとても重要だと感じました。
試行錯誤を高速で繰り返す
「PDCAを高速で回す」といった表現がありますが、エンジニアにおいても大切なことかもしれません。
具体的には自分の中やメンターとタスクの制限時間を決めてその時間内で達成すべきゴールを決めます。
そして間に合わなくても結果とやったことをレビュアーやメンターに共有する、というのをひたすら繰り返します。
最初は何もかもが分からないので制限時間の中で開発することはおろかコーディングにすら着手出来ていないことが多々ありましたが、その要因やどこに苦戦したかなどの詳細も共有します。
「ただ分かりませんでした」だけだとフィードバックをする相手も「どういう過程を経てどこに問題があったのか」が分からず有益なフィードバックをすることが難しく分からないことの分解作業や具体化から入る手間が生まれてしまいます。
そのため、自分がやったことの過程や分からないなりにも自分の言葉でどこが分からなかったのかを伝えることが大事です。
このフィードバックループをひたすら繰り返していけば段々と分からないことの数も減って開発のスピードも上がっていきます。
もちろんスピードを意識するのはフィードバックループ全体ではなく、過程の1つ1つにおいても重要です。
当初自分は開発でユニットテストを実行する際「エディタからターミナルに遷移してテストしたい箇所のファイルと行を指定して実行...」といった手順を踏んでおり画面遷移やキーボードのタイプ数も多くユニットテストの実行まで1分近く要していました。
メンターとペアプロをしていた際にエディタの拡張機能や設定を紹介していただき、ショートカットで閲覧しているファイルのカーソルの位置のテストを実行することが出来るようになりました。
これにより数秒でユニットテストが実行可能になり、自分が開発しているテスト対象の挙動確認を高速で行えるようになってフィードバックループ全体のスピードを速めることが可能になりました。
未知の領域に慣れるには、分からないことに挑戦する場数が重要です。そのためには、挑戦のサイクル全体とその過程のスピードを上げることが大事だと感じました。
何も分からないからこそスコープを絞る
ビズサイドより「特定のAPIが何故XXという結果になるか理由が分からない」と問い合わせを受けた時のことです。
フロントエンドから実行されるコントローラーのクラスから処理を辿っていき、集計・整形加工・レコードの参照、と何層ものクラスを経由していることは分かりましたが、どの部分の関与しているかの見当が自分にはさっぱりつきませんでした。
そのことをメンターの方に相談したところ自分が長時間かけて調査して分からなかった内容を数分コードリーディングをしてあっさりと原因を特定したのです。
驚いて自分は「このAPIの処理の詳細についてご存知だったんですか？」と質問したところ「詳細は知らないけど調べたらなんとなく分かりました」との返答が返ってきて「なんとなく！？」とさらに驚きました。
全く腹落ちしていなかった自分は一体どのような方法で原因を特定出来たのかペアプロで考え方を共有していただきました。
一部抜粋ですが次のようにコードリーディングをしながらつらつらと語っていただきました。
「このコントローラーの処理の全貌は分からないけど恐らく返している値からAというテーブルのレコードが返されている可能性が高い。だからレコードの値をクラス内で返却している箇所を探します。返却している箇所は今見ているコントローラーではなく内部で呼び出している集計用のクラスのようです。なので集計用のクラスのコードを見ます。やはりこのクラスでレコードの値をコントローラーに渡していそうだけどただレコードの値を返しているだけだと今回の事象の説明がつかない。恐らくどこかでフィルタリングをしている可能性が高そう...(以下略)」
このようなコメントをいただき、私とメンターの方には調査手法に次のような違いがあることに気が付きました。
私は分からない処理やクラスと相対した時に「その処理やクラスの全貌を調べようとした」のに対しメンターの方は「原因の仮説をまず立ててその仮説に関連しそうな箇所のみを調べていた」のです。
私の手法だと膨大な調査量となり効率が悪かったのに対し、メンターの方は仮説→特定と小さいスコープに絞り続けることで調査を効率良く進めることが出来ていたのです。
バックエンドの開発をしていて特にこのスコープの重要性を感じたのがORマッパーを使用した処理でした。
「全ての経由したコードを確認したけどどうしてこの結果になるのか分からない！」となった時にORマッパーの発行したSQLが関与していた、ということがとにかく多く、これも仮説→特定をちゃんと意識していれば早期に原因を特定出来たな、と感じる場面が多々ありました。
未知の領域では情報量に圧倒されるため、調べる範囲を絞り、解決すべき問題を明確にすることが大事だと感じました。
以上、バックエンドに挑戦することで得た大切な学びでした。
ふりかえってみてもバックエンド特有の内容がほとんどありませんが、逆にどのような領域においても重要なことは知識や細かいテクニックよりもアクションやマインドなのではないでしょうか。
こういった学びはバックエンドに挑戦したからこそ得られた経験だったと感じます。
バックエンドを経験してみてどうだったか？
まとめとしてバックエンドに挑戦したことで実際どうだったのか、その感想等ついてお話出来ればと思います。
ドメインとの距離も近くなり、プロダクトのあらゆることに挑戦出来るようになった
最初に「プロダクトのドメインともっと距離が近い開発をしてみたいからバックエンドを目指した」といった旨を述べましたが、これに関しては期待以上に希望を達成することが出来ました！具体的に達成したことの一例を挙げると次のようなものがあります。
- ドメインと距離が近くなったことで新規に開発する施策機能でビジネスロジックも含めた提案とより建設的な議論が出来るようになった
- ビズサイドからのプロダクトに関する問い合わせにスピーディに回答出来るようになった
- インフラはリアーキテクチャを主に担当したことによりチーム内で最もプロダクトのインフラについて詳しいポジションになった
*そのリアーキテクチャが実は次の記事で執筆した内容です
当初の自分の予想を上回るほど多種多様なタスクや課題に携わることが出来てこれだけでもバックエンドに挑戦して本当によかったと感じています! その反面やはり厳しい部分もあります...。
器用貧乏になりがちで薄く浅くでしか関われないこともある
色々な領域に触れたことで出来ることが増えた反面あらゆる領域にリソースを割いたことで深い専門性が問われる場面では貢献出来ないことが何回かありました。
特にパフォーマンスチューニングなどデータベースについての知識が必要な場面ではどのようにチューニングすべきか道筋が見えてなかったり、レコード量から負荷やレスポンスタイムが推測出来ずレイテンシの低い処理をリリースしてしまったりと未だに悩んだり躓く場面が多いです。
今はエンジニアの人数も増えて苦手な箇所でもサポートいただけることが多いですが、バックエンドも気付けば数年以上携わってきたのでこういった専門性が問われる場面でも自走出来たりジュニアなメンバーをフォロー出来るレベルを目指したいです。
まとめ
フロントエンドしかやってこなかった自分がバックエンドに挑戦した経緯や得た学び、感想についてお話しました。
今未経験の領域に挑戦するならAIを活用するのは間違いないですが、今回バックエンドに挑戦したことで得た学びはAIの有無に関わらず新しい領域を挑戦する上で重要な考え方だと思います。
本記事が未経験の領域に挑戦する方への一助になれば幸いです。
またファインディでは今回の自分のように未経験の領域への挑戦を積極的に推奨しています！
そういった取り組みの一例として弊チームリーダーの浜田が開催したフロントエンドエンジニア向けのバックエンド勉強会も実施しています。
気になる方は是非次の記事をご参照ください。
ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。
