「このHEX値って本当に正しいの？」 「なんで同一のプロダクトなのにボタンコンポーネントが沢山あるの？」 「この border-radius: 3px ってなんか意味があるの？」

プロダクト開発現場では一度は経験したことがあると思います。 かくいう私も、新規機能開発時に出くわしたことがあります。端的にオブラートに包まずに言うと不毛です。我々はエンジニアとして入ってきたのにデザインの意味についてとやかく言う必要はないと思います。しかし、「意味づけされていないデザイン」はレビューの場で確実に不毛なやり取りを生みます。 レビュアーはデザイナーではなく、一エンジニアだからです。もちろん、デザイナー自身もレビューに入ることがありますが、実際のコードを読むことはなく「デザイン」に対してレビューをすることが殆どだと思います。

「このレイアウトについては何か意味がありますか？」 「このボタンの配置が3pxズレているように思いますが、問題ないですか？」

PRコメントにこれが来た瞬間に頭に思い浮かぶのは、「デザイナーに聞いてくれ」という一言です。

デザイナーの頭の中には一貫したルールに基づいた Figma デザインデータがあっても、それをベースにコードに落ちる過程で暗黙知として失われていきます。結果、エンジニアは「渡された一枚絵になんとなく近しいそれっぽいもの」を実装し、デザイナーは「なんとなく違う」ということに気づく(或いは、そもそも気づかない)。この繰り返しが、冒頭の不毛なやり取りを生んでいます。

この問題はレビューの場に留まりません。「エンジニア側の負債」として処理しきれず、「プロダクトの負債」として蔓延し、影響範囲は多岐にわたります。

レビュー・開発プロセスでの問題

• PRの手戻りが属人化する: レビュアーによって指摘の判断基準が異なるため、ある人はスルーするが、ある人はデザインのズレを指摘する
• 実装前の確認コストが高くなる: 「この場合のボタンは何色？」「このコンポーネントは自作しても良い？」という一々デザイナーに聞く無駄な工数が発生する
• 見積もりが不安定になる: 類似した機能であっても、既存コンポーネントの有無や解釈の余地によって実装工数がブレる

コード上の問題

• 似て非なるコンポーネントの乱立: Button, PrimaryButton, SubmitButtonのように、微妙に異なる実装が並存し、どれを使うべきか誰も分からなくなる
• ハードコードされた値の散在: #3B82F6 のようなHEX値やpx(em)値が各所に直書きされ、ブランドカラーを更新する際に全箇所を探して回る必要がある
• CSSの肥大化・上書き地獄: 共通ルールが全くないため、コンポーネントごとに個別スタイルの上書きが積み重なり「削除できないCSS」が増え続ける

プロダクト・ユーザ体験上の問題

• 画面ごとに微妙にUIが違う: 同一の操作なのに画面によってボタンの位置・文言・確認ダイアログの挙動が異なるため、ユーザーの混乱を招く
• ブランドの統一性・一貫性が崩れる: 新機能ほど「その時の担当者の気分・感覚」でデザインされ、プロダクト全体での統一感が薄れる

組織・スケール上の問題

• 新規メンバーのオンボーディングコストが高くなる: 「プロダクトのルール」が明文化されていないため、口伝で学ぶほかない
• デザイナー・エンジニアの人数が増えるほど破綻が加速する: 一人でやっていれば感覚で回せることが、複数人・多チームになった瞬間に崩壊する

ここまで上げた問題は、根本を辿ると一つの原因に収束します。

デザインの共通言語が存在せず、コードという形に流通していない

つまり、デザイナーとエンジニアが会話をするための共通言語が存在していないことが問題なのです。私たちエンジニアとデザイナーが解決するべき問題はまさにこれになります。しかし、端的なデザイン集やコンポーネント集を提供しただけでは根本的には解決しません。それらには意味づけが伴っておらず、実装者が「これを使う時はどのようなときか」を逐一判断する必要があるからです。

本当に必要なものは、コンポーネントやデザイン集という「モノ」自体ではなく、そのモノの背景にある「判断基準」をコードとドキュメントの両方に埋め込むことにあります。更に、そのコードや判断基準をプロセスの一環として組み込み、デザインそのものをフローに組み込む必要があります。

これらを解決する手段こそが、デザインシステムです。

---

今後はデザインシステムについて徒然なるままに書いていこうと思います。気づいたことや気が向いたことをどんどん書いていきます。

参考URL・書籍

デザインシステムの育て方 継続的な進化と改善のためのアプローチ つくって、みなおす、デザインシステム 現場での合意形成から設計、運用まで Fogma for デザインシステム デザインを中心としたプロダクト開発の仕組み作り