【フロントエンド】駆け出しエンジニアが目指すジュニアレベルのエンジニアとは【2024年版】

はじめに

こんばんは。
駆け出しエンジニア真っ只中のmamiと申します。
最近ようやく業務にも慣れてきたタイミングで、自分のエンジニアとしてのレベル感や、この先目指すべき道筋を明確にしたいな〜という思いでこの記事を書いております。

これは自分のための記事であると同時に、同じように駆け出し中のエンジニアさんや、ミドル層を目指す手前のエンジニアさんにも刺さる内容になっているかと思います。
今、自分がどのようにキャリアアップしていくべきなのか、どのような道筋でスキルを磨いていけばいいのか。そんなふうに悩んでいる方は是非読んでみてください。

※内容はフロントエンジニアが対象になりますが、バックエンドの方もなにか通じるものがある…かもしれません。

逆算したキャリア戦略の必要性

そもそも何故、キャリア戦略が必要なのかについてお話しします。
結論からお話しすると、時間は有限だからです。

おそらく、何も意識せずとも普通に開発経験を積んでいれば、未経験からでも2~3年でジュニアレベルを脱することは可能でしょう。
しかし、何も考えずにただただコードを打ち続けるのはつまらない。
どうせエンジニアになったのであれば、論理的に自分のキャリアを組み立て、逆算して努力を積み重ねる。そのプロセスが必要であると私は思います。
そうすることで、自分の理想とするエンジニア像への最短の道へ辿り着くはずです。

そして何より、目標を明確にすることで「今自分は何をすればいいのか」が明確になります。
この記事を読み終わる頃には、自分がフロントエンジニアとして足りないスキルと既に会得したスキルが明確になります。

明確に慣れば後は簡単で、自分に足りないと思うスキルを身につけていくだけになります。

前提

まず、私のこれからお話しする「ジュニアレベル」とは、いわゆる「メンバークラス」であるとお考えください。
そして基本的には、フロントエンドのみにフォーカスしてお話ししております。

ジュニアレベルであってもバックエンドも出来た方がいいとか、インフラの知識も必要だ、などのご意見もあるかと思いますが
それはフロントで求められる最低限のレベル＝ジュニアクラスができた上で求められることかな、と思います。
フロントエンドエンジニアと名乗っておきながら、簡単なフロントの機能実装すらままならない。ではお話にならないので、まずは自分の専門領域を最低限確保しよう、ということですね。

ではいよいよ、ジュニアレベルに求められる技術スタックを下記に記していこうと思います。

ざっくり定義

●ジュニア

• リファレンス等を参照して不具合の調査ができる。（英語のドキュメントを含む）
• （単体）テストやデバッグに関して、考え方や手法を理解して活用できる。
• JestやTesting Libraryを用いてテストを行うことができる。
• APIの仕様を理解して、バックエンドとのデータの受け渡しを行うことができる。
• JavaScript の仕様に精通している。または、JavaScript を利用したプログラミングに関する高度な知識があり、それを十分活用できる。
  例）mapメソッドやfilterメソッド、if文、コールバック関数、三項演算子、スプレッド構文などを理解した上で、それを十分活用できる。
• React や Vue について基礎的な知識に関して十分理解しており、周辺技術と組み合わせて不自由なくアプリケーションの開発ができる。
• ReactであればContextやRedux、VueであればVuexなどの状態管理ライブラリの仕様を理解し、それを十分活用できる。
• TypeScriptについて基礎的な知識に関して十分理解しており、仕様書通りに開発を行うことができる。
• レスポンシブ対応のアプリケーション開発ができる。
• CSSの仕様に精通している。または、クロスブラウザ対応に関する深い知識があり、それを十分活用できる。
• UIコンポーネントライブラリを使用して、仕様書通りのコーディングができる。
• git/GitHub の仕組みを理解して適切に利用できる。
• storybookの仕様を理解し、それを元にコンポーネント開発を行うことができる。
• シンプルで他人が読みやすく理解しやすいコーディングができる
• 非同期通信の仕様を理解し、それを十分活用することができる。

●ミドル

