Tech & Design LAB

Material Designベースの 「頑張らないデザインシステム」で爆速フロントエンド開発

#フロントエンド #Vuetify
author icon
Posted on
tech

はじめに

こんにちは、フロントエンドエンジニアの尾島です。 2 年ほど前から副業という形で HiCustomer の開発にちょこちょこと関わっていましたが、今年の 7 月からはフルタイムで開発をしています。 入社以来、新機能の開発と並行してデザイナーと共に進めている HiCustomer のデザインシステムの作成、アプリケーションへの適用、また運用についてご紹介します!

この記事で話すこと:

デザインシステム、デザインガイドラインとは

デザインガイドラインやデザインシステムという言葉は、人や組織によって定義や解釈が微妙に異なりますが、 一般的に以下のような構成要素(一例)のフルセットとして認識されているのではないでしょうか。

これらがあることで、プロダクト全体で一貫したデザインが保たれる。チーム内でデザインに対する共通認識が持てることによってコミュニケーションコストを下げることができる。といった意味があります。

この記事ではこれ以降、上記の認識を前提として話を進めていきます。

余談ですが、以下の記事では言葉の定義を明確にするよりも、実態としてその組織においてどのような役割があるかの認識を明確にすることが重要だと言っています。

なぜデザインシステムが必要だったか

実はこのタイミングでデザインガイドラインを定義する以前から、デザイナーが複数画面で共通化されているコンポーネントの利用用途やカラーバリエーションを定義した、 デザインガイドラインのベースとなる Figma が存在していました。

しかし、これらはアプリケーション全体でボタンの色やヘッダーのスタイルを共通化したいいったアドホックな要望に対して個別に作成されたもので、 それらの実装が終わった後は更新されることなく陳腐化した状態でした。

このような状況だったデザインガイドラインを再定義しデザインシステムを作成する必要があると感じ、アクションに移した理由には以下のようなものがあります。

この中で、特にクリティカルな課題が「プロダクトのフロントエンド開発に割けるリソースに対して UI の実装コストが高い」でした。 現在の HiCustomer というプロダクトは、CS 活動に必要な完全な機能性が揃っているわけではなく、まだまだ発展途上のプロダクトです。 そのため、足りない機能をスピード感を持って開発し、いちはやく顧客のもとにデリバリーすることがプロダクトチームとしての最大のミッションだと感じています。

この課題をさらに掘り下げて考えると、具体的に以下の課題が見えてきました。

Semantic UI の負債化

プロダクト開発初期から UI 実装に CSS フレームワークである Semantic UI を利用していました。これによプロダクトの開発初期は、ある程度一貫性をもったボタンやタイポグラフィ、レイアウトを実装でき、高い生産性を発揮できました。 しかし、現在ではアプリケーションの規模が大きくなるにつれて、次のような課題が顕著化してきました。

共通化されていないコンポーネント

デザイナーが機能ごとに作成するデザインには、機能開発ごとに新しいコンポーネントが登場し、都度1 からコンポーネントを作成する作業が発生していました。

これは、Semantic UI が提供するコンポーネントの機能だけでは足りない場合に、1 からマークアップ・インタラクションの実装などが必要だったという背景があります。 チームの規模にもよると思いますが、現在の HiCustomer にとって、これらの実装に使っている時間はなるべく抑えたいコストでした。

HiCustomer におけるデザインシステムとその実装

上記までの課題をデザイナー、PdM に共有&ディスカッションした結果、すでにあるデザインガイドラインを拡充してより実用的なものにブラッシュアップすることになりました。

具体的に行うことになった施策は次のとおりです。

次に、ベースとなるデザインシステムを選定するに当たり、以下の基準を設けました。

そして、これらの基準にマッチしたのが、Material Design でした。

またこれに沿ったコンポーネントライブラリの Vue.js 実装に当たるライブラリは複数ありましたが、比較的シェアが高く比較的コニュニティが活発であること、公式による Tree Shaking のサポートがされていることなどから Vuetify を採用しました。

HiCustomer のデザインシステム

HiCustomer におけるデザインシステムは以下の要素で構成されます。 また、それぞれの構成要素についてスモールスタートするための施策について説明します。

HC UI Guidelines(ガイドライン)

Figma に定義されたデザインガイドラインのシングルソースであり、デザイナーがこれを定義して、実装者であるフロントエンドエンジニアがこれを参照します。

