【実務・中級編】大規模組織のFigma管理術！チーム・プロジェクト・プロジェクト権限の設計とデザインガバナンスの維持方法 – UI/UX・デザインツール活用バイブル

組織崩壊を防ぐFigmaガバナンス：大規模組織におけるワークスペース設計とスケーラブルな運用術

プロダクト開発組織がスケールするフェーズにおいて、コードベースの治安が崩壊するのと同様に、Figmaのワークスペースもまた「野良ファイル」「重複したコンポーネント」「カオスな権限設定」によって急速に蝕まれていく。

「誰が作ったか分からない検証用ファイルが本番デザインと混ざる」
「退職者のアカウントが外部共有ファイルのオーナーとして残り続ける」
「エンジニアがどれを実装していいか迷い、結局デザインシステムを無視してハードコーディングする」

これらはデザインツール自体の問題ではなく、「構造（Architecture）」の欠如に起因する。本稿では、Enterprise/Organizationプランの機能を極限まで引き出し、デザインの整合性と開発スピードを両立させるための「Figmaガバナンス設計」の全貌を、テックリードの視点からコードと構造をもって解説する。

—

1. チーム・プロジェクト・権限のトポロジー設計

大規模組織における最大のアンチパターンは、「部署ごとにチームを作る」という短絡的なアプローチだ。チーム構造は、組織図ではなく「デリバリーのライフサイクルとライフサイクルのスコープ」に基づいて設計すべきである。

階層構造のベストプラクティス

[Organization / Enterprise]
├── 00_Design System（全社基盤・Strict権限）
├── 10_Core Product（主要プロダクト群・Squad別プロジェクト）
├── 20_R&D / Labs（概念実証・実験的機能）
└── 99_Archived（過去資産の凍結保存）

権限マトリクスとセキュリティポリシー

Enterpriseプランの真価は、細粒度な権限コントロール（Granular Permissions）とドメイン制限にある。外部コントリビューターや委託ベンダーを含めた組織において、以下のマトリクスを厳守させる。

「Viewer-restricted」の活用: デザイナー以外のメンバー（PMやマーケター）に無暗にEditor権限を与えない。意図しないコンポーネントの改変を防ぎ、ライセンスコスト（Seat Cost）の最適化を図る。
共有リンクのセキュリティポリシー: 組織外へのリンク共有は「組織内（Organization only）」をデフォルトとし、パスワード保護とダウンロード制限（Export restriction）を必須化する。

—

2. 野良ファイルを根絶する「ライフサイクル運用ルール」

ファイルが乱雑になるのは、「どこで作業を始め、どこで終わるべきか」の動線がデザインされていないからだ。以下の3階層ファイル分類とライフサイクルを強制する。

1. `[DRAFT]` プレフィックス（個人のサンドボックス）

置き場所：各個人の「Drafts」または専用のSandboxプロジェクト。
ルール：他メンバーへの共有禁止。ここで合意形成を行ってはならない。

2. `[WIP]` プレフィックス（チーム内での検討・検証用）

置き場所：該当するスクワッドのプロジェクト。
ルール：ステークホルダーレビュー前の状態。URLは社内共有のみ可。

3. `[READY FOR DEV]` プレフィックス（実装基準を満たした確定版）

置き場所：Core Productプロジェクトの固定エリア。
ルール：テックリードおよびPMの承認（Approved）が必須。この状態になって初めてエンジニアはDev Modeでの実装を開始する。

—

3. 開発スピードを加速する！プロのキーボードショートカット極意

デザインとコードの往復運動を極限まで効率化するため、テックリードが指に叩き込んでおくべきショートカット。

`Shift + 1` : ファイル全体を俯瞰（Overview）
`Shift + 2` : 選択中のレイアウト/コンポーネントにズーム
`Shift + 3` : 現在の選択範囲（Selection）にズーム
`⌥ + 1` (`Option + 1`) : Layersパネルへのフォーカス
`⌥ + 2` (`Option + 2`) : Assetsパネル（コンポーネント）へのフォーカス
`⌥ + 3` (`Option + 3`) : Design Mode / Dev Mode の切り替え（※これによってインスペクトの速度が劇的に変わる）
`⌘ + Shift + L` : ピクセル精度のリンクコピー（特定の要素に直結するURLを即座にエンジニアに共有）

—

4. チーム導入必須：デザインシステムを守る「神プラグイン」