• 他部署やPMと協働して仕様の策定ができる
• 工数の見積もりを正確に出すことができる
• パフォーマンスを意識した実装ができる
• 他メンバーの可読性・拡張性を考慮したコードが書ける
• 効果的なリファクタリングを行うことができる
• 大きいタスクを分割してジュニアに指示を出すことができる
• ジュニアの質問に的確に答えることができる
• 環境構築や技術選定が行える
• バグの発見や、詳細なレビューが出来る
• テストの策定やスケジューリングが出来る

●シニア（未開の地）

• 経験豊富で、より大きなプロジェクトを牽引出来る
• ミドルクラスの条件に加え、経験に基づく深い洞察力でより複雑で重大な問題を解決することが出来る。

ジュニアに求められるレベルをまとめると

長々と箇条書きしましたが、簡潔にまとめると「モダンな技術を使用して、指示された要件を満たす実装ができる」こと。これに尽きると思います。

それを細分化して言語化したものが上記の箇条書きリストになります。

結論

では実際問題、どうすればいいのでしょうか？
結論は、簡単。先ほど細分化した箇条書きリストを一つずつ自分のものにするです。

これらの箇条書きリストを見て、あなたはどれだけの項目が自分には出来て、どれだけの項目が自分にはまだ足りないなと思ったでしょうか？
この記事を書きながら、私自身にもこれはできると言えるけど、この項目はまだ難しいな…とか、これ勉強したことはあるけど実際にやれと言われてできるか怪しい…。
そういったものが可視化されました。

その可視化された情報をもとに、あとは自分に足りないスキルを一つ一つ習得していくだけになります。
本を読んだり、公式ドキュメントを読んだり、Udemyで学習するのもいいと思います。
そして、これらすべてのスキルを習得できた時
「モダンな技術を使用して、指示された要件を満たす実装ができる」
という先ほどの大きな要件も難なくこなせるレベルになっていることでしょう。

そして晴れて、ジュニアレベルを卒業して次のステップへ進めることができるのです。

具体的にどうすれば良いのか

では次は具体的にどうすればいいのかを考えていきましょう。
箇条書きしたものでもいいのですが、やや抽象的です。

どのような本や記事を参考に学んでいけばいいのかや、何故それを学ぶ意義があるのかについてそれぞれ深掘りしてみました。

ちなみにレベル感の定義ですが、いずれの条件も頭で理解するで終わるのではなく、実務レベルで実装できるレベルであること。
「仕様を理解」のみの項目に関しては「他人に説明できるレベル」を理解したレベルとして定義します。

①リファレンス等を参照して不具合の調査ができる。（英語のドキュメントを含む）

エンジニアにとってエラーをどう解消するか、についての問題は永遠の課題と言えるでしょう。
エラーが出るたびに先輩エンジニアにいちいち聞いていては、お互いの時間を消費してしまいます。

最初のうちはしょうがないのですが、独り立ちできるようになるためには、自分でエラーを読み、それを理解し、コードに反映させる必要性があります。
そんな時に重要となるのが「公式ドキュメント」です。

なぜ公式ドキュメントを読むのが重要なのかというと、一言で言うと信頼性が高いからです。
作者か作者の意図を知っている人が公開しているので、信頼性が高いことが期待されます。

とは言え、エラー文でググっても解決方法は出てきますよね？
それで出てきたコードをそのままコピペしたら動いた！なんて経験は誰しもがあると思います。

ですが、それだと「なぜエラーが起きていたのか」、そして「なぜエラーが治ったのか」。
これが理解できないまま先に進むことになってしまいます。
それでは次また同じエラーが出た時にまた同じ検索をする羽目になるだけではなく、そのコピペしたコードが正しいものかもわからないので、また別の意図しないエラーが発生してしてしまう原因にもなってしまいます。

重要なのは「ググって解決方法を出す」のが悪いのではなく、その出た情報が本当に正しいのか。
またその情報をもとに、エラーの根本原因をドキュメントで読み解けるかがエンジニアとして重要になるわけです。

公式ドキュメントの読み方については下記記事が大変分かりやすかったです。

本題とは外れますが、ググり力に関連して英語での検索力も重要なスキルです。

