既存プロダクトにデザインシステムを後付けする方法

「画面Aの登録ボタンは青いのに画面Bは緑」「余白の指定がpxだったりremだったり画面ごとにバラバラ」「新規メンバーが1つボタンを置くのに毎回既存画面を探して真似している」。こうした状態に心当たりがあれば、それはデザインが崩れているのではなく、デザインシステムが存在しないことの症状です。継ぎ足し開発を1〜2年続けたプロダクトでは、ほぼ必ずこの状態に行き着きます。

この記事では、ゼロから作り直さずに既存プロダクトへデザインシステムを後付けする現実的な進め方を整理します。

なぜ画面ごとにバラバラになるのか

デザインシステムが崩れる原因は「デザイナーが手を抜いた」ではなく、構造的なものです。

• 初期は「動けばいい」で個別実装：MVP段階ではボタン1つのために共通コンポーネントを作る余裕がなく、画面ごとにベタ書きされる
• 担当者交代でスタイルの解釈がずれる：最初の実装者が抜けると、次の担当者は既存コードの意図を推測しながら似せて作る。似せたつもりで微妙にズレる(padding 8px vs 10px、border-radius 4px vs 6px)
• デザインツールとコードが同期していない：Figma上ではコンポーネント化されていても、実装側は都度CSSを書いていて片方だけ更新される
• 急ぎの改修でコピペが横行：既存の似た画面をコピーして作るため、元の画面にあった微妙な非一貫性がそのまま複製・増殖する

結果として、CSSファイルには使われているのかいないのか分からないクラスが積み上がり、!important で個別に上書きした跡があちこちに残ります。この状態で新しい画面を1つ作るだけでも「どのボタンスタイルを真似ればいいか」を探すコストが発生し、改修速度そのものが落ちていきます。

崩れている度合いをまず数値で把握する

いきなり手を動かす前に、崩れの規模を可視化します。感覚ではなく数字で示すことで、後の投資判断の根拠にもなります。

• 色の種類をカウントする：CSSファイルから使われている color / background-color の値をユニーク数で数える。ボタンの背景色が5種類以上ある、微妙に違う青が3つある、といった状態はよくある
• 余白の値をカウントする：margin / padding の指定値をユニーク数で数える。8px刻みの設計思想があるはずが、13px や 17px のような半端な値が混じっていないか
• 同種コンポーネントの実装箇所を数える：「ボタン」を実装しているCSSクラス・Reactコンポーネント・Hamlパーシャルが何箇所に散らばっているか
• フォントサイズの種類：見出し・本文の指定が何段階あるか

目安として、色が10種類を超える、ボタンの実装が5箇所以上に分散している、といった状態であれば後付けの投資対効果は高いと言えます。逆に、画面数が少なく(10画面未満)崩れも軽微であれば、後述のとおり後付け自体が過剰投資になることもあります。

進め方：いきなり全画面をやらない

デザインシステムの後付けで最も多い失敗は、「全画面を一斉に新デザインへ置き換えるプロジェクト」として始めてしまうことです。これは通常のリニューアルと同じリスク(長期化・途中で優先順位が下がり凍結)を抱えます。後付けは以下の順序で進めるのが現実的です。

1. 既存UIの棚卸し

まず画面のスクリーンショットを一覧化し、ボタン・フォーム・カード・モーダルなど繰り返し登場する部品を洗い出します。この段階ではコードは触らず、「見た目として何種類のバリエーションがあるか」を可視化するだけに留めます。デザイナーがいれば、この棚卸し結果を見ながら「本来あるべき姿は何種類か」を一緒に決めます。

2. 最重要コンポーネントから共通化する

すべての部品を一度に共通化しようとせず、登場頻度が高く、かつ一貫性の欠如が最も目立つものから着手します。多くの場合、優先順位は次の通りです。

• ボタン(プライマリ・セカンダリ・危険操作)
• フォーム部品(入力欄・セレクト・エラー表示)
• カード・リスト項目
• モーダル・ダイアログ

これらは画面数に対して登場回数が多いため、共通化した際の効果(見た目の統一・実装コストの削減)が最も大きく出ます。逆に、1〜2画面にしか出てこない特殊なUI(特定の管理画面の複雑な表)は後回しにします。

3. デザイントークン化する

色・余白・フォントサイズ・角丸などの「値」を、直接指定ではなく変数(トークン)として定義し直します。SCSS変数やCSS Custom Propertiesとして $color-primary、$spacing-unit のように定義し、コンポーネント側はこのトークンだけを参照するようにします。

トークン化の効果は「後から一箇所を変えれば全体に反映される」ことです。逆にトークン化せずコンポーネントだけ共通化しても、ブランドカラーを変更するたびに全コンポーネントのCSSを個別に修正する羽目になります。順番としては、コンポーネント共通化と並行してトークンを先に(あるいは同時に)整備するのが効率的です。

4. 段階的に置き換える

