【実務・中級編】Figmaの「Library Analytics」を徹底活用！デザインシステムの利用率とコンポーネントのデッドコードを可視化する方法 – UI/UX・デザインツール活用バイブル

Figma Library Analytics 最強攻略！デザインシステムを血肉化し、ゾンビコンポーネントを駆逐する「現場で震える」実践ガイド

現代のプロダクト開発において、デザインシステムはもはや「あれば良いもの」ではなく、「なくてはならないもの」へと進化しました。しかし、ただデザインシステムを構築しただけでは、その真価は発揮されません。それは「生きた資産」として、常にメンテナンスされ、利用され、そして進化し続ける必要があります。

テックリードとして、私は常にチーム全体の生産性と品質の最大化を追求しています。デザインと開発のシシームレスな連携は、その最前線です。Figmaが提供する「Library Analytics」は、この「生きたデザインシステム」の健康状態を可視化し、改善サイクルを加速させるための、まさに隠された宝物と言えるでしょう。

この記事では、Figma Library Analyticsの基本から、使われなくなった「ゾンビコンポーネント」の特定と駆逐、そしてデザインシステムのROI（投資対効果）を数値で証明するレポーティング手法まで、あなたの開発チームの生産性を劇的に高める「現場で震える極限の知見」を、魂を込めて伝授します。

1. Library Analyticsの真髄：デザインシステム浸透度を測る

デザインシステムは、それを使うメンバーによって初めて価値が生まれます。FigmaのLibrary Analyticsは、その「利用状況」という最も重要な指標を数値で提示してくれる強力なツールです。

1.1. Library Analyticsへのアクセスと基本機能

Library Analyticsは、Figma OrganizationまたはEnterpriseプランで利用可能です。チームの管理者またはエディター権限を持つユーザーは、Figmaの左サイドバーにある「Analytics」セクションからアクセスできます。

主要なメトリクスが語るもの:

  • Usage Rate (利用率): 指定期間中にライブラリ内のコンポーネントがインスタンス化された回数や、どれだけのファイルで利用されたかを示します。これはデザインシステムの「浸透度」を測る最も直接的な指標です。
  • Top Users: 最も多くコンポーネントを利用しているユーザーを特定できます。ヘビーユーザーからベストプラクティスを抽出し、他のメンバーへの展開に役立てましょう。
  • Components Used: 各コンポーネントがどれだけ利用されているかを一覧できます。ここが「ゾンビコンポーネント」特定のための最重要ポイントです。
  • Published Libraries: 公開されている全てのデザインシステムライブラリの概要が表示されます。
  • Used Libraries: 実際に各ファイルで利用されているライブラリの状況を確認できます。

これらのデータは、単なる数値の羅列ではありません。「誰が、何を、どれくらい使っているか」というリアルな利用実態を映し出す鏡です。

1.2. 活用例：デザインシステムを血肉化する

1. 新規コンポーネントの採用率追跡: 新しくリリースしたコンポーネントが、どれくらいの期間でどれだけ使われているかを監視します。利用率が低い場合は、ドキュメントが不足している、使い方がわかりにくい、そもそもニーズがない、といった課題を特定し、迅速な改善アクションにつなげられます。
2. 使われていないライブラリの特定と改善: あるライブラリの全体的な利用率が低い場合、そのライブラリが本当に必要とされているか、あるいは内容が古くなっていないかを議論するきっかけになります。必要であれば、ワークショップの開催やドキュメントの更新で利用を促す、あるいはアーカイブを検討します。
3. デザイナーと開発者の連携度合いの数値化: 開発チームがFigmaを「コード生成の設計図」として活用している場合、Library Analyticsで特定のコンポーネントの利用率が高いことは、デザインシステムと実装が密接に連携している証拠です。逆に乖離が見られる場合は、連携プロセスの見直しを検討します。

2. ゾンビコンポーネントを駆逐せよ！デッドコードの特定と削除戦略

デザインシステムが肥大化し、使われなくなったコンポーネント（通称「ゾンビコンポーネント」「デッドコンポーネント」）が残存することは、パフォーマンスの低下、メンテナンスコストの増加、そして何よりもチーム内の混乱を招きます。

2.1. デッドコンポーネントの定義と問題点

