こんにちは、エンジニアの egurinko です。今年も Vue Fes Japan 2024 が無事開催されました👏 その中で、弁護士ドットコム株式会社様の「Vue と Vite で作る UI コンポーネントライブラリ」の発表でデザインシステムのお話がありました。ギフティにもデザインシステムがありますので、発表内容を 1 つ 1 つ照らし合わせて比較してみたいと思います。
発表の元資料はこちらになります。
UI コンポーネントライブラリを導入した背景
弁護士ドットコム株式会社様のプロダクトでは、デザインシステムのコンポーネントとプロダクトのコンポーネントが混在している状態だったそうです。
この時に以下 4 つの課題があったそうです。
- Storybook の肥大化
- コンポーネントの重複とメンテナンスコストの増加
- 事業拡大に伴うデザインシステムの横展開
- エンジニア・デザイナーチームの規模の急拡大
そこで、プロダクトからデザインシステムを分離したとのことです。
ギフティのデザインシステムの立ち上がりの背景も似ているところがあります。ギフティでは、事業の拡大に伴いプロダクト数が増大していました。それにより、デザインの統一が難しくなったり、統一されていたとしても各プロダクトで似たコンポーネントを作成している状況でした。そこで、デザインシステムを導入しました。
また、デザインシステム周りのツールも若干違っています。弁護士ドットコム株式会社様では、Figma と zeroheight を連携してデザインを作り、実装したものは Storybook で Story 化しているそうです。そして、zeroheight と Storybook を連携しデザインと実装をチェックしているそうです。
ギフティでは Figma でデザインを管理し、Figma の API やプラグインを介してデザイントークンなどを実装側に連携しています。そして、実装したものは Storybook でドキュメント化はしていますが、デザインと実装のチェックまでは効率的に行われていません。そこに改善の余地はあると考えておりましたので、とても参考になりました。
UI コンポーネントライブラリの開発
弁護士ドットコム株式会社様のデザインシステムは、Vite と Vue を軸に作成されているそうですが、ギフティでは Vite を使いつつ React のデザインシステムを作成しています。 そのため、vite.config.js の構成は似ていて、Vue/React で若干違いがあります。
また、型定義ファイルの出力方法は違いそうです。弁護士ドットコム株式会社様では、tsc で出力していますが、ギフティでは vite-plugin-dts を利用しています。
開発導入プロセス
Focus Day 制度を使った開発
弁護士ドットコム株式会社様では、「Focus Day 制度」と呼ばれる時間を使ってデザインシステムの開発をしているそうです。これは、月 2 回内発的/主体的な開発をできる時間であり、日常業務と切り離して開発できるそうです。この場合、誰もが均等に参加可能な機会を与えられるため、デザインシステムに参加できるメンバーが増えそうでとても良いなと思いました。
一方ギフティでは、デザインシステムに興味のある有志メンバーが開発に参加しています。プロダクト開発もしているため、PdM と相談して一定時間をデザインシステムと割くことを許可していただいています。この場合、有志メンバーは非常に柔軟にデザインシステムの開発をすることが可能ですが、多くのメンバーに関わっていただくのは少し難しい状況になっています。
スモールスタートを意識した開発
弁護士ドットコム株式会社様では、npm パッケージ開発が初めてで、1 コンポーネントをプロダクトの 1 画面に導入することを目指したそうです。これはギフティでも全く同じで、とにかく小さく試して、そこから拡大するようにしています。
ディレクトリ構成の整備
弁護士ドットコム株式会社様では、src/components 配下にコンポーネントを格納しているそうです。ギフティでは、CSS ライブラリとそれを利用した React コンポーネントライブラリを開発していますが、どちらも src 配下に components ディレクトリを置いています。
- CSS: https://github.com/giftee/design-system/tree/main/packages/css/src/components
- React: https://github.com/giftee/design-system/tree/main/packages/react/src/components
なお、CSS 側は reset.css などを格納する base ディレクトリや mixin を管理するディレクトリなど、若干複雑な構成になっています。
Storybook のグルーピング
弁護士ドットコム株式会社様では、zeroheight と Storybook 上のコンポーネントは役割ごとにグルーピングされているそうです。しかしギフティでは、全てのコンポーネントを並列に管理しています。役割があった方がわかりやすいと思いつつ、役割が曖昧なものもありグルーピングはしていません。
ESLint のルール整備
弁護士ドットコム株式会社様では、クラウドサインのコーディングルールと Vue のスタイルガイド推奨内容を反映したルールを整備しているそうです。ギフティでは、まだそこまでできてない現状で、とても素晴らしいなと思いました。将来的には、アクセシビリティの観点なども含めて ESLint のルールを整備したいと考えています。
タグプッシュをトリガーにしたデプロイ自動化
弁護士ドットコム株式会社様では、tag push をトリガーにレジストリへの公開をしているそうです。ギフティでは、changesets を利用してリリースを行なっています。そのため、ある PR をマージすると、リリース PR が自動で作成され、それをマージすると自動で npm publish するようにしております。
ドキュメントの整備
弁護士ドットコム株式会社様では、以下の内容をドキュメントにしているそうです。
- UI コンポーネントライブラリの役割
- 目的、インストール手順・使い方
- 運用ルール(バージョン管理の詳細、どんなコンポーネントを管理するか)
- デプロイ手順
ギフティでは、以下のようになっています。
- デザイン原則
- デザイントークン
- コンポーネントライブラリの一覧と利用例
- 導入の仕方(インストール手順など)
- 運用ルール(機能リクエストの方法、バグ報告の仕方など)
- 開発手順
コンポーネントの役割があったり、運用ルールなどがあるのは非常に親切でとても良いなと思いました。利用者も開発者もとてもデザインシステムを利用しやすいだろうなあと思います。
まとめ
今回は、弁護士ドットコム株式会社様の「Vue と Vite で作る UI コンポーネントライブラリ」の発表内容に照らし合わせてギフティのデザインシステムと比較してみました。
ギフティではデザインシステムを一緒に考えていけるようなエンジニア/デザイナーも絶賛募集中です。気になる方は、是非一度カジュアル面談でもなんでも良いので一度お話ししましょう!