yuheijotaki.com

【読書メモ】フロントエンド開発入門 プロフェッショナルな開発ツールと設計・実装

フロントエンド開発入門 プロフェッショナルな開発ツールと設計・実装

フロントエンド開発入門 プロフェッショナルな開発ツールと設計・実装

目次

  • Part1 導入編 なぜ使うかを知る
    • Chapter1 フロントエンドエンジニアの歴史
    • Chapter2 フロントエンドエンジニアに求められるスキル
    • Chapter3 フロントエンドにおける一般的なツール群
    • Chapter4 開発の現場における仕事の進め方
  • Part2 実践編 どう使うかを学ぶ
    • Chapter5 開発環境
    • Chapter6 設計と実装
    • Chapter7 CI/CD によって受けられるメリット
  • Part3 応用編 より深く学ぶために知る
    • Chapter8 解析とモニタリング
    • Chapter9 チーム開発と Web への貢献

Part1ではフロントエンド領域においてツールの紹介を取り入れつつ、そのツールを使う意義を解説しています。
Part2ではシンプルなjQueryのWebアプリをReact.js/TypeScriptへリプレイスする作業を題材に、環境構築・設計/実装・テスト・CI/CDの構築までのより実践的な内容の説明です。
最後のPart3ではプロダクトにを伸長させるためのGoogle AnalyticsなどSaas解析ツールの活用、実際にチームで働くことをイメージしやすいようにスクラム開発の現場でどのような役割をフロントエンド領域において行うかなどが解説されています。

著者のおひとり武田さんのブログ 「フロントエンド開発入門」出版のお知らせ でも触れられていますが、「これが今のフロントエンドの主流の技術スタックです」というような紹介や解説本ではなく

  • 昨今の移り変わりが早いフロントエンドという領域とどのように向き合うべきか
  • そのために必要となるスキルはどのようなものがあるか
  • なぜ現在主流のツール、フレームワークが求められているか

を主にフォーカスした内容となっていました。

ポイント

Part1 導入編 なぜ使うかを知る

Chapter1 フロントエンドエンジニアの歴史

ティム・バーナーズ＝リー的なところから90〜00年代のブラウザ戦争、ブログ流行などの流れから当時のマークアップエンジニアやHTMLコーダーという職種がどのように関わりを持ち始めたかという内容。
その後のJavaScriptを用いて動的なUIを提供する流れを経て2000年代後半から「フロントエンドエンジニア」という専門職が一般化し始める。

個人的には、2010年前後からHTML/CSS/JS（jQuery）を触ったりしていて、書かれているようなAngularJS、Backbone.jsなどSPAを実現するためのフレームワークの存在はちらっと横目で見てる程度でした。

HTMLのマークアップ、CSSによるスタイリングという範疇に収まらない、より一層専門性の高い能力が求められると「フロントエンドエンジニア」という言葉がここでようやく専門職として一般化しだします。 それと同時にサーバサイドのWebエンジニアがフロントエンドに軸足を置いたり、デザイナーがマークアップを簡単なUI実装まで担当したりとフロントエンド界隈は徐々にボーダレス・るつぼ化してきます。

ちょうどこのときですね。自分はデザインから入ったので「デザイナーがマークアップを簡単なUI実装まで担当したり」に近いところでこの仕事に足を踏み入れたと思っています。

その後Node.jsが発表、npmによって開発におけるエコシステムが急速に充実。ライブラリのバージョン管理やタスクの自動化が可能になる。
同時にECMAScriptへ追加仕様提案の動きが活発化。次期バージョンES6への利用熱が高まりES6からES5への変換ツール、6to5（後のBabel）が発表され注目され始める。

一方でトレンドが日々移り変わるかのような世界になってしまい、海外を中心に JavaScript/Front-End Fatigue（＝フロントエンド疲れ）といった言葉が囁かれるようにもなる。

  • HTML/CSS/JavaScriptの仕様のアップデート速度
  • 支払いや認証APIをChrome（ブラウザ）が提供し、OSやデバイスと紐づく仕様提案が増加
  • プライバシー保護の動きやセキュリティ上の懸念（.userAgent文字列の凍結予定など）

確かに Angular/React/Vue 以外にも当時JSフレームワークは当時雑多にあって絞れない状態だったりしたので、日本でもフロントエンドの領域広すぎ問題はあがっていた記憶があります。