デッドコンポーネントとは、デザインシステムに「存在する」ものの、どのFigmaファイル内でもインスタンスとして「利用されていない」コンポーネントを指します。

なぜゾンビコンポーネントは問題なのか？

  • メンテナンスコスト: 誰も使っていないのに、デザインシステム側のアップデート時に検証・修正の手間が発生します。
  • 混乱の元凶: デザイナーや開発者がコンポーネントを探す際、似たような古いコンポーネントが残っていると、どれを使うべきか迷い、誤った選択をしてしまうリスクがあります。
  • デザインシステムの信用低下: 古いコンポーネントが残っていると、デザインシステム自体の品質や最新性が疑われ、利用をためらわれるようになります。

2.2. 特定手法：Library AnalyticsとFigma API

Library Analyticsの「Components Used」ビューは、ゾンビコンポーネント特定のための主要なインターフェースです。

1. 「Components Used」ビューで絞り込み:

  • Figma Analyticsを開き、対象のライブラリを選択します。
  • 「Components Used」タブに移動し、「Usage」列でソートします。
  • 利用回数が「0」または極めて低いコンポーネントに注目します。これらがゾンビコンポーネントの候補です。

2. Figma APIを活用した自動化（上級編）：
Figma APIを利用することで、より詳細な分析や自動化されたレポートが可能です。例えば、特定のデザインファイル全体を走査し、どのコンポーネントがどこで使われているかをプログラムで把握できます。

// scripts/findDeadComponents.ts (Node.jsの例)
import { FigmaClient } from ‘figma-api-client’; // figma-api-client は例として。実際はaxiosなどでFigma APIを叩く
import as fs from ‘fs’;

const FIGMA_FILE_ID = process.env.FIGMA_FILE_ID || ‘YOUR_FILE_ID’;
const FIGMA_TOKEN = process.env.FIGMA_PERSONAL_ACCESS_TOKEN || ‘YOUR_TOKEN’;

const client = new FigmaClient({ personalAccessToken: FIGMA_TOKEN });

async function getFigmaFile(fileId: string) {
try {
const response = await client.file(fileId);
return response.data;
} catch (error) {
console.error(`Error fetching Figma file ${fileId}:`, error);
throw error;
}
}

async function analyzeLibraryUsage(libraryFileId: string, consumerFileIds: string[]) {
console.log(`Analyzing library: ${libraryFileId}`);

const libraryFile = await getFigmaFile(libraryFileId);
const libraryComponents = Object.values(libraryFile.components || {}); // ライブラリ内の全コンポーネント

const usedComponentKeys = new Set();

for (const consumerFileId of consumerFileIds) {
console.log(` Checking consumer file: ${consumerFileId}`);
const consumerFile = await getFigmaFile(consumerFileId);

function traverse(node: any) {
if (node.type === ‘INSTANCE’ && node.componentId) {
// インスタンスのcomponentIdがライブラリのcomponentIdと一致するか確認
// Figma APIは`componentId`にファイルのIDを含めるので、正確なマッチングには追加のロジックが必要
// ここでは簡易的に、componentIdが参照するマスターコンポーネントのキーを記録
const masterComponent = libraryFile.components?.[node.componentId];
if (masterComponent) {
usedComponentKeys.add(node.componentId);
}
}
if (node.children) {
for (const child of node.children) {
traverse(child);
}
}
}
traverse(consumerFile.document);
}

const deadComponents = libraryComponents.filter(comp => !usedComponentKeys.has(comp.id));

console.log(‘\n— Dead Components Found —‘);
if (deadComponents.length === 0) {
console.log(‘No dead components found. Great job!’);
} else {
deadComponents.forEach(comp => {
console.log(`- ${comp.name} (ID: ${comp.id})`);
});
}

fs.writeFileSync(‘dead_components_report.json’, JSON.stringify(deadComponents.map(c => c.name), null, 2));
console.log(‘Report saved to dead_components_report.json’);
}

// 例: デザインシステムライブラリのIDと、それを利用しているデザインファイルのIDリスト
const designSystemLibraryId = ‘YOUR_DESIGN_SYSTEM_FILE_ID’;
const projectFileIds = [‘PROJECT_FILE_ID_1’, ‘PROJECT_FILE_ID_2’]; // 実際のプロジェクトファイルID

