CLOSE

デザインシステムにおけるフロントエンド(全2記事)

2019.12.18

Brand Topics

PR

柔軟性と拡張性の両立––LINEのデザインシステム構築における、フロントエンドエンジニアたちの挑戦

提供:LINE株式会社

2019年11月20、21日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2019」が開催されました。1日目は「Engineering」をテーマに、LINEの技術の深堀りを、2日目は「Production」をテーマに、Web開発技術やUI/UX、プロジェクトマネジメントなど、より実践的な内容についてたくさんのプレゼンテーションが行われました。「デザインシステムにおけるフロントエンド」に登壇したのはLINE Front-end Standardizationチーム Front-end Engineerの岡崎晶彦氏。LINEはなぜデザインシステムを必要としたのか? どのようにデザインシステムを捉えているのか? 後半パートとなる今回は、Webで用いるパターンライブラリの各要素の解説と、実装について解説しました。講演資料はこちら

デザインロスをなくすために必要なこと

岡崎晶彦 氏(以下、岡崎):それでは現在開発中のWebを中心としたパターンライブラリに移ります。

パターンライブラリにはCSS、Vue、React、そしてIconsがあります。Iconsは少し特殊で、Webとアプリの共通のパターンライブラリになります。独立したミニマムなデザインシステムと呼べるかもしれません。そのため、この階層図ではWebとアプリの中間に位置しています。

これはLINEのメッセンジャーの設定画面です。右上を見ていただきたいんですが、クローズボタンがあります。このアプリに入っているクローズボタンは何種類ぐらいあるか、みなさま想像つきますか? なんと10種類もあります。よく見ていただくとカラーだったり、透明度、大きさ、ストローク、アイソレーション、あとはファイル名が全部異なっています。正直、こんな多くのクローズボタンは必要ないですよね。

ところでみなさま。農家の方にとって一番悲しいことって何でしょう。それは自分たちが作った食材が使われずに廃棄されることです。

売れ残りや食べ残し、規格外、本来消費されるはずだった食品が廃棄されることをフードロスと言います。

これをデザインに置き換えるとデザインロスになります。

規格を統一して計画的に生産と在庫を管理すれば悲しいデザインロスは防げたはずです。アイコンを正規化してデザインロスを回避します。正規化するにはネーミング、柔軟性、そしてシングルソース化が必要です。

LINEのメッセンジャーに含まれるアイコン名です。機能としては非常にわかりやすいんですが、ライブラリとして提供するには汎用性が必要です。

固有の機能を示す言葉ではなく、アイコンの形状を示す言葉に置き換えます。friendであればuser、add friendであればuser-plus、membersであればusersですね。これが私たちの命名規則です。

LAICONの仕組みとできること

次はLAICON、LINE Atomic Iconsを紹介します。

アイコンを元素に見立てて周期表を作りました。せっかくアイコンを作ってもアクセスできなければ何の意味もありません。LAICONは簡単にアイコンを検索できるシングルソースです。検索用のmetaデータも追加できるので、名前以外の情報でも検索できます。現在200を超えるアイコンが登録され、LINEのWebサービスで利用されています。

アイコンのソースはすべてSVGで管理しています。

テキスト同様にカラーを変更したり縮小・拡大が可能です。XMLなので軽量ですし、gzip圧縮でさらなる軽量化も可能です。非常に柔軟性があります。

さまざまな開発シーンに合わせて使えるように、基本的なCSS、Vueコンポーネント、React、インラインSVG、Unicodeの多彩な実装方法を提供しています。

現在のデプロイフローです。

デザイナーが作ったアイコンをZeplin経由で受け取ります。エンジニアがGitHubにプッシュします。登録されたSVGはWebフォントに変換されます。WebフォントはCDN、Private npm、そしてLAICONのWebサイトにデプロイされます。ちょっと更新の手順が多いのが難点です。

こちらは将来のデプロイフローです。

デザイナーが直接、管理ツールのLAICONマネージャーにSVGアイコンをアップロードします。その際に検索に必要なmeta情報を追加します。そしてレビューが終わると自動的に配信される仕組みを検討しています。ニーズの高いスケッチのシンボルもWebサイトから配信予定です。さらにここのImaging API経由で画像の提供も計画しています。

Imaging APIの仕様です。

画像フォーマット、カラー、高さ、シェイプを指定できます。画像フォーマットはWebPとPNG、カラーはRGB形式でアルファチャンネルも指定可能です。シェイプはsquareとcontentの2種類用意しています。squareは常に正方形で出力されます。contentはアイコンの形状に沿ったものが出力されます。フォントで言えば等幅とプロポーショナルの関係に近いです。

一般的な用途ではアイソレーションを含んだsquare型が適しています。

