なぜ命名はいつも難しいのか
私たちが使う言葉は、物事の捉え方だけでなく、その物事に関する会話の方向性まで決定づけます。だからこそ、色・アイコン・UIコンポーネント・機能について話すたびに混乱が生じ、デザイントークンやHTMLクラス、変数の命名に苦労するのです。
問題は2つに集約されます。名前が一般的すぎると何を指すのか正確に伝わらず、具体的すぎると柔軟性や再利用性が損なわれます。では、適切な名前はどう選べばよいのでしょうか。本記事では、実務で即活用できる命名戦略と検証済みのリファレンスを整理して共有します。
根拠資料: Smashing Magazine - A Practical Guide To Naming Things
実践的な命名戦略：領域別アプローチ
1. HTMLクラスと関数名
命名で行き詰まったとき役立つリソースがあります。Classnamesは、振る舞い・類似性・順序・グループ化・関連性といったテーマ別に分類された単語リストを提供しています。自然・芸術・建築・ファッションなど、コードとは一見無関係に見える分野の語彙も含まれており、発想の転換を促します。
2. 色の名前
#FF5733 のようなコードではなく意味のある名前が必要な場合、David Aerne氏が管理するリポジトリには30,355個の固有の色名が収録されています。カラーピッカーと名前検索機能も提供されており、実務で即参照できます。
3. レイヤーとグループ
良い名前の条件は明確です：論理的な構造、短さ、意味のあること、チーム全員が知っている言葉、視覚的プロパティと無関係であること。Javier Cuello氏がまとめたベストプラクティスは、サイズ・色・グループ・レイヤー・コンポーネントの命名時に考慮すべき細部にまで踏み込んでいます。
4. デザイントークン
Intuit（Mailchimp、QuickBooks、TurboTaxを運営）は、複数製品にまたがって機能する柔軟なトークン分類体系を構築しました。Nate Baldwin氏のケーススタディは、旧システムの課題、新システムの基準、構築プロセスを詳細に共有しています。マルチブランド・マルチテーマ環境において、トークン名だけで用途を把握できるようにすることが核心です。
// デザイントークンの命名例（階層構造）
const tokens = {
// プリミティブ値
colorBlue500: '#3B82F6',
// セマンティックトークン
colorActionPrimary: '{colorBlue500}',
colorTextOnAction: '#FFFFFF',
// コンポーネントトークン
buttonBackgroundDefault: '{colorActionPrimary}',
buttonLabelDefault: '{colorTextOnAction}'
};
// 名前だけで「ボタンのデフォルト背景色」であることが即座に把握可能
5. UIコンポーネント名
類似のものを別名で呼ぶ慣行を整理したComponent Galleryは、50以上のUIコンポーネント（アコーディオンからvisually hiddenまで）について、各システムが使用する代替名称を併記しています。チーム内の用語統一に非常に有用です。
6. 機能（Feature）名
機能の導入率が低い原因は、ほとんどが発見可能性（discoverability）の不足です。良い機能名はユーザーのニーズと課題から出発し、機能の価値や成果（job-to-be-done）を示唆する必要があります。最も重要なのはユーザーが実際に使う言葉を反映することです。ユーザーに機能を自分の言葉で説明してもらい、その単語をそのまま使いましょう。
注意点と実務のヒント
よくある落とし穴
- 視覚的プロパティに依存した名前:
red-buttonはテーマ変更時に嘘になります。primary-actionのように役割ベースで命名してください。 - チームごとの方言（dialect）: デザイナーは「コンポーネント」、開発者は「ウィジェット」、PMは「モジュール」と呼ぶと、同じものを指して会話が噛み合いません。命名規約ドキュメントを作成し、単一の用語集を維持しましょう。
- 命名衝突の放置: 衝突を発見したらバックログに登録し、必ず解消してください。小さなディテールがチーム協業の摩擦を大きく減らします。
日本の開発エコシステムにおける適用文脈
日本の受託開発・SIer環境では、プロジェクトごとにクライアントが変わるため命名規約が毎回リセットされるケースが多々あります。そのような場面では、**デザイントークンの階層構造（プリミティブ → セマンティック → コンポーネント）**をテンプレート化しておくと、新規プロジェクトのオンボーディング速度が目に見えて向上します。特にダークモードやマルチブランドの要件が増えた昨今、セマンティックトークン階層なしに色を直接参照するコードは、保守地獄への近道です。
このアプローチの限界
完璧な命名体系は存在しません。チーム規模が大きくなり製品が成熟するほど、既存の名前が陳腐化する技術的負債となります。したがって命名規約は「一度決めて終わり」ではなく、四半期ごとにレビューし、マイグレーション計画を立てる生きたドキュメントとして管理すべきです。
結論：良い名前はチームとユーザーが共に使う名前
答えは1つです。チームとユーザーがよく理解し、実際に使っている名前が良い名前です。同じものを指してデザイナーの方言、開発者の方言、PMの方言、ユーザーの方言で語る瞬間、時間と感情が浪費されます。
導入率が低いなら、原因は名前かもしれません。命名衝突はバックログに積み、1つずつ解消してください。些細に見えるこのディテールが、チーム協業の質を変えます。
次のステップ学習方向
- デザイントークンの実習: FigmaのVariables機能でセマンティックトークン階層を実際に構築してみてください。
- 用語集の運用: チームWikiにUI用語辞典を作成し、PRレビュー時に参照するプロセスを整備しましょう。
- 自動化: StylelintやESLintのカスタムルールで命名規約違反をCIで検出しましょう。