RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

フロントエンドとバックエンドを改めて整理する

はじめに

みなさんこんにちは。フジサワです。
「フロントエンド」や「フロントエンドエンジニア」という単語を耳にするようになって久しいですが、自他共に認めるバックエンドエンジニアを出自に持つ私にとって フロントエンド界隈の移り変わりは激しく、追いかけるのもなかなか大変です。
そこで今回は、改めてフロントエンドとは、またフロントエンドエンジニアに必要なスキルとは、といったあたりを整理してみたいと思います。
フロントエンドエンジニアに興味を持ったものの、あまりよくわかっていないと言う方の参考になれば幸いです。

フロントエンドとは

まずはフロントエンドとは何なのか、その定義から確認してみましょう。
Web開発業界におけるフロントエンドとは、システムの利用者が直接触れる・見ることができる領域、つまりWebブラウザ上で動作する領域をさします。
一昔前は、「クライアントサイド」と呼ばれることが多かったですが、最近は「フロントエンド」という呼び方をすることが多い印象です。
実際に、Googleトレンドなどで調べてみると、2014年ごろを境に「フロントエンド」の呼称が増えているようです。

※「クライアントサイド」の比較対象を「フロントエンドエンジニア」という単語にしているのは、「フロントエンド」という単語がアプリケーション開発以外でも 用いられる単語のためです。厳密には比較する対象の次元が異なっていますが、呼称の移り変わり程度は、上記画像からでも読み取れると思います。

フロントエンドエンジニアとは

主にHTML,CSS,JavaScriptを用いて、前述のフロントエンド領域、すなわちWebブラウザ上のUI部分を開発するエンジニアを指すことが多いです。
利用者からの操作を受け付け、後述のバックエンドに対して情報の取得・検索や更新などのリクエストを行い、得られた結果を加工・表示する部分を担います。
以前は、Webデザイナーが兼務をすることも多かったですが、フロントエンド領域の複雑化・大規模化によって求められる範囲が広くなるに従い、分業されるようになっています。
ただし、これはあくまでそういうケースもある、ということで、チームの体制、人員、プロダクトの規模によってはこの限りではありません。

バックエンドとは

フロントエンドに対して、バックエンドとは、利用者が直接触れない領域、つまりサーバー上で動作する領域を指します。
このため、クライアントサイドの対義語として、サーバーサイドと呼ばれることも多いです。

バックエンドエンジニアとは

JavaPHPPythonRubyなどの言語を用いて、サーバー上で実行される処理を開発するエンジニアです。
フロントエンドからのリクエストを受け付け、計算処理やデータベースに対して情報の取得・検索や更新の処理を実行し、処理結果をフロントエンドにレスポンスする部分を担います。

Webデザイナーとフロントエンドエンジニアの線引きがときに存在しないように、フロントエンドエンジニアとバックエンドエンジニアの線引きも、状況によっては存在しない場合もあります。
一人のエンジニアが、フロントエンド領域とバックエンド領域、双方を担うというケースも少なくありません。
大規模な開発においてはフロントエンド、バックエンド、あるいは、デザイナーやインフラエンジニアといった分業が行われることが多いと思いますが、 前述の通り、プロダクトの状況によっては一人のエンジニアが多くの領域を担うことも十分にありえます。
おそらくこの記事を読まれている方の中には、これからエンジニアを目指そうとされている方も多いかと思いますが、 私見として、どのような領域を目指すにせよ、それはあくまでその領域に対する専門性が突出して高い・強みである、という状態であって、 「フロントエンドエンジニアなのでバックエンドのことは全くわからない」よりは、「フロントエンドエンジニアだけどバックエンドもある程度分かる」という状態を 目指すのが良いのではないでしょうか。(もちろん、その逆も然り)

フロントエンドエンジニアが押さえておいた方が良い技術要素

それでは、フロントエンドエンジニアはどのような技術要素を押さえておけば良いかを見ていきましょう。
「これが正解」というものはないと思いますが、筆者が参考にしている下記のWebサイトを元に簡単にそれぞれの技術要素について抜粋する形で補足をします。
また、ここで紹介する技術要素が全て必要、というわけではありませんので、その点もご留意ください。

