スマートラウンドのデザインシステムのこれまでとこれから ~第2回 基本パーツの整備によって統一されたデザインとCSSを書かなくて良い世界へ~

はじめに

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

この記事は連載シリーズ「スマートラウンドのデザインシステムのこれまでとこれから」の2回目の記事となります。

第1回はエンジニアとデザイナーでデザインルールを整備する仕組みを整え、カオス化したStorybookを整理する話でした。

https://zenn.dev/smartround_dev/articles/1dc3fef219baa3

今回の記事では、汎用的に使えるレイアウト用コンポーネントや基本パーツとなるコンポーネントを整備することで、エンジニアが実装する際に各自でCSSを意識する必要がなくなり、作業効率とメンテナンス性を向上させた話を共有したいと思います。

サーバーサイドエンジニア視点から見るフロントエンドの課題

スマートラウンドには、仕様提案・議論にも積極的に関与し、フロントエンド・バックエンド問わずフルスタックで開発・運用を行うプロダクトエンジニアが活躍しております。

（smartroundのプロダクトエンジニアについて詳しく知りたい方は下の記事をご覧ください！）

https://note.com/smartround/n/n0f338c6a3234?magazine_key=md372615ad168#4ebdfa5b-ce4a-4a4e-aa8a-0bf3cd4f3172

経歴や使用言語は様々なバックグラウンドを持ったエンジニアが集まっていますが、比較的サーバーサイドを得意としているエンジニアが多いです。

そのため、フルスタックにプロダクト開発をするにあたって、フロントエンド開発に次の問題がありました。

1. CSSに関する知識・経験が人によって異なり、様々な書き方が存在していた
   同じような見た目であっても、CSSの実装が異なることがあり、メンテナンス工数がページによって異なっていた。
2. 似たような画面がコピペで作成されていた
   似たような画面であってもコンポーネントがないため、コピペでページが作成されていた。
3. 方針が統一されておらず、使用も徹底されていなかった
   似たようなボタンでも、素の<button>にCSSを当てただけのものや、コンポーネント化されたものが使われていたりと、様々な実装が存在した。

これら開発上の問題に加えて、プロダクト的にも次の問題が発生していました。

1. ページによってはタスクにかかる作業がまちまちになっていた
   同じような見た目であっても実装が違うため、リファクタリングや機能追加が難航した。
2. 既存実装を確認しようにも、効率のいい確認方法がなかった
   実装が統一されていないため、思い当たるページを探すしかなかった。
3. デザインを統一したくても、漏れが発生してしまっていた。
   コンポーネントをデザイン反映しても、使われていない箇所には反映されなかった。

こういった問題を解消するために、デザインルールの整備と並行して汎用レイアウトコンポーネントと基本パーツのコンポーネントの整備を行いました。

CSSを書かなくて済む仕組みを目指して

CSSを基本的に書かずにページのマークアップができるように、ボタンやリンクのような基本パーツのコンポーネントとそれらのコンポーネントを配置するためのレイアウト用コンポーネントを整備しました。

• 汎用レイアウトコンポーネント
  • FlexboxやCSS gridを簡単に実現するためのコンポーネント
  • marginやpadding、borderやbackground colorを簡単に実現するためのコンポーネント
  • などなど
• 基本パーツのコンポーネント
  • Buttonを表現するコンポーネント
  • Linkを表現するコンポーネント
  • Textを表現するコンポーネント
  • Headingを表現するコンポーネント
  • Empty stateを表現するコンポーネント
  • などなど

特に汎用レイアウトコンポーネントはEvery Layoutという書籍を参考に整備を行いました。

https://www.borndigital.co.jp/book/24204/

（コンポーネントの実装については、別の記事でご紹介しようと思います！）

実際の実装例

実際にコンポーネント整備によってBefore/Afterでどのように実装が変わったか紹介してみようと思います！

よくあるようなHeadingの下にカード形式の要素を3つ並べたレイアウトを例にしてみます。

今までの例

<template>
  <div class="main">
    <h1 class="heading">
      サンプル
    </h1>
    <div class="list">
      <div class="item">
        Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
      </div>
      <div class="item">
        Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
      </div>
      <div class="item">
        Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
      </div>
    </div>
  </div>
