組織のスケールに負けないデザイン基盤：Penpot大規模運用と権限管理のアーキテクチャ
こんにちは。テックリードとして日々プロダクトのライフサイクルを最適化している者だ。
組織が拡大し、開発チームやプロダクトの数が倍増していくフェーズにおいて、最もボトルネックになるのはコードの品質ではない。「デザインのコンテキストと資産の管理破綻」だ。
Figmaが業界標準となって久しいが、オープンソースかつセルフホスト可能、そしてSVGネイティブなデータ構造を持つ「Penpot」を全社導入する企業が急増している。特にセキュリティ要件の厳しいFintechや医療、あるいは完全なオンプレミス環境を強要される組織において、Penpotのアーキテクチャは強力な武器となる。
しかし、雑にワークスペースを切って「ご自由にどうぞ」と野放しにすれば、一瞬で野良ファイルと破綻したコンポーネントの山ができあがる。
今回は、数百人規模の開発組織でPenpotを運用し、開発スピードを極限まで高めるための「ワークスペース階層設計」「権限管理ポリシー」「ガバナンス自動化」の極意を、実践的なコードと設定を交えて伝授する。
—
1. チーム・プロジェクト・ライブラリの階層構造（アーキテクチャ設計）
大規模チームにおける最大の悪夢は、「誰がどこに正（Single Source of Truth）のコンポーネントを置いたか分からない」状態だ。Penpotの論理構造を正しくハックし、コードベースのモノレポ（Monorepo）思想に似た階層設計を構築する。
組織階層のベストプラクティス
[Enterprise Workspace (全社共通)]
┣ 📁 01_Design_System (Core Tokens & Atoms) <-- 全社共通のDesign Systemチーム
┣ 📁 02_Brand_Guidelines <-- マーケ・広報
┗ 🚀 Product_Alpha (特定プロダクト組織)
┣ 📂 Team_Core_Experience <-- 機能ドメイン別チーム
┃ ┣ 📄 [PROJ] Authentication
┃ ┗ 📄 [PROJ] Dashboard
┗ 📂 Team_Growth
┗ 📄 [PROJ] Onboarding_Flow
- Workspace (ワークスペース): 会社単位、または完全に独立した事業部単位で分割。セキュリティ境界線となる。
- Team (チーム): 組織図（ドメイン駆動設計の境界づられたコンテキスト）に一致させる。「Core Experience」「Growth」「Platform」など。
- Project (プロジェクト): 開発のエピックや、単一のユーザーフロー単位。「Auth_v2」「Checkout_Flow」など。
黄金ルール：デザインシステムは「依存される側」に徹する
Core Design System（デザイントークンや基礎コンポーネント）は、他のすべてのプロダクトチームから参照（Libraryとしての共有）される必要がある。
したがって、Design Systemチームのワークスペースは「Read-Only（閲覧権限）」を全社に解放し、編集権限をデザインコアメンバー数名に限定するのが鉄則だ。
—
2. 外部委託・他部署と安全に共存する権限管理ポリシー
外部の協力会社（業務委託デザイナー）や、他部署（プロダクトマネージャー、QA）をプロジェクトに巻き込む際、過剰な権限を与えるとコンポーネントの破壊や誤削除のリスクが生じる。
Penpotのロール設計を正しく理解し、最小権限の原則（Principle of Least Privilege）を適用せよ。
ロールマトリクス運用表
| ロール | 該当者 | ワークスペース権限 | プロジェクト権限 | できること / できないこと |
| :— | :— | :— | :— | :— |
| Admin | デザインエンジニア / デザイントップ | Full Access | Full Access | メンバー管理、課金、全削除可能 |
| Editor | プロダクトデザイナー | Modify | Modify | コンポーネント作成、編集、プロトタイプ構築 |
| Commenter | PdM, QA, エンジニア | Read Only | Read Only | コメント、インスペクト（CSS確認）、プロトタイプ試遊 |
| Guest | 外部委託メンバー | Read Only (限定) | Modify (特定PJのみ) | 該当プロジェクトのみ編集可能。コアライブラリは触らせない |
外部ベンダー安全運用のアクションプラン
1. 直接ワークスペースに招待しない: 外部メンバーは必ず「Guest」または制限付きの「Editor」として、特定のプロジェクトのみに招待する。
2. マスターライブラリの隔離: 外部メンバーが参加するプロジェクトでは、グローバルなDesign Systemライブラリの「リンク」を強制するが、上書き保存やマスターコンポーネントのパブリッシュ権限は剥奪しておく。
—
3. 開発スピードを劇的に高めるショートカット＆神プラグイン
デザインからコードへのトランスレーション（実装移行）のスピードを上げるためには、デザイナーとエンジニアが共通の言語とショートカットを習得している必要がある。
開発者が覚えるべき隠れたキーボードショートカット（Linux / Windows / Mac共通思想）
- `Shift + 2`: 選択した要素へのズーム（FigmaのShift + 2と同様だが、PenpotではSVGツリーの深度に応じたフォーカスが高速）
- `Alt (Option) + ホバー`: 要素間の正確なCSSボックスモデル（マージン・パディング）の数値計測
- `Ctrl/Cmd + Shift + I`: インスペクトモードの即時切り出し（CSSコードスニペットのコピー）
- `V`: ムーブツール、`H`: ハンドツール（空間移動の高速化は思考を止めないために必須）
絶対入れるべき「神プラグイン・拡張アプローチ」
Penpotのエコシステムは急速に成長している。特に以下のワークフローを自動化する拡張やスクリプトは、チームに即座に導入すべきだ。
1. Tokens Studio for Penpot (連携ブリッジ):
FigmaのTokens Studioと同様に、JSON形式のデザイントークン（Style Dictionary互換）をPenpotに直接同期する。
2. Accessibility (A11y) Checker:
コントラスト比（WCAG 2.1 AA/AAA基準）をリアルタイムで検証し、開発前にアクセシビリティ負債をゼロにする。
—
4. チーム開発で役立つ設定の共有化ルール（ガバナンス）
野良デザインを根絶するためには、ツールの運用ルールをドキュメント化するだけでなく、プロジェクトの初期設定テンプレートとして強制力を持たせる必要がある。
A. グリッド・レイアウト規則の統一
すべてのファイルで以下のルールをチーム標準とする。
- ベースグリッド: 8ptグリッドシステム（スペーシングは全て 4, 8, 16, 24, 32, 48, 64 の倍数のみ）。
- レイアウトグリッド: モバイル（375px/4col）, タブレット（768px/8col）, デスクトップ（1440px/12col, マージン80px）。
- Auto Layoutの徹底: グループ化（Group）の使用を禁止し、必ずフレキシブルなFlexbox概念である「Auto Layout」で構築させる。これにより、フロントエンドのCSS Flex/Gridへ直結する構造になる。
B. レイヤー命名規則（Nomenclature）
フロントエンドのクラス名やコンポーネント名（BEMやTailwind的発想）を意識したレイヤー名をつける。
- `component / button / primary`
- `layout / header / navigation`
- `element / icon / search-24px`
—
5. 実用的な設定ファイル（YAML/JSON）のベストプラクティス構成例
Penpot自体はブラウザベースのDB駆動型ツールだが、デザイントークンやCI/CDパイプライン連携において、「設定のコード管理（Design as Code）」は大規模組織の必須要件だ。
以下に、Style Dictionary等と連携し、Penpotからエクスポートしたデザイントークンをフロントエンド（React / Vue / Tailwind CSS）へ自動同期するための `config.json` およびワークフロー構成のベストプラクティスを示す。
デザイントークン定義ファイル (`tokens.json`)
このJSON構造をベースに、デザイントークンをPenpotのVariables機能と同期させる。
{
“color”: {
“brand”: {
“primary”: { “value”: “#0D9488”, “type”: “color”, “comment”: “メインブランドカラー (Teal 600)” },
“secondary”: { “value”: “#4F46E5”, “type”: “color”, “comment”: “アクセントカラー (Indigo 600)” }
},
“surface”: {
“default”: { “value”: “#FFFFFF”, “type”: “color”, “comment”: “ベース背景色” },
“subtle”: { “value”: “#F3F4F6”, “type”: “color”, “comment”: “カード・セクション背景 (Gray 100)” }
},
“text”: {
“main”: { “value”: “#1F2937”, “type”: “color”, “comment”: “メインテキスト (Gray 800)” },
“muted”: { “value”: “#4B5563”, “type”: “color”, “comment”: “サブテキスト・プレースホルダー (Gray 600)” }
}
},
“spacing”: {
“xs”: { “value”: “4px”, “type”: “dimension” },
“sm”: { “value”: “8px”, “type”: “dimension” },
“md”: { “value”: “16px”, “type”: “dimension” },
“lg”: { “value”: “24px”, “type”: “dimension” },
“xl”: { “value”: “32px”, “type”: “dimension” },
“xxl”: { “value”: “64px”, “type”: “dimension” }
},
“typography”: {
“fontFamily”: {
“sans”: { “value”: “Inter, sans-serif”, “type”: “fontFamily” },
“mono”: { “value”: “Fira Code, monospace”, “type”: “fontFamily” }
},
“fontSize”: {
“sm”: { “value”: “0.875rem”, “type”: “fontSize” },
“base”: { “value”: “1rem”, “type”: “fontSize” },
“lg”: { “value”: “1.125rem”, “type”: “fontSize” },
“xl”: { “value”: “1.5rem”, “type”: “fontSize” }
}
}
}
Style Dictionary 連携設定 (`style-dictionary.config.json`)
デザイナーがPenpot上で更新したトークンを、エンジニアリング側のビルドプロセスに組み込むための設定ファイル。
{
“source”: [“tokens//.json”],
“platforms”: {
“css”: {
“transformGroup”: “css”,
“buildPath”: “build/css/”,
“files”: [
{
“destination”: “_variables.css”,
“format”: “css/variables”,
“options”: {
“comment”: “Auto-generated by Style Dictionary from Penpot Tokens. Do not edit directly.”
}
}
]
},
“js”: {
“transformGroup”: “js”,
“buildPath”: “build/js/”,
“files”: [
{
“destination”: “tokens.js”,
“format”: “javascript/es6”,
“options”: {
“comment”: “Design tokens for Tailwind/React integration”
}
}
]
}
}
}
—
結び：ツールに縛られず、システムをスケールさせよ
ツールの移行や大規模導入は、単なる「お引越し」ではない。それはチームのコミュニケーション構造、ひいてはプロダクトのアーキテクチャそのものを再定義する絶好のチャンスだ。
Penpotのもつオープンでクリーンな構造と、ここで解説した厳格かつスマートな権限管理・ワークスペース運用ルールを組み合わせることで、あなたの組織は「野良デザインの混乱」から完全に解放されるはずだ。
さあ、今すぐワークスペースの階層を見直し、開発とデザインのパイプラインを強固に接続しよう。エンジニアリングのスピードは、デザイン基盤の美しさと共に加速する。