The following article is offered for informational purposes only, and is not intended to provide, and should not be relied on, for legal or financial advice. Please consult your own legal or accounting advisors if you have questions on this topic.

Flexのエンジニアリングチームは小規模ながら、その規模に比して大きな成果を出すことで知られており、行動を非常に重視しています。数年間の急速な製品変更と方向転換を経て、私たちは相当量のUX負債を抱え、それがぎこちないユーザー体験として現れ始めました。 

私たちは依然として迅速なリリースが求められていましたが、品質に対する基準ははるかに高くなり、そして「品質」が実際に何を意味するのかについて共通認識を持つ必要がありました。しかし、デザインシステム構築のアイデアが私に持ちかけられたとき、私は密かにパニック状態に陥りました。

以前に2つのデザインシステムを構築した経験から、それらが伴う落とし穴を知っていました。不要なカスタム作業、無駄な議論（バイクシェディング）、古いドキュメントなどです。デザインシステムに付随しがちな「お荷物」に時間を取られたり、リソースを割いたりする余裕はありませんでした。 

依頼

そこで、すぐに疑問が浮かびました。 「どうすれば「軽量な」デザインシステムを導入できるのか — 私たちのスピードを落とすことなく価値を提供するようなシステムを？」

まず最初に行うべきことは、包括的なデザインシステムが何を伴うのかを、私たちが構築を目指す軽量なシステムと比較して評価することでした。

通常の、包括的なデザインシステム

• カスタムコンポーネント（ボタン、モーダル、テーブルなど）
• カスタムツール（Storybookのセットアップ、内部インフラなど）
• 変更に関するプロセス/ガバナンス
• 高いメンテナンスコスト

軽量なデザインシステム

• 最もよく使われるコンポーネントとパターンのみ
• 導入が容易 — ドキュメントとコードは開発者が普段作業する場所に存在する
• ゼロから構築するのではなく、既存のライブラリを活用する（可能な場合）
• 使用方法を示すための標準がある

私たちの制約：小規模なチーム、大きな目標

アトミックレベルのコンポーネント（ボタン、入力フィールドなど）から、一般的なレイアウトや複数ステップのフローまで網羅する、洗練された一連のデザインから着手しました。 

このプロセス全体を通して、私たちはあらゆる努力をしました 必要不可欠な場合を除き、新しいコンポーネントを作成しないようにしました。 選定したツールを最大限に活用することが不可欠でした。私たちは毎週大量の作業をこなす小規模な会社であり、カスタムコンポーネントに起因する固有の問題の細部に囚われることだけは避けたかったのです。

視覚的な不整合は明らかでしたが、Flexで私が気づいたより根深い問題は、フォームのような一般的なUIを構築するための統一されたアプローチが欠如していることでした。コードベースを見ると、フォームUIを実装する方法が5種類も見つかるような状況で、一連の標準が必要であることは明らかでした。

統一された一連の標準の策定

以前から、開発者向けにベストプラクティスをコピー＆ペーストできる「チートシート」セクションの作成に着手していました。これは、私たちの新しいデザインシステムを紹介するのに最適な場所となりました。この領域（後に「Playground」と改名）を利用して、開発者が最も一般的なUIの標準を確認・使用し、作業を迅速に進められるようにしました。また、デザイナーが作成したものが実際に使用されていることを確認できるようにしました。最終的に、これを（Storybookのような外部プラットフォームではなく）自社のウェブアプリに組み込むことで、その利用が確実に促進されました。

しかし、物語はまだ始まったばかりでした。まず、いくつかの大きな課題を解決する必要がありました。

1. 選定したUIライブラリの以前のバージョンに縛られていました アップグレードには途方もない努力が必要となるでしょう。この変更は、顧客向けアプリと社内ツールAlfredの両方全体に及ぶものでした。
2. 社内アプリとウェブアプリを同じ場所に配置するために、リポジトリを統合する必要がありました アプリケーション横断的なデザインシステムの利用を確実にするため。

これらのマイルストーンを達成した後、新しいデザインに合わせて両方のアプリを再テーマ化し、勢いがつき始めました。

相乗効果

社内ツールAlfredとウェブアプリの再テーマ化後、Playgroundで一連のベストプラクティスを作成し始めました。時間の経過とともに、Playgroundには私たちのユースケースの主要な部分（80/20）が集約され、コンポーネント、レイアウト、共有ユーティリティのワンストップショップとなりました。

‍

‍

Playgroundが開発者にとってコンポーネントをコピー＆ペーストして作業を迅速に進めるのに役立つことは分かっていましたが、この標準のコレクションは、LLMがUIコードをどのように生成すべきかを理解するのに最適であることが判明しました。

