デザイン事業部のまきです。
最初にお伝えしておくと私はマークアップはできないデザイナーです。
Gitを利用したことは数えるほどしかなくこの数年に至ってはまったく触れていないので、Git界隈の「ブランチ」の理解も赤ちゃんレベルと思っていただければと思います。（そして私のようなWebデザイナーは少なくないのではないかと思っています。）
その上で、Figma公式機能にもある「ブランチ機能」のように、メインファイルとブランチファイルの構造を無理矢理にでも再現したらいい感じに運用しやすくなるのでは？と思いついて私が知る限りの「メイン」「ブランチ」の概念部分だけを拝借しFigmaのファイル構成に利用してみた、という内容です。

目次
・Figma公式のブランチ機能の解説ではありません
・前提条件： Figmaの階層をどうすみ分けているか
　・なぜこの構成がベストと考えるか
　　・容量制限の問題
　　・Figmaの利用プランによる制限の問題
・本題：「擬似的なブランチファイル構成」とは
　・無理やりメインとブランチっぽいファイル構成にする
・どう運用するのか
　・１）変更や追加が発生したら、ブランチファイルを作成
　・２）作成したブランチファイルでデザイン作業
　・３）デザインレビュー
　・４）リリースまで済んだところでメインファイルに手動でマージ
　・５）ブランチファイルのサムネをマージ済みの表示に変更
　　・なぜマージ済みブランチを削除せず残すのか
・メリット
・デメリット
・個人的なこだわりポイント
・全然関係ないおまけ – The Figma Store購入品紹介
　・Tシャツ「Doodle Tee」
　・Tシャツ「Chunky Glyph Tee」
　・トートバッグ「Butterfly Tote」

　

Figma公式のブランチ機能の解説ではありません

Figmaには公式の機能として、ビジネスプラン以上だと「ブランチ機能」と「マージ機能」がありますが、私たちの利用しているプランではそれは使用可能対象外の機能となります。
なので今回紹介するのはFigma公式のブランチ機能ではありません。
無理やりメインとブランチっぽいファイル構成をとらせる独自にあみだしたやり方になります。
Figma公式のブランチ機能を利用したことがないのでそちらの使用感は把握していない状態で勝手にやっています。こんな使い方してる人がいるんだなあくらいに受け取っていただければと思います。
公式機能のような高度な細かいことはまったくできない、とてもアナログな構成です。

　

前提条件： Figmaの階層をどうすみ分けているか

前提条件ですが大事なところなのでちょっと長くなります。
みなさんはFigmaで長期に渡りデザイン運用しているウェブサイトで一部の画面にデザイン変更が発生したり新機能などを追加することになった際、Figmaのどこでそれらをデザインしてますか？
作成済みのFigmaファイル内でしょうか？その場合、当該画面に対して直接なのか、同じページに変更版の画面を作成してこれは変更デザイン案ですとメモなどしておくのか、それとも別のページを追加して変更分を作成するのか、それとも新しいファイルに？

この回答は、Figmaの 「チーム」＞「プロジェクト」＞「ファイル」＞「ページ」という階層構造を、デザインデータとしてどうすみわけて利用しているかによるところが大きいと思います。
私自身この数年様々な案件でFigmaを使用してきたデザイナーのひとりとして、規模の大小に関わらず以下の構造にするのがベストではと考えています。（これはプロフェッショナルプランを利用していて「チーム」は１つのみ所持可能という前提での考えです）

■ チーム：自身の所属する組織
■プロジェクト：1案件の単位
例：A社のサービスサイト、B社のサービスアプリ、自社のコーポレートサイト、など
■ファイル：用途別
例：ワイヤーフレーム、デザインシステム、デザイン画面、過去案、など
■ページ：さらに細分化
例：Figmaのサムネ用ページ、グループ分けした画面群のページ、など

　

なぜこの構成がベストと考えるか

なぜこの構成がベストと考えるのかに関しては、ファイル単位での容量制限の問題と、利用しているFigmaのプランに起因しています。

容量制限の問題

Figmaではファイルで一定の容量を超えるとアラートが表示されるようになっています。アラートが表示されるレベルになると、Figmaの挙動も重くなり作業効率がかなり落ちるので、極力１つのファイル内で作成する要素は抑える必要があると考えてます。
ちなみに同じくデザイン事業部のデザイナーである野田がこちらの記事でFigmaの容量制限についてまとめてくれています。
「Figmaのメモリ使用率が80%を超える傾向にある場面TOP3とメモリ削減手段」https://iret.media/104353