analyzeLibraryUsage(designSystemLibraryId, projectFileIds)
.catch(console.error);

コメント: このスクリプトは、Figma APIを使ってデザインシステムライブラリ内のコンポーネントが、特定のプロジェクトファイル内でインスタンスとして使われているかをチェックする簡易的な例です。`FigmaClient`は仮のもので、実際には`axios`などで`https://api.figma.com/v1/files/{file_id}`エンドポイントを叩きます。`componentId`のマッピングはFigma APIの複雑な構造を理解する必要がありますが、基本的にはライブラリのコンポーネントIDと、インスタンスが参照するコンポーネントIDを比較します。この自動化により、大規模な組織でのデッドコンポーネント特定が効率化されます。

2.3. 削除手順とベストプラクティス

デッドコンポーネントの特定は第一歩に過ぎません。その後の「駆逐」には慎重なプロセスが必要です。

1. 最終確認と関係者へのヒアリング:

  • Library Analyticsで利用率が低いと出ても、それが一時的なものかもしれない、あるいは特定のプロジェクトでしか使われない特殊なコンポーネントかもしれないという可能性を考慮します。
  • 該当コンポーネントを作成したデザイナーや、利用実績のある開発者にヒアリングを行い、本当に削除しても問題ないかを確認します。この際、Figmaのコメント機能で過去の議論履歴を追うことも有効です。

2. 「Deprecation (非推奨)」プロセスの導入:

  • 即時削除はリスクが伴います。まずは該当コンポーネントを「非推奨 (Deprecated)」とマークし、一定期間（例: 3ヶ月）の猶予期間を設けます。
  • Figma上では、コンポーネント名に`[Deprecated]`などのプレフィックスを追加したり、専用のページに移動させたりします。
  • デザインシステムガイドラインやStorybookにも非推奨であることを明記し、代替コンポーネントがあればそれを提示します。

3. Figma上でのコンポーネント削除:

  • 非推奨期間を経て、誰も利用していないことが確実になったら、デザインシステムライブラリからコンポーネントを削除します。
  • 削除前に、必ずFigmaの「Version History」でバージョンを保存し、いつでもロールバックできるようにしておきましょう。

4. 開発側での対応:

  • Figmaでの削除に合わせ、開発側のコンポーネント（React/Vueコンポーネント、Storybookのストーリーなど）も削除します。
  • CI/CDに組み込まれたデザインリンターがあれば、非推奨・削除されたコンポーネントがコードに残っていないかをチェックする仕組みも有効です。

2.4. 神プラグインの紹介

ゾンビコンポーネント駆逐とデザインシステムの健全化に役立つFigmaプラグインをいくつか紹介します。

  • Clean Document:
  • 使われていないスタイル（カラー、テキスト、エフェクト）、コンポーネント、ローカルコンポーネント、画像を自動でクリーンアップしてくれる強力なツールです。定期的な利用でファイルサイズを最適化し、混乱を防ぎます。
  • Component Organizer:
  • Figmaの左サイドバーにあるアセットパネルのコンポーネントリストを、より整理しやすくしてくれます。ネストされた構造を視覚化したり、不要なコンポーネントを特定しやすくしたりするのに役立ちます。
  • Master:
  • マスターコンポーネントのインスタンスをすべて選択したり、マスターコンポーネントを素早く見つけたりできます。これにより、削除対象のコンポーネントが本当にインスタンス化されていないかを確認する際に役立ちます。

3. デザイン効率を数値化し、ROIを証明するレポーティング術

デザインシステムの導入は、しばしば大きな投資を伴います。テックリードとして、その投資がどれだけの効果を生み出しているのかを数値で示し、組織全体の理解と継続的な支援を得ることは極めて重要です。Library Analyticsのデータは、このROI証明のための強力な武器となります。

3.1. なぜROIを示す必要があるのか

  • 経営層への説明責任: デザインシステムの価値をビジネスインパクトとして示すことで、予算や人員の確保を円滑にします。
  • チームのモチベーション向上: 努力が具体的な成果として数値化されることで、チーム全体のモチベーションが高まります。
  • 継続的な改善の根拠: データに基づいた分析は、デザインシステム自体の改善点を見つけ、次のアクションプランを策定する強力な根拠となります。

