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

目次

  • 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の仕様のアップデート速度
  • 支払いや認証APIChrome(ブラウザ)が提供し、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部門のテストエンジニアと協働し仕様から正常系のテスト項目のレビューを行う
フロントエンドエンジニアの実務から想起されるスキル群

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

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

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

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

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

f:id:jotaki:20210318195822p:plainThe 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
フレームワーク:ビューライブラリ: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プラットフォームを使って開発を進めていくのだ・課題を解決するのだ、ということに意識的であることや楽しむことがフロントエンド開発では大切なポイントなのです。

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

2020年に読んだ本

フロントエンド / Web

UI/UXデザイン

開発手法

AWS関連

自己啓発・その他

まとめ

2019年と比べると3〜4冊少なめ。
SAPの試験本ばかり読んでる時期があることを考えると、思ったよりは読んでました。
結構偏ってしまった印象で、Vueやフロントエンド周りのインプットが書籍ではできてないという感じですね。

リモートで通勤時間なくなって本を読む習慣を付けづらくあるのが難しい所ですが、時間的には前より増えているはずなのでうまく時間みつけて今年も本を読んでいきたいです。

2020年後期のWebサイト

2020年後期分です。

RSSでギャラリーサイト購読して気になったのはPocketでブックマークのなかから選んでます。
今回はジャンル別で分けてみました。

医療系が多めになってしまいましたが、特に注目していたわけではないのでたまたま好きなサイトが多かったのかなと。
テイストとしては柔らかめのものでも今までよりもがっつり柔らかい感じではなく適度なものが多めで、パリッとしたサイト(V-RESAS, ベンザブロック, ジャストシステム)も対象に入るようになりました。

個人的ベストは、気仙沼 男山本店のサイト。
今までWebで見たこと無いトーンやレイアウトで印象が強く残りました。

医療・福祉

V-RESAS | 新型コロナウイルス感染症が地域経済に与える影響の可視化

f:id:jotaki:20210303120654p:plain https://v-resas.go.jp/

鼻水・のどの痛み・熱。症状別の風邪(かぜ)薬ベンザブロック

f:id:jotaki:20210303120703p:plain https://benza.jp/

医療法人社団せいおう会 | 鶯谷健診センター

f:id:jotaki:20210303120716p:plain https://seioukai.jp/

株式会社 日本・精神技術研究所(日精研) | 心理アセスメント・心理トレーニン

f:id:jotaki:20210303120735p:plain https://www.nsgk.co.jp/

天水福祉事業会

f:id:jotaki:20210303120753p:plain https://tensui.or.jp/

コーポレート

株式会社にんべん|鰹節やだしの製造販売なら

f:id:jotaki:20210303120808p:plain https://www.ninben.co.jp/

次の「あたりまえ」をつくる - ジャストシステム

f:id:jotaki:20210303120828p:plain https://www.justsystems.com/jp/

TAGUCHI | タグチ工業

f:id:jotaki:20210303120844p:plain https://www.taguchi.co.jp/

株式会社果実堂テクノロジー

f:id:jotaki:20210303120853p:plain https://www.kajitsudotech.co.jp/

気仙沼 男山本店|蒼天伝・美禄・男山|創業大正元年

f:id:jotaki:20210303120904p:plain https://www.kesennuma.co.jp/

メディア

SUB-ROSA

f:id:jotaki:20210303120914p:plain https://sb-rs.com/

The Graphic Design Review

f:id:jotaki:20210303120930p:plain https://gdr.jagda.or.jp/

gooone(ゴーン) | 三浦・三崎の観光情報マガジン

f:id:jotaki:20210303120947p:plain http://gooone.help/

その他

ホンマタカシ監督「建築と時間と妹島和世

f:id:jotaki:20210303121007p:plain https://kazuyosejima-movie.com/

養生ごはんのひみつ | 大阪北堀江の薬膳 天然食堂かふぅ

f:id:jotaki:20210303121024p:plain https://cafuu-shokudou.com/

2021年2月 振り返り

結果

ブログ

目標:月 8 回(週2回)更新
結果:月 4 回 更新

読書

目標:月 1 冊
結果:月 1 冊

反省点など

振り返りすらままなりませんでしたが、ちょっと復調

来月に向けて

資格勉強も落ち着いて色々勉強する気持ちになれているので、まずは昨年残しになってしまったものからがんばります。

【読書メモ】オンスクリーン タイポグラフィ 事例と論説から考えるウェブの文字表現