Figmaの利用プランによる制限の問題

私たちが利用しているプロフェッショナルプランでは作成できる「チーム」が１つのみのため、「チーム」=所属組織 としています。
そしてその下の階層である「プロジェクト」に関しては、
A：クライアント単位にする場合
B：Aよりもう１段階細かく、案件単位にする場合
の両方のパターンでやってみた感触としては、Bの方が融通がきいてやりやすいと考えてます。
Aのように「プロジェクト」をクライアント単位にして「ファイル」を案件単位にすると、その案件が大規模な場合には１ファイルでは容量の問題などが発生し複数のファイルを用意せざるを得なくなる場合があります。そうすると案件単位でデザインデータをグルーピングすることができなくなるので、Bのように「プロジェクト」を案件単位で管理する構成に自然と行き着いたという感じです。
（ビジネスプラン以上であれば複数のチームを作成できるようなので、例えば「チーム」からクライアントごとに分けることが可能になり、より細分化した構成にすることができるのかなと思います。）
Figma公式ドキュメント：Figmaのプランと特徴

　

本題：「擬似的なブランチファイル構成」とは

ここからやっと本題である「擬似的なブランチファイル構成」についてです。
上記の階層構造でデザインデータを棲み分けている前提でいくと、「プロジェクト」１つに対して１案件としているので、ブランチファイル構成は「プロジェクト」内で完結するものとなります。

無理やりメインとブランチっぽいファイル構成にする

「擬似的なブランチファイル構成」ってのは結果的にどういうものなのか、ていうのを先に絵でお見せした方が早いかと思うので、プロジェクト単位で見た時の画面をはります。

これだけでなんとなく「あーそういうことね」とわかっていただけたかもしれません。
メインファイルとブランチファイルを物理的に分けています。
サムネのビジュアルでそのファイルがメインなのかブランチなのかが分かりやすいようにして、マージ済みの場合はそれもぱっと見でわかるようにしています。

先ほどの画面に補足をつけたのがこちらです。

メインファイル＝今現在本番に上がってる状態の画面デザインが入っているファイル
ブランチファイル＝変更・追加に対応するためのファイル
ブランチファイル数は、変更や追加が発生するたびぽこぽこ無制限に増えていく形になります。

多数のブランチファイルの更新が続くとメインファイルが下に追いやられて探しにくくなったりするので、メインファイルはピン留めしておくと便利です。

　

どう運用するのか

１）変更や追加が発生したら、ブランチファイルを作成

デザイン作業をするためのブランチファイルを作成します。
■ ファイル名：
プロジェクト全体の運用方針や使用するタスク管理ツールによって適切なファイル名はそれぞれ異なってくるかと思いますが、私が実際にやっているやり方ではBacklogやJIRAなどの課題番号を設定します。日本語の課題タイトル（変更・追加内容の概要）はサムネイル内のみに記載します。
■ サムネイル：
あらかじめブランチファイルのサムネはコンポーネント化しておいて、＜進行中＞と＜マージ済み＞の２つの状態でバリアントを用意しておきます。
マージ済みの状態はグレーアウト的な見た目にしておくとプロジェクトでファイル一覧を見た時にどれが進行中なのか・マージ済みなのかがわかりやすくなります。
実際にサムネに設定する際は、コンポーネントを直でサムネに設定することはできませんが一度Frameでくるむことでサムネに設定できます。
※Gitなどではマージ済みのブランチは削除するものかと思いますが、削除しない理由はこの後の「５）ブランチファイルのサムネをアーカイブ済みの表示に変更」で説明します。

２）作成したブランチファイルでデザイン作業

１で作成したブランチファイル内で、変更・追加が発生した画面のみをデザインしていきます。
コンポーネントを変更・追加する必要がある場合は、まだメインファイル内のコンポーネントは編集せず、ブランチファイル内にコンポーネントのインスタンスを配置し、一旦それを編集してやりくりする形になります。

３）デザインレビュー

GitやFigmaのブランチ機能では、他者にレビューしてもらえるようにする機能が備わっているかと思いますが、本記事の試みでは当然そのような機能は無いため、デザイナーが作業終えた段階で他のデザイナーやディレクター、PM、クライアント等に直接SlackやBacklogやFigmaコメント機能を介して「Figmaのこちらをご確認ください！」とアナログに連絡を入れる形になります。
ちなみに私たちのチームでは、Figmaで該当箇所にコメントをいれてから、本来の課題が起票してあるBacklogでも証跡として連絡を入れ、Slackでもサクッと連絡する、という形をとる場合が多いです。（急ぎの時はどれかを端折る場合も多いですが）

