Open10

フロントエンドエンジニアとして必要なスキルを整理してみる

ken7253ken7253

フロントエンドエンジニア特有の言語

HTML

当たり前ではあるけれどもHTMLはフロントエンドエンジニアにとって最重要な言語であることは変わりない。
ReactやVueのような宣言的UIフレームワークが流行っているが結局のところ、どのようにうまいことHTMLを出力するかというのはWebというプラットフォームにいる以上避けられない。
むしろ、JQueryで手続き的にUIを構築していた時代よりも、コンポーネント志向とTypeScriptの型システムによってよりDOMを意識する必要が増えたため求められる理解度や解像度は高くなっている傾向にあると考えている。

セマンティックなHTMLが書けるか

アクセシビリティの全体的な設計はデザイナーの職域ではあるものの、フロントエンドエンジニアとしてセマンティックなHTMLが書けるかどうかという点は非常に重要であると思う。
HTMLにおける専門性というのは現代ではセマンティックなマークアップができるかという比重が多いと思うし、単純にHTMLが書けるだけではフロントエンドエンジニアとは呼ぶことはできずHTMLがブラウザにどう解釈され最終的にどのようなインターフェースを提供するのかという部分まで含めてHTMLへの理解が必要であると考えています。

具体例としてよく挙げられるのはa要素の挙動にだと思う。

https://developer.mozilla.org/ja/docs/Web/HTML/Element/a

download属性やhref="tel:***"やhref="mailto:***"などHTMLをちょっとかじったことがあるような人であれば知っている記法もあれば、通常のハイパーリンクとしてa要素を利用した場合にブラウザがどのような機能をユーザーに提供するのかという部分まで理解しているフロントエンドエンジニアは少数派だと思います。

普段から仕様を深く知って暗記しているというレベルまでは求められることは少ないですが、必要なときに仕様を確認できるスキルは必要であると考えています。

無駄のないコンポーネントを書く技術

HTMLの仕様を理解するということは開発効率にも直結します。
例としてdetails及びsummary要素を使った実装と、同等の機能をJavaScriptで作る場合では開発自体とテストなどにかかる工数が大きく変わってきます。

https://developer.mozilla.org/ja/docs/Web/HTML/Element/details

また、Reactなどで開発をしている場合本来であれば書かなくてよかったロジックをコンポーネント内部に記述するため保守性も低下します。

つまり

HTMLを書けるというだけではフロントエンドエンジニアとして仕事をしていくのは厳しい。
HTMLの仕様やブラウザの挙動などを頭に入れて必要であれば正しく調べられる技術が必要。

ken7253ken7253

補足事項

HTMLが大切であるというのは変わらないが、ReactなどではHTML側で持つべき状態をReact（ライブラリ）側で巻き取ることを推奨している場合もあります。

https://ja.reactjs.org/docs/uncontrolled-components.html

なのでHTMLは使えるようになりつつ、開発の目標や設計思想に応じて原理主義的になりすぎないように広い視野が必要だと思うことも多々あります。

ken7253ken7253

CSS

CSSについてはどちらかというとフロントエンドエンジニアよりもデザイナーの職域に近い言語になりつつあると個人的には思っています。

Sass

私はよくSassを利用していましたがコンポーネントベースで開発をしていくWebアプリケーションにおいてはその必要性は減ってきていると感じています。
一番の大きな理由としては素のCSSで不自由を感じることがないという点と、コンポーネントごとに独立してスタイルを持つようになりmixinなどの機能を使うほうがかえって保守性を下げてしまうことに繋ががるからだと考えています。

コンポーネントベースでの開発において`mixin`/`extend`が保守性を下げると考える理由

コンポーネントベースで開発を行う最大の利点は

  • HTMLによる意味合い
  • CSSによるビジュアル
  • JavaScriptによる挙動

これらがコードの中に一つの単位として強く結合してまとまっていることにこそ意味があると考えています。
そのためスタイルの共通化は過度なDRYであるとも捉えられます。

  • 共通する見た目を持つが意味が違うコンポーネント
  • 共通する見た目を持つが別の挙動を持つコンポーネント