先日、オンラインの発売記念イベント にも参加した「オンスクリーン タイポグラフィ」を一通り読んだのでメモしておきます。

目次

構成はWeb Typograpy, Accessibility, Web Font, Historical Changesの大項目からなり、上記の各10ページ前後のコラム文、それらに関する10例程度の事例を画面キャプチャ付きで掲載されています。 コラムもビジュアル多めなので文章を読む感覚はさほどなく、めくりやすい本だと感じました。

ポイント

気になった点などのメモです。

01_ オンスクリーンタイポグラフィの本文

  • 文字サイズはPCで16px相当が2020年現在で最も読みやすいサイズといえる
  • 行帳は全角35〜45文字がひとつの目安
  • サイズ指定は相対指定で
  • 書体は基本的にユーザはデフォルト書体が読みやすいのでは。しかしそこでデザイナーが思考停止するのも良しとは言えない。
  • Webフォントも日本語の場合デメリットがフォーカスされがちだが、書体開発など業界のこと考えるとそこも尊重すべき選択があって良い。
  • コントラスト的に黒は#111〜#333がベター、#000は少し強く感じる。
  • 文字詰めは主要ニュースサイトで本文で font-feature-settings を適用しているサイトはなし。
  • 各環境での最善を尽くしつつ、ユーザーの自由度を奪わないデザインを心がけるべき。

事例の選定、イトイ新聞とTHE FASHION POST、Yahoo!ニュースのピックアップでらしいなあと思った。