LAICONは今、Webを中心に使われていますが、Android、iOSともに、カスタムフォントがアプリ内で使える環境が整ってきています。クライアントアプリにLAICONを導入する日も近いと思います。

パターンライブラリにおけるCSSについて

次はパターンライブラリにおけるCSSです。デザインシステムに求められるテーマ機能、即時性、アダクティブコンポーネント。

これらの取り組みについてお話します。CSSでは用途に応じた6つのカラーを定義し、コンポーネントのバリエーションに適用しています。

primary、secondary、success、danger、warning、info。Bootstrapと同じです。

iOSに導入されたダークモード、省電力やコンテンツへのフォーカス、ナイトモード対応へのメリットがあります。モバイルファーストで考えたとき、ダークモードへの対応も考慮しなければいけません。LINEのブランドカラーはご存知のとおりで緑ですが、メッセンジャー以外のサービスはそれぞれ異なるブランドカラーを持っていることがあります。

サービスの個性を引き出すためには個別のテーマが必要でした。

もし、テーマを切り替えることができれば、デザインシステムはサービスにフィットして非常に使いやすいものになります。それを実現するのがカスタムプロパティです。

カスタムプロパティによって、CSSだけでテーマ機能を実装

プライマリカラーがvar関数でセットできます。1番目の引数がセットされていなければ、2番目の引数が代替値としてセットされます。この仕組みを使ってCSSだけでテーマ機能が実装できます。

CSSでカラーを指定する方法は複数ありますが、ここではRGBとHSLを比較します。

ここの緑を見てください。上から下にかけて10パーセントずつ暗くなっています。これをRGBで調整するのは非常に大変です。でもHSLであればL、ライトネス、こちらの明るさをコントロールするだけで簡単に調節できます。10パーセント暗くしたければ10パーセントマイナスするだけです。

これはよくあるボタンのデフォルト、ホバー、アクティブ状態です。先ほどと同じように明るさが上から10パーセントずつ暗くなっています。カスタムプロパティとHSL、calc関数を組み合わせればCSSだけで色合いを作ることができます。Sassやコンパイルが必要ないので、即時性に優れています。

アクセシブルなコンポーネントにはコントラストが必要です。

ライトなバックグラウンドであればダークなフォアグラウンド、反対にダークなバックグラウンドであればライトなフォアグラウンド。こちらも同様にカスタムプロパティとHSL、calc関数を組み合わせて実現できます。

この例では明るさ70パーセントを閾値として、指定された明るさとの差分を出します。そこに-100パーセントを掛けてオーバーフローさせます。

すると文字色は閾値を上回ったら黒、下回ったら白に変換します。こちらもCSSだけで実現できます。グリッドを含めたらレイアウトは5段階のレスポンシブレイアウトを提供しています。

一方、コンポーネントは今までブレイクポイントに関わらず同一スタイルでした。しかし、モバイルとデスクトップではクリッカブル領域やスペース上の制約が異なります。

そのため、スモール以下をモバイル、それより上をデスクトップと位置付け、2段階のアダプティブコンポーネントを計画しています。レスポンシブなレイアウトとアダプティブなコンポーネント、それが私たちのCSSです。

VueとReactの使用率が高いが、しかし…

次はパターンライブラリにおけるJavaScriptです。冒頭のイントロダクションでもお伝えしたように、LINEはVueとReactが多いです。この2つだけで考えるとVueが57パーセント、Reactが43パーセントで、VueがReactよりも優勢です。

それに基づき、私たちはkoromo-vueを開発しました。そして次はニーズの高かったkoromo-reactの開発を計画していました。

しかし、ある問題に気付きました。koromo-vueはVueで動きますが、ReactやAngularでは動きません。

同様にkoromo-reactはReactで動きますが、VueやAngularでは動きません。コンポーネントライブラリは開発のイニシャルコストだけではなく、維持するランニングコストもかかります。保守するライブラリが増えれば増えるほど、我々の負担はどんどん増えてきます。

Webコンポーネントの検証と採用

そこでWebコンポーネントの登場です。

再利用可能なコンポーネントを作ることができるブラウザのAPIです。WebコンポーネントはIE、Edgeを除く、ほとんどのブラウザで動作します。

また、Web標準技術ですので、普遍的な仕様として開発の投資効率が期待できます。Webコンポーネントが我々のデザインシステムの実用に耐えるかどうか、検証実験を行いました。

観点は全部で5つ。

WebViewで正常に動作するか、VueやReactで使えるかどうか、そしてkoromoのソースを再利用できるかどうか、そしてデベロッパーの学習曲線はどうか、最後はPolyfillのインテグレーションです。結果はIE 11のサポートが必要な場合だけPolyfillの設定が必要ですが、それ以外はすべてクリアできたので、我々は開発に踏み切りました。