3.2. レポーティングで使うべき指標

Library Analyticsのデータと、開発プロセスから得られるデータを組み合わせて、説得力のあるストーリーを構築します。

1. デザインシステム利用率の向上:

  • 指標: 特定期間におけるデザインシステムライブラリの利用ファイル数、インスタンス化されたコンポーネントの総数。
  • ストーリー: 「過去1年間でデザインシステムの利用ファイル数がX%増加し、新規プロジェクトのY%でデザインシステムが適用されています。これにより、デザインの一貫性が向上しました。」

2. コンポーネント再利用率:

  • 指標: 新規デザインファイルにおけるデザインシステムコンポーネントのインスタンスが占める割合。これはFigma APIや手動での分析が必要になる場合があります。
  • ストーリー: 「平均的な新規ページのデザインにおいて、Z%のUI要素がデザインシステムコンポーネントとして再利用されています。これにより、デザイナーがゼロから作成する時間が大幅に削減されています。」

3. デザインレビュー時間の短縮:

  • 指標: 毎週のデザインレビューにかかる平均時間（Figmaのコメント数やレビュー会議の時間などから間接的に測定）。
  • ストーリー: 「デザインシステムの導入により、デザインの一貫性が高まったため、デザインレビューにおける指摘事項がA%減少し、結果としてレビュー時間がB%短縮されました。」

4. 開発速度の向上:

  • 指標: 新機能の実装にかかる時間、UI関連のバグ報告数の減少（Jiraなどのデータから取得）。
  • ストーリー: 「デザインシステムとコードコンポーネントの同期により、開発者がUIを実装する時間がC%短縮されました。また、デザインと実装の乖離によるUIバグがD%減少しました。」

3.3. データの抽出と可視化

  • Figma Library Analyticsのスクリーンショット/CSVエクスポート: 最も手軽な方法です。主要なグラフや表をそのままレポートに組み込みます。
  • BIツールとの連携: より高度な分析やダッシュボード構築には、Tableau, Power BI, Looker Studio (旧 Google Data Studio) などが有効です。Figma APIを介してデータを抽出し、これらのツールに投入することで、多角的な視点からデザインシステムの健康状態を可視化できます。
  • Figma APIを使ったカスタムスクリプト: 定期的なデータ収集、特定の条件でのアラート発動など、より詳細なカスタマイズが可能です。上記のゾンビコンポーネント特定スクリプトのように、利用状況をカスタムデータベースに記録し、そこからレポートを生成することも考えられます。

4. 開発スピードを劇的に高めるFigma連携の奥義

Figmaはデザイナーだけでなく、開発者にとっても強力なツールです。テックリードとして、その真価を引き出すための隠れたショートカット、役立つ設定、そしてデザインと開発の境界線を曖昧にする連携テクニックを伝授します。

4.1. 隠れたキーボードショートカットで爆速化

Figmaの操作速度は、そのまま開発スピードに直結します。以下のショートカットは、私が日常的に使用し、デザイナー・開発者双方に推奨しているものです。

  • `Shift + I` (Insert Component):
  • アセットパネルからコンポーネントをドラッグする代わりに、このショートカットでコンポーネントを検索し、選択した位置に挿入できます。デザインシステムのコンポーネントを高速で組み上げる際に必須です。
  • `Option/Alt + Cmd/Ctrl + K` (Create Component):
  • 選択したオブジェクトを瞬時にコンポーネント化します。Atomic Designの原則に従い、再利用可能な要素を素早くコンポーネントに昇格させる際に使います。
  • `Cmd/Ctrl + Shift + R` (Replace Component):
  • 選択したコンポーネントインスタンスを、別のアセットパネル内のコンポーネントに置換します。特にプロトタイピング中にコンポーネントのバリエーションを試す際や、旧コンポーネントを新コンポーネントに一括で置き換える際に絶大な効果を発揮します。
  • `Cmd/Ctrl + /` (Quick Actions):
  • Figmaのコマンドパレットです。あらゆる機能、プラグイン、設定を検索・実行できます。「Clean Document」を呼び出したり、特定のプラグインを実行したりするのに便利です。
  • `Cmd/Ctrl + P` (Show/Hide UI):
  • FigmaのUIを非表示にし、デザイン領域を最大化します。集中してデザイン作業に取り組む際や、デザインレビューで全体像を見せたいときに役立ちます。
  • `Shift + 2` (Zoom to selection):
  • 選択中のオブジェクトに瞬時にズームインします。細かい部分の確認や編集に便利です。
  • `Cmd/Ctrl + Y` (Toggle Outline Mode):
  • 全てのレイヤーをアウトライン表示に切り替えます。複雑なレイアウトの構造を把握したり、隠れた要素を見つけたりする際に非常に有効です。