プログラミングに限らず、英語の情報量はネット上で60%を占めているのに対して、日本語は2%ほどしかないため約30倍の差があるそうです。
日本語では出てこなかったけど、英語で検索したらStackOverFlowなどで似たようなエラーで議論されていた、なんてことはよくある話だと思います。

詳しい検索方法などに関してはこちらの記事を読んでみてください。

②（単体）テストやデバッグに関して、考え方や手法を理解して活用できる。

テストに関して、フロントエンドでテストコードを導入するのには賛否両論ありますが
個人的には
・安全で高速にリリースできる
・ある一つの変更によって不具合を混在させていないことを事前に検知でき、変更のコストが下がることで、結果として品質の高いコードをリリースできる
この２つが大きなメリットかなと思うので、テスト導入には賛成派です。
（と言っておきながら、動作としては何も問題ないのに自動テストが通らなくて台パンした経験は数え切れません）

もちろん、テスト自体を書く・メンテナンスしていくコストも発生するので、そのコストに見合ったリターンが得られるかどうかはプロジェクト次第だと思います。
テストを書く ROI （投資対効果/投資収益率）が低いと感じる場合は、テストを書かないのも一つのテスト戦略とも言えます。

いずれにしても、テスト戦略とはどういったものなのか。テストにもどういった種類のテストがあるのか。
それをしっかり理解しましょう。

③JestやTesting Libraryを用いてテストを行うことができる。

②でテスト戦略についての重要性と理解ができたら、実際に自分でテストしてみましょう。
Reactの現場では主にJestとTesting Libraryを用いたテスト手法が一般的かと思います。

参画しているプロジェクトがテスト戦略を導入しているのに、書いたことがありませんではお話にならないでしょう。
せめて自分の実装したコードくらいはテストできるようにしておきましょう。

④APIの仕様を理解して、バックエンドとのデータの受け渡しを行うことができる。

APIを触る機会は非常に多く、「バックエンドとのデータの受け渡しを行うことができる」というのは、フロントエンドエンジニアにとって必須のスキルと言っても過言ではないと思います。
また、バックエンドエンジニアでなくても、APIへの深い知識は必要不可欠です。

初めにAPIとは何かを深く理解する上でオライリージャパンの下記本は良書です。
メインはAPI設計の話にはなりますが、そもそも部分のAPIの説明も丁寧にしてくださってます。
そこまで分厚い本ではないので、読んでおいて損はないでしょう。

APIの基礎が理解できたら、次は実際に連携する方法を覚えましょう。
個人的によく使うのはaxiosですが、同じ非同期通信で比較の対象になるfetchもあります。

現場でAPIを取得する場面は多いので、すぐに対応できるようにしっかり覚えましょう。

⑤JavaScript の仕様に精通している。または、JavaScript を利用したプログラミングに関する高度な知識があり、それを十分活用できる。

フレームワークやライブラリを使いこなす前に、大元のJavaScriptを理解していないとお話になりません。
まだ、その辺の知識が怪しい人は、まずはJavaScriptの基礎から理解していきましょう。

とは言っても、現場でもよく使う頻出文法もあります。
最低限覚えておくべき一例ではありますが、下記文法やメソッドなどはフレームワークを利用している中でもよく出てくるので必ず覚えておきましょう。
例）mapメソッドやfilterメソッド、if文、コールバック関数、三項演算子、スプレッド構文などを理解した上で、それを十分活用できる。

⑥React や Vue について基礎的な知識に関して十分理解しており、周辺技術と組み合わせて不自由なくアプリケーションの開発ができる。

やっと出ましたね。モダンフロントと言えばReact や Vue は外せない存在かと思います。

Reactを使うべきなのか、Vueを使うべきなのか的な議論もあるかと思いますが個人的にはどっちでもいいかなと思います。
VueもVue3になってから、書き方がReactに似てきているみたいなので、どちらかがちゃんと実装できるレベルを持っていればキャッチアップしながらでも可能だと思います。

重要なのはそこではなく、ちゃんと「実務レベルで実装できるかどうか」です。
これは一番メインのスキルとなるので時間はかかりますが、頑張って自分のものにしましょう。