koromoのWebコンポーネントライブラリ、それがkoromo-elementです。

koromo-elementはどのようなフレームワークでも動作します。

Vue、React、Angularで動く再利用可能なコンポーネントです。今使っているフレームワークが将来バージョンアップで破壊的なアップデートをしたり、また、それにとって代わる新しいフレームワークが登場してもkoromo-elementはそのまま使い続けることができます。

カスタムエレメントで見通しの良いコードが実現できます。

koromoのコードはkoromo-elementではこのようにスマートに記述することが可能です。もうdivだらけのコードを使う必要はありません。koromo-elementはkoromoをベースに開発を行います。koromoの各コンポーネントごとに分解したHTML、CSS、JavaScriptをコピー、再利用してkoromo-elementを開発します。

コンポーネントにもよりますが、HTML、CSSの再利用率は90パーセント以上と、非常に高い利用率を見込んでおります。今までのところを少しまとめます。

koromo-elementは再利用可能なコンポーネント、そして容易にテーマを変更できるコンポーネント。また、WebViewとブラウザ、そしてモバイルとデスクトップで動作するコンポーネントを目指して開発をしています。

koromo、koromo-element、LUIの関係

ところでみなさま、「LIFF」をご存知でしょうか。「LIFFを知っているよ」という人はどれぐらいいらっしゃいますか?

(会場挙手)

ありがとうございます。70パーセントぐらいですね。LINE Front-end Frameworkを我々はLIFFと呼んでいます。

LIFFとはLINEアプリで動作するWebViewベースのフレームワークで、一般にも公開されています。ここにいるみなさまもお使いいただくことが可能です。去年の6月にバージョン1をリリースして、先月バージョン2をリリースしました。

私たちはみなさまがLIFFでお使いいただける専用のユーザインタフェース、略してLUIの提供を企画しています。

これはコンパクトなViewタイプの例ですが、アプリ上のレイヤーがLUIです。LUIはkoromo-elementを組み合わせて構成する予定です。

LUIの説明のためにAtomic Designを定義します。

原子レベルが単体のコンポーネント、分子レベルが複数のコンポーネント、有機体が機能の完結したコンポーネント、それらを組み合わせたものがテンプレート、実際にデータを流し込んだものをページとします。koromoは原子レベルからテンプレートまでを提供します。

koromo-elementはkoromoの原子・分子レベルを再利用して開発します。そしてLUIはkoromo-elementの原子・分子レベルをまとめた有機体のテンプレートレベルを提供します。少し複雑ですが、koromo、koromo-element、LUIは、このような棲み分けになっています。

デザインシステムを支えるフロントエンド

それではサマリーです。

私たちのデザインシステムにおけるアプローチは押し付けたり強制するものではなく、ボトムアップ型のゆるめなスタンスです。提供するパーツはモジュール型と統合デザイン型の中間になります。そしてデザインシステムを支えるチームは分散型ではなく集中型となっています。

デザインシステムを構築しているメンバーは30名弱の規模です。これはWebだけではなくアプリも含めた全体の人数になります。

プロジェクトマネージャーは先ほどのJakeの1名と、UXデザイナーが6名、UIデザイナーが10名、Androidエンジニアが1名、iOSが3名、そしてフロントエンドエンジニアが10名超の構成になっています。

我々フロントエンドパートは東京と京都のメンバーが参画しています。

LAICONが3名、koromoとkoromo-vueが4名、そしてkoromo-elementは6名の構成になっています。koromo-elementのうち3名はLIFF開発チームであり、LUI開発にも携わっています。ここにいるのはすべてUITのメンバーになります。

これが私たちのデザインシステムにおけるフロントエンドです。

Webのパターンライブラリとしてkoromo、koromo-element、そしてLAICON。CSSであればkoromo。Vue、React、Angularであればkoromo-element。Webアプリ共通で使えるのがLAICON。このようにして我々フロントエンドはデザインシステムを支えています。

デザイン原則の上にスタイルガイドとパターンライブラリは乗っています。パターンライブラリとスタイルガイドは自転車の両輪に似ています。方向性を決める前輪がスタイルガイド。それを推進する後輪がパターンライブラリ。どちらか一方が欠けてしまうと、うまく走ることができません。互いにつながって連動しています。

本日紹介したkoromo、koromo-element、LAICONはギアの付いた後輪です。私たちは状況に応じてギアを切り替え、LINEの開発を加速させていきます。

本セッションは以上になります。ありがとうございました。

(会場拍手)

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

LINE株式会社

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • お互い疑心暗鬼になりがちな、経営企画と事業部の壁 組織に「分断」が生まれる要因と打開策

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!