基礎知識

フロントエンド開発とは。仕事内容・使う技術・キャリアを解説

フロントエンドは、利用者が直接触れる部分を作る仕事です。見た目を整えるだけの仕事と思われがちですが、実際には設計と性能の判断が求められます。この記事では、仕事の実際を整理します。

担当する範囲

フロントエンドが担うのは、ブラウザ上で動くすべてです。

画面の構造、見た目、操作への反応、入力の検証、サーバーとのデータのやり取り、表示速度の最適化。「見た目を作る仕事」という理解は、範囲の一部にすぎません。

とくに近年は、ブラウザ側で処理する量が増えました。画面の切り替え、状態の管理、データの保持。かつてサーバーが担っていた処理の一部が、こちら側に移っています。

その結果、設計の善し悪しが規模の限界を決めるようになりました。構造が整理されていないと、機能が増えるにつれて手がつけられなくなります。

3つの技術の役割分担

基礎となる技術は3つです。役割が明確に分かれています。

• HTML／構造を定める。見出し、段落、表、入力欄。文書の骨格
• CSS／見た目を定める。色、大きさ、配置、余白、動き
• JavaScript／動作を定める。押したときの反応、データの取得、表示の切り替え

建物にたとえると、HTMLが骨組み、CSSが内装、JavaScriptが設備にあたります。

この3つは順に学ぶのが効率的です。構造が分からないまま見た目を整えても、崩れます。

HTMLについては、意味に応じた要素を選ぶことが重要です。見出しには見出し用の要素を使う。これは検索エンジンの理解や、読み上げ機能への対応にも関わります。

枠組みを使う理由

実務では、JavaScriptを直接書くより、枠組みを使うのが一般的です。

最も広く使われているのがReactです。次いでVue、Angular。案件の募集要項では、Reactの経験が指定されることが多くあります。

枠組みを使う理由は3つあります。画面を部品に分けて再利用できること、データと表示を連動させられること、複数人で開発しやすいこと。

たとえば、データが変わったら画面も自動で更新される。この仕組みがないと、すべての更新箇所を手作業で書く必要があり、規模が大きくなると破綻します。

近年はNext.jsのような、Reactを土台にした枠組みも普及しています。表示速度や検索エンジン対応を強化したもので、新規開発での採用が増えています。

デザイナーとの分業

現場では、デザイナーとフロントエンドエンジニアが協働します。

デザイナーが担うのは、何をどう見せるかの設計です。配置、配色、文字の大きさ、操作の流れ。

フロントエンドが担うのは、それを実際に動く形にすることです。ただし、単に指示どおり作るだけではありません。

画面の幅が変わったときの見え方、入力に誤りがあった場合の表示、通信中の状態、データが0件のときの画面。デザインで指定されていない状況を、実装側が判断して埋めることになります。

この判断を的確にできる人が評価されます。指示待ちではなく、抜けている条件を先に指摘できるかどうかです。

求められるスキル

案件で実際に問われる能力を挙げます。

• 設計する力／部品の分け方、データの持ち方。規模が大きくなるほど効く
• 性能を測って直す力／表示速度の計測と改善。感覚ではなく数字で扱う
• 幅広い環境への対応／端末や画面サイズの違いを吸収する
• アクセシビリティ／読み上げ機能やキーボード操作への配慮。公共案件では要件になる
• 型を使った開発／TypeScript。大規模開発ではほぼ前提

1つ目と2つ目が、単価の分かれ目になります。画面を作れる人は多く、大規模でも破綻しない構造を設計でき、速度を数字で改善できる人は限られます。

案件の傾向と単価

案件の性質は、大きく3つに分かれます。

受託開発。クライアントの要望に沿って画面を作る。案件数が最も多い層です。

自社サービス。継続的に改善を重ねる。設計の判断を任される機会が多くなります。

デザインシステムの構築。複数のサービスで共通の部品群を整備する。上流の仕事です。

単価は月額60〜90万円の範囲が中心です。指示された画面を実装する場合は下限寄り、設計や性能改善まで担う場合は上限に近づきます。

なお、この数字は民間各社が自社の案件から集計したもので、公的統計ではありません。

キャリアの道筋

この領域からの進み方を整理します。

深める。設計、性能、アクセシビリティ。専門性を高める道です。大規模サービスでは、この専門性が求められます。

広げる。バックエンドも扱えるようにする。小規模なチームでは、両方できる人材の価値が高くなります。

上流へ。要件定義や画面設計。デザイナーと協働しながら、何を作るかを決める側へ。

この領域の特徴は、技術の入れ替わりが速いことです。数年前の主流が現在は使われていないこともあります。学び続ける前提の領域だと考えるのが妥当です。

アクセシビリティという要件

見過ごされがちですが、実務では重要度が上がっています。

アクセシビリティとは、誰もが使える状態にすることです。視覚に障害のある方が読み上げ機能で使う、マウスを使えない方がキーボードで操作する、といった状況への対応です。

公共機関の案件では要件になります。民間でも、対応を求める企業が増えています。

実装上の要点はいくつかあります。意味に応じたHTML要素を使う、画像に説明を付ける、キーボードだけで操作できる、色だけで情報を伝えない、十分な明度差を確保する。

後から対応するのは困難です。構造に関わるため、設計段階で織り込む必要があります。この知識を持つ技術者は限られており、差別化の要素になります。

状態管理という課題

規模が大きくなると必ず直面するのが、状態の管理です。

状態とは、画面が保持している情報です。ログインしているか、どの項目を選択したか、読み込み中か、入力途中の値は何か。

小規模なうちは、各部品が個別に持てば足ります。問題は、複数の画面で同じ情報を使う場合です。

整理されていないと、同じ情報が複数の場所に存在し、食い違いが生じます。片方を更新したのに、もう片方が古いまま表示される。

対処として、状態を一元管理する仕組みが使われます。ただし、導入すると構造が複雑になるため、必要になってから入れるのが実務的です。

どこまでを共通で持ち、どこからを個別に持つか。この判断が設計力の中心にあります。