02_ Webで紙のようなレイアウトを実装するには

  • 見出しの文字詰めを実現するには font-feature-settings, letter-spacing を使うことが代表例だが、イラレからアキ情報取って使うことも可能(getKerning
  • 本文の約物が続いた場合の処理はアキを自動調整するフォントを使う方法がある(約猫
  • text-align: justify にすると欧文の長めの単語が入ると前の行が不自然に開くときも。 そのときは hyphes: auto
  • その他、行間を基準にしたグリッド設計、箱組みのためのfloatボックスの活用など

03_ オンスクリーンタイポグラフィの夜は明けたか

デジタルメディアの特徴や課題として、

リリース後ほぼ変わらないコンテンツを最大限に魅力的につくろうとする取り組みとは逆に、どんな内容でも見やすい状態を提供する可視・可読性のためのフォーマット設計の方を重視すべき場面も多い。

とありますが、自分も最もデジタルで考えるのはその点。うまいデザイナーの定義あげるとするとその点がうまい人がWebのデザインがうまい人と思ってます。

また乗り越えておきたい課題として、「実装者を評価する」をあげています。

デジタルメディアのエンジニアは、視覚的な完成度や意味、文書構造、情報構造などに対する興味が薄い場合がある。プログラム的素養を高めるほうが業界での年収が上がりやすい一方で、視覚的な再現はエンジニアリングを介さずとも実現できる仕組みづくりが活発になってきているため、目標とし難いのが実情なのであろう。 ... プログラムしたものを伝わる、使える形に転換できる。そんな実装者を評価し、よきパートナーとなることもクオリティ改善の一助となるであろう。

こちらも深くうなずきたい部分で、デザインの再現性や汲み取りする能力をエンジニアは評価されづらいと思う。(or そもそも評価軸がない。)それはエンジニアの評価はエンジニアが行うというのも大きいように感じていて、より良いものが世の中に出回るようにデザイナーや視覚性を大事にしている人がもっとフックアップ的なことをすることも大事なのかなと思っています。

04_ Webアクセシビリティタイポグラフィ[前半]

  • Webのメディア特性として、特徴的な点はユーザー自身が見た目を変更できる点がある。
  • コンテンツ側はよいデフォルトを提供し、ユーザーはユーザースタイルシートなどを活用しコンテンツとユーザーが協力した形でよいタイポグラフィが実現できる。
  • WCAG2.1達成基準例
    • テキストは支援技術なしで200%までサイズ変更できる
    • 使用している技術で意図した視覚的提示が可能である場合、文字画像ではなくテキストが使われる
    • テキストブロックブロックでは利用者が全景と背景色を選択できる。幅が80字を超えない(全角の場合は40字)

05_ Webアクセシビリティタイポグラフィ[後半]

  • 文字サイズは実機で評価する
  • サービスのターゲットに合わせて適切な文字サイズを選択する
  • 視野は個々人により異なる。重要な要素ほど中央寄りに集める
  • 疑似ボールドは意図しない潰れの原因になるので使用しない

06_ プロダクトのアイデンティティを表現する文字

Apple, Google, Uber, Dropbox, Atlassian, Facebook, Twitter, Figma, 楽天, メルカリの書体選定や使用例。
確かにAppleのSan Franciscoなど自社開発でのフォントが増えるなか、TwitterHelvetica Neueを使用していて普遍性を強調しているのが印象的です。最近、Chirp フォントが出回っているので、そのようにサービスに組み込まれるかも楽しみです。

07_ 「読みやすさ」の不思議

  • 「読みやすさ」の指標はさまざま。道路標識と書物では異なる視点でのフォント選びが必要
  • オンスクリーンでの「読みやすさ」は「バックライトによる文字のアウトラインのぼけを考慮したフォントを選ぶこと」
    • ふところの広い書体
    • 縦線と横線のコントラストが低い
  • スクリーン向きのフォントの例にオンスクリーン用にリデザインされた Benton Sans RE などは使ってみてよいのでは
  • 各UD書体、オールドスタイルでも丸明オールド、明朝で3種類のコントラストが用意されているTP明朝もオンスクリーンに適している

08_ 日本語Webフォントの過去、現在、未来

  • Webフォントの変遷(2009年〜)
  • 日本語環境ならではの配信技術(ダイナミック・サブセッティング)
  • セルフホスティングでの配信
  • 日本語Webフォントの文字詰め機能
  • Webフォントのサイズはサンセリフ体よりセリフ体のほうが基本は軽くなる。(アンカーポイントが少ないため)

日本語環境におけるWebフォントの課題について、Webフォントを導入すると重くなる、は必ずしも正解ではなく、さまざまな配信技術やレンダリングの方法があるのでそれを使っていきましょうという方向性の話でした。

表示が遅く感じる理由は、システムフォントが表示された後に、Webフォントの表示が開始されることに起因していることが多い。つまり、この画面がチラつく挙動が遅さを感じさせてしまうのである。

確かに盲目的にWebフォントは遅いっていうイメージにとらわれている感は否めないので、きちんと切り分けして考えないとなと思いました。

09_ Webタイポグラフィの変遷と現代的常識

感想

この本に掲載されているような文字周りのCSSって、ボックスをレイアウトしたりするCSSとはまた別で、そこの対象範囲で興味を広げないと今のブラウザでできることやスタンダートなことを捉えるのがなかなか難しかったりすると思っているのですが、今回この本を通してそのあたりはインプットできた印象があります。
ただもっと大枠の選定の話とか、先日のイベントの際にも感じましたがここ数年追えていない感が残っていて、たづがね角ゴシックは結構使いやすいと言われてる書体なんだなとか、そんな程度なのでもうちょっと追いついておきたいなあという焦りも持ちました。

オンスクリーンに絞ったタイポグラフィ系の書籍は ウェブタイポグラフィ もありますが、今回のオンスクリーンタイポグラフィも初学者が読むには敷居が高めな印象もあるので(基礎的な内容もあるが発展系への展開もある部分で)、もう少し大衆的な雰囲気のあるベーシック部分をカバーした書籍も今後出るともっと裾野が広がるというか興味を持ったり意識を持ちながら仕事をする人が増えるのかなと感じます。
決して教科書的なこうしなさいというやり方を教える成分は弱めかなと思います。こういう考え方がありますよの提示的要素の強い本だなという印象です。

ともかく久しぶりに発売が楽しみな本があって、それを予約して届いて読んで、執筆陣も個性豊かでとてもお気に入りの本になりました。

【イベント】Front-End Study #4「いま考えるユーザー体験とデザイン」

ForkwellさんのオンラインイベントFront-End Study #4「いま考えるユーザー体験とデザインの世界」を視聴しました。
フロントエンドエンジニアがデザインとどう向き合うべきかという興味のあるテーマの中で各セッションを聞けたので、メモと感想を残しておきます。

セッション

  • 基調講演「フロントエンドエンジニアが今学ぶべきデザイン」
  • セッション1「共創するためのデザイン批評」
  • セッション2「サービス横断デザインシステムのフロントエンド開発に携わって学んだこと」

基調講演「フロントエンドエンジニアが今学ぶべきデザイン」

サイバーエージェント 谷さん
発表Figmahttps://www.figma.com/file/a4m5ohTjU6JWZ80CGVTAMd/Front-End-Study-%234?node-id=44%3A103

FLOCSSのは知ってましたが、魅せるiPhoneサイトもこの方だったんですね。昔とてもお世話になりました。
スマホのリキッド実装と拡縮実装の両方どっちが正解やスタンダードが分からなくて、本読んで腑に落ちた記憶があります。

フロントエンドエンジニアができること

マイクロインタラクション

表現としてのエフェクトはデザイナー
ただリアクションには多くの領域が含まれる(VoiceOverに対してなど)のでエンジニア側も一緒に考える必要。

レイアウト

ずれているのが問題というより設計された情報の意味や狙っている効果がなくなることが問題
そうならないために「デザイン」をプロセスとして遡る必要がある
レイアウトの意図、情報構造の設計を理解してそれに適したマークアップをする

パフォーマンス

Core Web Vitals(LPC/FID/CLS)
CLSの向上は実装する段階ではもうどうしようもないこともある
状態ごとのパターンのデザインを作る

デザインへの接し方

  • デザインの批評・レビューをする
  • デザインの仕組みをつくる
  • UIデザインのアプローチを変える
  • デザインツールを使ってみる

デザイナーとフロントエンジニアのデザインの境界はない
職務ではなく役割として考える

質疑応答

Q.異なる職種でやってよかったこと、うまくいかなかったこと
新規のタイミングからみんなでFigmaに向かいあってやるとよい
デザイナーは途中経過のものは見られたくないみたいな感覚が初期はあるがそこを1回乗り越える

感想

レイアウトのところでピクセルパーフェクト論ではなく、伝えたいことが伝わるかが大事というところでちょっとハッとしました。
自分はデザイナーの意図汲んでコーディングするの得意と思ってますが、完璧に再現できるのが大事というよりは本質的にユーザーに届くかが大事だなと思って今後はその視点でやっていこうと思いました。
Figmaの使い方にちょっと触れていましたが、考えてみたらこれワイヤーとデザイン並行で同じところに描けるのでおもしろいですね。

セッション1「共創するためのデザイン批評」

ClassDo takanoripさん
スライド: https://speakerdeck.com/takanorip/gong-chuang-surutamefalsedezainpi-ping

デザイン批評の基本

デザインがプロダクトの目的を達成するために適切かどうかを判断する
批評には適切な方法がある

デザイン批評とデザインレビューの違い

  • デザイン批評:デザインが目的を達成できるか判断するための分析手法
  • デザインレビュー:デザインの承認や合意形成のために行われるミーティング。

ベストプラクティス

  • 質問で始める
  • 感情のままに話さない
  • 自分の意見が正しいと思い込まない
  • 意見を押し付けない
  • 長所について話す
  • 「誰の視点から考えているか」を考える

おおまかにスタンスとしてはコードレビューと同じですね

見た目にとらわれない = 見た目の好き嫌いを表明することは「批評」ではない
エンジニアがデザインに口出しし辛い風潮があるのは見た目に意識が行っているからで、本質に焦点を当てることが必要になる

デザイン批評

  • デザインの目的を理解する
    • なぜこのデザインにしたのか、これがレビューの「基準」になる
  • 使いやすさを確認する
    • 達成したいことを迷わず達成できるか
  • ダークパターンになっていないか

デザインレビューで考慮すべきポイント

  • UIの一貫性(一貫性のないデザインを鵜呑みにしない)
  • 実装難易度
    • 本来はデザインつくる前に確認する
  • データとUI
    • データ構造とUIに矛盾がないか

みんなではじめるデザイン批評 はデザイナーもエンジニアも読んだほうが良い

感想

どこからどこまでがデザイン批評と定義されどういうメリットがあるのか話されていたのでその点が一番勉強になりました。
見た目にとらわれない、っていうのはなるほどなあと。
ある程度慣れが必要とも感じますがデザイン確認するとき基本実装可否についての確認に留まってしまっていましたが、もうちょっと踏み込んでやってみようと思いました。

セッション2「サービス横断デザインシステムのフロントエンド開発に携わって学んだこと」

ヤフー 春野さん
ヤフーのデザインシステム「Riff」の開発においての話

デザインシステムを作る目的

  • UIデザインの品質向上
    • デザインの当たり前品質を担保する
  • UIデザインの業務効率化

制作物としてはスタイルガイドとUIライブラリに分けられる

デザインシステム制作の流れ

  • スタイルガイド制作グループ
  • UIデザインキット制作グループ
  • コーディング開発グループ それぞれ5名程度、兼務でジョイン

  • プロダクト側へヒアリング

  • 必要なスタイルガイド、コンポーネント洗い出し

取り入れているツール

React/TypeScript/StoryBook
ビジュアルのテストツールには reg-suit
これはVRT(ビジュアルリグレッションテスト)というものでビジュアル面のテストが行える
reg-suitは変更前と変更後のキャプチャを撮って差分を確認できる

感想

ビジュアルリグレッションテスト、初めて知りましたが便利そうで使ってみたいですね。
デザインシステム制作チームの人員ってYahooでもだいたい兼務でということだったので結構大変そうだなと・・・
最後にメインの仕事のノウハウ持ってこられるというのを聞いてメリットもあるなあと感じました。

全体感想

一応括りはフロントエンドの勉強会で視聴人数はそこまでなかったと思いますが、平日夜にオンラインで1000人規模で興味持たれるイベントもすごいよなあと感じました。スポンサーもついてライトなTV番組みたいです。
全体としては、登壇した方々は自分と同じフロントエンドエンジニアという職種で、組織として個人としてデザインへの関わり方の熱量がちょっと違うなというところでモチベーションが高まりました。自分ももともとデザインから入った世界というのもあり、そこにもっと向き合う必要がありそうです。

次回もなかなかつよつよなメンツなので参加してみたいと思います。

【イベント】タイポグラフィを武器にする 〜文字とデザイン、WEBとUI、そしてUXのお話〜

イベント概要

Connpass: タイポグラフィを武器にする 〜文字とデザイン、WEBとUI、そしてUXのお話〜
書籍『オンスクリーン タイポグラフィ 事例と論説から考えるウェブの文字表現』の発売記念イベントとして、この書籍から派生して現場で使えるTipsやあるある話などを共有する会という感じでした。

トークテーマ

など、実際の現場レベルでのよくある悩みやこれどうしている話をされていました。

登壇者はGoodpatch Anywhereのカワセさん、ハマダさん、SmartHRの桝田さん、編集者の宮後さん。 自分の中ではネット上での昔からの有名人の方々でした。

オンスクリーン タイポグラフィについては、カワセさん、ハマダさん、桝田さんなど計9名の方の論説をまとめている本です。 2/17の発売で今読んでいる最中ですが読書メモは別でまとめます。

勉強になったこと

ガイドラインを守ることが大事」ではなく、主観によって判断されがちな色の指定などの基準にこういうのを使うといいですよっていう内容

桝田さんはアクセシビリティに大変詳しいエンジニアの方ですが、自己紹介の流れで書籍のコラムの内容についてこのように最初に話していて、そういう心持ちなのかとちょっと意外なところもありました。
個人的な勝手なイメージですがアクセシビリティ詳しい人と詳しくない人って分断されがちで、詳しくない人(自分)は詳しい人を怖がっているところがある印象があります。
それに加えて「善意のバリア」的な見方で、僕の去年読んで一番印象に残った記事にある、「アクセシビリティはさ、誰かのためにとかじゃなくて、自分のためにって思ってやるといいと思うよ」 的なスタンスでのトークだったのでとても自分ごととして勉強させてもらえました。

要素をちゃんと作ってからページデザイン作成

  • カラーパレット作る
  • フォントサイズのジャンプ率作る

コンポーネント作る前にこれらをエンジニアと話して進めるだけで後々の辛さが軽減されるというは納得です。

デザインカンプの一枚絵ではなくレイヤーなどのデザイン構造など中間成果物のなかを見ること

どういうデザインがコーディングしやすいか、みたいな話の流れだったと思いますが、デザインで空けられているスペースが16pxなのか1文字分として空けられているのかはデザインデータ見て分かると実装もしやすいと。
自分もエンジニア側なのでもちろん同感で、リストテキストのline-heightでリスト間のマージンを取っちゃうかline-heightは適正値で取ってちゃんとスペース開けるかで全然違うところかなと感じました。

また難しいデザインが上がってきたときにチーム全体で解決できなくフロント側だけが負荷がかかってしまうことが問題みたいな考え方も、これまでそういう取り組み方で仕事あまりしてないのでなるほどそういう考え方なんだなあと思いました。

アクセシビリティ向上、「向上」は何を持って判断しているのか

定量的な結果ではなく、特定の機能が特定の条件で動く
例えば特定の機能をキーボードのみの操作で完了できるなど。

まとめ

失礼ながら書籍の宣伝的な要素が強いイベントと思ってましたが、その要素がゼロだったので楽しかったです。
参加する前はデザイン的な話がメインかなと思ってましたが、聞いてみると実装のテーマや内容に関してばかり興味が惹かれたり勉強になりました。
登壇のデザイナーさんの話聞いてると実装のリテラシーも高いんだなというのが印象的でした。