アーム代表の伊藤です
デザインシステム構築が失敗するのは、作り方ではなく、作ったあと誰が維持するかが決まっていないからです。
壊れ方には順番があり、大半は作り直さずに戻せます。実際に立て直した現場では、変数を1つ直しただけで40画面が一度に切り替わった日が来ています。
自社のデザインシステムがどこまで壊れているか。4つの質問で分かる
- ファイルを開かず4つの質問で位置が分かる
- 壊れ方は6段階で上から順に連鎖する
- 最初の一手は正の宣言で作業はゼロ
Figmaを開く必要はありません。次の4つに答えてみてください。
- 色を1つ変えるとき、何画面を触る必要がありますか
- 「いま何が最新ですか」と聞いて即答できる人がいますか
- 登録済みのスタイルとコンポーネントのうち、実際に使われているのは何割ですか
- 新しい人が入った初日に、どこを見ればいいかを示せますか
1つでも詰まるなら、次の6つの壊れ方のどこかがすでに始まっています。2番に即答できなければ5番まで進んでいます。デザインデータを本番に合わせて直した経験があるなら、6番です。
段階 | 起きていること |
|---|---|
1 | 部品になっていない |
2 | スタイル名に意味がない |
3 | 画像が部品化されていない |
4 | 変数の代わりに複製している |
5 | 担当交代で正が分からない |
6 | 本番を正にして後追い |
6番に到達すると、デザインデータは資産ではなく負債に変わります。ただし、立て直しの最初の一手は正はどこかを1つ宣言すること。作業はゼロ。それだけで6番目の壊れ方は止まります
この宣言だけでは、すでに払った150万円が消えるかどうかまでは決まりません。担い手を決めなければ、1年から2年でまた6番目の状態に戻ります。
使われないデザインシステムは作り直す前に棚卸しする
- 作り直しても半年〜1年後に同じ相談が再発する
- 部品化は上位2割から始める
- 使われない部品は資産でなく在庫
壊れていると分かったとき、最初に浮かぶのは作り直しです。ただ多くの場合は最も筋の悪い選択になります。壊れたのはデータではなく運用だからです。
作り直しても半年後に同じ相談が起きる理由
新品のデザインシステムを、維持の担い手が決まっていない同じ組織に渡せば、同じ経路をたどって同じ場所に戻ります。半年から1年後に同じ相談がもう一度発生するだけです。
作り直しの見積もりが出てきたら、維持の工数が入っているかを見てください。入っていなければ同じ失敗をもう一度買う契約です
立て直しは全部やらない。宣言の次に上位2割
手順 | 作業量 |
|---|---|
1. 正を1つ宣言する | 決めるだけ、ゼロ |
2. 使う順に上位2割を部品化 | 全部やらない |
3. 命名を決める、色から | 半日〜1日 |
4. 変える予定の値だけ変数化 | 予定のないものは触らない |
1番目が最も重要で最も軽い作業です。「これからはFigmaを正とします。本番と食い違ったらFigmaを直すのではなく、実装を直します」と宣言する。手を動かす前にこの線を引いてください。
立派に作り直さない。担い手を決めてから広げる
網羅性の高いデザインシステムは、作った瞬間が最も美しく、その後ずっと維持コストを払い続けます。いま困っている範囲から作ってください。使われない部品は資産ではなく在庫です。
着手の前に、誰がどのタイミングで部品へ還元するかを決めます。決められない事情があるなら、決められる範囲までスコープを小さくするほうが安全です。進め方と対応範囲はデザインハーネス構築に整理しています。
デザインシステム構築のあと、現場で実際に起きる6つの壊れ方
- 色変更が100画面中40画面なら年8時間
- 報告書の登録数は壊れ方を隠す
- 複製は未来の自分あての請求書
複数の現場で共通して見た形にまとめています。6つは独立した問題ではなく、上から順に連鎖します。
見た目は整っているのに部品になっていない
最も多いのがこれです。色もフォントも揃っている。ただしボタンもカードもヘッダーも、ただの図形の集合として置かれています。
症状は1つで変更コストが画面数に比例します。色を1つ変えるとき、部品なら1箇所。なっていなければ、その色を使っている画面の数だけ手で直します。
色を1つ変える | 作業 |
|---|---|
部品になっている | 1箇所 |
なっていない | 40画面×3分＝2時間 |
総100画面のうち40画面で使う色を、1画面3分で直す計算です。年4回なら8時間。金額より重いのは、その8時間が「今回は直さない」という判断を生むことです。乖離はここから始まります。
色の名前が「color1」のまま止まっている
登録はされている。ただし名前が color1、color2 のまま、一度もリネームされていない。登録は5分で終わりますが命名は設計です。color1 は、その色が何のためにあるかを誰も決めなかった証拠になっています。
次に入った人はどれを使えばいいか判断できず、スタイルを使わずに直接カラーコードを打ち込みます。
報告書に書く数字 | 見えるもの |
|---|---|
登録数 | この壊れ方は見えない |
使用率 | 何割が使われているか |
見るべきは整備率ではなく使用率です。
比率を変えたいのに、画像だけ総当たり作業になる
画像は装飾だと思われがちなので、部品化が後回しにされます。ところが変更頻度でいえば、画像はテキストより高いことが多い領域です。
画像の扱い | 実際 |
|---|---|
装飾だから後回し | 変更頻度は文字より上 |
部品として持つ | 比率とサイズを一括変更 |
サムネイルを16対9から4対3に変えたい、というよくある要望が総当たりになります。そして総当たりになる作業はやはり実行されません。
バリアブルの代わりに複製で差分を持っている
厄介なのは複製した当日は誰も困らないことです。動くので困るのは3ヶ月後、ブランドカラーが変わったときです。複製は未来の自分あての請求書です。
差分の持ち方 | 3ヶ月後の色変更 |
|---|---|
バリアブル | 値を1つ直す |
複製 | 複製の数だけ作業 |
Figmaの公式ガイドでは、バリアブルは「デザインのあらゆるプロパティやプロトタイプの動作に適用できる、再利用可能な値を保存する」ものと説明されています（出典: Figma「Guide to variables in Figma」）。差分を値として持つための仕組みで、複製はその差分を実体として持つやり方です。
担当者が代わった瞬間、なぜ24pxかが消える
デザイン担当者はいつか必ず代わります。業務委託なら数ヶ月単位です。それ自体は事故ではなく前提です。問題は、代わるときに引き継がれるのがファイルだけだということ。
引き継ぎの中身 | 実際 |
|---|---|
ファイル | 手元に残る |
判断の履歴 | 誰も知らない |
なぜこの余白が24pxなのか、なぜこのボタンだけ角丸が違うのか。理由を知る人がいなくなると後任は触れなくなります。触ると何かが壊れるかもしれないからです。維持を埋めていた前任者の善意もここで途切れます。
設計図の役割が終わり本番の後追いになる
何が正しいか分からなくなった結果、いま公開されている本番環境を正とみなし、それに合わせてデザインデータを後から直す運用に変わります。
データの位置 | 役割 |
|---|---|
実装より前 | 設計図 |
実装より後ろ | 記録、しかも不正確 |
実装より後ろを歩いているものは、設計図ではなく記録です。更新が手作業なので、記録としても不正確になっていきます。維持コストだけがかかって誰の意思決定にも使われない。負債に変わったと言えるのはこの線を越えたときです。
壊れる理由は怠慢ではない。今日最も速い選択の積み重ね
6つを並べると担当者の管理が甘かったように見えます。実際は逆です。部品化しないほうが今日は速い。複製したほうが今日は速い。リリース日が決まっているなかで、どれも合理的な判断です。誰も怠けていません。むしろ締切に対しては誠実でした。
壊れるのは、その合理的な判断を打ち消す仕組みが置かれていないからです。担当者を責めても直りません。設計すべきなのは、忙しい日に部品を使うほうが速くなる状態のほうです。
払った150万円が1〜2年で消えていく瞬間
- デザインハーネスは月15万円〜で作る
- 回収の見方は維持の工数が誰の見積もりにあるか
- 投資が表れるのは売上でなく販管費
アームの料金です（2026年10月時点）。中身はデザインハーネスのページにまとめています。
範囲 | 月額（税別） |
|---|---|
デザインハーネス（トークン・ルール文書・部品10個） | 月15万円〜 |
回収の見方は作った金額ではありません。維持の工数が誰の見積もりに入っているかです。150万円をかけても担い手が決まっていなければ、1年から2年で6番目の状態に戻り、150万円は償却されずに消えます逆にトークンと部品10個だけでも、担い手と判断のルールが決まっていれば、新しい画面が増えるたびに元が取れ続けます。
投資が表れるのは売上ではなく販管費です。画面追加のたびの確認と手戻り、新しい人の立ち上がり、実装との差分を埋める時間。毎月かかっている固定費なので、1回の制作費ではなく3年分の運用工数と比べてください。
AIに渡すと粗さが出る
- MCPが読むのはバリアブル・部品・レイアウト
- AIは構造の粗さを人のように補完しない
- 整えるのは機械が読める状態にするため
デザインデータをAIに渡して実装させる流れが、ここ1年で前提を変えました。Figmaの公式ガイドでは、MCPサーバーは「バリアブル、コンポーネント、レイアウトのデータを直接IDEに取り込む」機能で、「実際のコンポーネントを再利用することで出力品質が上がる」と説明されています（出典: Figma「Guide to the Figma MCP server」）。つまり、それらが無いファイルからは取り込むものがありません。MCPは構造を読む道具であって、構造を作る道具ではないというのが、アームが実際に触った範囲での実感です。
これまで、データの粗さは実装者が「たぶんここは同じ部品だろう」と目で補完していました。AIはその補完をせず、書いてあるとおりに出します。人の善意で見えなくなっていた負債が、いま可視化されている段階です。AIを入れても現場が速くならないなら、原因は渡しているデータの構造にあることが多いです。
運用を再始動した例
- Ubieは2024年1月に運用を再始動
- 公開は放置できなくするための仕掛け
- 社外公開でなくても同じ圧力はかけられる
一度運用が停滞したところから再始動した経緯を、Ubieが自社で公開しています。テックブログには、Notionで管理していた時期に「どこに何があるか誰がメンテナンスしているかが明瞭でなく」「中途半端で形だけのドキュメントが残される結果」になったと、率直に書かれています。6つの壊れ方の5番目にあたる状態です。
再始動で置いた装置が示唆的です。ドキュメントサイトを外部に公開した理由として「公開できるものは公開していくことで運用することへの意識を高める狙いもあります」と挙げられています（出典: Ubie「Rebooting Ubie Vitals Design Systems」2024年1月）。公開は、放置できなくするための仕掛けとして使われています。
これは社外公開でなくても再現できます。社内の誰でも見られる場所に置き、更新が止まったら分かる状態にするだけで、同じ圧力がかかります。1人のチームでも置ける装置です。
よくある質問
デザインシステムとデザインガイドラインは何が違いますか？
ガイドラインは判断のルールを文書にしたもので、デザインシステムはそこに実際に使える部品と値、運用の仕組みまでを含みます。ガイドラインだけがある状態はレシピ本はあるのに食材が無い状態に近く、現場では使われません。
社内にデザイナーが1人しかいなくても、デザインシステム構築はできますか？
できます。むしろ人数が少ないほど、部品化の効果は大きくなります。ただし1人体制はその人が抜けた瞬間に5番目の壊れ方に直行するので、判断の履歴を残す仕組みだけは最初に決めてください。
デザインシステム構築にはどのくらいの期間がかかりますか？
デザインハーネスで約1ヶ月が目安です。ただし決め手は期間より、そのあとに誰が維持するかが決まっているかどうかです。
デザインシステム構築で150万円を無駄にしないコツは、正を1つ宣言する立て直しにある
- 150万円が消えるのは作り方でなく維持の担い手が決まっていないとき
- 作り直さず正を1つ宣言して使う部品の上位2割から整える
- 作り直しの見積もりは維持の工数が入っているかで見る
記事