特にスタイルについてはデザイナーの要望が強く反映される領域であるため、意図に沿っていない共通化してしまい変更コストが重くなってしまうという問題が発生しがちです。
そのためコンポーネントのスタイル定義は例え似ていてもデザイントークンレベルの共通化に抑えコンポーネントに固有で持たせる必要があると考えています。

無駄がなくセマンティックなCSS

一方でHTMLと同じくCSSにおいても無駄なく、セマンティックなCSSを設計できるかという点においてはフロントエンドエンジニアが活躍する場面であると思います。
セマンティックなCSSとは、下記のようにHTMLの属性値とCSSのセレクターを密結合にし壊れづらく意味とデザインを関連付ける書き方のことを指します。

/* この場合本当にボタンが非活性になっているかは保証されない */
button.is-disabled {
  opacity: .7;
}
/* こちらの場合はボタンが非活性になっていることが保証されている */
button:disabled {
  opacity: .7;
}

デザイナーが一部コードを書くような組織の場合フロントエンドエンジニアとしてきちんと保守性の高いスタイリングができるのかという点が、今後は更に重要になっていくと感じています。

CSS設計

命名規則によるCSS設計はコンポーネント志向のライブラリによってスタイルのカプセル化が行われるようになり重要度は低下していると感じています。
一方でJavaScriptをあまり触らないWeb制作の現場においては前述したSass + 命名規則という運用のほうが総合的に学習コストが低く扱いやすい場合もあると思います。
そういった現場では引き続きSassなどのメタ言語と命名規則による管理がしばらくは続くと思います。

CSSも書けるデザイナーとどう向き合うか

最近ではReactを勉強しているデザイナーさんやCSSに明るい人が増えてきていると感じます。
デザイナーがデザインの作成からCSSによるスタイリングを行う場合デザインの意図を反映した記述を行うことができるため、そういったデザイナーが多い組織においてはフロントエンドエンジニアではなくデザイナーがスタイルを記述するという方式も考えられる。

つまり

HTMLと同様にただ見た目を再現できるだけではフロントエンドエンジニアとしては厳しい。
将来的に使い続けるUIとしてCSSを使ってスタイルを組んでいく力が必要だと思う。

ken7253ken7253

補足

ユーティリティ系のスタイルライブラリとCSSについて

Tailwind CSSのようなスタイル系のライブラリが使える必要があるのかという点については議論が分かれる部分ではあると思うが、個人的な見解としては素のCSSもTailwindも両方同じ程度不自由なく使えるという人と、Tailwindしか書けないという人ではかなりの差があると思います。

これはJavaScriptが進化する以前にJQueryでしか書けない人と同じような問題だと思っています。
JavaScriptとTypeScirptはスーパーセットですのでTypeScirptは書けるけどJavaScriptは書けないという人は書きたいのかどうかは別として、そもそも存在しないという構造になっているのに対して別の環境を提供するようなライブラリ全般に言える問題だと思います。
これについてはReactも同じでReactでしかページを作れないという人がいればそれも同じような問題だと思っています。

ken7253ken7253

JavaScript

フロントエンドエンジニアに最も重要な言語はHTMLではなくJavaScriptであると考える方もいらっしゃると思います。
私もHTMLが最重要であると書き始めましたがそれに匹敵するほど重要な割合を占めていると思っています。

TypeScript

現在のWeb開発においてそのままJavaScriptを記述する場面はまず存在しないのでTypeScriptで書けるというのはJavaScriptで機能を作っていくよりも重要度が高い項目かもしれないなと感じます。
とはいえ普段の業務でそこまで高度な型定義が必要になることは少なく、"strict": true,の状態でasなどを使わずにコーディングできるレベルのスキルがあれば十分だと思います。

ECMAScript

前提としてES5以降の新しい書き方でJavaScriptが書けるということ。
また、アプリケーションなどの開発に携わる場合はオブジェクト指向や関数型などの命令形以外のプログラミング手法について基礎的な理解が必要になってくると思います。

