🦔

フロントエンドエンジニアの3年目の総括

6 min read

初めに

初めまして!
株式会社おてつたびでフルスタックエンジニアをしています、ぶりぼんこと橋本です。主にフロントエンド領域を開拓しており、React や TypeScript が最も得意です。

ついに、Zenn デビューします!

Zenn デビュー 1記事目が1年の振り返りといきなりヘビーな内容になりますが、この1年やってきたことをつらつらと書いていければと思います。
若手エンジニアやエンジニアとしてのキャリアに悩んでいる人の一助になれば幸いです。

1 年の総括

2021年2月に株式会社OZ退職。
2021年3月から東京の会社でフロントエンドエンジニアとして勤務。
2021年6月メンタルを崩したことにより会社を退職。
2021年7月より株式会社おてつたびにフルスタックエンジニアとして勤務。

転職が多く、今まででのキャリアの中でもかなり動乱な 1 年となりました。
ただ、技術的な挑戦を多く行うことができ、バックエンドでは Ruby on Rails に挑戦し、フロントエンドでも自分の技術力を伸ばしつつ様々な挑戦ができました。
以下の章から、詳細に振り返っていきます。

株式会社 OZ 退職

インターン経験も含めると、3社目の会社です。エンジニア1年目はフロントエンドエンジニアとして勤務していて、JavaScript, React を主に扱っていました。
そんな環境から一変して、OZ 初のエンジニアとして勤務し、バックエンドとインフラをメインに、製品のお客様との打ち合わせやそこから出てきた要件を整理したりしていました。エンジニア2年目の話はこちらの noteを参照ください。

2021 年 1 月には転職先が決まっていて、ドキュメントを作成したり、ソースコードにコメントを書いていたり、お客様からの最後の要望を実装していたり、特段変わったことをしていませんでした。その中で技術的に行ったこととしては、 Vue.js の導入です。
Django の template で HTML をレンダリングしていたので、モダンなフロントエンドライブラリを使わずに、 HTML + CSS + jQuery という旧世代の技術で開発をしてました。jQuery は静的ページに簡単な動作を実装する分には問題ないのですが、ある程度フロントでの処理が増えると、ソースコードの複雑化を招くことになります。例に漏れず、OZ の製品でも同様に、jQuery によるフロントエンド開発の限界を感じていました。
そこで注目したのが、Vue.js です。
私は今までモダンなフロントエンドライブラリでは React しか使ったことがなかったのですが、Vue.js の導入が React よりも行いやすいことに着目しました。jQuery のように部分的に実装することができたり、state 管理によるコードの保守性が上がったりと、かなり恩恵を受けました。

なんやかんやでこの2ヶ月は大きく動くことはせず、無事に退職することができました。

東京への出戻り

2021 年から1年ぶりに東京へ戻り、再びフロントエンドエンジニアとしての勤務がスタートしました。この時勤務していた会社は非常に技術レベルが高く、日々の仕事についていくのに必死だったのを覚えています。
私はある製品のフロントエンド開発をまるっと任されていました。「まるっと」というのは、フロントエンドの技術選定から、サービスのデザイン、実装までを担当していました。求められるレベルは高く、デザイン一つにしてもなぜこうなるのか、技術選定一つにしてもなぜこれが必要かというのをたくさん問われ、普段使用したとしても何となく使っていた技術を、片っ端からたくさん調べていました。2年目から何となく開発するのではなく、一つ一つ理解して開発しようと心がけていたのですが、ここにきて真の意味で、何となく開発することからの脱却ができたと思います。

しかし、私には色々な意味で厳しい環境でした。3 ヶ月でメンタルを崩し、会社に行けなくなってしまいます。
これ以上の説明は省きますが、勤務したのはたった 3 ヶ月だったとしても、技術者としてかなり成長できたと確信していますし、悪い意味でも勉強ができました。また、「本物」のエンジニアと一緒に働けたという経験が一番大きかったです。

おてつたびでの勤務

メンタルを崩して自宅療養しつつ、次の転職先を探していましたが、その中の一つに「おてつたび」という会社がありました。
入社の経緯はこちらの noteに書いていますので、お時間があれば読んでいただければ幸いです。

おてつたびでは、全エンジニアがフルスタックエンジニアとして働きます。それはつまり、自分でデザインを作成し、フロントエンドもバックエンドも一人のエンジニアが実装します。
最近ではリプレイスプロジェクトが始まっており、デザイン経験のあるエンジニアやリードエンジニアがデザインを作成していますが、基本的には一人のエンジニアが全ての工程を担当します。
ちなみにおてつたびでは、バックエンドは Ruby on Rails、フロントエンドは React, 一部ページでは jQuery を使って実装しています。

おてつたびではフロントエンド領域に特化したエンジニアがおらず、リードエンジニアが独学でコードを書いている状況でした。だからこそ、自分が提案できることがたくさんあり、リードエンジニアも会社や製品が良くなるのであればと快く提案を受け入れてくれました(もちろん全ての提案を鵜呑みにする訳ではありません)。
私が提案して導入したことは以下の通りです(全部をあげるとキリがないので、抜粋しています)。

  1. ESLint と TypeScript の導入
  2. コンポーネント設計やコーディング規約の策定
  3. フロントエンドのテストコードの導入
  4. React 移行プロジェクトの調査とリード

一つ一つ簡単に説明していきます。

1. Eslint と TypeScript の導入

