こんにちは、UNIBAの MJ です。今回は、サイバーエージェントさまが企画されている Frontrend Vol.8 - 帰ってきたフロントレンドに参加したので、そのまとめと感想を書きます。

この記事は、絶対ブログ書くマン枠 3枠のうちの一つです。他の方の記事もきっと上がると思うので是非読んでください。

有用なリンク集

当日の動画
- ストリーム配信もやっていた！僕のまとめ見るより、本人の言葉で解釈した方が圧倒的良い
console.lealog(); さまの圧倒的なまとめ
- 各発表のポイントなどが良くまとめられており、私が書く必要ないのではと思うくらい。さっくりどんな内容か知りたい方は是非。

以下から各発表のまとめ・感想などを書きます。ざっくりとした、まとめに関しては上のリンクから見ていただいた方が良いと思うので、私的な感想の方が多いかもしれません。

Design Systems as a Product プロダクトとしてのデザイン・システムについて by @cssradar

この発表はかなり長く内容も詰まっているので、順を追って書きます。

デザインシステムって何ですか？

と言う質問が、冒頭から私たちに投げかけられました。
知ってる！と手を挙げる方は全体の 1 ~ 2 割程度でした。
当然、私は手を挙げない側です。

どうやらデザインシステムは

ユーザが利用するプロダクト全てを網羅するシステム
- タイポグラフィー
- レイアウト
- グリッド
- カラー
- アイコン
- コンポーネント
- コーディングスタイル
- etc...

だそうです。
表面的な部分だけでなく、コーディングスタイルなどプロダクトに関わる全ての人間が意識しなくてはいけなそうな話題です。

デザインシステムにはどんなものがあるか？

などが例で紹介されました。

BOOT STRAP も MATERIAL DESIGN もデザインシステムの一つなのか、と私は素直に思いました。
あくまで、それらを利用するユーザとして考えると、MATERIAL DESIGN がカバーする範囲が大きすぎて同じようなものとしては見れなかったのです。
重要なのは、デザインシステムは プロダクトのプロダクト ということです。

一つのプロダクトを作ろうとした時にできるプロダクト。
Twitter を作ろうとした時に生まれた BOOT STRAP
Gmail, Calendar などを作り直そうとした時に生まれた MATERIAL DESIGN

範囲の大小やフォーカスは異なるけれど生まれたモチベーションは一緒で、それは今もメンテナンスされ続けるもの
そう考えると不思議と納得できました。
(間違っていたらご指摘お願いします。)

なんで必要か？

プロダクトを作るにあたってありがちなケースとしてとりあえず作ってしまうということがあります。
これ自体は決して間違ってはいません。
ただデザイン的にも、技術的にも長い目で見ると負債になってしまうことがしばしばあります。

という説明がありました。
確かに、と思う方も多いと思います。私もそうです。
時間が限られた中で、どうすれば良いのか？ということに対してデザインシステムは

より良いものをより早くつくるための必須の存在
空いた時間でより上流のことに時間が避けるようになる
ユーザ視点では
- サービスのどこに触れても同じ体験ができる
- 同じサービスが受けれるという信頼性につながる

といったメリットがあるそうです。
最高ですね。
特に、ユーザと開発の視点がブレないことでより良いユーザフローの考案やパーツの開発の助けになる。という点が非常に魅力的に感じました。

構成要素は何ですか？

STYLE GUIDE
- BRAND IDENTITY
- DESIGN LANGUAGE
- VOICE AND TONE
- CODE STYLE
- PATTERN LIBRALRY

だそうです。
フロントエンドの方なら lint などを使用してコードスタイルを決めた方も多いんじゃないでしょうか？
当然デザイナ側にもそう言った要素があるといったお話ですね。

デザインシステムの難しさは？

技術的な難しさより、デザインシステムをどう運営していくかが本当の難しさ

だそうな。ここら辺は実践してみないとどうにも感じにくいですが、
まぁプロダクトも作るよりも運用していく方が難しいし納得といったところでしょうか。

重要なのはチーム

ここからが本題です。
運営していくのが非常に難しいデザインシステムにおいて、重要なのは人材です。

ここから発表は、どういったマインドやタレントでデザインシステムの構築をすれば良いかの説明が続きます。

デザイナがどんなことを形にしようとしているかに共感できること
エンジニアがシステムを作るのに必要となる仕様や方法論について理解できること
デザイナとエンジニアの中間に身を置けるバランス感覚を持てる人

