— 01 —両者の対応関係と、小さく始める導入手順
まず構成要素を並べて対応を取る。ブランドガイドラインは、ミッションや価値観、トーン、ロゴの扱い、色や書体の意味づけといった「なぜそうするか」を語る。デザインシステムは、その意味づけを実装可能な形に落としたもので、デザイントークン（色・余白・角丸などの最小単位の値）、コンポーネント、利用ルールなどで構成される。同じ「ブランドカラー」でも、ガイドラインでは意味や使いどころを語り、システムではトークンとして値と名前を持つ。抽象と具体で層が分かれている、と捉えると混乱しない。
導入は一気に完成形を目指さず、小さく始めるのが現実的だ。順番としては、まずコンポーネントの棚卸しから入る。実際のプロダクトで使われているボタンや入力欄、カードを集め、似て非なるものがいくつあるかを見える化する。多くの現場で、ボタンだけで何種類も乱立している状態が見つかる。ここが改善の出発点になる。
棚卸しで重複が見えたら、次にトークンを定義する。色や余白を個別の値ではなく名前付きの変数に置き換え、「この色はここで使う」という約束を最小単位で固める。そこまで整ってから、コンポーネントをトークンの上に組み直す。棚卸し→トークン→コンポーネントの順で進めると、最初から全部を作ろうとして頓挫する事態を避けられる。整備は一度で終わる作業ではなく、使いながら育てていく前提で始めたい。
両方まとめて任されると、つい派手なコンポーネント集めから始めたくなるんですよね。でも棚卸ししてみると、まず既存のボタンの種類の多さに驚くことのほうが多い。整えるより先に、散らかり具合を直視するのが第一歩な気がします。
— 02 —「整った無個性」と「絵に描いた餅」──二つの症状
うまくいっていない現場には、対照的な二つの症状が出る。ひとつは、システムだけ立派で世界観が無い状態。コンポーネントは整い、トークンも切られ、開発は速い。なのに出来上がった画面は、どこのサービスとも見分けがつかない。整ってはいるが、そのブランドである必然性が感じられない。これは、上流の意味づけが無いまま実装だけを最適化した結果だ。
もうひとつは逆で、ガイドラインだけあって実装が伴わない状態。理念もトーンも美しく言語化されているのに、実際のプロダクトを見ると、そこで語られた世界観がどこにも表れていない。ガイドラインは資料の中で完結し、日々の実装とつながっていない。立派な理想が、絵に描いた餅で終わっている。
この二つは、実は同じ断絶の裏表だ。片方は「なぜ」を欠き、もう片方は「どうやって」を欠いている。だから、どちらか一方だけを豪華にしても解決しない。ガイドラインが語る意味づけが、トークンとコンポーネントを通じて実装まで一本の線でつながっているか。この接続こそが、両者を整備する本当の目的になる。次の章で、その線をどの順で引くかを見る。
— 03 —順番はコア→ガイドライン→トークン→コンポーネント
接続を成立させる順番がある。コア（ブランドの核となる価値や人格）→ガイドライン（それを言葉と原則にする）→トークン（原則を値に落とす）→コンポーネント（値の上に部品を組む）。上流から下流へ、抽象から具体へ、意味が値に翻訳されていく流れだ。この向きが保たれていれば、末端のコンポーネントを見ても、なぜこの角丸なのか・なぜこの間隔なのかを、コアまで遡って説明できる。
この順番が守られないと、02で見た「整った無個性」が生まれる。コアもガイドラインも無いままシステムだけを組むと、判断の基準が「一般的にきれいかどうか」しか無くなる。結果、技術的には正しくても、どこにでもある画面に着地する。整っていることと、そのブランドらしいことは、別の話なのだ。上流が空白だと、下流をどれだけ磨いても、らしさは出てこない。
だから03は、システム整備を任された人ほど意識してほしい前提になる。手を動かしたくなるのはトークンやコンポーネントの層だが、そこに着手する前に、コアとガイドラインが言葉になっているかを確認する。もし空白なら、そこを埋めるところから始める。上流を飛ばして組んだシステムは速く動くが、速く「無個性」を量産してしまう。順番は、効率のためではなく、らしさを守るための設計だと捉えたい。
— 04 —AIで速く整える。経営には速度・一貫性・採用で語る
整備そのものは、AIの支援でかなり速くなった。既存画面からのコンポーネント抽出、命名の整理、ドキュメントのたたき台づくり、トークンの候補出し。こうした手間のかかる作業は任せられる部分が増えている。ただし、何をコアに据えるか、どの原則を優先するかという上流の判断は人が握る。速く整える道具が増えたからこそ、整える方向を決める人の役割がむしろ重くなる、という関係だ。
経営に価値を説明するときは、二つの効果を並べると伝わりやすい。ひとつは開発速度と一貫性の両立。システムがあれば作るのが速くなり、ガイドラインがあれば間違えなくなる。速さと正しさは、しばしばトレードオフに見えるが、両者がつながっていれば同時に取れる。もうひとつは、見落とされがちな採用広報への波及だ。整ったデザインシステムは、開発者にとって「働きやすそうな組織」だという合図になる。開発者向けのブランド、という視点でも効いてくる。
システムは速く作るため、ガイドラインは間違えないため。この二つを対立ではなく接続として設計できると、日々の制作からチームの採用まで一本の線でつながる。トークンの具体的な作り方や、ガイドラインの起こし方については、内部の関連記事で個別に掘り下げているので、そちらも合わせて辿ってほしい。
- ガイドラインは「なぜ」を、デザインシステムは「どうやって」を担い、抽象と具体で層が分かれる。
- システムだけ立派で無個性、ガイドラインだけあって実装が伴わない──症状は同じ断絶の裏表。
- コア→ガイドライン→トークン→コンポーネントの順を守らないと「整った無個性」が生まれる。
- 整備はAIで速く。経営には速度と一貫性の両立、そして開発者採用への効果で語る。