Figmaのコンポーネント設計で失敗しない「命名規則」の作り方｜現場で使える実践テクニック

こんにちは！

今日は「Figmaのコンポーネント設計で失敗しない『命名規則』の作り方」について解説します。

命名規則がないことで起こる現場の混乱

僕も最初は「別に適当に名前付けてもええやん」って思ってたんです。
でも、プロジェクトが大きくなってきた瞬間、めっちゃ後悔しました。
デザインファイルにButton、Button_01、Btn、button_primaryみたいに、同じボタンなのに複数の命名パターンが混在してるんですよ。

エンジニアに共有するときも困るんです。
「このボタンのコンポーネントはどれですか？」って聞かれるたびに、ファイル内を探し回る羽目になります。
現場あるあるですけど、命名がバラバラだと、デザイン→開発の引き継ぎもスムーズにいかないんですよね。

さらに問題なのが、チームで作業してるときです。
デザイナーが増えると、各自が好きに命名するから、もうカオスです。
ほんま統一された命名規則がないと、プロジェクト管理が大変になります。

実践的な階層型命名規則の考え方

現場でうまくいってる命名規則の多くが「階層型」なんです。
僕らのチームで採用してるのは、こんな感じの構造です。

基本形式：カテゴリ/コンポーネント種/バリエーション

具体例を挙げますね。

• Button/Primary/Default（プライマリボタンの標準状態）
• Button/Primary/Hover（プライマリボタンのホバー状態）
• Button/Secondary/Default（セカンダリボタンの標準状態）
• Form/Input/Text（テキスト入力フィールド）
• Form/Input/Email（メール入力フィールド）
• Card/Article/Large（大サイズの記事カード）

この命名規則のいいところは、Figmaの左パネルで自動的に階層化されることなんです。
スラッシュ/で区切ると、Figmaが勝手にフォルダみたいにグループ化してくれるので、視認性が格段に良くなります。

僕が最初に失敗したのは「どの粒度でコンポーネント化するか」を決めていなかったことです。
ボタンのホバー状態をコンポーネント化するか、それとも単なる別のレイヤーにするか、その判断基準がなかったんですよ。

今は「再利用される可能性があるか」「他のデザイナーが迷わないか」を基準に判断してます。
ホバーやアクティブ状態も、エンジニア側で参考にすることが多いから、コンポーネント化して命名しておくと、めっちゃ引き継ぎがスムーズです。

チーム全体で統一するためのポイント

命名規則を作ったあとで大事なのが「徹底」です。
でも強く言いすぎると、後輩デザイナーも困るし、ほんまは緩やかに統一していくのがコツです。

僕がやってるのは、Figmaのファイルに「命名規則ガイド」を作るんです。
実際のコンポーネント例を見せながら「こういう時はこう命名する」っていうルールをドキュメント化してます。
新しい人が入ってきたときも、これを見れば悩まずに進められます。

あと実践的なポイントとしては、以下のことを意識してるといいですよ。

• 英語で統一する：日本語だと文字数が多くなって、パネルが見づらくなります
• 小文字で統一する：Buttonとbuttonが混在すると、後々判断に迷います
• 略語は避ける：BtnとButtonが混在しないように、一つに統一します
• 状態管理は/の最後に：Button/Primary/Hoverみたいに、最後に状態を付けることで検索しやすくなります
• メインコンポーネントと子コンポーネントを区別する：Figmaではメインを作ってから、そこから子を作るのが基本ですが、名前でも「これがメインだ」と分かるようにしておくといいですよ

エンジニア側との引き継ぎを考えると、命名規則がちゃんとしてると、彼らもコンポーネント構造を一目で理解できるんです。
実装の時間も短くなりますし、修正依頼も減ります。

まとめ

Figmaのコンポーネント設計における命名規則は、単なるルールではなく、チーム全体の生産性を左右する大事な要素です。
最初は「面倒だな」って感じるかもしれませんが、プロジェクトが進むにつれて、その効果を実感できるようになります。

大事なのは「完璧を目指さない」ことです。
まずは簡単なルールから始めて、チーム内で「ここは調整しよう」って改善していく、そんな柔軟な姿勢がいいですよ。
僕のチームも、今のルールに至るまで何度も見直してきました。

命名規則がしっかりしてると、デザイナーも開発者も、そしてプロジェクト全体も、ほんまに動きやすくなります。
ぜひ試してみてください！