Webフロントエンドエンジニアのすゝめ

Web フロントエンドエンジニアの実態を現場から完全主観でお届けします。

現代のフロントエンドエンジニアについて理解したい方向けです。

#動機

みんな（誰やねん）が思う「フロントエンドエンジニア」像と、私自身を含む実際の現場の「フロントエンドエンジニア」像に大きな乖離を感じることが増え、それについて説明する機会が増えてきたので、私が思う「フロントエンドエンジニア」像をまとめてみました。

みんなとは、IT企業の人事部・IT人材系エージェント・デザイナー・駆け出しエンジニア・MPAに固執するエンジニアなどです。

#定義

Web フロントエンドエンジニアの定義は多岐に渡ります。

ここでは、以下条件を「全て」満たすエンジニアを Web フロントエンドエンジニアと定義して話を進めます。

• Web ブラウザや Web ビューなどの Web プラットフォーム上で動作する UI/UX・機能を実現することを目的とする。
• HTML5・CSS3・SASS・CSS Modules・styled-components などを使用して、適切なマークアップとスタイリングができる。
• React・Vue.js・Angular などの SPA フレームワークを使用して、SPA を実装できる。
• Redux・Mobx・Vuex・ngrx などの状態管理ライブラリを使用して、コンポーネントをまたいだ状態管理を実装できる。
• Next.js, Nuxt.js などの フレームワークを使用して、SSR を実装できる。
• Node.js サーバー・サーバーレスファンクション等を使用して、簡易的な BFF を実装できる。
• Gatsby.js・Hugo・Next.js・Nuxt.js などを使用して、SSG（静的サイトジェネレーション）を実装できる。

要件に対して最適な手段を選択するためには、 SPA・SSR・SSG など、それぞれ異なる強みをもつ複数の技術を使用できることが必要です。

フロントエンドのお仕事図鑑という記事のフロントエンドの主な業務範囲と責務の分類が秀逸なので、是非ご参照ください。この記事の分類をお借りすると、以下の業務範囲を一通り担当できるエンジニアが上記定義に概ね該当します。

• UI/UX マークアップ
• UI/UX エンジニアリング
• フロントエンドアーキテクト
• Static Site Generation
• BaaS エンジニアリング
• Server Side Node.js
• BFF(Backend For Frontend)

定義の説明なげえ。

#よくある認識齟齬

デザイナーや経営者などの非エンジニア職の方だけでなくエンジニア職の方でも、フロントエンドエンジニアは Web ページの見た目を作るだけの（上記の「UI/UX マークアップ」に該当する）仕事だと認識している方がまだ少なくありません。そのため、ここで定義しているようなフロントエンドエンジニアの想定で「フロントエンドエンジニア」の仕事を受けたら、実際の作業内容の 9 割は UI/UX マークアップ だったみたいなことが平気であります（みんな悪気はありません）。事前によく確認しましょう。

#必要な技能

フロントエンドエンジニアとして必要な技能を把握するには、Frontend Developer Roadmap 2020という毎年更新されるロードマップが参考になります。このロードマップの末端要素のうちそれぞれ一つは使用して実装できないと、特定の問題を根本的に解決できない場面が多くなってしまうと思います。

ただ、Web Components・Progressive Web App・Web Assembly が必須になる要件は今のところ珍しいので、理解しておく程度で十分だと思います。

また、Mobile Applications・Desktop Applications については、文字通りそもそも Web プラットフォーム向けではありませんが、Flutter は Web フロントエンドにかなり近い考え方で、WebView やブラウザエンジンを使わないモバイルアプリを簡単に開発できて、そのうちWebまでカバーする可能性があるので、習得する価値が非常に高いと思います。

#参入障壁を考える

先述のロードマップを見て分かる通り、UI/UX マークアップと「フロントエンド開発」には、必要となる技術知識（＝調査量・勉強量）に大きな乖離があります。そのため、デザイナーや UI/UX マークアップ専門の方がフロントエンドエンジニアになるには、それなりに高い参入障壁を乗り越える必要があります。デザインが得意な方がひとたび参入障壁を乗り越えられるとレアなフロントエンドエンジニアになれますが。

また、10 年以上プログラミング歴があるベテランエンジニアや情報系の大学院を卒業したハイスペックエンジニアの方は、アルゴリズムやインフラを含むバックエンドを主戦場にしている（なんでもできる）場合が多い印象があるので、バックエンドよりフロントエンドの方がまだ参入障壁は低いというか競争が激しくないとも言えます。

#仲介役としての役割

フロントエンドエンジニアはデザイナーとバックエンドを仲介する立場になることが多いので、双方の技術や常識などを理解している必要があります。以下に、認識齟齬がよくあることを挙げてみました。

バックエンドエンジニアとの認識齟齬

• DB 構造・データ構造の変更コストを過小評価しがち。
• データの整合性を担保するするコストを過小評価しがち。
• そもそもインフラ周辺知識を全く理解していない。

デザイナーとの認識齟齬

• 実装しやすいようにデザインを多少変更してもよいと思っている。
• 小さな変更が全体のバランスを崩すという感覚が分からない。
• デザイナーが妥協できる部分とできない部分の区別がつかない。

その他にも、プロダクト設計者や営業担当者など様々な職種の方が言語化しきれない UI/UX （例：「なんかこれがこうなってこうなる感じにして」）を表現する必要があることも多いので、意図をロジックに落とし込む思考力が必要です。また、実装可否（フィジビリティ）を聞かれることも多いので、その場で実装可否をなるべく正確に想像できるとベターです。

