コンポーネントライブラリの現場運用: 逸脱を止める仕組み

ボタン、カード、モーダル、フォーム——コンポーネントを作るのは、実は難しくない。難しいのは、それが本当に使われ続けることだ。ライブラリを作った直後は使われるが、半年後、新しい人が入ったり、急ぎの案件が入ったりして、少しずつ逸脱が始まる。この逸脱を止める仕組みを持てるかどうかが、コンポーネントライブラリの成否を決める。

逸脱の検出は「見る」ではなく「仕組み」で

「レビューで見つける」は、実務では機能しない。案件が忙しくなると、レビューが甘くなる。だから逸脱の検出は、人間の集中力に頼らない仕組みに置く。

• コードのリンター: 特定のインライン色や余白の直書きを禁止する。
• Storybookの差分表示: コンポーネントの見た目が意図せず変わったら気づける。
• ビジュアル回帰テスト: 主要画面のスクリーンショットを自動比較する。

これらはすべて、レビュアーが夜中に見落としても働く。品質の関所を仕組みで持つ考え方は品質の関所を設計するで扱った。

例外は認める、ただし記録に残す

実務で「例外は絶対に許さない」を貫くと、ライブラリは陳腐化する。むしろ、例外は認める。ただし、なぜその案件で例外が必要だったかを記録する。四半期に一度この記録を見直すと、ライブラリに反映すべきパターンが浮かび上がる。逸脱は、ライブラリの成長のシグナルでもある。

「一貫性」は静的な状態ではなく、逸脱と反映の反復として維持される。

コンポーネントは増やしすぎない

「使うかもしれない」で作ったコンポーネントは、大半が使われない。使われないコンポーネントは、探す時間だけを奪う。私たちは、実案件で二回使われたパターンが、初めてコンポーネント昇格の候補になる、というルールで運用している。

ドキュメンテーションは短く

コンポーネントの使い方説明は、A4半分に収める。API仕様の一覧より、「いつこれを使い、いつ使わないか」が書かれているほうが実務では効く。この選択基準がないと、似たコンポーネントが乱立する。

デザインとコードの一致

Figma上のコンポーネントと、コード上のコンポーネントは、同期していないと二重管理になる。同期の運用は、ツールを跨いで自動化するのが現実解だ。基礎の設計はスケールするデザイントークンを参照。

反論: shadcn/uiのように「コピー&改変」でも運用できる

shadcn/uiに代表される「ライブラリではなくコピー可能なパターン集」というアプローチは、有力な選択肢だ。中央集権的なライブラリより、各プロジェクトの自由度が高い。一方で、逸脱の検出は各プロジェクト任せになる。中央集権とパターン集は、対立するのではなく、規模と成長段階で使い分ける関係にあると考えるほうが妥当だ。

参照

• Frost, Brad. “Atomic Design.” Brad Frost, 2016.
• Airbnb Design. “Building a Visual Language.” Airbnb Design blog, 2016.

コンポーネントライブラリは、部品の集合ではなく、逸脱と反映の運用そのものだ。作った瞬間ではなく、二年目に光る道具だから、そのつもりで設計しておくとよい。