４）リリースまで済んだところでメインファイルに手動でマージ

レビューを経てデザインがfixしたら、マークアップ→開発へと進み、リリースまで済んだところで手動でマージ作業をします。手動なので、その名の通り変更・追加になった要素を手作業でちまちまとコピペなどで作業します。
Figmaではビジネスプラン以上の場合「ブランチ機能」と合わせて「マージ機能」がありますが、それが使えないプランを利用している前提ですので、手動でマージする形になります。
コンポーネントの変更・追加を伴う場合は、先にそれらをメインファイルにマージしてから、実際の画面をマージする形になります。
手作業なので、ブランチファイルでfixしたデザインと齟齬がないよう慎重に作業する必要があります。

５）ブランチファイルのサムネをマージ済みの表示に変更

サムネを、あらかじめ用意していたバリアント「Archived」のグレーアウト状態の表示に変更します。これでプロジェクト全体で見たときに「このブランチはもうリリース終わってるのね」というのがぱっと見でわかりやすくなります。

なぜマージ済みブランチを削除せず残すのか

Gitなどではリリースが済んだ内容のブランチは削除するのが定説かと思いますが、一旦本記事の試みでは削除せずにブランチファイルを残す形をとってみています。
というのは、「あの時の改修はどのファイルで議論してどうしてこのデザインになったんだっけ」という時に、ブランチファイルが残っていることでコメントのやり取りやVersion historyからそのデザインに決定した経緯を振り返ることができる、というメリットがあると考えているためです。
担当したデザイナーがたまたま不在の時であったり退職した場合に、「この画面や機能はなぜこのデザインになったのか」の記録を誰でも参照できるようにしておくことは、長期的に一貫したスタイルでデザインを作り上げていくプロジェクトにとって、結構大事なことなのではないかと思います。

　

メリット

このファイル構成にすることでなにが良いかをまとめると、このへんを挙げられるかと思います。

• ファイル構成が綺麗に整う：複数件が並行して同時進行する場合にもファイルを物理的に分けてるので同一ファイル内でそれを行うよりもファイル内がごちゃつかない。
• 誰が見ても理解しやすい：プロジェクト単位で見た時に、なにが本番の状態でなにが変更・追加しようとしてることなのかを誰が見ても単純に理解しやすい。途中から新しいメンバーが参加したとしても、そのファイル構成から理解してもらいやすい（はず）。
• 本番の状態を参照しやすい：本番の状態を独立したメインファイルとして維持しつつ変更・追加を検討できるので、いつでも本番の状態を参照できる。（とくにログイン工程が必要なウェブサイトや分岐が多く階層も深くなるタイプのサイトだと、本番状態を綺麗に守った状態が担保されているのはとても安心）
• 過去の変更・追加内容を経緯込みで振り返りやすい：マージ済みのブランチファイルも残しておけることで、その改修をリリース後に振り返りたい時に、そのファイル内容やコメント内容やVersion historyから、どういう経緯で何を変更・追加したのかが振り返りやすい。
• Version historyが混ざらない：変更・追加要件ごとにブランチファイルを分けることで、Version historyにも複数件の同時並行作業が織り混ざって記録されずに済むので、万一作業ミスがあって復元などが必要になった際の気にするべきことが最小限になる。
• コメントが混ざらない：変更・追加要件ごとにブランチファイルを分けることで、関連性のないコメントが織り混ざらずに済む。
• メインファイルにノイズが入らない：さまざなステークホルダー(クライアント、開発、マークアップ、デバッグ、etc)にメインファイルを共有している状態で、それぞれが本番のデザインの状態を確認したい時に、まだ確定してない変更・追加要件のノイズがない綺麗な状態で見てもらえる。
• Figmaファイルの容量制限を気にしなくていい：ブランチファイル側のみでの作業になるので、よっぽど画面数の多い対応でない限りFigma側の容量制限の問題を気にすることなくさくさくと変更・追加の検討ができる。
• 運用方針が定まってるので作業者の迷いがなくなる：本件のように擬似的なブランチファイル構成にしないにしても、変更・追加対応時のデザイン作業運用方針をこのように定めてメンバーに周知しておくことで、デザイナーがその都度どこでどう作業するべきかを考える手間が減る。

　