このような経緯などがあるなかで、この書籍ではすべての情報をキャッチアップし網羅するのは難しいため、

  1. 昨今の技術要素が何のために必要なのか、何を解決するのか
  2. 実践的な内容で技術要素を取り扱い必要なことを必要なタイミングで学ぶ

ことにフォーカスした内容を以降で取り上げています。

Chapter2 フロントエンドエンジニアに求められるスキル

フロントエンドエンジニアでは実務でどのようなスキルが求められるかについて解説されています。

想定される実務例
  • 意味付けと文書構造・アウトラインが情報として適切に設計されたHTMLマークアップ
  • デザイナーと連携し画面に必要なパーツの書き出し依頼を行う
  • 保守性を重要視したCSSの設計およびスタイリング
  • WordPressに代表されるようなCMSの構築、テンプレート実装と運用ができる
  • 任意のJavaScriptフレームワークを十分に理解し実装する
  • Node.jsと周辺のエコシステムを理解したビルドパイプラインを実装する
  • Atomic Designによるコンポーネント設計を中心に据えFigmaでデザインしJSXとCSS in JSを利用し実装する
  • コンバージョンレート向上目的のA/Bテストの設計と結果から得られる簡単な分析とUI改善施策の提案
  • SEOのためにmeta要素を最適化、SNSでの参照時にOGイメージを表示させる
  • 画面キャッシュやアセットファイルのライフサイクルを考慮したCDNキャッシュ戦略とデプロイにおけるインフラ担当との協働
  • React SSRを目的としたExpressの実装
  • 既存REST APIをバックエンドとしたフロントエンドに親和性のあるGraphQL APIサーバの実装
  • QA部門のテストエンジニアと協働し仕様から正常系のテスト項目のレビューを行う
フロントエンドエンジニアの実務から想起されるスキル群
  • HTTP
  • HTML
  • CSS
  • SEO
  • アクセシビリティ
  • レスポンシブデザイン
  • CSSボックスモデル
  • CSS設計
  • CSSメタ言語
  • JavaScript構文
  • DOM操作
  • イベントループ
  • Node.js
  • npm,Yarn
  • セキュリティ
  • JSフレームワーク
  • コンパイルモジュールバンドラー
  • リンター
  • CSS-in-JS
  • CSS Modules
  • CSSフレームワーク
  • テスト
  • 型定義
  • Web Components
  • PWA
  • SSR ServerSideRendering
  • SSG StaticSiteGeneration
  • GraphQL
  • ネイティブアプリケーション
  • WebAssembly

羅列するととんでもない広さに見えてしまいますが、あくまでも必要なスキルを整理するための一覧。
この中でネックに感じることが多い部分はJavaScript周辺の情報のキャッチアップなどが多いように感じるとのこと。

現代においては「フロントエンド = JavaScriptのスキルセットが必須である」というイメージが拭いきれないと感じています。同時にフロントエンドエンジニアであると自認する開発者が必ずしもCSSやデザインについて十分な知識があるとは言いにくいのも現状です。

この点は、The Great Divide | CSS-Tricks という記事でも現在の「フロントエンドエンジニア」という言葉の意味が二分されており、その隔たりはかなり大きなものであると主張しています。

関心や責務の中心がJavaScriptによって解決できることを守備範囲としている開発者と、HTML・CSS・デザインやインタラクション・アクセシビリティにスキルセットが集中した開発者では活躍できるフィールドが大きく異なります。この主張に同調する意見も多かったことから、フロントエンドという言葉に求められる要素の多様化を示唆していることは紛れもありません。昨今では前者をフロントエンドソフトウェアエンジニア・フロントエンドWebデベロッパーとし後者をUXエンジニアとすることで区別し、まったく別のキャリアが用意されていることもあります。

とのことで、網羅すべき範囲が広くなってきたフロントエンドに対する理解や、二分されたイメージを開発チームがまだ持っていないという状況にある場合、まずはチームに必要なスキルセットが何であるかを明確にし、分野が違いすぎていないかを考える必要がありそうです。
やみくもに特定のスキルセットに対してベッドするということは、開発者としてあまり賢い成長戦略ではないように思えるということです。

f:id:jotaki:20210318195822p:plain 「The Great Divide | CSS-Tricks」より引用

今もWebの成長は止まらず今後も加速するであろうなかでどうしたらいいのか、というと

必要なとき（求められたときに）、正しい場所から、必要な情報を、深く調べて身につける

