この記事は、 セゾンテクノロジー Advent Calendar 2025 の2日目の記事です。シリーズ2では HULFT・DataSpider の開発メンバーによる投稿をお届けします🕊️
こんにちはこんにちは、1年ぶり2回目のQiita記事です。
今回は、今まさに試行錯誤しているFigmaデザインの運用方法について解説します。
プロダクトに機能追加や修正があり、デザインも変更がある場合、Figmaのデザインを修正してエンジニアに連携したりするわけですが、どこをどう変えたかを示すはっきりした運用ルールがなくて迷うことがあります。
そこで、Figmaにもあるブランチ機能を、開発で運用されているGitのブランチ管理ルールに合わせて運用すればわかりやすいのではないかと考えました。
※Figmaでブランチの作成・管理にはビジネスプランまたはエンタープライズプランが必要です。
Git flow と GitHub flow
代表的なGitのブランチ管理方法として、「Git flow」と「GitHub flow」があります。
Git flow
- メインブランチは2つ（main、develop）
- その他feature、release、hotfix など、用途に応じてブランチを細かく使い分ける
- リリースサイクルが長く、安定性を最優先する大規模なプロジェクト向け
GitHub flow
- メインブランチは1つ(main)のみ。これが常に本番環境と同じ状態
- Git flowに比べてシンプル。早いサイクルでの開発向け。
Figmaのブランチ機能
Figmaでデザインをブランチ管理する場合、GitHub flowのようなシンプルな運用のほうがフィットしやすいです。
というか、Figmaではブランチのブランチは作れないので、Git flowのようにdevelopブランチを切ってそこからfeatureブランチを切るという運用はできません。
おそらくFigmaのブランチ機能自体、Git flowのような厳密な運用は想定していないのだと思います。
ブランチ名は「feature/JIRA-xxxx_〇〇の改善」など、JIRAのチケット番号とわかりやすい内容をつけておきます。
開発のJIRAチケットと同じ番号にしておけば、エンジニアもどのブランチのデザインを見て作業すればいいのかが明確になります。
諸々確認やテストを終えて、コードがmainブランチにマージされたらFigmaのブランチもメインファイルにマージします。
ブランチ機能の注意点
Figmaのブランチ機能は慣れないと使いづらい所も多いです。
1. コンポーネントを変更した場合、そのインスタンスを使っている部分すべてが差分として表示される
- コンポーネントを変更した
- ちょっとずつ違うのでコンポーネントにしていない似たようなパーツを全部変更した
このような場合、すべて別々の差分として表示されます。
結局エンジニアはどこを見て修正すればいいのかわからなくなるかもしれません。
2. フレームを動かしただけで差分になる
ページがごちゃごちゃしてきたので整理しようと思ってフレームを動かしたり、フレーム外にあるメモ書きなどを編集すると、それも差分として認識されるため、開発に必要な差分が把握しづらくなります。
チケットの内容に関連した変更のみを該当のブランチで管理し、その他の整理整頓などは別で管理（もしくはメインファイルで直接整理）する必要があります。
3. コンフリクトが発生した場合はうまくマージできない
Gitのように行単位での自動マージができないため、同じ箇所を触ってしまった場合は「自分の変更」か「メインの変更」のどちらかを選ぶか、手作業でデザインを直していくことになります。
コンフリクトが発生しないようにできるだけ短期間でマージまで持っていきたいところです。
まとめ
Figmaでブランチと差分管理を効率的に行うには、まずFigmaデザイン自体をコンポーネントやバリアブルを駆使してきれいに作っておかないといけないなと痛感しました。
しかしこれができれば運用がスムーズになるはずですし、今後AIを利用して構築する際にも役立ってくるはずです。
さらにいい運用方法やノウハウがあればぜひ教えてください。
がんばっていきましょう！