私はコーダーを4年ほど経験した後、
Reactを扱うフロントエンドエンジニアに転向しました。

コーダーからフロントエンドエンジニアになるまでは、転職活動も結構苦労しましたし、
実際に現場で働き始めてからも、初めての内容の仕事ばかりで慣れるまでにかなり時間がかかりました。

今はフロントエンドエンジニアとして働き始めて2年ほど経ち、
一人で出来る仕事も増えてきて、状況も落ち着いてきました。

そこで本記事では、これまでの2年間を振り返り、
どういったところで最初躓いたのか、苦労したのかについて書いていきたいと思います！

よくコーダーもフロントエンドエンジニアとして扱われることがあり、
定義が曖昧なところがあると思いますが、
この記事では以下のように定義してお話しを進めます。

コーダーからフロントエンドエンジニアになって、現場でつまずいたこと4選

まずは早速結論から書きます。

技術不足による実装の壁

これは当たり前の話ではありますが、
コーダー時代とは使用技術が大きく違っていたので、実装面でかなり苦労しました。

コーダー時代の主な使用技術

• HTML
• CSS
• jQuery / 時々JavaScript
• WordPress

フロントエンドエンジニアの主な使用技術

• HTML
• CSS Modules / Vanilla Extract
• React（Next.js / React Router v7）
• TypeScript
• 様々な外部ライブラリ（Jotai / Mantine / MUI / Zod）

このように共通している部分はあるものの、使用技術の多さでいうとフロントエンドの方がかなり多いです。

どういうところで苦労したのか簡単にですが、書いていこうと思います。

Reactフレームワークの独自仕様とライフサイクル

Reactフレームワークにはそれぞれ独自の仕様があります。

またライフサイクルと言って、コンポーネントが生成されてから削除されるまでの一連の流れがあり、
そういったReact独自の概念についても、しっかり理解しておかなければなりません。

私の場合、公式ドキュメントを何回も読んだり、ブログ記事を何本も読んだりしながら、
かつ実務経験を重ねることで今ではやっと理解できるようになってきました。
（それでも50〜60％くらい？全然自信がありません...）

まだまだ知らない部分も多く、もっと深く知るにはあと何年もかかりそうだと思っています。

TypeScript

Typescriptも最初の頃は本当に苦労しました...😖

コーダーだとJavaScriptに触れる機会はあっても、
TypeScriptに触れる機会はほとんどないはずです。

型定義や型解決がとても苦手で、最初は分からなさすぎて泣きながら仕事をしてました。

TypeScriptについては、色んな方のYoutubeを視聴したり、公式ドキュメントを読みながら少しずつ理解を深めていきました。

静的ページから動的アプリケーションの開発による考慮事項の多さ

コーダー時代は、デザイン通りに見た目を実装することがゴールでした。

デザイナーさんと連携を取りながら、忠実にデザインを再現し、
時にはサイトにアニメーションを施しながら、見た目にこだわった緻密な作業が多かったと思います。

しかしフロントエンドエンジニアになってからは、
作る対象がWebアプリケーションになったため、見た目だけにこだわるのではなく、
様々なことを考慮して開発を進めていかなくてはなりませんでした。

例えば以下のような点です。

このようにアプリケーションとしての作り込みが必要になってくるため、
コーダー時代と比べて遥かに多くのことについて考えながら、仕事を進めていく必要があると感じています。

そのため最初の頃は、実装時の考慮漏れが度々発生し、コードレビュー時に指摘を貰うことが多かったです。

実装力だけでなく、設計力も重要視される

コーダーだったときは、もちろん実装スキルという点で知識が必要だったかと思いますが、
フロントエンドエンジニアになると、「設計力」というものの方が重要になってくると感じています。

というのも、アプリケーションとして長期的に運用していく必要があるため、
その場限りのコードではなく、運用保守しやすかったり、拡張性に富んだコードというのを意識して実装に取り組む必要があると感じています。

一人で勝手に実装を進めるのではなく、
事前に画面仕様書を作成したり、チームで話し合いながら実装計画について相談した上で、実装に取り掛かるというシーンが多いです。

このように都度チームメンバーで連携をとり、合意形成をとりながら作業を進めていくシーンが多いように感じています。

スクラムによるプロダクト開発

この内容は少し本題から逸れるかもしれませんが、苦労した点でもあるので書きたいと思います。

アプリケーションを開発している企業では、スクラム開発を導入しているところが多いかもしれません。

私はフロントエンドエンジニアとして入社した企業で、初めてスクラム開発という開発の進め方を経験しました。

しかしこのスクラム開発というのが、慣れるまでは結構しんどかったです。

スクラム開発とは

スクラム開発を知らない方向けに、Googleで検索して出たものですが、内容を引用しておきます。

つまりスクラム開発というメソッドに則って、素早くユーザーに価値が届けられるようにチーム開発を進めていくというものです。

何よりもチームワークが重要視されるので、個人のみの頑張りよりもチームとしての成果や結果が求められる傾向が強いと感じています（完全なる個人的意見ですが🙏）

スクラム開発の何が大変だったか

スクラム開発というものを進めるためには、ある程度の知識が必要になってくるのです。

例えば、

• スクラム開発の専門用語を理解する
• スクラム開発の定期イベントの趣旨を理解する（定期イベントは4つほどありました）
  など

しっかりとスクラム開発のメソッド・進め方があるので、
それらを理解していないとチーム開発が円滑に進められなくなり、実作業にも影響してくることがありました。

【番外編】 コーダーからフロントエンドエンジニアになって、楽になったこと

番外編として、これまでの話とは反対にコーダーからフロントエンドエンジニアになって楽になったことについて書こうと思います！

SEOについてあまり考えなくても良くなった

Webサイト制作の場合、検索エンジンに正しく評価され、上位表示させるためのSEOを意識した実装が重要になってくるかと思います。

例えば以下のような点です。

私は現在、主に契約したユーザーのみがログインして利用する「企業向けアプリケーション」の開発を行っています。
検索対象ではないクローズドな環境のため、以前ほどシビアにSEOを気にすることがなくなりました。

ただし、アプリケーションによっては変わらず上位検索表示を意識しないといけないプロダクトもあると思うので、そこは状況によりけりだとは思いますが。

アニメーションを実装することがほとんどなくなった

コーダー時代は、「スクロールに応じたコンテンツのフェードイン表示」や「画像のアニメーション動作」「カルーセルやアコーディオン表示」など、
様々なアニメーションを実装する機会がありました。

jQueryを使ったりしながら、実装することが多かったです。

しかし今はUIライブラリ（MantineやMUI）を使ったりすることが多いので、
自力でゼロからコードを書くというよりかは、
すでに完成された外部のUIコンポーネントをインポートして、組み合わせながら使うということが多いように感じています。

コーダー時代の経験はフロントエンドエンジニアになっても活かせます

前章で書いたように、コーダーのときの方が今思うと大変だったこともあります。
しかしコーダーとして働いていたときに得た経験やスキルは、今でも活かすことができています。

例えばデザインに忠実なコーディングができるという点では、一つアドバンテージになっていると感じています。

最後までお読みいただきありがとうございました。
参考になれば嬉しく思います！