また逆もしかりで、他の職種の方が、フロントエンドの実装コストを過小評価していることもよくあるので、その場合は、そのことを相手に分かる言葉で説明する言語能力と「自分の実装能力が低いだけかも？」と思わずはっきり伝える勇気が大切です。

#UI/UX の理解が必須

UI/UX に理解があるとは、UI の場合は、例えば、デザイナーから 1px 隙間を大きくしたいと要望された時に、その差が大切である・その差に意味があると思えることです。UX の場合は、例えば、ユーザーの行動データを元にボタンの位置を変えるなど、特定の情報や知識を実装に反映する決断ができることです。

#実装の本質とは

近年、フレームワークやライブラリを使用するハードルはかなり低くなっています。公式ドキュメントもわかりやすく書かれていますし、わかりやすい記事や教材も無料でいくらでも手に入るからです。コピペして見様見真似でいじればそれなりのレベルまで実装できます。

そのため、単にフレームワークやライブラリを使用して実装できるだけでは、あまり価値になりません。早晩、価格競争に巻き込まれる可能性が高いです。（っていうのは過言です。人手不足なので。）

フレームワークやライブラリの機能を駆使して自由自在に UI やロジックを構築できることにこそ価値があります。

例えば、「Mac や Windows のファイルエクスプローラーと同じ UI・機能 を実装してください。」と言われたらすぐに実装方法を思いつきますか？

すぐに実装方法を思いつかない方は、早晩、価格競争に巻き込まれる可能性が高いです。（っていうのは過言です。人手不足なので。）

ファイルをツリー上に表示するところまではライブラリを使用して実現できますが、そこから先は自分で考えて実装する必要があります。そのライブラリの中身のコードまで見に行かないと解決できないこともあるかもしれません。さらに強者になるとそのライブラリをフォークして中身のコードごとカスタマイズして解決するかもしれません。さらにさらに強者になるとライブラリ自体を作ってしまうかもしれません。

余談ですが、私は以前、人類が見たことある UI は作らないという思想の設計者の元で働いていたことがありましたが、そのおかげでゼロから自力で実装する能力が大幅に向上しました。

ここで言いたいことは、仮にこの世の全てのフレームワークやライブラリの使い方をマスターしたしても、実装能力には最大で 50％ぐらいしか寄与しないということです。なぜなら、実現したいデザインや要件がこの世に無限に存在し、それらを実現するための実装の正解はこの世にまだ存在していないからです。その正解は自分で考えるしかありません。

つまり残りの 50％は何かというと、いわゆるセンスや地頭なども含めた考える力です。ネットでいくら検索しても実装方法が見つからない場合がたまにありますが、それは実装方法がまだこの世に存在していない証拠です。

車輪の再発明は不要ですが、車輪のカスタマイズは必要です。

なぜなら砂漠で最も速く走行できる車輪と雪山で最も速く走行できる車輪は同じではないからです（決まった）。

#トレンドの移り変わり

フロントエンドはトレンドの移り変わりが速いと言われますが、トレンドの移り変わりが速いのはフロントエンドに限った話ではありません。

私が観測する限りにおいて、近年のトレンドをまとめてみました。

フロントエンド

• Vue.js が SPA フレームワークの主要な選択肢になった。
• Next.js や Nuxt.js などの発達し SSR がフロントエンド開発の主要な選択肢になった。
• Gatsby.js などの静的サイトジェネレーターの発達し、SSG がフロントエンド開発の主要な選択肢になった。
• Headless CMS が発達し、JAM Stack などフロントエンド中心の開発が増えた。
• TypeScript の採用が増えた。

バックエンド

• マイクロサービスアーキテクチャが主要な選択肢になった。
• Go 言語が開発言語の主要な選択肢になった。
• 機械学習のエコシステムが発達し Python を使用したバックエンド開発が増えた。
• Ruby on Rails の代わりに Laravel や Django を採用するケースが増えた。
• クラウドサービスについては、数えきれないほど多くのサービスがリリース・アップデートされている(雑)。

やはり、フロントエンドだけ特にトレンドの移り変わりが速いとは言えないと思います（だから何やねん）。

トレンドの移り変わりが速いのは人類が進歩している証拠です。私は、多くの GitHub リポジトリのリリースを watch しているのですが、朝起きて人類が進歩している通知を見ると割とテンション上がります。共感してくださる方いますか？

#時代の後押し

近年、バックエンドの抽象化が高速で進んでおり、SAAS・PAAS・IAAS・BAAS と言われるような多種多様なクラウドサービスを組み合わせれば（ドキュメントを大量に読んで試行錯誤すれば）高度に専門的な知識が無くてもバックエンドを実装できるようになってきたました。それによって本格的なプロダクトをフロントエンドエンジニア一人で作れるようになっています（その時点でもうフルスタックエンジニアなのか？）。

また、プロダクトに求められる UI/UX が複雑化・高度化しており、フロントエンドエンジニアの責任領域と難易度が大きくなっていると感じます。モダンなプロダクトを作るためにはもはや不可欠な職種になりつつあり、需要が高まっている印象があります。

#嬉

SSR とかしなければ、インフラにほとんどお金がかからないので、個人でも大規模開発を経験できます。

#怒

バックエンドエンジニアに見下されることがあります。おい。

#哀

見た目と実装難易度が釣り合わないことがよくあります。

#楽

自分が書いたコードが動作するのを、視覚的に認識できるのは楽しいです。

#結論

フロントエンドエンジニアに最も必要なのは、思いやりと優しさだと私は思っています。