ガイドラインを定義、メンテナンスするのはデザイナーです。「デザイナーが一番使い慣れたツール」で、「デザイナー以外の誰でもアクセスしやすい」という観点で、Figma を使っています。 情報を構造化して整理しやすくなることコンポーネントの実装を管理することを考えると、Invision DSM などの利用も候補に入るかと思いますが、現時点では、「Figma さえ見ればすべてがわかる」という安心感があるため現状ベストな方法だと思っています。

具体的には次のような情報がガイドラインとして提供されています。

Colors や Typography は本家の Material Design では、Foundation の項目に属し Guidelines の一部ではありません。 しかし、今回は全体としてコンパクトに収めるため、Guidelines の一部としてこれらの要素も含めることにしています。

Vuetify ベースのコンポーネント実装

先にも書いたとおり、Material Design の Vue のコンポーネントライブラリである Vuetify を導入しています。 Theme configuration で対応しきれないカスタマイズに関しては、もとのコンポーネントをラップする形でコンポーネントを実装し、style の調整や受け付ける Prop の制限などを行っています。 また、現段階ではこのデザインシステムを適用する対象のアプリケーションが 1 つだけであることもあり、パッケージ化などは行わずアプリケーションのメインリポジトリにこれらのコンポーネントを実装しています。

コンポーネント実装に関するドキュメント

デザインガイドラインに定義されたコンポーネントへの置き換えは段階的に行う想定で進めています。 そのため、例として同じボタンでもガイドラインに定義されたボタンと、そうでないボタンが同じアプリケーションの中で混在して使用されると いったケースが挙げられます。 こういったコンフリクトを避ける手段として、デザインガイドラインに沿ったコンポーネントの命名規則をリポジトリ直下の、docs/ 以下といった開発者がアクセスしやすい場所に配置するという運用をしています。

以下は、コンポーネントの命名規則に関するドキュメントの一例です。

基底コンポーネントの命名は以下のルールで行ってください。

- UIGuidelineに定義されているコンポーネントはprefix `Hc` で始める
- UIGuidelineに定義されていない基底コンポーネントはprefix `App` で始める
- Vuetifyが prefix `V` で始まるコンポーネントを実装しているため、開発者が実装するコンポーネントにはprefix `V` を使わない

Storybook

先にも書いたとおり、「デザイナーが画面のデザインを行う際に実際に使用できるコンポーネントの一覧がない」という課題がありました。 フロントエンドエンジニアが Figma に定義されたガイドラインを見ながら作業するというユースケースの他に、実装されたコンポーネント一覧を見ながら新しい画面のデザインを行うと行ったユースケースも考えられるためです。

特に段階的にガイドラインに沿った実装に移行していると、「ガイドラインには定義されているがまだ実装に反映されていない」といった場面はありがちです。こういった課題を解決するために、Storybook を導入しています。 また、これらは特定ブランチへのプッシュで、エンジニア以外のメンバーがいつでもアクセスできる状態になっています。

まとめ

上記のように HiCustomer というプロダクトのデザインシステムを Material Design ベースで、チームの規模にあった形に最適化し構築を進めています。

デザインシステムと聞くと、ある程度成熟したプロダクトや組織でこそ価値を発揮するものだというイメージがありますが、プロダクトのフェーズや組織の規模にあった形(頑張らない)で早期から構築を進めることはプロダクトの質やチームの生産性向上につながるのではないかと思っています。

ちなみに、Semantic UIに依存するコンポーネント数が減る = ガイドラインの適用が進んでいる という仮定のもと開発スプリントごとのガイドライン適用の進捗をトラッキングしている結果は次のようになっています。 (OKRの指標として追っている関係で0-1のグラフになっています)

どうしてもダイナミックにプロダクト全体に適用するということが難しいため、徐々にといったところですが、新機能の開発時に差し込む形でこれらの実装をしている状態です。

デザイナーと協力しつつ身の丈にあった形でデザインシステムを育て、いずれPublicにできる日が来るとよいかなと思っています。

最後に

私たちといっしょにフロントエンドをゴリッと開発してくれるメンバーをゴリッと募集しています。 少しでも興味を持っていただけた方は採用サイトを覗いてみてください🥺

author icon
エンジニア

常に変化を求めています。Node.js が好きで、HiCustomer のプロダクトチームではフロントエンドを担当しています。 趣味は slack に治安の悪い絵文字を追加することです。