
Figmaの機能とどう付き合うか──「全部使う」のが正解とは限らない理由《綿貫佳祐のFigma思考ラボ|Vol.9》

目次
はじめに:使えば使うだけ良いわけではない
Figmaを使い込んでいくと、「これも作れるのか」「こんなことまでできるのか」と気づくことが増えていきます。
機能が豊富で、プラグインや各種連携も充実しているおかげで、頑張れば大抵のものは作れてしまうのがFigmaの強みです。
ただし「できるからやる」「あるから使う」が常に正解とは限りません。私自身、仕事でFigmaを使う中で、機能を使うかどうかの判断基準を持っておくことの大切さを感じる場面は多いです。
今回は、Figmaで「できる」けれど必ずしも「やるべき」ではない場面と、機能や製品との付き合い方をどう考えるかについて、私なりの整理をお伝えします。

「できる」と「やるべき」が違う場面
例1:細かなアニメーションをFigmaで作り込む
Figmaで複雑なアニメーションを表現したいと思ったとき、選択肢はいくつかあります。
例えばLottieFilesのFigmaプラグインを使って、Figma上で作成したアニメーションをLottieとして書き出し、Webやアプリで動かすといった方法です。便利な仕組みですが、注意しておきたい点もあります。
Figma上で複雑なアニメーションを構築する場合、複数のフレームをプロトタイプで繋ぎ、アフターディレイのトリガーを使って動きを表現していくことになります。
仕組みとしては理にかなっているのですが、シーンが増えれば増えるほどフレームと接続線が増え、後から編集や調整をするのが大変になっていきます。ある程度の規模のアニメーションをこの方法で作ったあとに修正しようと思うと、思いのほか負担が大きいのです。
ボタンのちょっとした動きや、ローディングアニメーションのような小さな単位なら、Figmaで作るのは合理的な選択だと思います。
ただ、シーンが連続するような複雑なアニメーションになるほど、最初からAfter Effectsなどのアニメーション専用ツールに任せた方が楽になる、というケースはあります。このように「Figmaでできる」ことと「Figmaでやるべき」ことを切り分けて考える視点が必要です。

例2:すべてのインタラクションをプロトタイプで再現する
Figmaのプロトタイプは、画面遷移やインタラクションをかなり細かく再現できます。
頑張ればフォームのバリデーションエラーの全パターン、入力中のリアルタイムなフィードバック、特定の条件でのみ起こる小さな挙動など、コード実装に近いレベルまで作り込むこともできます。
ただ、プロトタイプを使って確認したいことの中心は、多くの場合は主要な動線や挙動であることが多いです。
・ユーザーがどうビューを遷移するか
・主要な操作の流れに違和感はないか
・全体としての体験が成立しているか
このあたりが伝われば、プロトタイプとしての役割は十分に果たせていると感じることが多いです。
すべての挙動や例外パターンまでFigma上で網羅しようとすると、プロトタイプの作成や更新に時間がかかりすぎて、本来したかった検証や改善のサイクルが遅くなってしまうことがあります。
「メインの動線はFigmaのプロトタイプで確認する」「細かい挙動はコードに落としてからE2Eテストでカバーする」というように役割分担を明確にすると、それぞれの強みを活かしやすくなるはずです。
私自身の話では、良かれと思ってプロトタイプを細かく作り込んでおいたら、他の人の修正が追いつかなくなった経験があるので、チーム全体の方針や習熟度にあわせて作り込みの度合いを変えるようになりました。

例3:最新機能をすぐに導入する
Figmaには次々と新しい機能が追加されます。公式ブログやSNSで紹介されるたびに「すぐに試したい」と感じるのですが、即時導入が常に最適であるわけでもないと考えています。
例えばCode Connect CLIは、Figmaのコンポーネントと実装上のコードを接続できる強力な仕組みです。ただ、運用にはFigmaの構造に対する深い理解と、コードに対する高い知識の両方が求められます。
メンテナンスし続けられる担当者がチームから抜けてしまうと、Figmaデータと本番との同期が取れなくなったり、誰も触れなくなったりするリスクがあります。なお細かい話になりますが、Code ConnectのUI版にも制約があります。
現状ではGitHub Organizationあたり1つのリポジトリしか紐づけられないため、複数のリポジトリを扱っている会社にとっては、運用上の面倒さにつながる場面があります。
また、登場したばかりの機能は他社の事例が少なく、細かい設定の意図が読み取れなかったり、結果的にFigma公式の想定する使い方とズレてしまう可能性もあります。
新機能の魅力に飛びつくのは自然なことですが、
・その機能を継続的に扱える体制がチームにあるか
・本当に自分たちのチームの課題を解決するか
・公式の意図と大きくズレた使い方になっていないか
といった点を冷静に見極めることが、結果としてFigmaを上手く使い続けることにつながると思います。