何か課題を目の前にした際、いつでも実現できる状態にしておくということはフロントエンドエンジニアとして健全であるとのことで、難しそうだな。。とも思いつつ確かに負荷のかからない付き合い方としては適当なんだろうなと感じました。

最後に本書におけるフロントエンドエンジニア像として、

  • 本格的なプロダクト開発チームへの参画は初めてとなる
  • ブラウザを主戦場としWebをプラットフォームにしたアプリケーション開発への興味関心がある
  • JavaScriptに関連する情報へのアンテナ感度が高い
  • デザインのオーサリングツールについては扱ったことがない
  • セマンティックなHTML構造への理解はあるものの熟知しているわけではない
  • CSSによるフルスクラッチのスタイリングや特定のCSS設計手法についての知識は乏しい

としています。つまり、The Great Divide の区分でいうと「フロントエンドソフトウェアエンジニア・フロントエンドWebデベロッパー」に近いフィールドを担う人というイメージをしました。

Chapter3 フロントエンドにおける一般的なツール群

ここでは具体的なライブラリやツールの紹介になります。またそれらが開発においてどういった課題を解決するのかといった観点が下敷きとして記載されています。

Node.jsとその周辺のエコシステム
  • 非同期型のイベント駆動モデルを採用したサーバーサイド向けのJavaScript
  • npm,Yarnなどのパッケージマネージャー
  • フロントエンドの開発環境構築を支える根幹そのもの
  • BFF（Backends For Frontends）層とブラウザとで同じ言語であるJavaScriptを扱うことも可能
  • フロントエンドを発端として発展したJavaScriptの価値のある言語の発展にはNode.jsがある
コンパイラ・モジュールバンドラー
  • Babel,webpack など
  • 言語仕様を吸収し解釈可能な状態で展開・連結する変換器
  • Babel：下位構文へダウンコンパイルする役割。ECMAScriptの年次策定する新しい仕様決定に対応可能
  • webpack：言語仕様の一部であるモジュール機構を実装していない下位環境においてのエミュレートを担当。他にParcelやRollup.js
  • 開発において変更可用性、スケーリングの担保をもたらす恩恵となる
JavaScript代替言語：TypeScript
  • JavaScriptに類似した言語体系を持ちつつ別の特性によって開発者に違った体験を与える、最終的にはJavaScriptにコンパイルされる言語
  • 静的型付言語であり型チェックとJavaScriptへのコンパイルも担う
  • コンパイラとしての一面も
  • スクリプト実行前の未然検知が可能、型補完やエラー発見を向上などの恩恵
フレームワーク：ビューライブラリ：Vue.js,Angular,React
  • Vue.js：モノリシックなフレームワークと異なり、少しづつ適用可能
  • Angular：HTMLとTypeScriptでSPAを開発するフレームワーク。ファイル構成やソフトウェアパターンなど初手から学習領域が多い
  • React：UI構築のためのライブラリ。オールインワンではなくUI表現のみに関心を寄せる
  • いずれもコンポーネント指向のフレームワーク・ライブラリ。変更が容易で、すぐに代替可能であるといった「捨てやすさ」が大きな特長
    • フレームワークを利用することでチーム開発におけるコードベースの一貫性や保守性を持つ
    • 疎結合なコンポーネントであることで技術的な変更に耐えうる、時間とともに古びたりしても変更可能な状態を保つことができる
    • スピード感のあるリリースサイクルを求められるフロントエンド開発において十分な堅牢性と持続性を発揮
その他
  • 状態管理のライブラリやパターン MVCの説明、Redux,Fluxの例
    • コンポーネント管理の煩雑さを少なくするため
  • CSSメタ言語、CSS-in-JS
    • 長期的な保守・運用のため
  • 静的解析ツール：Prettier,ESLint
    • 機械的にコードスタイルを規定するため
  • ユニットテスト：Mocha,Jest,Karma
    • 変更可用性に耐えうる環境を作るため

Chapter4 開発の現場における仕事の進め方

主にアジャイル、スクラムの開発手法とフロントエンドエンジニアがどのように関わるかの解説。

ゴールに向かって進み続けるプロダクトにおいて、変更要求を受けやすいのがフロントエンド・クライアントサイドでもあるのです。つまり、ユーザーや利用者に価値を届けるために一番近いエンジニアリングのフィールドにいるのがフロントエンドエンジニアと言ってもよいでしょう。