登場：Cursor

Playgroundの構築を開始して間もなく、私たちのフロントエンドチームは使い始めました カーソルAI. カーソルAIのルールが参照するPlaygroundを、UIベースのコードを生成する際の出発点として作成しました。

• 私たちのデザインシステムコンポーネントの使用例については、`src/areas/playground`にあるPlaygroundを確認してください。
• ドロワー、テーブル、ウィザード、レイアウトなどの新しいコンポーネントを実装する際は、Playgroundに実装されているファイルをコピーし、作業中の領域で出発点として使用してください。
• ほとんどの場合、`src/areas/playground`内のファイルを更新することはありませんが、そこにあるコンポーネントを`src/areas`内の新しいフォルダにコピーするための出発点として使用するだけです。

以前のリテーマの取り組みは、ここで非常に大きな成果を上げました。これにより、カーソルAIはスタイルガイドラインを参照することなく、私たちのデザインシステムと一貫性のあるUIを構築できるようになりました。

「Flexにおけるフロントエンドの品質とは何か」をさらに明確にするため、私たちはUIチームとして以前合意した標準を成文化しました。カーソルAIは、Playgroundのルールに加えてこれを参照することで、LLMは何を構築すべきかだけでなく、私たちの様々なツールや慣習と連携してそれをどのように構築すべきかを理解します。以下に、カーソルAIのルールファイルから、現在のUIライブラリであるMantineをどのように参照しているかの抜粋を示します。

• MantineをベースのReactコンポーネントライブラリとして使用してください。
• `@mantine/core`のコンポーネント、`@mantine/hooks`のフック、`@mantine/form`のフォームなど、Mantineライブラリを最大限に活用してください。
• コンポーネントについては、まず`components/core`または`components/composites`フォルダ内のコンポーネントを使用するようにしてください。それ以外の場合は、可能な限りMantineのコアコンポーネントを使用してください。
• インラインスタイルやクラスの使用は避けてください。まずは、色や背景色、間隔、サイズなどのスタイリングにはMantineのpropsを使用するようにしてください。
• 色については、必ずMantineのテーマカラーを使用してください (例: `theme.colors.yourColorHere[index]`)。
• 間隔とサイズについては、ピクセル値や数値ではなく、Mantineの`rem()`関数を使用してください (例: `gap={rem(12)}`)。

Flexの成果

AIをデザインシステムと併用することは、速度と品質の基準を向上させ、維持するために、全体的に状況を一変させました。最近の売掛金機能は、わずか3週間で完全に構築されました！ 

同様に、Playgroundをコンポーネントとパターンの確固たるコレクションとして活用することで、開発者とLLMの両方にとって品質の基準が強調されました。デザインシステム構築において、より軽量なアプローチを追求することで、一貫性と方向性という利点を維持しながら、デザインシステムによくある多くの落とし穴を回避することができました。

最近、私たちはPlaygroundを教育リソースとして活用し、開発者が現在廃止しようとしている状態管理ツールに代わるものをどのように使用できるかを示しました。近い将来、Playgroundの標準をCIビルドに組み込み、さらなる採用を確実にすることを目指しています。

他のチームへの教訓

初期段階にある場合は、私たちがお勧めするのは次のとおりです。

• 小さく始める: 最もよく使うUIコンポーネントに焦点を当てる
• カスタム作業は避ける: ほとんどの最新UIコンポーネントライブラリは、デザインシステムの構築を迅速に進めるために活用できます。カスタム作業は、より複雑なコンポーネントやワークフローのために温存しましょう。
• 「良いもの」とは何かを具体的に定義する: チーム内でUIツールやコーディング規約に関する合意された標準を確立し、AIツールでそれらを体系化できるようにしましょう。
• チームにとって分かりやすくする: デザインシステムを製品に組み込み、確実に利用されるようにしましょう。
• LLMがアクセスできるようにする: コード生成前に、AIツールがデザインシステムと標準を容易に参照し、整合性を確保できるようにしましょう。

最後に

カスタムの、あるいは完璧なデザインシステムは必要ないかもしれません。必要なのは「使える」デザインシステムです。

Flexでは、私たちのデザインシステムはエンジニアリング、プロダクト、デザインの各部門で相乗効果を生み出しています。これにより、品質基準をはるかに高く保ちながら、より迅速に作業を進めることができています。

スピードとAIツールに賭ける初期段階のチームにとって、これは最も賢明なインフラ投資の一つとなるでしょう。

‍