WIPこの記事は追記・更新される可能性があります。

Figmaで画面丸ごとコンポーネント化された謎ファイルを解剖したら、衝撃の「特に意味はない慣習」だった話

Design Ops / 設計・制作

#Figma · #UI/UX · #デザインシステム · #デザイン運用 · #コミュニケーション

公開
更新

Figmaで画面丸ごとコンポーネント化された謎ファイルを解剖したら、衝撃の「特に意味はない慣習」だった話

とある案件で共有いただいたデザインファイルを開いたとき、強烈な違和感に襲われました。

「……なぜ、画面フレーム丸ごとメインコンポーネント(❖)になっているの……!?」

レイヤーパネルを見ると、画面全体の枠が紫色のコンポーネントアイコン(❖)になっており、内部の要素をちょっと直そうにもガチガチにロックされている状態。

「これは何か深い設計思想があるのでは?」「別ファイルの仕様書やデザインシステムとデータ連携しているのでは……?」と真面目に調べ上げた結果、あまりにも衝撃的な結末を迎えたドタバタ実録です(^^)


1. 疑われた「深遠な理由」と検証のドタバタ

「画面全体のコンポーネント化」は、Figmaの運用において一般的にはメンテナンス性を落とすアンチパターンとされています。

しかし、共通のコアファイルという名称から「何か理由があるはず!」と仮説を立て、まずは裏で別ファイルと連携していないか捜索を開始しました。

  1. Figma標準の「Find all instances」 → 同一ファイル内しか検索できず撃沈
  2. プラグイン「Instance Finder」 → ファイルを跨ぐ検索は Figma API の仕様上不可
  3. ライブラリの Analytics → プラン権限の壁で確認できず

「別ファイルで画面一覧やプロトタイプ背景として呼び出されているのか……?」と脳内シミュレーションを重ねるも、調べれば調べるほど迷宮入りに(#^ω^)


2. 角を立てずに作成者へSlackで直撃!

「勝手に解体して別ファイルの参照が切れたら危険」と判断し、作成者の方へ直接 Slack で質問を投げることにしました。

ネガティブな印象を与えず、意図とルールを確認するためのコミュニケーション構成は以下の通りです。

  • 対象の画面と該当パーツのスクリーンショットを添えて特定
  • 「他ファイル等と連携させるためでしょうか?」と相手の意図を尊重する仮説を提示
  • 「メンテナンスしづらいイメージがあったため気になった」と質問の理由を明記
  • 「Figmaの運用ルールやドキュメントは存在するか?」と確認

配慮を込めたメッセージを送信し、緊張の面持ちで返信を待ちました。


3. 明かされた衝撃の真相

緊張しながら待つこと数分、返ってきたのは非常に親切でフランクなお返事でした。

確認してみると、何か特別な機能や連携を持たせているわけではなく、過去のファイル構造を踏襲した「ちょっとした運用のクセ(慣習)」のようなものだったことが判明。

さらに「作業しづらい場合は、手元でコンポーネントを解除して進めてしまって全く問題ない」という、ありがたい許可までいただくことができました!

……ということは、つまり……

「特に深い意味はなかった」という衝撃のオチ!!!!(#^ω^)

深遠なデータ連携も、厳格なデザインシステムルールも存在せず、まさかの「昔からのなんとなくのノリ」だったという結末でした^^;

とはいえ、作成者の方の柔軟で迅速な対応のおかげで「解体してOK」という公式のお墨付きを得られたのは大収穫です。


4. まとめ:画面のコンポーネント化とどう向き合うか?

今回学んだ Figma 運用の教訓と、今後のベストプラクティスです。

  • 画面そのものは「コンポーネント化」しない — コンポーネント化すべきはボタンやモジュールなどの「再利用する部品」であり、画面全体をコンポーネント化するとオーバーライドの崩壊やレイヤー階層の深化を招きやすい
  • 画面群の整理は「セクション(Shift + S)」を活用する — 画面一覧をまとめたい場合はコンポーネント化ではなく、セクション機能で囲むのがメンテナンス面でも扱いやすい
  • 迷ったら「右クリック → Detach instance」で解体! — 意図のないコンポーネント化に遭遇したら、無理に付き合わず Cmd + Option + B(右クリックから Detach)で普通のフレームに崩して作業するのが精神衛生上よい

「これ管理しづらくない?」という最初の直感を信じて確認しに行ったことで、無駄なストレスを抱えずに快適な作業環境を取り戻すことができました(^^)

(本文 随時追記予定)