また、これは持論ですが
スキルを定着させるには、「そのスキルを用いたアプリを自分で作ってみる」のが一番早いと思います。
これらの本や講座を読んだ後は、是非それを自分のアプリとしてアウトプットしてみてください。
自分で手を動かしてみないとわからないことがいっぱいあります。
実際にエラーと会話してみて初めて得る学びも多くあります。

そしてアプリが完成した頃には、それは自分の技術となって確かな自信へとつながるはずです。

⑦ReactであればContextやRedux、VueであればVuexなどの状態管理ライブラリの仕様を理解し、それを十分活用できる。

ReactやVueのスキルは言わずもがな、という感じですがこのスキルも間違いなくマストでしょう。
個人開発レベルであれば、規模が小さいのでpropsのバケツリレーでもそこまで影響はないかとは思いますが、実際の現場でグローバルに状態管理を行いわない現場はありません。

特にコードが複雑になってくると、状態管理も複雑になってくるのでしっかり読み解けるようにしておきましょう。

Reactの場合、Contextは中規模程度のプロジェクトであれば使用する場合もあるかとは思いますが、基本的にはやはりReduxが多いです。
Redux Toolkitを用いた開発も多いので、使い方をマスターしておきましょう。

また、まだ正式リリースこそされていませんがRecoilという状態管理ライブラリも注目度が高いです。
これはMeta社(旧Facebook)が開発しており、Reduxに比べて非常にシンプルに状態を管理することができます。
RecoilはStoreを複数作ることができるのも魅力の一つですね。

まあ、どちらも勉強しておいて損はないでしょう。

⑧TypeScriptについて基礎的な知識に関して十分理解しており、仕様書通りに開発を行うことができる。

学習カロリー高そうなのがしばらく続きますね。。笑
今からの新規開発案件で、TypeScriptを使わない現場の方が圧倒的に少ないと言えるほど、TypeScriptでの開発はデファクトスタンダードになっていますね。

しかしこれ、現場レベルまできちんと理解しようと思うと初心者には学習ハードルが高すぎる。。
そう思いながら私は泣きながら勉強しました…笑

そうは言ってもやらないといけないのでしっかり覚えましょう。
入門用として下記講座なんかおすすめです。

そしてみんな大好きブルーベリー本ですね！

⑨レスポンシブ対応のアプリケーション開発ができる。

プロジェクトにもよると思いますが、スマホ社会の現代において、レスポンシブ対応のアプリケーション開発は必須と言えます。
むしろスマホのデザインを元としてPCデザインを組むこともありますよね。

CSSにしろコンポーネントライブラリにしろ、レスポンシブ対応のやり方をしっかり覚えましょう。
また、この時に重要なのは「シンプルに分かりやすく、使いまわせるコード」と言うことです。

モバイル判定の方法については色々とありますが、こちら参考までに。

⑩CSSの仕様に精通している。または、クロスブラウザ対応に関する深い知識があり、それを十分活用できる。

フロントエンドエンジニアなので、Figmaなどでデザイナーさんが起こしてくれたデザインをもとにコーディングする場面は多いでしょう。
CSSを用いた難しいアニメーションなどは別に覚える必要はないですが、必要最低限はできるようにしておきましょう。

最近はCSSinJSやTailwind CSSあたりが主流でしょうか。

11.UIコンポーネントライブラリを使用して、仕様書通りのコーディングができる。

CSSメインで行うのか、UIコンポーネントライブラリを用いて開発を行うのか。
これはプロジェクトの方向性によって様々です。

どちらの方法でも対応できるようにしっかりキャッチアップしておきましょう。

12.git/GitHub の仕組みを理解して適切に利用できる。

言わずもがなですが、開発現場においてgit/GitHubを利用しないなんてことはあり得ません。
初学者にとって何個目かの壁になる印象ですが、覚えてしまえばそんなに難しいことではないので、体で覚えていきましょう。

いろんなところでお勧めされていますが、やはりGit講座であれば下記講座が一番分かりやすいかと思います。

そしてGitの仕組みとコマンドを覚えたらGUIツールのSourceTreeなんかおすすめです。
これで開発効率がぐんと上がります！

13.storybookの仕様を理解し、それを元にコンポーネント開発を行うことができる。