WebAPI

ken7253ken7253

Server side JavaScript runtime

数年前であればこのセクションの見出しはNode.jsと書いていたと思います。
しかしながら現在はdenoやBunといったNode.js以外のJavaScriptランタイムが増えてきているため総合してこの見出しにしました。

フロントエンドとサーバーサイドの境界が薄くなっているとはよく言われますが
実際はAPIを介して開発をすることが増え、責任範囲がより明確に分かれ担当領域も専門化が進んでいると思います。
フロントエンドでもテストを書いたり、サーバーサイドとは別のアプローチで独自に開発環境の整備や改善を行っていく必要が出てきました。

そのためフロントエンドエンジニアのチームであっても自力でCI/CDを構築する必要が出てきました。
また近年ではサーバーサイドのマイクロサービス化に合わせるようにBFF（backend for frontend）
をフロントエンドエンジニアが構築するという流れも存在します。

そのためフロントエンドエンジニアであってもCLIツールの利用・作成や、開発の自動化のためサーバーサイド言語を学ぶ必要性が増えてきています。
そんな中でもNode.jsなどのJavaScriptベースの環境はフロントエンドエンジニアが使うには学習コストも低く開発中のコンテキストスイッチも抑えられるため最良の選択であると考えられます。

標準モジュールについて

Node.jsを例として挙げますがフロントエンドエンジニアとしてNode.jsで開発環境のちょっとしたスクリプトを書いたりするレベルであればfsとpathモジュールの使い方が分かっていればある程度のことはできると思います。

ken7253ken7253

ソフトウェアエンジニア共通項目

Git

Git自体の操作だけでなくGitHubやGitLabのようなサービス自体の知識も必要だと思う。
GUIでも操作ができるアプリケーションなどがあるため普段の仕様はGUI上からでも問題はないがCLIでも不自由なく使える知識がないとCI/CDの構築や環境構築・改善を行うときに非常に苦労する。

GitHub/GitLab

前述したようにGit自体だけでなく、GitHubやGitLabの使い方がわかっていないとそもそもコーディングを始められない場合が多い。
特にGitHubの機能を利用して開発を行う場合PRやissueやworkflowなどの単語の意味がわからないとお話ができない場合があるので使ったことがなくてもどういう機能があってそれがどういう名前なのかは把握しておく必要があると思う。

ken7253ken7253

Markdown

BacklogとかでもMarkdown記法は使うし、非エンジニアでも使っている人はいるので記法を覚えておかないとという雰囲気はある。
また技術記事などを書く場合はおそらく必須なので記事を書きたい人はチートシートなどを見ないでも書けるぐらいにしておかないとスムーズに記事をかけないので辛い。

また、フロントエンドエンジニアであればきちんと構造化されたMarkdownを書くことがマークアップの練習にもなるので普段からMarkdownに触れるメリットは大きい。

ken7253ken7253

Linux（UNIX）

深く仕組みを理解する必要はないがCI/CDの環境などはLinux上に構築されていることが多いのでその前提として知識が必要になる。

基本的な操作に必要なコマンドを覚えたり、よく使われる引数などの操作のパターンは覚えておきたい。

ken7253ken7253

コンピューターに関する基礎知識

フロントエンドエンジニアの領域はブラウザによって抽象化されていることが多いのでOSやCPUのアーキテクチャの影響を考えたりする機会も少なく、他の職種のエンジニアに比べるとパソコン自体の知識よりも実行環境（ブラウザ）の知識のほうが必要になってくる。

しかしながら情報処理の知識がないとシステムの全体像を把握できないため、最低限サーバーサイドのエンジニアと話ができるレベルの知識は必要になってくる。

情報処理推進機構が実施している基本情報技術者試験は「ITエンジニアの登竜門」と書かれているようにエンジニアとして基礎的な知識を試す試験であるためこの試験に受かる程度の知識は必要かもしれない。