Figmaでは Team > Project > File > Page の階層でデータを管理します。例えばGoodpatch社の事例では、開発中の「デザインデータ用Team」と過去デザインを集約する「アーカイブ用Team」に分けています。デザイン用Team内では、サービスや機能ごとにProjectを切り分け、さらに共通UI用のProjectを設けています。各Project内には「マスターファイル（リリース用）」と「施策ファイル（開発用）」を用意し、マスターファイルに確定デザイン、施策ファイルに検討中デザインを格納します。このように階層構造を定めることで、「どのTeam/Projectに最新デザインがあるか」をチーム全員で把握しやすくなります。
たとえばProject構成は、「それぞれのサービスのデザインデータ」用と「共通で使うコンポーネント／スタイルキット」用に分けます。サービス独自のUI要素と、全サービス共通のUI要素を分離することで、不要な混乱を避け、必要なメンバーだけ必要なProjectを参照できます。スタートアップではProject名にサービス名や機能名、共通UIは「Library」「Design System」など名前を付けると分かりやすく整理できます。
各Project内のFile構成では、「マスターファイル」と「施策ファイル」を分けます。マスターファイルには、既にリリース済みの最終デザインと共有コンポーネント・スタイルをまとめます。施策ファイルは、新機能や改善案を検討する際に作成し、リリース前の試作を保管します。ファイル名には日付やバージョンを入れて置くと、履歴管理が簡単です。
マスターファイル内はさらにPage単位に整理します。Goodpatch社ではマスターファイルに「デザインのマスターデータ」「独自コンポーネント・スタイルキット」の2ページを置き、確定済みのUI設計を管理しています。各画面（ページ）には理想状態と状態変化バリエーションを揃え、実装用のトークン付きで作成しておくと抜け漏れが防げます。
施策ファイル内もPageで細分化します。例として「実装用マスター」と「作業場」の2ページに分け、作業場でアイデア出し・フィードバックを重ね、合意形成したデザインのみ実装用マスターに残す運用です。これにより、検討中のデザイン履歴（作業場）と確定版（実装用）が分かり、誰がいつ何を検討したかトレーサビリティが保たれます。
権限設定と活用
Teamレベルの権限
FigmaのTeamには主に**「編集可（Editor）」と「閲覧のみ（Viewer）」**の権限があります。編集可メンバーは新規Project/File作成や他メンバー招待も可能ですが、閲覧のみメンバーは同レベルの閲覧権メンバーのみ招待可能です。
ファイル共有の権限
ファイルを共有する際は「編集可」または「閲覧のみ」を付与します。編集可権限のユーザーはデザインの編集・移動・名前変更・共有ができます。閲覧のみ権限ではレイヤーやプロトタイプを確認でき、コメントやカーソルチャットなどコラボ機能は使用可能です。つまり、閲覧のみでもコメント機能は利用できるため、エンジニアや営業などは編集せずともフィードバックが行えます。
共有方法
ファイルやプロトタイプには固有のURLがあり、共有モーダルからリンクをコピーして送信できます。共有リンクではアクセス権（編集可/閲覧のみ）を設定できます。メール招待では相手のアドレスを入力し、権限を選んで送信できます。なお、デザインファイルで特定のFrameを選択して共有すれば、そのFrameへの直リンクを生成可能です。これにより、例えば「ログイン画面のみ参照してほしい」などピンポイントで非デザイナーに案内できます。
ファイル・ライブラリ管理
ファイル管理
各Projectごとにファイルを整理し、名称・用途を明確にします。上記のようにマスターファイルはリリース用、施策ファイルは検討用に分け、必要に応じて日付や機能名で命名しましょう。古い施策ファイルは別Project（アーカイブ用）へ移動するか、バージョン履歴に残して削除し、作業中データをすっきりさせます。
共有ルール
閲覧用のワークスペースには必要なメンバーを参加させ、編集権は最小限に留めます。例えばエンジニアや営業担当は閲覧のみとし、編集はデザイナー/PMだけに集中させると安全です。
ライブラリ活用
共通UIをTeamライブラリとして公開し、他のファイルで再利用します。公開されたライブラリは同一チームのユーザーや編集権を持つメンバーが自由に利用できます。更新があればライブラリの公開元ファイルで「Publish」を行い、使用ファイル側では更新通知を確認して「Update」する流れです。この仕組みにより、コンポーネントを1箇所で保守し、全体に反映できます。
共有公開除外
必要に応じて一部のコンポーネントやスタイルを公開から除外できます。名称先頭に.または_を付けるか、公開時にチェックを外すことで、そのアイテムはライブラリに含まれなくなります。例えばプロトタイプ専用の仮コンポーネントや一時的なパーツなどは公開範囲から外しておくと運用が安定します。
ノンデザイナーとのコラボレーション
コメント機能
Figmaのコメント機能はデザイナーだけでなく、ディレクターやエンジニアなど全員が利用できる便利な機能です。コメントはキャンバス上に直接残せるのでフィードバックが明確になり、返信・解決（Resolved）操作で議論を管理できます。担当者を@ユーザー名でメンションすると通知が飛ぶため、実装者や営業にも確実に意見を伝えられます。
プロトタイプ共有
インタラクティブなプロトタイプを共有リンクで送付し、非デザイナーに実際に操作してもらうと理解が深まります。リンクにはコメント機能も有効なので、「ここでこの動作が必要」「ボタンの色が何の意味か？」など、直接フィードバックを拾えます。プレゼンテーションモードでフルスクリーン表示しながら会議をするのも効果的です。
開発者コラボ
FigmaはDev Modeで開発者支援が可能です。開発者はFigma上でデザインからコードスニペット（React/Angular用CSSなど）を取得できるため、実装時の手戻りを減らせます。また、各画面を「Ready for Dev」とタグ付けし、変更点をノートで共有することで、エンジニアは差分を容易に把握できます（Figma Dev Mode活用）。
外部連携
スタートアップではSlackやTeamsと連携し、更新通知やリンク共有をすると便利です。FigmaのSlack連携やメール通知を有効にし、デザイン更新やコメント追加を見逃さないようにします。必要ならFigJamを使って非デザイナーも交えたブレストや仕様メモを行い、その後Figmaに落とし込むワークフローも推奨です。
リソース節約の工夫
無料シート活用
Figmaでは何人でも招待でき、招待メンバーは閲覧・コメント・エクスポートが無償で利用できます。スタートアップではこれを活用し、エンジニアや営業は無料の閲覧者シートとし、コアメンバーのみ編集者に割り当てるとコストを抑えられます。
シートタイプ管理
有料プランを導入した場合、新規メンバー招待時のデフォルトを「Viewer Restricted」に固定しておくと、意図せず追加課金されません。不要になったエディター席は早めに閲覧者に変更し、定期的に請求締め日前の座席整理（True-up前の削除）を行いましょう。
プランの最適化
Starterプラン（無料）ではチームあたりプロジェクト数に制限があるため、同一チーム内で役割を絞って運用する工夫が必要です。例えばメインのプロダクトごとにTeamを分けられなくても、ページやファイルで領域を分離することでカバーします。
テンプレートとAI活用
限られたリソースを補うために、FigmaコミュニティのUIキットやテンプレート、プラグインを積極的に利用しましょう。さらに最近のFigma AI機能では、テキストプロンプトからUIコンポーネントを生成したり、自社ブランドに即したプロトタイプを自動生成できるため、デザイン未経験者でも短時間で試作を作成できます。たとえば、Y Combinatorのスタートアップ事例ではFigma AIだけでMVPのUIを構築した例も報告されています。
運用ルール明文化
最後に、上記ルールはチームで共有しドキュメント化しておきます。例えば「ファイル命名規則」「ライブラリ更新時の通知方法」「コメント対応の締切目安」などを決めておくと、一貫性ある運用につながります。スタートアップでは担当者も流動的になりがちなため、ドキュメント化と自動化（通知設定、テンプレート活用）で工数を削減すると良いでしょう。
これらの構成や権限管理、共有ルールを整備することで、メンバーが増えてもFigma上でのコミュニケーションとデータ管理が円滑になります。実際の現場では、権限の付与ミスやファイルの置き場所不明がボトルネックになりがちです。今回紹介したTeam/Projectの例やライブラリ運用のポイントを参考に、わかりやすい構造を維持するよう心がけてください。
参考資料
Figma公式ヘルプセンター 、Goodpatchブログ 、Figma活用事例ブログ 、NML「Design System Infrastructure」 など。各社の事例や公式ドキュメントを参照しつつ、自社の開発プロセスに合った運用設計を進めてください。
コメントを残す