4.2. チーム開発で役立つ設定の共有化ルール

デザインシステムを運用する上で、Figmaファイルそのものの「作法」を統一することは、コラボレーションの質を大きく左右します。

  • 命名規則の徹底:
  • レイヤー/フレーム: `[Page Name]/[Section Name]/[Component Name]`や`_components/Button`など、一貫した命名規則を適用します。BEM (Block Element Modifier) の考え方をFigmaのレイヤー命名にも応用できます。
  • コンポーネント: `Button/Primary`, `Input/Text/Default`のようにスラッシュ区切りで分類し、アセットパネルでの視認性を高めます。
  • ファイル構造の標準化:
  • ページ分け: `01_Cover`, `02_Components`, `03_UserFlows`, `99_Archive`など、役割に応じたページ構造を定義します。
  • コンポーネントページ: マスターコンポーネントは専用のページに集約し、Variantプロパティを最大限に活用してバリエーションを管理します。
  • ブランチング戦略:
  • Figmaのブランチ機能は、開発におけるGit Flowのような運用を可能にします。新しい機能や大規模な改修を行う際はブランチを作成し、レビューを経てマスターにマージするフローを確立しましょう。
  • コメントとドキュメンテーションの活用:
  • Figmaのコメント機能を使って、デザインの意図、仕様の変更点、疑問点などを明確に残します。
  • Version Historyには、各バージョンの変更概要を簡潔に記述します。
  • スタイルガイドの共有:
  • Color Styles, Text Styles, Effect Stylesなど、Figmaのスタイル機能を徹底的に活用し、デザインシステムの一部として公開します。これにより、デザイナーは一貫したスタイルを簡単に適用でき、開発者はそれをトークンとして参照できます。

4.3. 実用的な設定ファイルのベストプラクティス構成例

Figmaは単体で完結するツールではなく、開発プロセス全体と深く連携することで真価を発揮します。ここでは、Figmaと開発を繋ぐための設定ファイルやスクリプトの例を挙げます。これらはFigmaのLibrary Analyticsデータと直接連携するものではないですが、デザインシステム運用全体の健全性を保つ上で不可欠です。

Figma Tokens との連携 (JSON)

Figma Tokensプラグインは、Figma上のスタイルをJSON形式のデザイントークンとしてエクスポートし、開発側でCSS変数やSCSS変数、JavaScriptオブジェクトなどに変換するワークフローを確立します。これにより、デザインと開発の間の「シングルソースオブトゥルース」を実現します。

