WIP — この記事は追記・更新される可能性があります。
なぜデザインシステムは「Figmaで作って終わり」になるのか?理想論を捨ててコード直打ちMVPから始める理由
#デザインシステム · #Design Ops · #Figma · #Next.js · #MVP · #個人開発
公開
更新
なぜデザインシステムは「Figmaで作って終わり」になるのか?理想論を捨ててコード直打ちMVPから始める理由
プロダクト開発の現場で「デザインシステムを作りましょう!」となったとき、よく起きる悲劇があります。
それは、「Figma上で美しく作られたコンポーネント集と、抽象的なポエムだけが完成して、現場の開発で使われないまま放置される」 という現象です^^;
Figmaのパーツ余白をちょっと調整したり、トークンのJSON数値を書き出したりしただけで「デザインシステム対応完了です!」と言われても、現場からすれば「……えっ、それってデザインシステムというより、ただの数値変更では……?(真顔)」と心がすーっと冷めてしまうことがあります。
UI/UXデザインとフロントエンド実装の両手を動かす立場からすると、コードに組み込まれ、現場のエンジニアやデザイナーが迷わず使える状態になって初めて「システム」と呼べるのではないか、と感じています。
今回は、なぜ世の中のデザインシステムがポエム化して破綻するのか、そしてその闇を突破するために私自身が「最小限の型(MVP)」から泥臭く作るアプローチを選んだ理由をまとめます。
1. 現場で発生する「ポエム付きStorybook」という闇
デザインシステムが形骸化する典型的なパターンは、だいたい次のような流れで発生します。
- デザイナーがFigmaでパーツを作り、エンジニアへ「ポイ投げ」する
- エンジニアが力尽くでコード化し、Storybookに並べる
- 添えられているのは「ポエム8割、ふわっとした現実2割」の使えないドキュメント
実際にそういう現場のドキュメントを見て一番最初に思ったのは、「……で?結局どう使うの??(真顔)」 でした^^;
単にFigma上でバリアント(Variant)やPropsが付いたコンポーネントを作るだけなら、「あ、便利な素材キットができたのね(^^)」で終わりです。しかし、使い方のルールが何も書かれていないものを「デザインシステム」と呼ぶのは、流石に無理があります(#^ω^)
現実的に何も使い方(ルール)が書かれていないなら、実際のプロダクトのコードや画面をじ〜っと観察して規則性を探す方が、まだよっぽどマシです。使えない「変なパーツの一覧」を作るくらいなら、最初から作らない方が現場のためになります。
2. ルールが未定義だと、画面を組む作業が「システムのバグ出し」になる
ルール(Do/Don't)がないシステムが引き起こす一番の被害は、「後からそのシステムを使って画面を設計・実装する人間(私)」にすべてのツケが回ってくることです。
いざ画面を作ろうとStorybookやガイドラインを開いても、そこに書いてあるのは抽象的なポエムだけ。
- 「あれ?この画面のPrimaryボタンは1個?2個置いてもいいの?」
- 「エラー時のトースト通知はどのトークンでどう呼び出すの?」
- 「レスポンシブ時のPaddingはどう可変するの?」
本来ならシステム側で定義されているべきルールを、私が画面を作りながら「自力で察知して、解釈して、交通整理(=未定義ルールの再定義)」するハメになるのです(#^ω^)
画面構築の作業が、そのまま「機能していないシステムのバグ出し作業」に化けてしまう。これでは開発効率を上げるためのシステムが、逆に現場の足を引っ張る最大のボトルネックになってしまいます。
曖昧なパーツギャラリーを100個並べるくらいなら、「たった1パーツでも、その時点での絶対的なルール(1画面にPrimaryは1個、エラー時は赤トークン等)」 が厳密に定義されている方が、現場の開発は100倍スマートに回ります。
3. スポット案件や個人開発で「年単位の大工事」は事故る
クライアントから「デザインシステムを導入したい」と相談された際、大手テック企業のような完璧で巨大なシステムを一から作ろうとすると、ほぼ100%挫折するか予算オーバーで事故ります。
特にスポット案件やリソースの限られた現場で求められているのは、「1か月で現場が回り出す最小限の型(MVP)」 です。
一発完成の理想論を追い求めるのではなく、
- 画面の8割をカバーする超基本のToken(カラー・タイポグラフィ・余白)
- 最頻出のパーツ2〜3個(Button / Card / Input など)
だけを厳選し、Figmaとコード(Next.js / Tailwind)で1対1で接続して即座に運用に乗せる。
足りないコンポーネントやルールは、実際の画面開発(ドッグフーディング)を進めながら後から追記して育てていく。この 「未完成を前提にしたアジャイルな構築OS」 こそが、現実的で泥臭い解決策だと考えています。
4. だから私は、自分の城(star-moti.com)で『動く型』の実証実験を始める
「口で言うだけなら誰でもできる」ということで、私はこの自分のサイト(star-moti.com)を泥臭い実験台(サンドボックス)にして、最小限のデザインシステム爆速構築ロードマップ を実践・公開していくことにしました!
自分自身で実際に組んで運用し、途中で直した理由(Why)まで含めて泥臭く公開していくことで、
- スポット案件でそのまま提示できる「デザインシステム構築の標準パッケージ(型)」
- 自城そのものが説得力のあるポートフォリオ(生きた実績カタログ)
として機能させます(^^)
全体のロードマップと試行錯誤の改修ログは、こちらのハブページに順次集約していきます。
👉 【ハブ】個人開発・ブログのためのデザインシステム爆速構築ロードマップ|MVPで始める型化とスポット導入ガイド
まとめ:ポエムを書いて時間を溶かす前に、小さな仕組みを動かそう
デザインシステムの目的は、Figma上で綺麗なお絵描きをすることでも、豪華なガイドラインを作ることでもありません。「開発スピードを上げ、品質を平準化すること」 です。
そのためには、思想(ポエム)に逃げず、現場のデザイナーとエンジニアが「ルールを感じ取れる状態」を最小単位で作るしかありません。
これからも、この泥臭いアプローチで自城のシステムを育てつつ、現場で本当に使えるデザインOpsの実験を続けていきます!(#^ω^)
(本文 随時追記予定)