</template>
<style scoped lang="scss">
.main {
  display: flex;
  flex-direction: column;
  gap: 24px;
}
.heading {
  font-size: 24px;
  font-weight: bold;
  line-height: 1.6;
  color: #314170;
}
.list {
  display: flex;
  flex-grow: 1; // これ実は不要
  gap: 16px;
}
.item {
  color: #50525f; // これも実は不要
  background-color: #fff;
  border: 1px solid #e0e0e0;
  padding: 16px;
}
</style>

※実際の実装では、BEM記法を使ったクラス命名や便利CSSクラス、CSS変数によって、もう少しメンテしやすい状態ではありました。

今までの開発ではエンジニア自身がHTMLとCSSを使ってマークアップしていました。
そのため、前述のマークアップ方法がブレたり、統一したデザイン改修が困難という問題がありました。
それ以外に実装観点として、不要なCSSが残ってしまったりDOM構造の修正が困難という問題がありました。
また、HTMLとCSSが離れているため認知的負荷が高いという問題もありました。

新しい実装例

<template>
  <SrYStack gap="24px">
    <SrHeading is="h1" size="xl">
      サンプル
    </SrHeading>
    <SrXStack gap="16px" no-wrap>
      <SrBox background="white" border="normal" padding="16px">
        Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
      </SrBox>
      <SrBox background="white" border="normal" padding="16px">
        Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
      </SrBox>
      <SrBox background="white" border="normal" padding="16px">
        Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
      </SrBox>
    </SrXStack>
  </SrYStack>
</template>
<style scoped lang="scss">
// CSSは不要！
</style>

それが新しい実装では、マークアップ方法が比較的統一され、統一したデザイン改修も容易になり、Storybookで見た目の確認もできるようになりました！
またレイアウトがProps指定になり、見た目の設定が確認しやすくなりました。

そして、個人的に一番重要なこととして、CSSをほとんど書かなくて済むようになりました！
Propsで取りうる値は型が効くため、コンポーネント側で隠蔽されているCSSについてもさほど意識しなくて済むようになっています。

コンポーネント整備がうまくいったポイント

1. Single Source of Truthとするべきデザインルールが整備されていた
   前回記事でも触れましたが、デザイナーが整備してくれたデザインルールをもとに協働してデザインルールを整備しました。コンポーネント実装するにあたって、このルールが真となることでブレずに実装することができました。

2. コンポーネントの実装はプロの専門家に依頼した
   UIコンポーネントの実装は、CSSやブラウザの仕様理解、デザインを正確に落とし込む実装力、それなりの規模の開発でも破綻しない設計力など、普段のプロダクト開発と異なる高度な技術力が必要です。そこでコンポーネントの実装はEvery Layoutの監訳者である@8845musignさんに行ってもらいました。

3. エンジニアの意見を取り入れつつ、整備を行った
   コンポーネントの実装は、実際の使いやすさや既存実装でよくあるケースなどエンジニアからの意見も取り入れての作業となりました。これによって、整備したけど誰も使わない・使いづらいなどの問題が生じないように配慮しました。

4. インパクトの大きいコンポーネントから整備した
   コンポーネント整備の効果をエンジニアチームにわかってもらうためにStack・Clusterといったよく使うレイアウト用の汎用コンポーネントやボタン・リンクといったよく使われるコンポーネントを優先的に整備しました。これによって整備されたコンポーネントがすぐに使われ、インパクトを出すことができ、開発生産性の向上にもつながりました。

おわりに

第2回では、サーバーサイドエンジニアが多い環境でも効率的にフロントエンド開発ができるように、汎用レイアウトコンポーネントと基本パーツコンポーネントを整備した取り組みについてお話ししました。
特に、Every Layoutを参考にしたレイアウトコンポーネントの導入により、CSSを書かずにマークアップができるようになり、開発効率とメンテナンス性が大きく向上しました。また、デザインルールの整備と並行して進めたことで、UIの一貫性も保たれるようになりました。

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

次回は、これらのコンポーネントを活用して弊社プロダクト内でよく使われるレイアウトやパーツとなるコンポーネントを整備した話をしたいと思います。引き続き、どうぞお楽しみに！
（もし弊社にご興味があれば、カジュアル面談お待ちしております！）

https://jobs.smartround.com/