Part1ではフロントエンド領域においてツールの紹介を取り入れつつ、そのツールを使う意義を解説しています。
Part2ではシンプルなjQueryのWebアプリをReact.js/TypeScriptへリプレイスする作業を題材に、環境構築・設計/実装・テスト・CI/CDの構築までのより実践的な内容の説明です。
最後のPart3ではプロダクトにを伸長させるためのGoogle AnalyticsなどSaas解析ツールの活用、実際にチームで働くことをイメージしやすいようにスクラム開発の現場でどのような役割をフロントエンド領域において行うかなどが解説されています。
著者のおひとり武田さんのブログ 「フロントエンド開発入門」出版のお知らせ でも触れられていますが、「これが今のフロントエンドの主流の技術スタックです」というような紹介や解説本ではなく
を主にフォーカスした内容となっていました。
ティム・バーナーズ=リー的なところから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(=フロントエンド疲れ)といった言葉が囁かれるようにもなる。
確かに Angular/React/Vue 以外にも当時JSフレームワークは当時雑多にあって絞れない状態だったりしたので、日本でもフロントエンドの領域広すぎ問題はあがっていた記憶があります。
このような経緯などがあるなかで、この書籍ではすべての情報をキャッチアップし網羅するのは難しいため、
ことにフォーカスした内容を以降で取り上げています。
フロントエンドエンジニアでは実務でどのようなスキルが求められるかについて解説されています。
- 意味付けと文書構造・アウトラインが情報として適切に設計された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エンジニアとすることで区別し、まったく別のキャリアが用意されていることもあります。
とのことで、網羅すべき範囲が広くなってきたフロントエンドに対する理解や、二分されたイメージを開発チームがまだ持っていないという状況にある場合、まずはチームに必要なスキルセットが何であるかを明確にし、分野が違いすぎていないかを考える必要がありそうです。
やみくもに特定のスキルセットに対してベッドするということは、開発者としてあまり賢い成長戦略ではないように思えるということです。
「The Great Divide | CSS-Tricks」より引用
今もWebの成長は止まらず今後も加速するであろうなかでどうしたらいいのか、というと
必要なとき(求められたときに)、正しい場所から、必要な情報を、深く調べて身につける
何か課題を目の前にした際、いつでも実現できる状態にしておくということはフロントエンドエンジニアとして健全であるとのことで、難しそうだな。。とも思いつつ確かに負荷のかからない付き合い方としては適当なんだろうなと感じました。
最後に本書におけるフロントエンドエンジニア像として、
- 本格的なプロダクト開発チームへの参画は初めてとなる
- ブラウザを主戦場としWebをプラットフォームにしたアプリケーション開発への興味関心がある
- JavaScriptに関連する情報へのアンテナ感度が高い
- デザインのオーサリングツールについては扱ったことがない
- セマンティックなHTML構造への理解はあるものの熟知しているわけではない
- CSSによるフルスクラッチのスタイリングや特定のCSS設計手法についての知識は乏しい
としています。つまり、The Great Divide の区分でいうと「フロントエンドソフトウェアエンジニア・フロントエンドWebデベロッパー」に近いフィールドを担う人というイメージをしました。
ここでは具体的なライブラリやツールの紹介になります。またそれらが開発においてどういった課題を解決するのかといった観点が下敷きとして記載されています。
主にアジャイル、スクラムの開発手法とフロントエンドエンジニアがどのように関わるかの解説。
ゴールに向かって進み続けるプロダクトにおいて、変更要求を受けやすいのがフロントエンド・クライアントサイドでもあるのです。つまり、ユーザーや利用者に価値を届けるために一番近いエンジニアリングのフィールドにいるのがフロントエンドエンジニアと言ってもよいでしょう。
と他のサーバーサイドエンジニアとの違いが述べられています。
また一般的な開発チームの職種の紹介、そのなかでの役割については開発を前に進めるコミュニケーションハブのような責務も持つこともあるということです。
開発において最新のライブラリやフレームワークや技術要素を選択することは優先度の高い事項ではありません。動くプロダクト=アプリケーションを速いサイクルで変化に対応しながらユーザーに届けるために、必要な解決策を持っていることが重要です。
デザイナーともサーバーサイドともPM・ディレクター的な立ち位置の人とまんべんなく絡んでいくので、コードを書くという部分のみのテクニカルスキルだけでなく、他の頭を使ったりコミュニケーションスキルも必要ってことですね。
書籍のレビューサイトのjQueryのWebアプリをReact.js/TypeScriptへリプレイスする作業を題材にしてコードを交えながら解説しています。
Chapter8の解析とモニタリングでは、仮説検証やA/Bテストをプロダクトやサービスを成長させるフェーズでなぜ大事になるのかが解説されています。
スクラム開発においてフロントエンドエンジニアがチームに効果をもたらす・メリットが得られると筆者は考えています。
- 短いリリースサイクルを実現しユーザーに価値を提供し続けます
- スプリント内には決まったイベントを定義することでチームの学習を促進しメンバーが自主的に改善を試みます
- チームやプロダクトが予期せぬ変化や不確実性の高い開発を求められる場合それに耐えうるように設計されています
技術的なトレンドのキャッチアップのためには、膨大な1次情報(WHATWGの規格など)のアップデートを追うのはほぼ不可能なので、ライトにキャッチアップすることをおすすめしています。
何らか知る必要があるか分からないという場合、まずは知るきっかけを作っておく、いったんは情報を目に入れておくということが良さそうです。
Part1を中心に感想等を書きましたが、久しぶりにフロントエンド周りの本でコードが大量に掲載されているような技術書ではない類のものを読みました。
主に入門者向きの内容で、あくまでなぜそれが必要かどういう観点で使うかが主目的のためコードに関して簡易なもので記載されています。
Part2以降は実践編〜応用編になるので開発者の方は読む内容になると思いますが、Part1の最初の方に関しては非エンジニアでエンジニアの考えを知りたいみたいな興味がある方にはとても良い内容だと感じました。
実際にフロントエンドエンジニアと働いている自分からすると、なかなか客観的にフロントエンド領域というものを捉える機会がなかったのでその点が特に勉強になりました。
書籍の最後で下記のように締められていました。
昨今フロントエンドは移り変わりが早いと言われてきました。これからあなたがどのくらいフロントエンドという領域と向き合うかはわかりませんが、Webプラットフォームの仕様に影響を受けるブラウザが主戦場だからこそ変化のスピードも早いように感じることもあるでしょう。早いと感じるときは情報をみすぎているかもしれないと自分を疑ってください。新しい仕様を知ることや新しいライブラリを使うことはいずれも単体ではなんの価値も生んでいません。Webプラットフォームのエンドユーザーは開発者ではなくあなたが担当するアプリケーションのユーザーなのです。Webプラットフォームとエンドユーザー、開発者であるあなたの立ち位置は時間が経っても変わるものではありません。
ユーザーの課題を解決するために、ユーザーへの価値提供のためにWebプラットフォームを使って開発を進めていくのだ・課題を解決するのだ、ということに意識的であることや楽しむことがフロントエンド開発では大切なポイントなのです。
「早いと感じるときは情報をみすぎているかもしれないと自分を疑ってください。」というのが今までにない視点でいいなと思いました。
確かに広い範囲を細かく追うと破綻する気がしますし、目に止めとく程度でいいのかなと。
今までは技術を知らなければいけないと思いすぎていた面もあるのでそれも大事な点ではあると思いますが、もう少し本質的な仕事を思い出してユーザーに寄り添って仕事をしようと思えるような本でした。