フロントエンド基本三要素

パッケージマネージャ

  • アプリケーションを開発する際に用いるフレームワークやライブラリなどのインストール、バージョン、依存関係のある関連パッケージの管理などを行うもの。
  • パッケージマネージャと呼ばれるもの自体は数多く存在しますが、フロントエンド領域においては、npmyarnが主に用いられます。

ビルドツール群

  • スクランナー
    • 開発の際に実行する様々なタスクを自動化するためのもの。
    • フロントエンドで開発をする際、コンパイルする、テストを実行する、ソースを難読化する…など様々なタスクを実行することが多くなりますが、自動化することで、省力化したり、ミスを防いだり、あるいは自動化の設定をチーム内で共有することで属人化を解消することができるようになります。
    • 以前はGulpやGruntをよく耳にしましたが、パッケージマネージャのnpmに備わっているnpm-scriptsがRoadmapでは推奨されています。
  • モジュールバンドラー
    • JavaScriptCSS、画像ファイルを一つにまとめるためのもの。
    • 複数のファイルに分割したJavaScriptの依存関係を整理する、Webサイトにアクセスした際のブラウザからのアクセスの回数を減らすことなどを目的に使用されます。
    • 特に、大規模なプロダクトのフロントエンド開発においては、JavaScriptを細かく分割し、可読性や保守性・拡張性の向上を行うことが必要になるため、モジュールバンドラーを用いない場合はこの管理がとても大変になります。
    • Roadmapではwebpackが推奨。なお、Webpackにはタスクランナーとしての機能も有しているため、タスクランナーの一種として紹介されることもあるので混乱しないように注意してください。
  • Linter/Formatter
    • ソースコードの整形や記述ルール、構文のチェックを行うためのもの。ESLint(Linter)や、Prettier(Formatter)など。
    • 複数のエンジニアでプロダクトを開発する際には、ソースコードを読みやすくするために、書式を統一することが一般的です。この際に用いられるのがFormatterです。
    • また、ソースコードの解析で検出できるレベルの記法ミス・バグを見つけるために用いられるのがLinterです。
    • なお、両者はソースコードの静的解析を行うという点で同じ領域を守備範囲に持つため、双方がルールに沿ったソースコードの自動整形や補正機能を持っていることがあり、同時に語られたり、併用する/しないといったケースがあります。

JavaScriptフレームワーク

  • 開発の生産性を高めるために、一定の枠組み・ルールに沿って実装を行うための基盤となるソフトウェア。
  • フロントエンド開発においてもっとも注目されている領域の一つががJavaScriptフレームワークではないでしょうか。
  • メジャーなJavaScriptフレームワークとしてはReact.jsVue.jsAnglarなど。RoadmapではReact.jsが推奨されていますが、弊社では、React.jsとVue.jsを採用しています。個人的な意見としては、フロントエンドエンジニアでも、バックエンドエンジニアでも、少なくともメジャーなJavaScriptフレームワークのうち、一つだけでも押さえておくと良いのではないかと思います。
  • 厳密にはJavaScriptフレームワークではないのですが、小規模な開発においては古くから活用されているjQueryを採用するケースもあります。
  • 「脱・jQuery」という文脈でJavaScriptフレームワークが代替手段として語られることがありますが、完全な代替手段というわけではなく、小規模なフロントエンド開発において、まだjQueryの活用範囲はあるかなと思っています。Sveltなど、新しいフレームワークもどんどん出てきており、今後のJavaScriptフレームワークの盛衰に注目です。

SPAと状態管理

  • JavaScriptフレームワークの進歩と共に、従来のWebブラウザの画面を全て書き換えて画面遷移を行うスタイルのアプリケーションから、よりリッチな操作性や表現を実現するために、一つの画面だけを用意し、その画面内の一部分だけを更新するというアプローチをとるSPA(SinglePageApplication)という手法がメジャーになっています。
  • SPAの流れの中で、画面に表示されているUI要素の状態(読み込み中、とか現在選択されている、など)を管理する量、複雑さが増すことになりました。
  • これらを解決する手段として用いられるのが状態管理ライブラリです。(ReduxVuexなど)

