スマートラウンドのデザインシステムのこれまでとこれから ~第1回 エンジニアとデザイナーの協業開始 ~

はじめに

はじめまして、株式スマートラウンドでチーフテックリードをしているtsukakei1012です。

私たちの会社では、エンジニアとデザイナーが協力してUIコンポーネントやルールを整備する「デザインシステム」を重視しています。今では、社内で誰もが当たり前に使うコンポーネントが充実し、見た目や使い勝手に大きなばらつきが出ないような仕組みができつつあります。

ただ、ここに至るまでの道のりは決して簡単ではありませんでした。特に1年ちょっと前までは、コンポーネント管理に使っているStorybookが「デザイナーの意図が正しく反映されておらず、カオス化してしまった」という課題がありました。そこで私たちエンジニアとデザイナーは、デザインルールを再度まとめ直し、Storybookの情報整理と整合性確保を最優先で進めることにしたのです。

今回の記事では、その取り組みの始まりとストーリーを共有したいと思います。

カオスに陥っていたStorybook

デザインのルールは存在しているのに…

スマートラウンドでは、デザイナー2人体制になったのをきっかけにデザインルールの整備・浸透が始まっていきました。しかし、運用の段階でいくつかの問題が浮かび上がりました。

1. デザインルールを容易に反映できるコンポーネントが存在しない
   エンジニアがデザインルールを容易に反映できるコンポーネントが存在せず、実装内容がデザイナーの想定から外れてしまった。
2. 似たようなコンポーネントの散在
   似たような機能やデザインのコンポーネントが増え、名前もバラバラで管理が難しくなってきた。
3. メンテナー不在のコンポーネントの増加
   デザイン修正やバグ修正が後手になり、ほぼ同じUI要素が違うコンポーネント名で追加されてしまう。

開発がスピードアップするに伴い、Storybook上のコンポーネント分類はよりカオスに。エンジニアとデザイナーの意図が合わず、同じようなコンポーネントが積み上がる状況が続きました。

なぜ問題に気づきにくかったのか？

• 機能開発への対応が優先になりがち
  新規機能のリリースや顧客要望による修正が次々と舞い込む中で、整理や命名規則のレビューは後回しにされていた。
• メンバー間の役割分担があいまい
  デザインルールの作成や保守をどこまでデザイナーが行い、どこからエンジニアが対応するのか、明確な線引きがなかった。
• 「不便だけど使える」状態のまま
  Storybookがカオス化していても、それぞれが「自分の欲しいコンポーネント」は把握していたため、大きな支障が表面化しにくかった。

まずはエンジニアとデザイナーが「同じものを見る」環境づくり

共通言語としてのデザインルールすり合わせ

混乱を解消するには、エンジニアとデザイナーが「同じ目的地」を認識できるようにする必要がありました。そこでまず取り組んだのが、コンポーネントごとのデザイン仕様や意図を整理することです。

• コンポーネントの役割と使いどころを明文化
• フォントやカラー、マージン・パディングの規定など、要素ごとのルールを一覧化

これには、デザイナーのSさんが整備してくれたデザインルールが非常に役立ちました。

https://note.com/smartround/n/n6e3ff6c5af95#becc75ea-3203-4e60-a68f-f796d5d8c7ee

最初はデザイナーが基本方針をまとめ、そこからエンジニアが現状の実装と照らし合わせた上で具体的な運用方法を提案する形でスタートしました。お互いの視点を交換しながら「これって想定どおり？」「こういうユースケースがあったらどうする？」というやりとりを丁寧に進めたのが、混乱を解消する大きな一歩になりました。

Storybookのリポジトリ構成を再検討

共通認識が得られたところで、Storybook内のコンポーネント階層も全面的に見直しました。

1. 階層構造を一新
   • 例：レイヤー構造と各階層ごとの命名をデザインルールに合わせるようにしました。
2. デザインルールとのコンポーネント名連動
   • Storybookの各コンポーネントとデザインルール上のコンポーネント名も合わせるようにしました。
3. 重複コンポーネントの統廃合
   • 似ているパーツを明確に比較検討し、基本コンポーネントに集約するか、バリアントとして一括管理するかを判断。
4. 利用頻度の少ないコンポーネントの廃止
   • あまり再利用されていないパーツはデザインルールからも外し、管理対象からも除外。

この際、各コンポーネントが「どのレイヤーなのか」「共通パーツを呼び出しているのか」「エンジニアが勝手に作ったものでないか」といった共通認識を揃えたことが大きなポイントでした。これにより、実装者がコンポーネントの位置づけをつかみやすくなり、メンテナンスコストが大きく下がりました。

協業を成功させるためのポイント

1. デザインシステムの重要性を理解し、トップダウンで始める
   実はこの取り組みを始めたのはCTOきっかけです。CTO自ら、デザインシステムの重要性を理解して実践（後からは支援）してくれたことで順調に協業が進みました。

2. 初期段階で「仮」でいいから運用ルールを固める
   完璧を目指して策定を先延ばしにせず、まずは仮決めで運用してみて、定期的に微修正・改善をしていくのが肝心です。

3. デザインの変更点や追加要望・実装を早めに共有する仕組み
   週次でエンジニアとデザイナーで定例MTGを行うことで、デザイナー側による仕様修正やエンジニアの実装を定期的かつ迅速に確認できる体制を整えました。

4. 実際の実装をデザイナーも頻繁に見る
   デザイナーが積極的にStorybookやプロダクトをチェックし、気になる点やデザインとの不一致をすぐにフィードバックしてくれるようになりました。結果的にUIの品質が早期に担保されやすくなっています。

これからの展望

Storybookを整理し、エンジニアとデザイナーが同じ視点でコンポーネントを扱える基盤ができたことで、今後はコンポーネント拡充や機能拡張をよりスピーディーに進められる見込みです。コンポーネントを増やすだけではなく、 「このコンポーネントの目的は何か」「どんなメリットをユーザーに提供するのか」 といった観点から議論しやすくなったのが大きな成果だと感じています。

連載の次の記事では、Storybook整理後に活躍した 汎用レイアウトコンポーネント や 基本パーツコンポーネント の話に進みます。これらの整備によって、私たちは ほとんどCSSを書かずにアプリケーションを組み上げる という世界にかなり近づきました。ぜひそちらもお楽しみに！

おわりに

第1回では、エンジニアとデザイナーの協業がどのように始まり、なぜStorybookがカオス化し、それをどのように再整理したかを中心にお話ししました。コンポーネント管理を軸にした協業体制を整えることで、UIの品質向上だけでなく、チーム内コミュニケーションの透明性も一気に高まったと感じています。

次回は「汎用レイアウトコンポーネントと基本パーツコンポーネントによるCSSを書かなくて済む世界へ」。まだまだ試行錯誤の最中ではありますが、その過程が皆さんの参考になれば幸いです。引き続き、どうぞお楽しみに！（もし弊社にご興味があれば、カジュアル面談お待ちしております！）

https://jobs.smartround.com/