新しい共通コンポーネント・トークンができたら、既存画面を一気に置き換えず、改修が発生した画面から順に置き換える方針(ストラングラーパターンに近い考え方)を取ります。新規開発・改修のたびに旧実装を見つけたら新しいコンポーネントへ差し替える、というルールをチームに徹底するだけで、半年〜1年かけて自然にプロダクト全体へ浸透していきます。

「全画面一斉置き換え」をやりたくなる気持ちは理解できますが、置き換え専業のプロジェクトは事業側の優先順位が下がった瞬間に凍結されるリスクが高く、実際に途中で止まったまま新旧2つのスタイルが混在する状態が固定化した例を複数見ています。

デザイナーとの協業のしかた

デザインシステムの後付けはエンジニア単独でも技術的には可能ですが、「本来あるべき見た目」を決める部分はデザイナーの意思決定が要ります。エンジニアだけで進めると、既存の非一貫性の中から「なんとなく多数派っぽいもの」を正解として選んでしまい、結局根拠のない統一になりがちです。

• デザイナーがいる場合：棚卸し結果を見せ、Figma上でコンポーネントライブラリを整備してもらい、それをエンジニアがコード側のトークン・コンポーネントに1:1で対応させる
• デザイナーがいない/確保できない場合：既存の中で最も評価が高い画面(社内で「ここは見やすい」と言われている画面)を基準に定め、そこに寄せる形で統一する。ゼロから新しいデザイン言語を作るより手戻りが少ない
• 外部のデザイナーに部分的に依頼する場合：トークン定義とコアコンポーネント(ボタン・フォーム・カード)の仕様策定だけを依頼し、個別画面への適用はエンジニア側で行うと費用対効果が良い

効果はどこに出るか

デザインシステムの後付けは見た目の統一だけが目的ではありません。実務上の効果は以下に現れます。

• 新規画面の実装速度が上がる：ボタンやフォームを毎回一から実装・調整する必要がなくなり、既存コンポーネントを呼び出すだけで済む
• 改修時の影響範囲が予測しやすくなる：トークンを1箇所変えれば全体に反映されるため、「この色を変えたら他に影響ないか」を画面ごとに確認する手間が減る
• QAの負荷が下がる：見た目のパターンが減ることで、デグレの検知範囲が狭まる
• 新メンバーのオンボーディングが速くなる：「この画面はどう作ればいいか」を毎回既存コードから推測する必要がなくなる

これらは定量化しづらい効果ですが、「1画面あたりの実装時間」を後付け前後で計測すると変化が見えやすくなります。

過剰投資にしない判断

デザインシステムの後付けは、やりすぎると投資対効果が悪化する典型的な領域でもあります。以下のケースでは、フルスケールのデザインシステム構築ではなく軽量な対応に留めるべきです。

• 画面数が少ない(目安10〜15画面未満)：トークン化やコンポーネントライブラリの整備コストが、統一による削減効果を上回ることがある。この規模ならボタンとフォームだけ共通化する軽量対応で十分なことが多い
• 近い将来リプレイスが決まっている：1〜2年以内に別技術スタックへの移行が確定している場合、既存側への投資は最小限にする
• プロダクトの成長が鈍化し撤退も選択肢にある：継続投資の意思決定が固まっていない段階でデザインシステムに投資するのは優先順位として低い
• Storybookやデザイントークン管理ツールの導入まで踏み込む必要は初期は無い：まずはSCSS変数と共通コンポーネントで十分効果が出る。ツール導入は運用が回り始めてから検討すれば良い

判断の目安は「画面数 × 改修頻度」です。画面数が多く、かつ今後も継続的に新規画面が追加される見込みが高いプロダクトほど、後付けの投資対効果は大きくなります。

外注する場合の進め方

デザインシステムの後付けを外部に依頼する場合、最初から「全画面のリデザイン」を発注してしまうと、スコープが膨らみやすく、かつ何をもって完了とするかが曖昧になります。発注時は次の順序を推奨します。

1. まず棚卸しと現状の非一貫性の可視化だけを小さく依頼し、規模感を把握する
2. トークン定義とコアコンポーネント(ボタン・フォーム・カード・モーダル)の設計・実装を発注する
3. 既存画面への適用は、優先度の高い画面から段階的に追加発注する

最初から全体を一括発注すると、要件が固まりきらないまま見積もりだけが大きくなりがちです。まずは既存プロダクト改善の初手チェックやレガシーCSSの整理で現状把握をしてから、段階発注に切り替える方が手戻りが少なくなります。

まとめ

• デザインシステムの崩れは属人化した継ぎ足し開発の必然的な結果であり、まず色・余白・コンポーネント実装箇所の数を可視化して規模を把握する
• 全画面一斉置き換えではなく、頻出コンポーネントから共通化・トークン化し、改修のたびに旧実装を差し替える段階移行で進める
• 画面数が少ない、近くリプレイス予定がある場合はフル投資せず軽量対応に留める判断も必要

torcheeesでは既存プロダクトの技術診断からデザインシステムの後付けを含む改善支援まで対応しています。UIの一貫性崩れや改修速度の低下にお悩みの方は、お問い合わせからご相談ください。