私は現場に入るまでstorybookの存在すら知らなかったんですが、実際のモダンな現場では結構使われている印象です。
使われる理由としてはやはり
・コンポーネントを素早く確認できる
・アプリのデザインを統一しやすい
・コンポーネントのカプセル化により再利用のしやすさ
・開発メンバーと非開発者の橋渡しになる
と言ったところでしょうか。

デメリットとしては、最初の段階では開発に時間が掛かることや、管理コストが掛かることが挙げられます。

特に最初の開発段階でstorybookが使えると、重宝されると思うのですんなり使えるようにしておくと便利です。

14.シンプルで他人が読みやすく理解しやすいコーディングができる

とりあえず動けばいい、の精神でコードを書ける個人開発とは違い、仕事やオープンソースプロジェクトにおけるコーディングでは、「他人が読むコード」を意識して書く必要があります。
他人が読むのですから、もちろんわかりやすいコードでなくてはなりません。でも、「わかりやすい」とは何でしょう。どうしたら実現できるのでしょう。

それをしっかり学んでおく必要があります。自分にしか読めないコードでは意味がないのです。

また、ソースコードは作って終わりではなく、その後何年、あるいは何十年にもわたって保守開発が行われます。
また、保守開発を行う開発者もその間に入れ替わります。
ソースコードを作る際は、このことを踏まえて高品質・低コストで保守開発ができるようにする必要があります。

名著として有名な「リーダブルコード」もいいですが、
より近代的な下記本もおすすめです。初心者にも読みやすい本となってます。

15.非同期処理の仕様を理解し、それを十分活用することができる。

いよいよ最後の項目になります。
JavaScriptにおける最も最大のつまずきポイント、それが非同期処理らしいです。

よく見るAsync,Await文ですね。
実務でよく使うコードなので、しっかり理解して活用していきましょう。

ジュニアレベル後のキャリア形成

ようやくジュニアレベルの説明が終わったところで
本題とは少しずれてしまいますがジュニアレベルのその後のキャリアについても少し考えてみたいと思います。
参考記事「Web系フロントエンド開発エンジニアのキャリア戦略」によると、大きく分けて３つの道へ分岐することができるそうです。

①フロントスペシャリスト

フロントがシニアに近いレベルで、フロントの実装力が突出して高いタイプ。簡単なプロジェクトではなく、複雑、困難なフロントエンドプロジェクトの実装を腕っ節で突破していく。フロントで高いバリューを発揮する代わりに、バック、インフラには深入りしない。

②フロントリード

フロントがミドル以上で、フロントのインフラ、アーキテクト、技術選定、開発、運用、テスト戦略まで一人称で対応できること。高いフロント実装レベルが必要な点でスペシャリストに近いところがあるが、他のバックエンド/インフラのリーダーと議論をしながら働くので、フロントだけでなく、バックとインフラ含めた幅広いエンジニアリングの基礎が必要。

③ミドルフルスタック

フロント＋1分野以上でミドルレベル以上あり、残り1分野についてもジュニアレベル以上。各分野で設計、開発、運用まで幅広く対応できる基礎力が必要。これまでのロールと違って、フルスタックではフロントエンド自体の能力はMaxで40％くらいまで程度しか評価されないので、生き残るにはバック/インフラどっちも手を動かせる必要がある。

要約すると、「フロントのみに振り切って突出させる」か「少しバックとインフラに知識のあるフロントエンジニア」か「すべてのレベルがミドル以上のフルスタックエンジニア」の３種類があるということですね。

個人的には、すべての領域に知見があった方が企業からも重宝されやすい点や、個人開発する際に一人で完結できる点などからミドルフルスタックを目指していきたいな、と思っております。
みなさんはどんなエンジニアになりたいでしょうか？？

終わりに

ここまで、フロントエンドエンジニアのジュニアレベルに求められるスキルについて深掘りして見ていきましたがいかがだったでしょうか？
もちろん、React一つ取っても物凄く奥が深いので「これもマストだよ」とか「これもいるんじゃない？」というご意見もあるかと思います。
これらの内容はすべて、他の方の記事や実際の現場を見た上で必要とされている技術を私なりに示したものになります。

少しでも、この先のキャリアに悩む駆け出しエンジニアさんの力になれたら嬉しいです。

参考