おてつたびでは、フロントエンドもバックエンドも Linter を導入しておらず、改行やクオーテーションなどが開発者によりバラバラに設定されていました。また Linter は、ソースコードを単にきれいにしてくれるだけではなく、コーディング規約に準拠しているか、コードベースでパフォーマンス悪化につながっていないかなどをチェックしてくれます。
TypeScript も同様に導入されていなかったので、コンポーネントや関数にどのようなデータが入ってくるかデバッグするまで分からないという状況が多々ありました。
リードエンジニア自身も Linter や TypeScript の導入を考えており、初期設定自体はリードエンジニアがして、その後の設定を私が行うことになりました。

ESLint の導入では、最初こそ差分が多過ぎて PR レビューが大変でした。ESLint を導入して半年経った今では、主要な機能に関してはフォーマットされています。開発者によるコードの書き方の差異がなくなり、かなり読みやすくなりました。

TypeScript の導入では、型が分かることで他人のコードでも読みやすくなり、追加実装もレビューも行いやすくなりました。個人的には、開発スピードが速くなったと感じるくらい恩恵を受けています。
一方で、TypeScript 導入後の課題がまだあります。その中の一つに、TypeScript に慣れてない開発者のコーディング時間がかかることが挙げられます。TypeScript に慣れていないメンバーがいる場合、まず TypeScript の書き方を調べることになります。TypeScript の書き方を調べることでさえ時間がかかりますが、書き方を調べたとしても上手くコンパイルが通らない場合もあります。TypeScript の導入はフロントエンド開発における常識となっていますが、導入時期は見定めた方が良さそうです。

2. コンポーネント設計やコーディング規約の策定

おてつたびでは、Container パターンを導入して、まずはロジックとレイアウト層の責務の分離を進めました。現在では Atomic Design の考え方を導入して、レイアウト層の責務の分離を進めたり、Clean Architecture の導入を勧めたりしています。

コーディング規約という点では、JS や TS における準拠して欲しいことを、Must, Should, Want の3分類に分けて定義しました。

3. フロントエンドのテストコードの導入

フロントエンドのテストは種類が多く、UI の変更によりテスト自体も大きく変わり得ます。保守・管理することが難しい中で、おてつたびではスナップショットテストだけを導入することに決めました。
スナップショットテストのメリットは、UI の予期せぬ変更を検知することができ、テストコードを管理するコストが他のテストに比べて低いことが挙げられます。
おてつたびのフロントエンドにおける課題の一つに、共通コンポーネントの変更に伴う予期せぬページへの影響がありました。バックエンドと比べてフロントエンドは影響範囲の調査が難しいと思っています。
スナップショットテストの導入は最近のことで、導入のメリットはこれから感じることになりますので、テストの効果に関しては別記事で解説できればと思います。

4. React 移行プロジェクトの調査とリード

おてつたびは、旅をしたいユーザーと人手が欲しい事業者をつなげるマッチングサービスです。B to C サービスですので、ユーザー向けにも事業者向けにもサービスを展開しています。
事業者向けの画面では、ほぼ全てのページが React の SPA で動いていますが、ユーザー向けの画面では react-rails を用いて部分的に React の実装を行っています。コードの保守性やバックエンドとの依存を考えた時、最終的にはフロントは単体で動かしたいよねということをリードエンジニアと話していました。
満をじて、ユーザー向け画面の React 移行プロジェクトが開始し、できる画面から React の SPA へ移行しようとしている最中です。

その他取り組んだこと

代表的な取り組みとして、上記4点を記載しました。ただ、これ以外にもたくさんの経験を積ませてもらっています。
例えば、Github Actions の導入や JS・画像リソース最適化、GA によるデータ収集・分析などなど、あげるとキリがないくらいです。
ここら辺の話は、おてつたびテックブログで詳細に解説しようと考えておりますので、興味がある方はお待ちいただければと思います。

4年目の抱負

この3年間で多くの経験をして、技術でサービスや会社を伸ばしていく基盤が整ったと思います。
私の中で明確に意識して磨いていこうと思っていることが2つあります。

1つ目が、パフォーマンスの追求です。これは、フロントエンドに限らずバックエンドも同様です。
3年目が終わりただコードを書くだけの仕事が明確に終わりを告げました。これからは、サービスを伸ばしていくためにパフォーマンスを意識して開発することで、サービスの UX を上げる必要があります。
パフォーマンスはただコードを書く以上に実践してみないと分からないことだらけだと思います。たくさん挑戦し、たくさん失敗し、最終的にエンドユーザーに価値あるものを届けたいと思います。

2つ目は、ネイティブアプリ開発です。
今までは Web アプリでのみサービスを展開していましたが、内部的にも外部的にもネイティブアプリの必要性は高まっていました。満を辞してネイティブアプリ開発が細々と進んでいるところです。
ネイティブアプリエンジニアは Web エンジニア以上に希少価値が高く、簡単に仲間を増やせないと考えています。だからこそ、フロントエンドエンジニアとしてのキャリアが長い自分がやる価値があり、やるべきだと思っています。

終わりに

これを書き終わった後、今までの3年間で最も技術や会社の事業にコミットした1年だったと強く感じました。
ただ技術者である以上、現状に満足すべきではなく、技術の深堀がなくなった時点で枯れてしまうと思います。4年目は3年目以上の飛躍を自身に誓いたいと思います。

そういえば、株式会社おてつたびでは一緒に働く仲間を募集しています!
Web アプリでのみサービスを展開してましたが、ネイティブアプリの開発も実際に進んでいます。
Web エンジニア、アプリエンジニア、バックエンドエンジニア、フロントエンドエンジニア、などなど募集していますので、少しでも興味がある方は、私たちと一度お話をしましょう!
Meety から私個人のカジュアル面談のお申し込みもできますので、お気軽にお話ししましょう。

長くなりましたが、最後までご覧いただき、、大変ありがとうございました。

採用ページ
Wantedly 採用ページ

GitHubで編集を提案

Discussion

ログインするとコメントできます