crowdworks.jp のデザインシステム構築活動を振り返る 2024 (実装編)

この記事はクラウドワークス Advent Calendar 2024 シリーズ 1 の 18日目の記事です。

こんにちは、crowdworks.jp のデザインシステム構築に携わっているエンジニアの @t0yohei です。

昨年は、crowdworks.jp のデザインシステム構築活動を振り返る 2023 (実装編)という記事で、デザインシステム実装の 0 -> 1 について書きました。

デザインシステム実装 2 年目である今年は、1 -> 10 として「やったこと」と逆に今の段階では「やらなかったこと」を書いてみたいと思います。

デザインシステムを実装中の方、これからデザインシステムを実装していこうという方の参考になれば幸いです。

状況整理
やったこと
やらなかったこと
最後に

状況整理

2024 年が始まった時は大体以下のようなことが実施済みの状況でした。

色やフォントなどの Design Token を作成
Button などの基本的な要素を Component Library として 10 個程度作成
Design Token と Component Library を Storybook 上に表示し内部向けに公開
フッターやいくつかの画面を Design Token と Component Library を用いてリプレイス

デザインシステムの立ち上げは一定上手くいってそうなものの、盤石と呼ぶにはまだまだ物足りない状況です。具体的な課題としては以下のようなものがありました。

Component Library の数がまだまだ足りない
Design Token と Component Library の適用箇所がまだまだ少ない
デザインシステム構築チーム以外での利用はまだまだ少ない

まとめると、デザインシステムのメリット(UI のクオリティアップや生産性向上など)を享受できる機会が少ない。それ故に 組織としてデザインシステムに投資していく価値を十分に示せていない状態でした。

この状態を改善すべく、最終的には 4 人に増えたエンジニアメンバーや他のチームメンバーと一緒に、この 1 年デザインシステムの開発に取り組んでいきました。

それでは、以降で具体的なやったこと・やらなかったことを話していきます。

やったこと

Design Token と Component Library を用いたヘッダーリプレイス

crowdworks.jp におけるサービスヘッダーのリプレイスを、Design Token と Component Library を用いて行いました。

昨年フッターのリプレイスを行っていたので、これにてヘッダー・フッターの Design Token と Component Library を利用したリプレイスが完了しました。

ヘッダーのリプレイスは、Design Token と Component Library の利用箇所を増やすという事以外にも、以下のような課題の解決が目的としてありました。

技術的負債が溜まっており、ヘッダーの修正コストが高い
新たにデザインシステムを適用する画面ではレスポンシブデザインを採用していたいが、ヘッダーがそれに対応していない

ヘッダーのリプレイスにより無事これらの課題が解決でき、ヘッダーの変更容易性や今後のデザインシステム適用に関する懸念が払拭できました。

リプレイスにおける困難は以下にまとまっておりますので、良かったらご覧ください。

サービスのヘッダーリプレイスがたいへんだった話 - クラウドワークスエンジニアブログ

サービスのヘッダーは、あらゆるユーザーがサービス利用中目にする UI なので、改善の効果を必ずかつ頻繁に提供することができる重要な要素になります。その反面、デザインシステムの適用はサービスによってはかなりのコストを支払う作業になるため、なかなか手が出せないこともあります。実際に我々のサービスでは 3 ヶ月以上の作業が必要でした。

デザインシステムを作りたての段階では手を付けず、一定の成果を積み上げみんなのやっていきが高まったタイミングで着手することをお勧めします。

Component Library の拡充

昨年に引き続き、今年も Component Library にコンポーネントをどんどん追加していきました。今年新たに追加しましたコンポーネントは以下になります。

Breadcrumb
ButtonCta
ButtonIcon
Dialog
Dropdown
LayoutTable
Pagination
RadioButton
Select
Spinner
TextArea

もう少しで crowdworks.jp で以前から利用していた独自 CSS Framework にあったものが一通り揃う予定で、Component Library としての一つの区切りを迎えれそうです。

Linter 整備

ESlint, Stylelint を用いて、 Design Token と Component Library が意図せず良くない使われ方がされないようにルールを整備しました。具体的には、

特定 base token の直接利用を禁止し、semantics token を介しての利用に限定する
Font Awesome の Icon は直接使わず、Component Library の Icon コンポーネント経由の利用に限定する

といったもので、アクセシビリティ観点やデザイン観点で意図せずアンチパターンを踏まないようにしています。

Linter 整備はまだまだ発展途上です。 Component Library に新規コンポーネントが追加されたり、他のエンジニアからのフィードバックを受けることでどんどんルールを更新していく予定です。

新規コンポーネントお披露目会の実施

新規で作成するコンポーネントを他のエンジニアやデザイナーなどにお披露目し、フィードバックや感想をもらう機会を設けました。

フィードバックによって新規作成するコンポーネントの品質が向上したのはもちろんのこと、デザインシステムに触れてもらう良い機会になり、 Design Token と Component Library の利用が段々と増えていきました。

余談ですが、お披露目会の実施は新規でチームに加入したメンバーの発案・主導の元行われました。自分 1 人で開発しているだけではできなかったことが、メンバーが増えたことでできるようになったと実感しすごい嬉しかったです。

やったことのまとめ

これまで述べてきた やったこと などにより、 Component Library が利用された画面が 100 画面を越え、 デザインシステムのメリットを享受できる機会が少ない という昨年時点での課題に対して一定の改善が見えて来ました。

この場を借りて、改めてこの 1 年皆様ありがとうございました。

やらなかったこと

ここからはやらなかったことです。やる必要がなくてやらなかったというよりも、優先順位付けを行った結果この 1 年ではやらなかったといったものです。

ドキュメントサイトの外部公開

SmartHR さんの SmartHR Design System や freee さんの vibesなど、デザインシステムを外部公開しているサービスは国内だけでも複数あります。

crowdworks.jp のデザインシステムを外部公開する案もあったのですが、今年のタイミングではやらないという判断になりました。

参考までに、デザインシステムの外部公開のメリット・デメリットは以下のようなものだと考えています。

メリット
- 採用活動などでアピールができる
- 外部公開することで、内部へのデザインシステム定着を図れる
デメリット
- 外部公開に向けた開発や調整にいくらかコストがかかる
- 保守のコストが継続的に発生する

今年我々のチームは、 やったこと に上げた内容に比重を置いたため、ドキュメントサイトの外部公開は行いませんでした。デメリットに関してはできない理由という感じではないため、タイミングが来たら外部公開に踏み切ると良さそうに思っています。

Component Library の npm パッケージ化

Component Library を npm パッケージとして作成し、他のリポジトリでも使用できるようにするといったことは実施しませんでした。 LP(Landing Page) 用のリポジトリで Component Library を利用したいという要望があったのですが、ひとまず実装をコピペする対応をお願いしました。

Component Library に対する破壊的変更がまだまだ発生しそうなため、npm パッケージ化した後の確認コストと Component Library を使いまわせるというメリットを天秤にかけて、今のタイミングではないなと判断した次第です。

コピペしたものに関しては定期的に差分検知のスクリプトを実行し、差分があれば再度コピーを行うことで長期間差分が出続けることを防ぐ仕組みを用意してもらいました。