Contents
Figmaの機能概観と出典
ここではFigmaの主要機能を短く整理し、信頼できる一次情報への参照を示します。運用方針を決める際は必ず公式ドキュメントを確認してください。
公式ドキュメントと主要リソース
主要な公式リソースは下記です。各機能の仕様やUIは更新されるため導入前に再確認してください。
- Figma ヘルプセンター（公式）：https://help.figma.com/
- Figma Developers（API / Webhooks）：https://www.figma.com/developers
- Figma Blog（公式アナウンス）：https://www.figma.com/blog/
- Figma Pricing（プラン情報）：https://www.figma.com/pricing/
- WCAG 2.1（アクセシビリティ基準）：https://www.w3.org/TR/WCAG21/
- テックメディア（買収や戦略報道の一次確認用）：TechCrunch https://techcrunch.com/、The Verge https://www.theverge.com/
企業買収やプロダクト戦略に関する報道を見かけた場合は、まずFigma公式ブログと対象企業の公式発表で一次確認してください。メディア報道のみで運用方針を変えないことを推奨します。
プランと権限の比較
導入時にプラン差で運用設計が変わります。ここでは主要機能の有無を分かりやすく示します。導入判断の際は必ず公式プラン表を確認してください。
主要機能別プラン比較（確認日: 2024-06-01）
下表は Figma 公式プランページ（https://www.figma.com/pricing/）を参照して作成した簡易比較です。実際の仕様や契約条件は導入時に公式ページで再確認してください。
| 機能 | Starter（無料） | Professional（有料） | Organization / Enterprise |
|---|---|---|---|
| ブランチ（Branch） | 利用不可（要確認） | 利用可 | 利用可（管理制御あり） |
| レビューページ（Review pages） | 利用不可（要確認） | 利用可 | 利用可 |
| SSO（SAML 等） | 利用不可 | 利用不可 | 利用可 |
| 監査ログ（Audit logs） | 利用不可 | 利用不可 | 利用可 |
| チームライブラリ公開 | 利用可（制限あり） | 利用可 | 利用可（承認フロー等の管理機能あり） |
| コンポーネントのバージョン管理 | 利用可（ベーシック） | 利用可 | 利用可（管理機能あり） |
| SCIM / ユーザープロビジョニング | 利用不可 | 利用不可 | 利用可 |
| プラグイン管理（Allowlist/Block） | 個人ベース | 組織管理なし | 管理者による制御可能 |
（注）表は参考用の簡易版です。機能の有無や管理オプションは契約種別で異なります。導入時は公式プランページで最新情報を必ず確認してください。
30日オンボーディングとKPI設計
小さく回して学び、運用ルールを現場に落とすことが重要です。以下は30日パイロットとKPI設計の実務例です。
30日パイロット設計（週次マイルストーン）
パイロットは4週間でルールを検証します。週次でスナップショットを取り、改善案を反映してください。
- Week0（準備）
- 既存ファイルの棚卸と依存ライブラリの把握。
- KPIと目標の設定（例：レビュー時間短縮、再利用率向上）。
- パイロットチーム選定（4〜8名が目安）。
- テンプレート準備（レビュー依頼、ブランチフロー等）。テンプレートは末尾の「テンプレートと用語集」を参照してください（#テンプレートと用語集）。
- Week1（キックオフ／教育）
- FigJamで運用ルールの合意形成。
- ハンズオン研修（短時間×2回）と録画配布。
- 役割（スクリーンオーナー等）の割当て。
- Week2（運用開始）
- ブランチ経由のレビュー運用を開始。
- コメントルール・ラベル運用を徹底。
- KPIの週次スナップショット取得を自動化。
- Week3（中間振返り）
- KPI を確認してルールを微調整。
- 課題はFigJamで可視化して改善案を決定。
- Week4（総括）
- 成果と課題を関係者に共有。
- ロールアウト計画（トレーニング、推進体制）を策定。
KPI設計と測定方法（スプレッドシート＆API例）
KPIは収集可能な小さな指標から始めます。ここでは計測方法とスプレッドシート／APIの実装例を示します。
- レビューサイクル時間（平均）
- 定義：レビュー依頼時刻 → 承認完了時刻の差の平均
- スプレッドシート列例：A=ReviewID、B=RequestTime、C=ApprovedTime、D=Duration_hours
- 例（Google Sheets）：D2 = (C2 - B2) * 24
- 平均（時間）: =AVERAGE(D2:D100)
- レビュー完了率
- 定義：期間内に承認されたレビュー数 ÷ 依頼数
- 例（Google Sheets）: =COUNTIF(StatusRange,"approved") / COUNTA(StatusRange)
- コンポーネント再利用率
- 定義：ライブラリからのインスタンス数 ÷ 総インスタンス数
- 例：=SUM(LibraryInstancesRange) / SUM(TotalInstancesRange)
- Figma API でのデータ収集（概略）
- コメント取得（curl 例）:
- curl -H "X-Figma-Token: $FIGMA_TOKEN" "https://api.figma.com/v1/files/$FILE_KEY/comments"
- ファイルノードを取得してコンポーネント・インスタンスを集計:
- GET https://api.figma.com/v1/files/:file_key
- Webhooks を使えばイベント駆動でスプレッドシートへ転送できます（実装はセキュリティ要件を確認のこと）。
（注）API仕様やエンドポイントは公式ドキュメント（https://www.figma.com/developers）を参照してください。トークン管理は厳格に行い、ベアラートークンを公開しないでください。
同時編集とレビュー文化の設計
同時編集は効率化に寄与しますが、ルールなしだと混乱します。簡潔なルール化とテンプレート運用で安定させます。
同時編集ルール
同一ファイルでの微修正と、ブランチでの大改修を明確に区別します。以下は運用例です。
- 編集前にコメントで「編集開始 @担当者」と宣言する。
- 編集後に「編集完了 vX.Y（短い説明）」を記載しバージョンを明示する。
- 複数人が絡む大規模変更は必ずブランチで実施する。
- Presence（カーソル）やペアデザインを活用し、同一オブジェクトの競合を避ける。
レビュー依頼テンプレート
レビュー依頼はフォーマットを統一して受け入れ基準を明示します。下記をコピーして使ってください。
- タイトル：レビュー依頼 / [画面名]
- 目的：この変更の目的を一行で記載
- 対象範囲：ページ名、フレームID、関連ブランチ名
- チェック項目：アクセシビリティ（WCAG 2.1 AA 準拠）、コピー、レスポンシブ、コンポーネント使用、パフォーマンス懸念
- 受け入れ基準：具体的な合格条件を列挙
- レビュアーと期限：一次／二次レビュアーと期日
テンプレートの完全版は「テンプレートと用語集」を参照してください（#テンプレートと用語集）。
コメント運用とエスカレーション
コメントは担当者と期限を明示して運用します。エスカレーションルールも決めておきます。
- ラベル例：needs_review、changes_requested、approved、blocked
- SLA 目安：非ブロッカーは72時間以内、重要事項は24時間以内に応答
- ブロッカーは即時エスカレーションし、FigJamで課題化する
- コメント解決時にスレッドをクローズする運用を徹底する
ブランチ運用とチームライブラリの管理
ブランチ運用はデザインの安全性を高めます。チームライブラリは設計資産の信頼性を保つ要です。運用上の手順とチェックリストを明確にしてください。
命名規則と作成タイミング
一貫した命名規則で履歴を追いやすくします。例を示します。
- 命名例
- feat/機能名（例：feat/login-flow）
- fix/issue-123（例：fix/button-contrast-212）
- chore/説明（例：chore/update-tokens）
- ブランチ作成のタイミング
- 設計の改廃、大規模UI変更、複数人で関与する変更の前に作成する
ブランチ作成からマージまでの操作手順（実務向け）
UIは更新されるため概略を示します。詳細は公式ドキュメントを参照してください（https://help.figma.com/ で "branches" を検索）。
- メインファイルを開き、ブランチ作成のオプションを選択して新規ブランチを作成します。
- ブランチ上で変更を行い、小さな単位でコミット（作業）します。
- ブランチからレビューページを作成し、レビュワーを割り当てます。
- 全てのコメントを解決し、マージチェックリストを満たしているか確認します。
- マージ実行後はメインファイルのバージョンを記録し、必要に応じてチームライブラリを公開・同期します。
レビューページの挙動や差分表示は公式ヘルプの説明を確認してください（https://help.figma.com/ の検索利用を推奨）。
マージチェックリストとコンフリクト対処
マージ時の標準チェック項目と、コンフリクトが発生したときの手順を定義します。
- マージチェック項目（必須）
- すべてのコメントが解決済みであること
- アクセシビリティ基準を満たしていること（後述のチェックを参照）
- コンポーネントの変更はライブラリに同期済みであること
- 影響範囲とロールバック手順を記載したリリースノートがあること
- コンフリクト対処
- 差分を可視化して影響範囲を特定する
- 所有者同士で妥協案を協議する
- 必要ならブランチを分割して段階的に統合する
- 最悪時はバージョン履歴から回復して差分を再適用する
FigJam・プラグイン・AIとテンプレート集
FigJamやプラグイン、AIは生産性を上げますが、ガバナンスとセキュリティを同時に設計する必要があります。テンプレートと用語もここに集約します。
FigJamの実務利用
FigJamは合意形成や発想整理に適しています。成果物は設計ファイルにリンクして追跡してください。
- 利用シーン：キックオフ、要件定義、ユーザージャーニー、ワークショップ
- 進め方のポイント：時間を区切る、役割（ファシリテーター/書記）を明確化する
- 運用ヒント：決定事項テンプレを用意し、FigJam成果をFigmaファイルへリンクする運用を定着させる
プラグイン選定基準とAIガバナンス（事例紹介／選定基準）
推奨プラグインは事例紹介です。採用基準を明示して中立性を担保してください。
- 選定基準（最低ライン）
- セキュリティ：必要最小限の権限で動作するか、データ送信先は明示されているか
- メンテナンス性：最終更新からの経過、コミット頻度、Issue対応状況
- 権限範囲：トークンやファイルアクセスの範囲が限定されているか
- 信頼性：公開実績やコミュニティ評価
- 事例紹介（例示）
- Content Reel：モック用コンテンツ挿入（事例）
- Figma Tokens：デザイントークン管理（事例）
- Stark：コントラストチェックなどアクセシビリティ支援（事例）
- Design Lint：スタイル不整合検出（事例）
- Autoflow：フロー図作成補助（事例）
- Remove BG：画像背景除去（事例）
- 導入プロセス（推奨）
- サンドボックスで検証 → セキュリティレビュー → 管理者承認 → ホワイトリスト登録
AI利用に関するガバナンス（必須事項）
- PII取扱い：氏名、メールアドレス、顧客ID、契約情報などはAIプロンプトに入力しない
- レビューとログ：プロンプトと生成結果は監査ログに保管し、誰が承認したかを記録する
- 保持期間：ログの保持期間（例：90日）を定める（法務／情報セキュリティと調整すること）
- 人間による検証：AI生成物は常にレビュー担当者が検証し、承認を必要とする
- サードパーティ契約：プラグインや外部AIサービス利用時は契約（DPA等）でデータ取り扱いを明確にする
アクセシビリティ基準（推奨）
- 準拠基準：WCAG 2.1 AA を目安にする
- 具体チェック：コントラスト比（通常テキスト 4.5:1、 大テキスト 3:1）、キーボード操作性、フォーカスの可視化、画像の代替テキスト、色のみで情報を伝えない
- ツール例：Stark プラグインや自動テストツールで定期チェックを行う
テンプレートと用語集
ここに運用で使えるテンプレートと用語集を集約します。コピーして社内のフォーマットに貼って利用してください。
- レビュー依頼テンプレート（テキスト）
- タイトル：レビュー依頼 / [画面名]
- 目的：一行で
- 対象範囲：ページ名、フレームID、ブランチ名
- チェック項目：WCAG 2.1 AA、コピー、レスポンシブ、コンポーネント適用
- 受け入れ基準：合格条件を具体的に
-
レビュアーと期限：一次／二次
-
ブランチ運用フローテンプレ（テキスト）
- ブランチ作成（命名規則に従う）
- 作業を小さくしてコミット（変更点を分ける）
- レビューページ作成・レビュワー割当
- コメント解決・チェックリスト通過
-
マージ・バージョン記録・ライブラリ同期
-
マージチェックリスト（テキスト）
- 全コメント解決済み
- アクセシビリティチェック合格
- コンポーネントは必要に応じライブラリ同期済み
-
影響範囲とロールバック手順を記載したリリースノートがある
-
30日オンボーディング要旨
- Week0：準備（KPI設定、テンプレート整備）
- Week1：キックオフとハンズオン
- Week2：運用開始（ブランチレビューを実運用）
- Week3：中間レビューとルール改善
-
Week4：総括と展開計画
-
KPI スプレッドシートのサンプル列
- ReviewID | RequestTime | ApprovedTime | Duration_hours | Status | Reviewer
- Duration_hours（D列）: = (C2 - B2) * 24
- 平均レビュー時間: =AVERAGE(D2:D100)
- 承認率: =COUNTIF(E2:E100,"approved") / COUNTA(E2:E100)
用語集（初出で英語表記と日本語訳を併記）
- Editor（編集者）：ファイル編集やブランチ作成が可能な権限
- Commenter（コメントのみ）：コメント作成は可能だが編集は不可
- Viewer（閲覧者）：閲覧のみ可能
- Team Admin（チーム管理者）：チーム設定やライブラリ公開を管理する権限
- Org Admin（組織管理者）：SSOや監査ログなど組織レベルを管理する権限
- Branch（ブランチ）：ファイルの分岐バージョン。安全に改修を行うために使用
- Merge（マージ）：ブランチでの変更をメインに統合する操作
- Review page（レビューページ）：ブランチから作成しコメントを集約するためのビュー
- Component（コンポーネント）：デザインシステムの再利用可能な要素
- Instance（インスタンス）：コンポーネントの実体
まとめ
運用のポイントは「ルールの簡潔化」と「検証可能な計測」です。機能ごとに役割を切り分けて、同一ファイルは微修正、ブランチは大改修に使い分けてください。プラン差は運用ポリシーに影響するため、導入前に公式プラン表（https://www.figma.com/pricing/）で確認してください。AIやプラグインは効率化に有益ですが、PIIの禁止やログ保持など法務・情報セキュリティとの整合を取った上で運用してください。
参考・出典（主要公式ページ）：
- Figma ヘルプセンター（https://help.figma.com/）
- Figma Developers / API（https://www.figma.com/developers）
- Figma Blog（https://www.figma.com/blog/）
- Figma Pricing（https://www.figma.com/pricing/）
- WCAG 2.1（https://www.w3.org/TR/WCAG21/）
（注）本文中のプラン情報は参考用です。プラン差や機能は変更されるため、導入時に公式ページで最新情報を再確認してください。