WebComponents

  • フロントエンド開発が大規模化すると、画面を構成するHTML要素を意味のあるカタマリ、役割でまとめ、他の要素の影響を受けなくしたり(カプセル化)、部品として再利用できるようにする必要が生じました。
  • これを可能にするのがWebComponentsの考え方で、HTML TemplatesCustom ElementsShadow DOM、といった3つの技術要素がベースになっています。ChromeFireFoxSafariやEdgeといった主要なブラウザ全てでWebCompotentsがサポートされています。
  • なお、HTML要素を部品化する、カプセル化するというアプローチは、ReactやVueなどのJavaScriptフレームワークでも行われており、それらも「コンポーネント」と呼ばれています。
  • いずれにせよ、HTMLの要素とその振る舞い、デザイン、これらを意味のあるカタマリでまとめるというアプローチが、現在のフロントエンド開発では重要な考え方となります。

Modern CSS

  • JavaScriptES Modulesによって、HTMLはWebComponentsというアプローチによって適切にカプセル化することができるようになりました。
  • CSSも、JSやHTMLと同様に適切に意味や責務によってカプセル化をしたくなります。これを実現するのがStyled ComponentsCSS Modulesといった技術要素になります。

テスト

  • バックエンド開発においては、テストコードを書いてテストするというのは一昔前からスタンダードな開発手法になっていますが、フロントエンド開発の大規模化により、フロントエンドでも同様にテストコードを書くようになりました。RoadmapではJestCypressなどが推奨されています。

型システム

  • JavaScriptは実行時に初めてデータの種類(型)が評価される言語であるため、数値を格納するための変数に文字列を代入できてしまうなどの不具合があったとしても、実行時までそれを十分に検出することができません。そこで、JavaScriptに対して型の概念を導入し、安全な実装ができるようにしたいというニーズが生じました。
  • 型の導入により、より安全な実装ができるようになった他、ソースコードの実装者の意図や処理、部品の役割を表現しやすくなることで、可読性や保守性の向上も実現できるようになりました。
  • この領域においては、現在ではほぼTypeScriptの採用一択なのではないかと思います。

サーバーサイドレンダリング(SSR)

  • SPAで実現されたアプリケーションは、JavaScriptなどの読み込みファイルが大きくなったり、ブラウザ上で動的にレンダリングを行うため、従来のWebアプリケーションに比べ、初回アクセス時の表示が遅くなりがちという課題が生じました。
  • これを解決するためにサーバー側でHTMLを生成してしまおうというアプローチがSSRです。React.jsの場合はNext.js、Vue.jsの場合はNuxtjsで実現することができます。

GraphQL

  • SPAでは、フロントエンドとバックエンドの通信をREST APIの呼び出しで行うことが一般的です。
  • REST APIの仕様はシンプルである一方、柔軟なリクエストに対して柔軟なレスポンスを返すことを実現するのが難しく、専用のAPIを大量に実装したり、あるいは不要なパラメータをフロントエンド側で取捨選択するといった方法が取られていました。また、REST APIではAPIの仕様を理解する必要があり、フロントエンドのエンジニアがバックエンドの仕様を理解するオーバーヘッドが発生していました。
  • GraphQLでは、APIのデータ構造の表現方法(スキーマ)と問い合わせ方法(クエリ)を規格化することで、バックエンドの内部実装に依らず、フロントエンドで必要な情報を柔軟にリクエストすることができるようになります。

おわりに

さて、本項では、フロントエンドとバックエンドの定義から、現在フロントエンドで主流となっていると思われる各種技術要素について整理して解説させて頂きました。 今回改めて整理してみると、フロントエンド領域の変化はとても激しく、情報をキャッチアップするのにとても苦労しました。 自分自身の知識整理もかねて、今回の記事を書かせて頂きましたが、これがみなさまのキャッチアップのお役にも立てれば幸いです。 解説に誤りなどありましたら、ご指摘いただけると幸いです!

参考


◆TECH PLAY
techplay.jp

◆connpass
rakus.connpass.com

Copyright © RAKUS Co., Ltd. All rights reserved.