🛹

FE的観点からのデザインシステム事始め

2022/12/12に公開

■ はじめに

こんにちは。株式会社ペライチ のフロントエンドエンジニア藤田です。
デザイナーやサーバーサイドのエンジニアと連携を取り、アプリケーション内におけるユーザーと関わる部分の機能開発や改善が普段の主な業務内容です。

現在開発に携わっているプロジェクトにおいて、CSS 周りの負債を返済する一環として実験的にデザインシステム的な概念を導入してみました。
すべて触れると長くなってしまうため、今回はそのきっかけと、簡単に導入部分のお話をできればと思います。

■ ペライチにおける CSS 周りの課題

ペライチでは機能ごとにドメインが別れていて、リソースもそれぞれで用意されています。(ユーザーの管理画面、ページを作成するエディタ、その他機能の画面...etc)
CSS も同様で、各機能ごとに別の FW が入っていたり自前のコンポーネントが用意されていたり、それぞれ独自に運用されてしまっているのが現状です。

▼ ペライチの CSS 周りの現状
https://zenn.dev/peraichi_blog/articles/01fyt2n1nymx82jqkad2e4s1gz

独自運用されているということはルールや値もバラバラで、ユーザーに提供される UI/UX にも差が生じてしまいます。
組織のスケールに伴いスピード感を持った実装も難しくなってきていて、上記のような CSS の負債による影響がちらほら出てきました。

■ デザインシステム

そんな課題解決の第一歩として、以下のようなものが必要だと感じました。広義であいまいな単語ですが、いわゆる「デザインシステム」ぽいものですね。

  • UI コンポーネントやスタイルガイドなど、デザインに関することがまとまって定義されている場所
  • どのプロジェクトでも共通で読み込めるスタイルシートを生成できるしくみ

■ 実際にやったこと

上記のようなシステム導入を実現していく上で行ったことは主に以下の点です。

  • デザイナーとの協業
  • 専用プロジェクトの作成
  • 各環境からの参照方法の検討

デザイナーとの協業

デザインに関するルールが開発側で定められていなかったので、まずはデザイナーに協力してもらって、Figma をベースとしたデザイン(スタイル)ガイドラインを作成しました。
これによって混沌としていたカラーコードやタイポグラフィなどのトークンが整理されて、サービスを通したルールの種ができました。
併せてコンポーネントの定義や、使われ方の指定など UI 単位で参照できるようにもなりました。
こちらに関してもまだまだ育て中で、デザイナーとともによい管理方法を模索している最中です。

トークンの定義

専用プロジェクトの作成

FE 側では共通で参照できるスタイルシートを生成するために、専用のリポジトリを新たに用意しました。
UI コンポーネントを格納し、Storybook でカタログを参照できるようにするため、Nuxt.js を使用しプロジェクトを立ち上げました。(ペライチでは Nuxt を用いて作られているプロジェクトが多いのも選定の理由のひとつでした)

CSS のフレームワークはひとまず Tailwind CSS を導入し、PostCSS のエコシステムを利用して最終的なスタイルシートをビルドするような構成にしています。
また、Font Awesome などのバージョンが違っていて各ドメインで使用できるアイコンに差が生じている問題も解消すべく、アイコン類もこのプロジェクト内で管理しスタイルシートへ含めるようにしました。

前述したデザインガイドラインを元にコンポーネントを作成し、カラーパレット・タイプスケール・フォントなどをカスタマイズして独自の utility クラスとして生成。それらを元にして、最終的に使用されているクラスやアイコンが含まれたスタイルシートを生成する、といった流れです。

各環境からの参照方法の検討

開発環境では nginx を介して、各環境から決まった url でビルドされたスタイルシートへアクセスできるようにしました。
テスト環境と本番環境では GitHub Actions を利用し deploy 時に s3 へスタイルシートを保存するようにし、それを参照するようにしています。
リリース時にバージョンを指定できるようにし、リリースバージョンの管理ができるようにもなっています。

■ 現状の課題とこれからの展望

実験的な側面も多いので、実際に運用していく上でさまざまな課題が生じています。

  • 開発時に立ち上げないといけない環境が増える
  • ビルドする環境と実際に使用する場所が違う
    • マークアップの際に suggestion 等が使えない
    • Tailwind の旨味の 1 つである purge 機能が最大限活かせてない
  • 最初はデザインシステム側の assets も空だったので、開発と並行して太らしていく必要がありコストが倍増
  • コンポーネントの実装は現状各プロジェクトでやってもらう必要がある
  • 他プロジェクトでも利用されるようになった際の法整備、運用ルールの策定

などなど課題は山積みですが、まずは他プロジェクトでも安定期な使用ができるようにし、各環境のバラバラな CSS をなくしていくのが目下の目標です。
その先では、単なるスタイルシートの提供だけでなく、js や css を含めた Vue コンポーネント自体を提供するパッケージ的なものにできないかという構想もあったりします。
そのために課題を 1 つ 1 つ解決していき、試行錯誤しながら前に進めていければと思っています。

今後の進展や、今回お話しできなかった細かい構成内容なども機会があれば書いていけたらと思っています。最後までご覧いただきありがとうございました。

採用情報

現在エンジニア募集しています!

▼ 選考をご希望の方はこちら(募集職種一覧)。
https://hrmos.co/pages/peraichi/jobs?category=1629135637016141824&utm_source=techblog&utm_medium=referral&utm_campaign=article-01fyt2n1nymx82jqkad2e4s1gz

▼ まずはカジュアル面談をご希望の方はこちら
https://hrmos.co/pages/peraichi/jobs/0000029?utm_source=techblog&utm_medium=referral&utm_campaign=article-01fyt2n1nymx82jqkad2e4s1gz

募集中の職種についてご興味がある方は、お気軽にお申し込みください(CTO がお会いします)

ペライチ

Discussion