と他のサーバーサイドエンジニアとの違いが述べられています。
また一般的な開発チームの職種の紹介、そのなかでの役割については開発を前に進めるコミュニケーションハブのような責務も持つこともあるということです。

開発において最新のライブラリやフレームワークや技術要素を選択することは優先度の高い事項ではありません。動くプロダクト＝アプリケーションを速いサイクルで変化に対応しながらユーザーに届けるために、必要な解決策を持っていることが重要です。

デザイナーともサーバーサイドともPM・ディレクター的な立ち位置の人とまんべんなく絡んでいくので、コードを書くという部分のみのテクニカルスキルだけでなく、他の頭を使ったりコミュニケーションスキルも必要ってことですね。

Part2 実践編 どう使うかを学ぶ

書籍のレビューサイトのjQueryのWebアプリをReact.js/TypeScriptへリプレイスする作業を題材にしてコードを交えながら解説しています。

  • Yarn,Docker,webpackを使った環境の構築
  • jQueryからReact.js/TypeScriptリプレイス作業
  • Jestでのテスト
  • GitHub Actionsを用いたCI/CD環境構築
  • Lighthouseを用いたパフォーマンス測定・改善

Part3 応用編 より深く学ぶために知る

Chapter8の解析とモニタリングでは、仮説検証やA/Bテストをプロダクトやサービスを成長させるフェーズでなぜ大事になるのかが解説されています。

Chapter9 チーム開発と Web への貢献

スクラム開発においてフロントエンドエンジニアがチームに効果をもたらす・メリットが得られると筆者は考えています。

  1. 短いリリースサイクルを実現しユーザーに価値を提供し続けます
  2. スプリント内には決まったイベントを定義することでチームの学習を促進しメンバーが自主的に改善を試みます
  3. チームやプロダクトが予期せぬ変化や不確実性の高い開発を求められる場合それに耐えうるように設計されています

技術的なトレンドのキャッチアップのためには、膨大な1次情報（WHATWGの規格など）のアップデートを追うのはほぼ不可能なので、ライトにキャッチアップすることをおすすめしています。

何らか知る必要があるか分からないという場合、まずは知るきっかけを作っておく、いったんは情報を目に入れておくということが良さそうです。

感想

Part1を中心に感想等を書きましたが、久しぶりにフロントエンド周りの本でコードが大量に掲載されているような技術書ではない類のものを読みました。
主に入門者向きの内容で、あくまでなぜそれが必要かどういう観点で使うかが主目的のためコードに関して簡易なもので記載されています。
Part2以降は実践編〜応用編になるので開発者の方は読む内容になると思いますが、Part1の最初の方に関しては非エンジニアでエンジニアの考えを知りたいみたいな興味がある方にはとても良い内容だと感じました。

実際にフロントエンドエンジニアと働いている自分からすると、なかなか客観的にフロントエンド領域というものを捉える機会がなかったのでその点が特に勉強になりました。

書籍の最後で下記のように締められていました。

昨今フロントエンドは移り変わりが早いと言われてきました。これからあなたがどのくらいフロントエンドという領域と向き合うかはわかりませんが、Webプラットフォームの仕様に影響を受けるブラウザが主戦場だからこそ変化のスピードも早いように感じることもあるでしょう。早いと感じるときは情報をみすぎているかもしれないと自分を疑ってください。新しい仕様を知ることや新しいライブラリを使うことはいずれも単体ではなんの価値も生んでいません。Webプラットフォームのエンドユーザーは開発者ではなくあなたが担当するアプリケーションのユーザーなのです。Webプラットフォームとエンドユーザー、開発者であるあなたの立ち位置は時間が経っても変わるものではありません。

ユーザーの課題を解決するために、ユーザーへの価値提供のためにWebプラットフォームを使って開発を進めていくのだ・課題を解決するのだ、ということに意識的であることや楽しむことがフロントエンド開発では大切なポイントなのです。

「早いと感じるときは情報をみすぎているかもしれないと自分を疑ってください。」というのが今までにない視点でいいなと思いました。
確かに広い範囲を細かく追うと破綻する気がしますし、目に止めとく程度でいいのかなと。
今までは技術を知らなければいけないと思いすぎていた面もあるのでそれも大事な点ではあると思いますが、もう少し本質的な仕事を思い出してユーザーに寄り添って仕事をしようと思えるような本でした。