野良コンポーネントの発生を防ぎ、デザイナー・エンジニア間の言語統一を自動化するプラグイン群。

1. [Linto / Design System Analytics](https://www.figma.com/community/)

用途: ファイル内で「ローカルコンポーネント（非ライブラリ製）」や「デタッチされたインスタンス」がどれだけ存在するかを監査・可視化する。ガバナンス違反の早期発見に不可欠。

2. [Tokens Studio for Figma (旧Figma Tokens)](https://tokens.studio/)

用途: Design TokensをFigma上で一元管理し、後述するJSON形式でGitHubと双方向同期させる。デザイントークン駆動開発（Token-driven Development）の要。

3. [Automate / Autofill](https://www.figma.com/community/)

用途: ワイヤーフレームやモックアップのテキスト差し替え、レイアウトの自動整理をスクリプトベースで実行。定型作業の時間を8割削減する。

—

5. チーム開発で役立つ設定の共有化ルール（Tokens & Variables）

デザインシステムとコードベースの乖離を防ぐ究極の手法は、「Figma Variables（またはTokens Studio）のJSONを、GitHubのCI/CDパイプライン経由でコード（CSS/Tailwind/Style Dictionary）に変換し、再びFigmaへ戻す」というエコシステムの構築である。

以下の設定ファイル群は、Figmaのデザイントークンをエンジニアリング側と完全に同期させるためのベストプラクティス構成例である。

① `design-tokens.json`（Tokens Studio形式のマスター定義例）

このJSONファイルをGitHubでバージョン管理し、Figmaとコードベース双方のSingle Source of Truth（信頼できる唯一の情報源）とする。

{
“global”: {
“color”: {
“primary”: { “value”: “#0F172A”, “type”: “color” },
“secondary”: { “value”: “#3B82F6”, “type”: “color” },
“surface”: { “value”: “#F8FAFC”, “type”: “color” }
},
“spacing”: {
“xs”: { “value”: “4”, “type”: “spacing” },
“sm”: { “value”: “8”, “type”: “spacing” },
“md”: { “value”: “16”, “type”: “spacing” },
“lg”: { “value”: “24”, “type”: “spacing” }
}
},
“semantic”: {
“color”: {
“background”: {
“default”: { “value”: “{global.color.surface}”, “type”: “color” },
“brand”: { “value”: “{global.color.primary}”, “type”: “color” }
},
“text”: {
“main”: { “value”: “{global.color.primary}”, “type”: “color” },
“accent”: { “value”: “{global.color.secondary}”, “type”: “color” }
}
}
}
}

② `style-dictionary.config.json`（FigmaトークンをCSS/TS変数に変換するビルド設定）

Style Dictionaryを使用し、上記のJSONを各プラットフォーム（Web/iOS/Android）向けのコードへトランスパイルする。

{
“source”: [“tokens/design-tokens.json”],
“platforms”: {
“css”: {
“transformGroup”: “css”,
“buildPath”: “build/css/”,
“files”: [
{
“destination”: “_variables.css”,
“format”: “css/variables”,
“options”: {
“outputReferences”: true
}
}
]
},
“ts”: {
“transformGroup”: “js”,
“buildPath”: “build/js/”,
“files”: [
{
“destination”: “tokens.ts”,
“format”: “javascript/es6”
}
]
}
}
}

③ `.figmaignore`（リポジトリ連携時の不要ファイル除外設定 / 概念的構成）

Figma APIやプラグインを用いて自動同期スクリプトを回す際、ワークスペース内のカオスなファイルがコードベースを汚染しないための除外設定の思想。

.figmaignore
開発対象外のワークスペースや実験用ファイルをAPI同期の対象外にする
exclude_projects:

“02_Sandbox_”
“[DRAFT]”
“[ARCHIVED]”

exclude_file_types:

“brainstorming” # Miro代わりの壁打ちボードは同期対象外
“user-interview”

—

結び：デザインガバナンスは「自動化」で宿る

規約やドキュメントによる属人的な管理は、組織の拡大とともに必ず破綻する。
「人間が気をつけて整理する」のではなく、「権限設計」「ライフサイクル」「トークンの自動同期」「プラグインによる監査」という構造的なシステム（Architecture）を構築すること。

それこそが、デザイナーの創造性を解放し、エンジニアの開発スピードを極限まで高めるテックリードの仕事である。今すぐワークスペースのツリー構造を見直し、最初の一歩を踏み出してほしい。