が理想だそうで。。。そうですね、是非弊社にも欲しい人材だと思います。
と同時に改めてデザインシステムを構築・運営するにあたってはエンジニアとデザイナの距離が近くなる必要があるなと思いました。

フロントエンドは実装に当たっては、しばしばデザインを都合の良い解釈をしたりします。
逆を言えば、デザイナはブラウザを無視して自身にとって都合のデザインをしたりします。

時折これが重なるとストレスになって、良いプロダクトができない。何て経験があったりします。
つまり、言いたいのは共通の言語を持って意識をすり合わせる。という当たり前のことなんではないでしょうか。

そのために

フロントエンドはデザインの知識があると良い
デザイナは web の基礎は知っといた方がいい

とまとめてくれてます。

ここら辺は昔からある永遠の課題という気もしますが、デザインシステムということに取り組むと自ずとそれらも解消される。
と考えることができます。

お互いが作りたいものに対して言語化していくことで両者のギャップが埋まっていく。
という言葉はすごく納得できます。

その上でのキーパーソン

以上のことを解決していくために重要なことが幾つかあります。

ローカル開発環境
ユニット、E2E テストの自動化
クロスブラウザテストの自動化
ビジュアルリグレッション
コンポーネントを表示できる環境
ドキュメントの生成

これらを土台として、デザインシステムを構築・運用をしていきます(と言っているような気がした)。
私自身も幾つかの経験はありますが、全てできるわけではありません。
自分にできることを増やしてチームに対して貢献していきたいですね。

チームモデルの例

単生モデル
- BOOTSTRAP
- そのチーム用のUI コンポーネント集
- 一番多い
- 弱点
  - １つのプロダクトに対してやっていることなので、他への有用性はない
中央集権モデル
- デザインシステムだけを作り、メンテナンスする
- 他の人に共有したり、広めていくのが目的
- 弱点
  - プロダクトのつながりが弱い
  - アクティブな参加や貢献を得づらい
連合モデル
- MATERIAL DESIGN
- 合議によって意思決定する
- 優秀なデザインとエンジニアが必要

この中からプロダクトにあったデザインシステムを選択していくことになります。
弊社の規模だと単生モデルがあってますかね。
発表では、

一番良い力を発揮するのは連合モデルではないかと感じているが、まずはどうやって単生モデルから抜け出すかが課題

といっていました。うーむ先は長そうだ。

まとめ

デザインシステムはプロジェクトではなくプロダクト
- プロジェクトでは作り終えることがゴールになってしまう
- 一過性のプロジェクトだと良い発想には繋がらない
コストが掛かって儲かるわけではない
チームが必要
- 良いプロダクトには良いチームが必要
- マーケティング・ディレクションをする人も必要
デザイナとエンジニアのギャップが小さいければ良い
- そういう環境が人材を育てる

良い話でした。
私としては、いきなりデザインの中にどう立ち入るかというのは難しいので無理です。
そういう話ができるための土台を作れるような技術を習得しておいて、その中でギャップを埋めてく所に力を避ければなと思いました。

弊社でもこういう話は議題に上がります。ただよくあるのが、デザイナとエンジニアのギャップがあるが故に本当にうまくいくのか？と疑心暗記になりがちです。当然プロジェクトの進行などによっても妨げられたりもします。

その中でデザインシステムをプロダクトとして運用していくということが脱却するための一歩と考えると、一つ新しい視点として取り組む理由になりそうです。

良い発表ありがとうございました。

Introduction to Resource Hints by @1000ch

個人的に一番すごいと思った話。
こういう話が聞けるので勉強会は楽しい。

resource Hints とは？

W3C に仕様が書かれています。
英語読むの辛いお、、という方向けにはこちら 69log ありがたい記事。

まとめると先読みを適切にして、ページ読み込みを爆速にしようぜ！
という記事でした。
とはいえ全てのブラウザではまだサポートされてないよう。。。
ですが、適切に使えば色々便利になりそうな予感！使えるとこで使いたいですね。

そういえば昔にホバーしたリンクのソースを先に取っておくというライブラリがあったような、、、時代は進歩した。

##　Atomic Designで助かった人たち by @becyn

これは Atomic Design を使った実体験の話。
弊社でも Atomic Design チャレンジしようよ！という動きはありますが、実際使っている話を聞けるとよりやってみたいなぁという気持ちになります。

ちなみに Atomic Design はデザインシステムの一部にはなり得るけど、システムそのものにはなりませんね。
聞いた話だと デザイナーさんと阿吽の呼吸ができるようになる とか。

祭りから半年たったプロジェクトにジョインしてみた by @asukaleido

