← 一覧へ戻る

NN/g が『小規模デザインシステムは戦略』と言った朝に、micro SaaS を 3 つ持つ自分が考えたこと

『2〜5人デザインシステムは制約ではなく戦略』と NN/g が論じた論考を、複数 micro SaaS を並走する作者として読み直す。

「小規模デザインシステムは制約ではなく戦略」というフレーズ

Nielsen Norman Group が今朝公開した論考が、2〜5 人のデザインシステムチームを「制約ではなく戦略として運用する」視点で論じている。社内に巨大なデザインシステム部門を抱えず、少人数のまま速く動くアプローチ。論考の主張の核は「小規模は許容できる選択肢ではなく、特定の条件下では勝つ運用モードだ」というものに見えた。NN/g は組織論として書いているが、自分は別の角度で読んでしまった。

自分は gpdf、gsql、renma の 3 つのプロダクトと、それらを束ねる nadai.dev を兼業で並走している (複数 SaaS 並走の現実 は別の記事で書いた)。デザインシステムどころか「デザインシステムと呼べる何か」を持っていないと長らく思っていた。NN/g の論考はそれを「2〜5 人」ではなく「1 人未満の専従工数」に拡張すると、自分の状況が見えてくる。

自分のデザインシステムは、最小共通項として後から見つかった

実態を正直に書くと、自分が運用しているのは「最小共通項のトークンだけ」だ。Tailwind の preset でカラー 6 色、フォントスタック、余白の刻み 4 段階。Button と Card と Container のクラス組み合わせを各プロダクトで使い回している。それだけ。Storybook も Figma library もない。

これは戦略として始めたものではなかった。nadai.dev を作者ハブとして作る過程で、gpdf の LP や renma の web と視覚的に揃えないと不自然になることに気付いた。一貫性を保つ最小コストが「トークンを揃える」だったので、後から共通化した、というのが時系列上の事実だ。NN/g の論考は「制約ではなく戦略」と言っているが、自分の場合は「妥協から始まって、振り返ったら戦略っぽく見えた」が正しい順序だったと感じている。

ここで NN/g に学べるのは、その状態を恥じる必要がないという点である。「足りない」と思って Storybook や Figma library を本格導入する方向に投資すると、兼業の時間配分が破綻する。小さいまま、明示的に小さく保つ判断ができるかどうかが分かれ目だ。

NN/g が触れていない「兼業作者」という変種

NN/g の論考は社内デザインシステムチームを前提に書かれている。2〜5 人で動くチームは小さいが、それでも「専従の業務時間」がある。自分のような業務外で複数プロダクトを並走させる作者には、その前提が成立しない。

具体的には、業務外の可処分時間が週 15〜20 時間、その大半は機能実装・OSS のレビュー・記事執筆に流れる (兼業作者の 1 日の時間設計 で詳しく書いた)。デザインシステム単独の作業時間は週 1 時間未満になる。NN/g が言う「2〜5 人を戦略として運用する」を 1 人未満に圧縮すると、原理が成立する境界が変わる。具体的には、デザインを「資産として育てる」ではなく「使い捨て可能な決定の連鎖」として扱う必要が出てくると感じている。

これは制約だ。NN/g の枠組みでそのまま「戦略」と呼べるかは、自分にはまだ自信がない。ただ、共通項を最小限だけ意識的に維持するだけで、4 つのプロダクトが視覚的に同じ作者から出ていることが伝わる効果はあった。これは導入当時には想定していなかった副次効果だった。NN/g の枠組みは社内チーム向けだが、その本質「小さく保つ判断を意図的に下す」だけ抜き出せば、兼業作者にも輸入できるかもしれない。

具体的な失敗を 1 つ書いておくと、半年ほど前に gpdf 周辺の Web UI 用に Storybook を入れようとした時期があった。3 週間で挫折した。コンポーネントの stories を書く時間と、実プロダクトの機能実装の時間が同じ可処分時間プールから取り合いになり、Storybook 側が常に負けた。それ以来、デザインに割ける専従の手がないという前提を、自分のデザインシステム設計に組み込むようになった。NN/g の言う「small by design」は、自分にとっては「大きいものを諦める」設計判断の言い換えだった気がしている。

次に動かすつもりのこと

NN/g の論考を読んだ翌日に何かを変えるとしたら、まず gpdf.dev と nadai.dev のボタンのスタイルが微妙にずれているのを直す。トークン化しているはずなのに、半年前に CSS を直接書いた箇所が残っているのに気付いている。次に、renma の web と gsql の README ページの見出しの行間とカラーをまとめて nadai.dev 側のプリセットに寄せる。

「small by design」を 1 人で実行する場合、定期的にこういう微小な揺らぎを潰す時間を取らないとデザインシステムは崩壊する。NN/g の論考が暗黙的に前提にしていた「専従の手」がない以上、月 1 回くらいのスパンで自分の中に「揺らぎ掃除日」を設定するのが現実的かもしれない。次回 nadai.dev の docs を触るときに、このルールが続くかどうか答えが出る。半年後に同じテーマでもう一度書くとしたら、たぶんその記事は「揺らぎ掃除日が定着しなかった理由」についてのものになるかもしれない。それが正直な予想だ。

今朝の他に読むべき記事

© 2026 nadai · 日本Set in Instrument Serif · Inter