機能を取捨選択するための判断軸
機能をどう取捨選択するかを考えるとき、私は次のような問いを自分に投げかけるようにしています。
・そのタスクは、本当にFigmaで完結させるのが最適か
・その機能を使い続けるための知識やリソースが、チームにあるか
・今すぐ導入する必要があるか、それともしばらく様子を見るべきか
・Figma公式の想定する使い方とズレていないか
「全部使えば良い」「使っていないものがあるとダメ」という発想ではなく、自分たちのチームの状況に合うものをピックアップしていく考え方です。
何かの機能を使う目的は、あくまでチームのアウトプットを良くすることであって、Figmaの機能カタログを埋めることではありません。
Figma Designの中だけの話ではない
これはFigma Designの機能選択に限った話ではありません。
Figmaには、Figma Make、Figma Sites、Figma Slidesなど、さまざまな製品が用意されています。
それぞれ便利なツールではありますが、かといって「全部使うのが正解」というわけでもありません。
例えば、資料作成においてはチームや関係者で既に使っているツール(Google Slides、Keynoteなど)の方が周囲との連携が取りやすいなら、無理にFigma Slidesに切り替える必要はありません。
逆に、デザインデータとの一貫性や同じファイル群で管理することを重視するチームなら、Figma Slidesを採用するメリットが大きい場合もあります。
ここでも判断軸は同じで、「自分たちのチームに適しているか」です。
「使っていない機能がある」ことを恐れない
Figmaには本当にたくさんの機能・製品があるので、「あの機能は便利らしいけど自分は使えていないな」と感じることもあるかもしれません。
ただ、使っていない機能があること自体は、悪いことではありません。
機能を使うこと自体が目的ではなく、デザインの仕事を良くするためにFigmaを使っているはずだからです。
新機能のキャッチアップをおざなりにして良い、ということではなく、「自分たちにとって今必要なものは何か」を主体的に選び取る姿勢を持つことが、長期的に持続するワークフローにつながるということです。
まとめ:チームに合うものを選ぶ姿勢が大切!
今回お伝えしたかったポイントを整理します。
・Figmaは頑張れば大抵何でも作れるが、「できる」と「やるべき」は必ずしも一致しない
・複雑なアニメーションのように、別のツールに任せた方が結果的に楽になるケースもある
・プロトタイプも、すべての挙動を網羅するのではなくメインの動線に絞り、細部はE2Eテストなどで補うという役割分担もある
・最新機能をすぐに導入したい気持ちは分かるが、運用を続けられるか・公式の意図とズレていないかを見極めることが大切
・Figma DesignだけでなくFigma MakeやFigma Sitesなどの製品選択でも、判断軸は同じ
・使っていない機能があること自体は問題ではなく、チームに合うものを主体的に選ぶ姿勢が大切
機能の多さや進化のスピードは、Figmaの大きな魅力です。しかし、その魅力に飲み込まれず、自分たちのチームのコンテキストに照らして主体的に選び取っていくことが、長期的にFigmaと上手く付き合っていくコツだと思います。
著者プロフィール

綿貫佳祐
株式会社エイチームホールディングス デザイナー
部長として顧客体験の向上に寄与しつつ、スペシャリストとして社内の技術をリード。2017年に新卒でエイチームホールディングス(旧:エイチーム)に入社。2023年2月に初心者向けのFigma書籍『Figmaデザイン入門 〜UIデザイン、プロトタイピングからチームメンバーとの連携まで〜』(技術評論社)を上梓。
文:綿貫佳祐
あわせて読みたい


Figmaを“使う”から“考える”へ──UIデザイナーが見た進化の7年間《綿貫佳祐のFigma思考ラボ|Vol.1》
Web制作に携わる人にとって、いまや日々の業務に欠かせない存在となったコラボレーションプラットフォーム「Figma」。一方で、「もっと使いこなしたい」「ほかの人はど…
あわせて読みたい


オートレイアウトは誰のためにあるのか? ―視点の違いから考える使い分け―《綿貫佳祐のFigma思考ラボ|V…
Web制作に携わる人にとって、いまや日々の業務に欠かせない存在となったコラボレーションプラットフォーム「Figma」。一方で、「もっと使いこなしたい」「ほかの人はど…
あわせて読みたい


コンポーネントはどこまで作り込むべきか? 〜デザインとコードの狭間で考える設計思考〜《綿貫佳祐のFi…
Web制作に携わる人にとって、いまや日々の業務に欠かせない存在となったコラボレーションプラットフォーム「Figma」。一方で、「もっと使いこなしたい」「ほかの人はど…
あわせて読みたい


バリアブルで何を「定義」すべきか? 〜デザイントークンの粒度と規律を考える〜(前編)《綿貫佳祐のFi…
Web制作に携わる人にとって、いまや日々の業務に欠かせない存在となったコラボレーションプラットフォーム「Figma」。一方で、「もっと使いこなしたい」「ほかの人はど…
あわせて読みたい


バリアブルで何を「定義」すべきか? 〜デザイントークンの粒度と規律を考える〜(後編)《綿貫佳祐のFi…
Web制作に携わる人にとって、いまや日々の業務に欠かせない存在となったコラボレーションプラットフォーム「Figma」。一方で、「もっと使いこなしたい」「ほかの人はど…
あわせて読みたい


Claude × Figma連携が切り開くデザインワークフローの新しい形。現実的な使いどころは?《綿貫佳祐のFig…
Web制作に携わる人にとって、いまや日々の業務に欠かせない存在となったコラボレーションプラットフォーム「Figma」。一方で、「もっと使いこなしたい」「ほかの人はど…
あわせて読みたい


スロット機能で変わるコンポーネント設計。Figmaでも「レイアウトと中身の分離」は実現するのか?《綿貫…
Web制作に携わる人にとって、いまや日々の業務に欠かせない存在となったコラボレーションプラットフォーム「Figma」。一方で、「もっと使いこなしたい」「ほかの人はど…
あわせて読みたい


Figmaのデータ設計に迷わないための2つの指針──コード構造とFigmaの思想をどう扱うか?《綿貫佳祐のFigm…
はじめに:Figmaデータの作り方に正解はあるのか Figmaを使ってデザインデータを作成していると「このコンポーネント、どう作ればいいんだろう?」といった悩みが出るこ…