祭り(not 炎上) からジョインからの所感

フレームワークを導入しなくても貫かれた意志があれば上手くいくという現実

それは体力が全てを凌駕する仕組みなのではと、一瞬恐怖を感じた話でした。
懇親会で聞けばよかったなーと思ったところ。

UI実装の再考とa11y by @ahomu

資料はこちら

初手、残念な実装の紹介。う、頭が。
とはいえ半分以上は納得できる話。

どうやってやる？のお話に

普段からコードレビュー時の観点に含める

というのが良い話だなぁと思いました。
とかく、時間がなくて最後に良くない実装になっていたことに気づくことがありがちなパターンなの気をつけたいですね。

WCAG 2.0 を読む勉強会開いてもいいかな。と思いました。

アメブロフロント刷新にみるひかりとつらみ by @kouhin / @herablog

アメブロ2016 ~ React/ReduxでつくるIsomorphic web app ~ | CyberAgent Developers Blog | サイバーエージェントデベロッパーズブログ

にですでに書かれたお話を噛み砕いて説明してくれた最高の発表。

少し順を追って

なぜ刷新？

PV が落ちてきた
表示速度がかなり遅い
２年前の２倍まで伸びていた
Backend の API化が完了していた

というところの条件が揃っていたので、フロントエンドでのスピード改善を行おうというのがモチベーションらしいです。
表示速度はフロントエンドにとっては気になる話ですね。
やはり、表示速度は PV に深く関わるらしいです。
結果的に速度改善が行われ離脱率が減ったそうです。素晴らしい。

やったこと

速度改善
- コンセプト決め
  - 観測
    - speed curve
      - ATF 以外のリソースの遅延表示を画策
  - ブログというプロダクトについて考える
    - テキスト中心の読みもの
    - SSR と SPA
    - SSR は first Paint
    - SPA は Runtime Paint
  - 縦方向は lazy load
  - renderToString が遅い
    - Caching HTML
    - 動的な要素は Node 側で処理を入れる

今あるプロダクトを見直すというのは羨ましい経験だと思います。
観測して、プロダクトの整合性を考え、実装を行っていく。
とても良い例だと思いました。

システムのモダン化
- まるで example アプリのように
- React with Redux
  - コンポーネント思考の強制が良い
  - 見通しが良くなる
- CSS モジュール
  - スコープが切れる
- Atomic design
  - Redux 流儀のコンポーネントだと状態が多くなってしまった
  - 開発途中で書き換え
    - Organism コンポーネントがデータを撮ってきて各自更新するようにした
- Isomorphic JavaScript
- Babel を使う
  - ESLint, StyleLint
- CIテスト
- Docker
  - node の最新版をなるべく使うようにする

外でもそのまま使える技術を使うという名言。
どれもここ最近出始めた技術。惜しみなく使っていて素晴らしいなぁの一言。
Lint は弊社でも積極的に導入していて私自身も効果を実感しています。
とにかくコードが綺麗になりますし、個人の段階で問題を解消できるので余計な労力を他人にかけずに済むのも良いところ。

UX の改善
- No more ガタン
  - 初期表示の高さは固定させる方が素敵
- スクリーンリーダーで読めるように
  - マークアップも自然と良くなる

ここら辺は UX の基本ですよね。忘れがちなとこでもあるのでケアしたいと思いますね。
スクリーンリーダーに関しては、アクセシビリティの話と通ずることもありそう。

まとめ

ガンバリーリエ！！（皆がんばろう！！）

はい。頑張ります！
とはいえ、FF15, トリコ, ポケモンがある私にそんな余裕があるのか。。。
という冗談は置いといて、そういうのが当たり前に導入していける基礎練しないとなぁと思いました。

最後に

フロントレンドの内容を見ると、2,3 年前とは内容がかなり成熟した内容になったなぁと思いました。
というのも前は、単なる技術の紹介などの話が多かったなと個人的に思っていますが、
今回は、ほぼプロジェクトに導入しての何某という話や、より良いプロダクトを目指すためにまつわる何某。といった話が多いような気がしました。

そういう話が

デザイン・システム
Atomic Design

などに集約されていた気がします。

今まで色々な話がフロントエンドの中で話が出てきましたが、
個人やエンジニアの枠を超えて、プロダクトの構造自体をしっかりと考えていく力をつけていくのが今後の課題かな。と思いました。
何だか書くと、今まで考えてなかったんかい、、、的な印象になってしまいます。
認識することが第一歩ということで、社内で今回の発表を共有したいですね。