// tokens/colors.json
// Figma TokensプラグインでFigmaのカラースタイルからエクスポートされた例
{
“color”: {
“brand”: {
“primary”: { “value”: “#007bff”, “type”: “color”, “description”: “ブランドの主要なアクションカラー” },
“secondary”: { “value”: “#6c757d”, “type”: “color”, “description”: “ブランドの副次的なアクションカラー” }
},
“text”: {
“default”: { “value”: “#212529”, “type”: “color” },
“light”: { “value”: “#6c757d”, “type”: “color” },
“inverted”: { “value”: “#ffffff”, “type”: “color” }
},
“background”: {
“default”: { “value”: “#ffffff”, “type”: “color” },
“alt”: { “value”: “#f8f9fa”, “type”: “color” }
}
},
“spacing”: {
“xs”: { “value”: “4px”, “type”: “spacing” },
“sm”: { “value”: “8px”, “type”: “spacing” },
“md”: { “value”: “16px”, “type”: “spacing” },
“lg”: { “value”: “24px”, “type”: “spacing” }
},
“font”: {
“family”: {
“body”: { “value”: “Inter, sans-serif”, “type”: “fontFamilies” },
“heading”: { “value”: “Inter, sans-serif”, “type”: “fontFamilies” }
},
“size”: {
“xs”: { “value”: “12px”, “type”: “fontSizes” },
“sm”: { “value”: “14px”, “type”: “fontSizes” },
“md”: { “value”: “16px”, “type”: “fontSizes” }
}
}
}

コメント: このJSONファイルは、Figmaで定義された色、スペーシング、フォントなどのデザイントークンを表現しています。Figma Tokensプラグインを使えば、Figma上のこれらのスタイルをGUIで管理し、この形式でエクスポートできます。開発側では、`token-transformer`のようなツールを用いて、このJSONをCSSカスタムプロパティ、SCSS変数、Tailwind CSSの設定などに変換し、開発コードに反映させます。これにより、デザインの変更が開発に自動的かつ一貫して同期されます。

Storybook のコンポーネント設定例 (TypeScript/JavaScript)

Storybookは、UIコンポーネントのカタログであり、インタラクティブなドキュメントです。Figmaのコンポーネントと1対1で対応するStorybookのストーリーを作成することで、デザイナーと開発者が同じ「言語」でコンポーネントを理解し、コミュニケーションを円滑にします。

// src/components/Button/Button.stories.tsx
// ReactとTypeScriptを用いたStorybookのCSF (Component Story Format) の例
import React from ‘react’;
import { Meta, StoryObj } from ‘@storybook/react’;
import { Button } from ‘./Button’; // 実際のButtonコンポーネントをインポート

// Storyのメタデータ定義
const meta: Meta = {
title: ‘Design System/Atoms/Button’, // Storybook上での表示パス
component: Button, // 対象となるコンポーネント
tags: [‘autodocs’, ‘design-system’], // 自動生成ドキュメントの有効化、タグ付け
parameters: {
// Figmaデザインへのリンクを設定。Library Analyticsで利用状況を確認したコンポーネントと紐付け可能
figma: {
url: ‘https://www.figma.com/file/YOUR_FILE_ID/YOUR_DESIGN_SYSTEM?node-id=0%3A1&t=YOUR_TOKEN’,
},
},
argTypes: {
// Storybookのコントロールパネルで操作できるプロパティの定義
variant: {
control: { type: ‘select’ },
options: [‘primary’, ‘danger’, ‘ghost’],
description: ‘ボタンのスタイルバリエーション’,
},
size: {
control: { type: ‘select’ },
options: [‘small’, ‘medium’, ‘large’],
description: ‘ボタンのサイズ’,
},
disabled: {
control: ‘boolean’,
description: ‘ボタンを無効にするか’,
},
children: {
control: ‘text’,
description: ‘ボタンに表示されるテキスト’,
},
onClick: {
action: ‘clicked’, // クリックイベントをログに出力
description: ‘ボタンがクリックされた時のハンドラ’,
},
},
};

export default meta;
type Story = StoryObj;

// 各ストーリーの定義
export const Primary: Story = {
args: {
variant: ‘primary’,
size: ‘medium’,
children: ‘Primary Button’,
},
};

export const Danger: Story = {
args: {
variant: ‘danger’,
size: ‘medium’,
children: ‘Danger Button’,
},
};

export const Ghost: Story = {
args: {
variant: ‘ghost’,
size: ‘medium’,
children: ‘Ghost Button’,
},
};

export const Disabled: Story = {
args: {
variant: ‘primary’,
size: ‘medium’,
children: ‘Disabled Button’,
disabled: true,
},
};

コメント: Storybookのストーリー定義は、コンポーネントのプロパティ、バリエーション、使用例を明確に示します。`parameters.figma.url`を通じてFigmaの該当コンポーネントへの直接リンクを貼ることで、デザイナーと開発者がFigmaとStorybookを行き来しやすくなり、情報の一貫性を保ちます。Library Analyticsで使われていないコンポーネントが特定された場合、対応するStorybookのストーリーも確認・削除の対象となります。

GitHub Actions を使った Figma API 連携の例 (YAML)

CI/CDパイプラインにFigma APIとの連携を組み込むことで、デザインの変更を自動的に開発側に反映させ、手動での同期作業を削減できます。これは、デザインシステム運用の自動化における究極の目標の一つです。

.github/workflows/sync-design-tokens.yml
name: Sync Design Tokens from Figma

on:
workflow_dispatch: # GitHub ActionsのUIから手動実行を可能にする
push:
branches:

  • main # mainブランチへのプッシュ時に実行

paths:

  • ‘design-system/’ # デザインシステム関連の変更があった場合のみ実行（例: Figma Tokensのconfigファイル）

schedule:

  • cron: ‘0 0 ‘ # 毎日午前0時に実行

jobs:
sync:
runs-on: ubuntu-latest # 実行環境の指定
steps:

  • name: Checkout repository

uses: actions/checkout@v3 # リポジトリのチェックアウト

  • name: Setup Node.js

uses: actions/setup-node@v3
with:
node-version: ’18’ # Node.jsのバージョン指定

  • name: Install dependencies

run: npm install # Figma APIクライアントやtoken-transformerなどをインストール

  • name: Fetch Figma Tokens

env:
FIGMA_FILE_ID: ${{ secrets.FIGMA_FILE_ID }} # FigmaファイルのID（GitHub Secretsで管理）
FIGMA_PERSONAL_ACCESS_TOKEN: ${{ secrets.FIGMA_PERSONAL_ACCESS_TOKEN }} # Figmaのパーソナルアクセストークン（GitHub Secretsで管理）
run: |
echo “Fetching Figma tokens from file ID: $FIGMA_FILE_ID”
# ここに、Figma APIを叩いてデザインファイルからトークンを抽出し、
# `token-transformer`などのツールでCSS変数やSCSS変数に変換するスクリプトを記述します。
# 例: node scripts/fetchAndTransformFigmaTokens.js
# このスクリプトは最終的に `src/styles/_tokens.scss` や `src/styles/tokens.css` を生成します。
# ダミー出力
mkdir -p src/styles
echo “// Generated from Figma Tokens” > src/styles/_tokens.scss
echo “\$color-primary: #007bff;” >> src/styles/_tokens.scss
echo “:root { –color-primary: #007bff; }” > src/styles/tokens.css

  • name: Commit and push changes

uses: stefanzweifel/git-auto-commit-action@v4
with:
commit_message: “chore(design-tokens): Auto-sync design tokens from Figma 🎨”
file_pattern: ‘src/styles/’ # 変更をコミットするファイルのパターン
branch: main # コミット対象のブランチ
# pull_request_branch: ‘feature/design-token-sync’ # PRを作成する場合
# pull_request_labels: ‘automated,design-system’ # PRにラベルを付与する場合

コメント: このGitHub Actionsのワークフローは、定期的に（または手動で、あるいは特定のファイル変更時に）Figma APIを介してデザインファイルから最新のデザイントークンを抽出し、開発プロジェクトのコードベースに自動的にコミットする例です。これにより、デザインの変更が開発コードにタイムリーかつ一貫して反映され、デザインと開発の乖離を防ぎます。`FIGMA_FILE_ID`と`FIGMA_PERSONAL_ACCESS_TOKEN`は、機密情報であるため、GitHub Secretsで安全に管理することが必須です。

結論：デザインシステムは「生き物」である

Figma Library Analyticsは、単なるデータ表示ツールではありません。それは、あなたのデザインシステムが「生きた資産」として機能しているか、あるいは「ゾンビ」と化しているかを診断し、健全な状態へと導くための強力な羅針盤です。

テックリードとして、私たちは常に変化するプロダクトとチームの要求に応えなければなりません。デザインシステムの浸透度を数値で把握し、デッドコンポーネントを特定して駆逐し、そしてその投資対効果を明確にレポーティングすること。これらは、組織全体の生産性を底上げし、より良いプロダクトを迅速に市場に投入するための不可欠なプロセスです。

この記事で紹介したFigmaの隠れた機能、神プラグイン、そしてデザインと開発を繋ぐ連携の奥義を駆使すれば、あなたのチームはFigmaの真の実力を引き出し、デザインシステムを「血肉化」できるでしょう。データに基づいた意思決定と継続的な改善サイクルを通じて、あなたのデザインシステムを常に最高の状態に保ち、プロジェクトの成功を盤石なものにしてください。

スポンサーリンク
タイトルとURLをコピーしました