こちらは<a href="https://qiita.com/advent-calendar/2021/design-code" target="_blank" rel="nofollow noopener noreferrer">「エンジニアリングに興味があるデザイナー、デザインに興味があるエンジニア Advent Calendar」</a>５日目の記事です。
業務ではサービスの仕様検討からデザイン作成、フロントエンド実装まで器用貧乏にやっています。
前職も現職もデザイナー不在の組織で働いており、デザインまわりで苦い思いをすることが多々あるのですが、最近特に思うのは「デザインの一貫性を保つのは難しい」ということ。ここでは、そんな悩みの原因、そして現職での対応策を書き連ねます。
<h2 id="%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%A0%E3%81%91%E3%81%A7%E9%96%8B%E7%99%BA%E3%81%97%E3%81%A6%E3%82%8B%E3%81%A8%E3%80%81%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%81%AF%E7%A0%B4%E7%B6%BB%E3%81%99%E3%82%8B">
<a class="header-anchor-link" href="#%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%A0%E3%81%91%E3%81%A7%E9%96%8B%E7%99%BA%E3%81%97%E3%81%A6%E3%82%8B%E3%81%A8%E3%80%81%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%81%AF%E7%A0%B4%E7%B6%BB%E3%81%99%E3%82%8B" aria-hidden="true"></a> エンジニアだけで開発してると、デザインは破綻する</h2>
初期はデザイナーさんにデザインを作ってもらっていたが、保守・運用フェーズに入ったらエンジニアのみでデザインも実装も進める、みたいな現場をちょくちょく見かけます。
そんな現場で目にするのは、初期デザインにはなかった色やマージン、レイアウトのパターン。時間が経つにつれて初期デザインは崩れ、統一感のないデザインになっていきます。
デザイナーさんが「こういうデザインを作ってね！」と丁寧にドキュメントやコンポーネント集を作ったとしても、時が経つと作った人はいなくなり、ドキュメントはメンテナンスされなくなり、誰も詳細が分からず、じゃあ見なくていいや、という負のループに突入します。
自分のいた組織も例外ではなく、こんな流れの末に「デザインの一貫性を維持するのは無理」という悩みが生まれました。
<h2 id="%E3%83%87%E3%82%B6%E3%82%A4%E3%83%8A%E3%83%BC%E3%82%92%E9%9B%87%E3%81%86%E3%80%81css%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%AB%E9%A0%BC%E3%82%8B">
<a class="header-anchor-link" href="#%E3%83%87%E3%82%B6%E3%82%A4%E3%83%8A%E3%83%BC%E3%82%92%E9%9B%87%E3%81%86%E3%80%81css%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%AB%E9%A0%BC%E3%82%8B" aria-hidden="true"></a> デザイナーを雇う、CSSフレームワークに頼る</h2>
ここで問題となるのは、
<ol>
<li>
デザインの面倒を見る人が会社にいない
</li>
<li>
デザイナー以外じゃメンテナンスできない
</li>
<li>
エンジニアのデザイン知識の不足
</li>
</ol>
それぞれ解決するには
デザインの面倒を見る人が会社にいない 
→　デザイナーを雇う
デザイナー以外じゃメンテナンスできない 
→　デザイナーを雇う
エンジニアのデザイン知識の不足 
→　CSSフレームワークを使う
3つの問題点と対応策を考えましたが、1と2の対応策の「デザイナーを雇う」はまあそうですね、という話なので、今回は３つ目の「CSSフレームワークを使う」について。
ちなみに、デザインの勉強をするという手もありますが、時間がかかる上に習熟度の統一が難しく、とても見通しの悪い方法です。あまり考えずとも一定のデザインルールに則っているCSSフレームワークを採用するほうが効果が見込めます。その上で、デザインの勉強を並行して実施すると良さそうです。
<h2 id="css%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%AE%E9%81%B8%E5%AE%9A">
<a class="header-anchor-link" href="#css%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%AE%E9%81%B8%E5%AE%9A" aria-hidden="true"></a> CSSフレームワークの選定</h2>
現職でCSSフレームワークを選ぶ機会があり、候補にはMaterial UIとTailwind css、Chakra UIが上がりました。
<ul>
<li>Material UI
<ul>
<li><a href="https://mui.com/" target="_blank" rel="nofollow noopener noreferrer">https://mui.com/</a></li>
<li>マテリアルデザインに準拠したCSSフレームワーク</li>
<li>多彩なコンポーネントが用意されている</li>
</ul>
</li>
<li>Tailwind CSS
<ul>
<li><a href="https://tailwindcss.com/" target="_blank" rel="nofollow noopener noreferrer">https://tailwindcss.com/</a></li>
<li>ユーティリティファーストCSSフレームワーク</li>
<li>コンポーネントはなく、スタイルを効率的に作るためのクラスが提供されている</li>
</ul>
</li>
<li>Chakra UI
<ul>
<li><a href="https://chakra-ui.com/" target="_blank" rel="nofollow noopener noreferrer">https://chakra-ui.com/</a></li>
<li>一般的に使用されるコンポーネントが用意されている</li>
<li>
<a href="https://emotion.sh/docs/introduction" target="_blank" rel="nofollow noopener noreferrer">emotion</a>でのスタイリングができる</li>
<li>「NARUTO」が命名の元ネタ</li>
</ul>
</li>
</ul>
現職の前提として、デザイナーを雇うかもしれないこと、エンジニアのデザイン知識にばらつきがあること、の２点が挙がったので必要な要件を以下に２つに定めました。
<ol>
<li>
デザイナーさんの作ったデザインも実装できること
</li>
<li>
デザイナーさんがいなくても、最低限の一貫性を保てること
</li>
</ol>
これらの要件をもとに、Chakra UIを選びました。
Material UIは一貫性という点ではアリですが、独自デザインの実装となるとスタイリングしづらいところがあり断念しました。
Tailwind CSSは独自デザインの実装は問題なくできますが、用意されたコンポーネントがあるわけではないので、エンジニアだけで一貫性を保つという点で断念しました。
採用したのはChakra UI。 
必要最低限のコンポーネント、emotionでの柔軟なスタイリングができるという点で選びました
<h2 id="%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%88%E3%83%BC%E3%82%AF%E3%83%B3%E3%81%AE%E3%81%BF%E6%AD%BB%E5%AE%88%E3%80%82%E4%B8%80%E8%B2%AB%E6%80%A7%E3%81%AF%E6%9C%80%E4%BD%8E%E9%99%90">
<a class="header-anchor-link" href="#%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%88%E3%83%BC%E3%82%AF%E3%83%B3%E3%81%AE%E3%81%BF%E6%AD%BB%E5%AE%88%E3%80%82%E4%B8%80%E8%B2%AB%E6%80%A7%E3%81%AF%E6%9C%80%E4%BD%8E%E9%99%90" aria-hidden="true"></a> デザイントークンのみ死守。一貫性は最低限</h2>
実際にChakra UIを採用し、半年ほどが経ちました。
初期のプロトタイプ実装はChakra UI標準のコンポーネントで実装し、現在はデザイナーさんが業務委託で入ったので標準コンポーネントは使わずスタイリングをおこなっています。
ただ完全に独自デザインというわけでもなく、デザイナーさんにはChakra UIのデザイントークンをもとにデザインを作ってもらってます。 
もしデザイナー不在になっても、Chakra UIに沿って実装すればデザイントークンに差異は生まれず、よっぽどひどいデザインにはならないだろう、と希望的観測もまじりながら考えた結果です。
もちろんデザイントークンだけ統一されても、デザインの質が保たれるわけではないので本当に最低限の保証です。
どこまで一貫性・質を担保するか、という基準は色々あると思いますが、今回はデザイントークンレベルでは一貫させる、という試みです。
デザイナーが本採用されればまた違った取り組みになると思いますが、まずは小さいことをうまくやり、クリアできたら次の基準を設けたいと思います。

デザインの一貫性を保つのは難しい

エンジニアだけで開発してると、デザインは破綻する

デザイナーを雇う、CSSフレームワークに頼る

デザイントークンのみ死守。一貫性は最低限

Discussion