デメリット

• 手作業でマージが必要：手作業でのマージ作業が発生する。ブランチファイルでfixした内容と齟齬がないよう慎重にマージする必要がある。
• ブランチファイルが無限に増えていく：プロジェクト内のファイルの数は無限に増えていくことになるので、その数があまりにも膨大な場合どこかで整理が必要になるかもしれない。
• 教育・学習コストがかかる：複数のデザイナーが携わる場合、メインファイルとブランチファイルの構成になってることを理解してもらい、使用するサムネはこれですよ、などの教育・学習コストがかかる。

今思いつく限りではこんなところでしょうか。運用していく中で「ここがちょっとなあ」というところに気づいていくかもしれません。

　

個人的なこだわりポイント

個人的にこのファイル構成にトライするにあたりこだわったところがいくつかあります。

• メインファイルとブランチファイルのサムネのビジュアルの差別化
• マージ済みのブランチファイルと進行中のブランチファイルのサムネの差別化
• メインファイルが迷子にならないようにピン留め

主にプロジェクト単位でファイル一覧を見たときの見やすさです。
ちなみにFigmaのサムネ設定に関しては別記事にも思いの丈を書き連ねているのでぜひ読んでください！
「Figmaにサムネを設定する」 https://iret.media/103807

今のところは滞りなくこのファイル構成で運用できている（と私は思っている）のですがまだ始めたばかりなので、長期運用していく中で新たな発見があったりアップデートが発生したら記事を更新したいと思います。

　

全然関係ないおまけ – The Figma Store購入品紹介

The Figma Store（https://store-jp.figma.com/）でいくつかのアイテムを購入したので、今回はそのうちの３つのアイテムを紹介します。

Tシャツ「Doodle Tee」

このグラフィックを見た時の率直な感想が「ああ、Figmaここまでやっちゃうんだなあ」　でした。（どこまでも囚われなくて、ひらけているなあという意味で）

背中側のピンクの文字「REFRESH」「RETHINK」「RESET」「REDO」ってメッセージ最高すぎませんか？このグラフィックのポスターもあったら部屋に飾りたいなあなんて思いました。

　

Tシャツ「Chunky Glyph Tee」

黒地にグラフィックの薄い緑色がなんともさりげない彩度で素敵です。右下に「F3FFE3」とHEXカラーコードを入れてるのがクールですね。

中央の 「A?」は何を指しているのか悔しいことにわからなく、ご存知の方いらっしゃいましたら教えていただけたら嬉しいです。

上記Tシャツ２枚は、どちらもMサイズを購入しました。
身長161センチが着用してお尻が隠れるくらい、女性にしては肩幅広めの私が着て肩幅はちょっとだけ余るくらい、腕をまっすぐ下に下ろした時に袖が肘まであと６センチ届かないくらい、です！！サイズ感の参考になるんだかならないんだか、という情報ですね。個人的にはこういう情報が服を買う時にわかるとちょっと助かるので書いてみました。
The Figma Storeには身丈と身幅がインチで書いてありますが、日本に住む人は「インチって何センチなのよ」となってしまいがちと思うので、素人採寸ですが身幅などを測ってみました。Mサイズで、肩幅46cm・身幅51cm・袖丈20cm・身丈72cm・着丈63.5cmでした。多少の誤差はご了承ください。購入検討してる方のサイズ感の参考になれば幸いです。

　

トートバッグ「Butterfly Tote」

「Doodle Tee」の背中側にもいたちょうちょがおかわですね。
なかなかしっかりした生地なので、PCなど重いものを入れて毎日持ち歩いてもへこたれなさそうです。私が会社支給で使用している MacBook Air 13.6inch は余裕で入るサイズ感です。
サイズがThe Figma Storeに書かれていないので測ってみました。高さ(持ち手は含まない)41.5cm・横幅41.5cm・マチ幅10cm・持ち手の長さは72.5cm でした。こちらも素人採寸なので多少の誤差があるかと思いますがご了承ください。底だけマチがついてるタイプです。

　
今回の購入品紹介は以上です。
他のThe Figma Store購入品紹介記事はこちらです。
「FigmaのVersion historyを使いこなす」 https://iret.media/119827
記事の最後にウォーターボトルの紹介をしてます。

また別の記事で他の購入品も紹介したいと思います！