Figmaコメントで起こる“伝わらない現象”
Figmaは、デザインの確認や修正指示をスムーズにやりとりできる便利なツールです。
コメント機能を使えば、離れた場所にいるメンバーともリアルタイムでやりとりでき、制作の効率が一気に上がる
――はず、なんですが…。
実際の現場では「これ、伝わってる？」「意図と違う方向に進んでない？」と感じる瞬間も意外とあります。
「ここ違和感あるかも」が伝わらないワケ
Figmaのコメント欄に頻出するワード、それが「ここ、なんか違和感あるかも」。
誰しも一度は目にしたことがあるのではないでしょうか。
一見、指摘してくれているように見えるこの言葉、実はものすごく曖昧です。
「違和感」と言われても、それが色なのか、フォントなのか、レイアウトなのか、そもそも要素なのか、受け取る側には判断できません。
これは、“フィーリング”だけで伝えようとする危うさです。
デザインの世界では感覚も大事ですが、それだけでは具体的な作業に落とし込めないのが実務というもの。
実際にWebサイトを公開するまでのプロセスでは、感覚を具体的な作業に翻訳することが不可欠です。
「違和感ある」という気づきはありがたい。でも、その正体を共有できなければ、デザインや開発の手は動きません。
曖昧なコメントが生むすれ違い
Figma上のコメントにおける“曖昧語”は、プロジェクトの混乱を生む温床です。
よくあるのが以下のような表現…
「もっとスッキリさせてほしい」
「もう少し柔らかい感じで」
「とりあえず仮で置いときました」
これらは一見会話が成立しているように見えますが、実務ではほとんど“伝わっていない”と言えます。
言ってる側は「言ったつもり」、受け取る側は「分からん」のミスマッチですね…。
こうした曖昧さが重なると、デザインと実装の間にズレが生まれやすくなります。
「スッキリって、どのくらい？」
「柔らかいって、配色？レイアウト？」
「仮って、いつまで？」と、細かな疑問が残るのです。
情報共有ツールとしてFigmaを使っていても、「言葉」が足を引っ張るとプロジェクトは空回りします。
コメントだけでプロジェクトが回る…は幻想
最近は、Figmaだけで制作から公開まで進めるチームも増えてきました。
プラグインでCSSを確認できたり、レイアウトの構造をコードとして抽出したりと、機能もかなり充実しています。
ただし、「コメントだけで完結」はちょっと危険です。
例えば、制作の方向性を議論する場面や、サイト全体の構成を決める際など、細かなニュアンスや裏の意図まで伝えるには、やはり会話が必要です。
コメントは便利ですが、万能ではありません。
Figmaの中だけでやりとりしていると、意思疎通が「文字情報」に偏りがちです。
デザインをどうコードに落とし込むか、その方法を話し合う余地もなく、なんとなく進んでしまうケースも。
実務レベルでいえば、Figmaのコメントは「補足情報」であって、すべての指示や進行管理を担うものではないという位置づけが理想です。
「もっとスッキリ感を出して！」がもたらした現場の混乱
ある案件で起きた実話です。
サイトのトップページのデザイン案に対して、クライアントからコメントが入りました。
もっとスッキリ感を出してもらえますか？
デザイナーは「余白を広げて、要素を減らす方向かな？」と判断し、情報量を半分近くまで削減しました。
しかしその結果、提出したデザインはすっきりしたものの「情報が少なすぎる」と指摘され、やり直しに…
クライアントの意図は、「すっきり＝まとまりがある」という意味で、要素数を減らしたいわけではなかったのです。
“スッキリ”という表現が、まったく違う方向に受け取られてしまった例ですね。
このようなケースでは、「どこを」「どう」「なぜ変えたいか」をセットで伝えるだけで、齟齬は防げたはずです。
曖昧な言葉や感覚的な表現だけで進めると、結果的に効率も下がってしまいます。
フィーリングを否定するわけではありません。ただ、それを相手が手を動かせる言葉に翻訳するひと手間が大切なのです。
コメントは、伝わってこそ価値があります。
Figmaコメントでよくある社内あるある集
「とりあえず◯◯しておきました」の行き先
Figmaでのやりとりを見ていると、よく登場する言葉があります。
「とりあえずこのバナー、仮で置いときました」
「とりあえずレイアウト変えてみました」
「とりあえず文章は入れておきました！」
こういった“とりあえず”コメント、現場ではごく自然に使われていますよね。
その場の判断としては便利ですし、スピード感も出ます。
でも、この“とりあえず”がどこまで有効なのか、そのまま放置されてしまうケースも少なくありません。
仮のはずだった素材が最終データに残ってしまったり、誰かが「修正済みだと思っていた」と勘違いして進めてしまったり…。
「仮で置いたはずなのに、納品データにそのまま入っていた」…ヒヤリとしますよね。
“とりあえず”を使うときには、具体的な状態や差し替え予定などもセットで書いておくのがおすすめです。
「この画像は仮です。〇月〇日までに正式版に差し替えます」
といった一言があるだけで、他のメンバーも状況を正しく把握できます。
明確な情報共有は、プロジェクト全体のコード設計や制作工程にも良い影響を与えてくれます。
Figmaのコメントがタスク管理ツール化してしまう現象
「Figma上で完結できるなら、タスク管理ツール使わなくてよくない？」
…そんな気持ちも、わかります。
でも、Figmaコメントがタスクの“メモ帳”になり始めると危険信号です。
「LPのAパターンにボタン追加する→明日まで」
「ヘッダー調整：戻すかどうか再検討」
「フッター修正 →〇〇さんに確認してから」
このように、プロジェクトの進行がFigmaコメントに頼りすぎてしまうと、誰がいつまでに何をするか不明確になりがちです。
コメントが多くなるほど、「あのやりとり、どこに書いてあったっけ？」と探す羽目になり、作業効率は逆に落ちていきます。
タスクのつもりで書いたコメントが、自分でも見つけられなくなったことあります…。
Figmaのコメントはあくまでも軽いやりとりや補足説明の場。
実際の作業進行は、TrelloやBacklogなどの正式なタスク管理ツールに切り分けて連携するのが理想です。
コメント欄が“やることメモ”になると、確認漏れ・対応漏れが爆増するので、ご注意ください。
コメントに潜む「誰向けか不明」問題
Figmaコメントあるあるの中でも、地味にストレスになるのがこれです。
「ここ、直しお願いします」
「確認済みです」
「修正しました！」
……いや、それ、誰に言ってるの？！
そして、どこを指してるの？となるパターンです。
この「誰向け？」コメントが厄介なのは、プロジェクトが複数人で動いているときほど、伝わらない率が上がるという点です。
例えば、「修正しました！」と言われても、デザイナーへの報告なのか、ディレクターへの報告なのか、エンジニア向けの通知なのかで意味合いが変わります。
さらに、指している場所がぼんやりしていると、関係ない人が混乱するだけになってしまいます。
対策としてはシンプルで、
@メンションを使って対象者を明示する、具体的にどの部分に対するコメントかを指し示す、
この2点を徹底するだけで驚くほど伝わりやすくなります。
Figmaコメント欄が“伝言板”にならないように、目的と相手を明確にして書くのが一番のコツです。
まとめ：あるあるの裏にある「プロジェクトの癖」
Figmaのコメント欄に表れる“あるある”たちは、実はプロジェクトの進め方の癖を反映しています。
・曖昧なステータス管理
・タスクの所在不明
・伝わらない指示
こうした現象が起きやすいチームほど、デザインからコードへの橋渡しでつまずきやすくなります。
Figmaのコメント欄は、ただのメモではなく、制作チームの会話の縮図です。
ちょっとした気配りひとつで、グッと伝わるようになりますよ！
実装まで見すえたFigmaコメントの工夫
「実装する人目線」でコメントを書いてみる
Figma上のコメントが伝わらない原因のひとつは、「見る人によって解釈が変わる」ことです。
特に、デザインの意図が制作側にうまく伝わらないと、HTMLやCSSに落とし込むときにズレが生まれがちです。
「ボタン、もう少し大きめで」
と書かれていたとしても、それがどのくらいのサイズを指すのか、どこに余白を足すのか、どこを基準にしているのかが曖昧だと、エンジニアは迷ってしまいます。
コメントを書くときに「これを見た人がどう実装するか」を想像するだけで、伝え方は大きく変わります。
例えば、こう書き換えるだけでも精度がぐっと上がります。
▲「少し余白を広げてください」
☑「現在左右16pxの余白を、24pxに変更したいです」
数値を出す、対象を明示する、意図を添える。
ちょっとした意識の差で、手戻りも、認識のズレも防げます。
エンジニアの手が止まる瞬間って、だいたい「どうすればいいのか迷うとき」なんです。
コメント＋仕様共有ができるとズレにくくなる
コメントで補えない情報も、Figmaには共有する手段があります。
例えば、デザインの構成ルールや、色・フォントの使用基準などをスタイルガイドとしてまとめておくと、プロジェクト全体の統一感が生まれます。
スタイルガイドやコンポーネント設計に関する情報は、別ページを作って明記するのも効果的です。
「コメントで書くと長くなるな」という内容こそ、補足資料として整理しておくことで、実装とのズレを防げます。
Figmaには変数（Variables）機能や開発モードもあるので、CSSに近いスタイル情報を確認することも可能です。
開発者がFigma上で直接スペーシングやカラーコードをチェックできる状態になっているだけで、無用なやりとりを省くことができます。
「伝えること」と「見えること」、両方を整えると、開発フェーズのストレスが大幅に減ります。
例：ホバー時の挙動はどう伝える？
ホバー（hover）時のアニメーションやインタラクションに関して、口頭では伝えやすくても、Figma上で共有しきれないことは多いです。
このボタン、ホバーしたら色が変わる感じでお願いします！
ありがちですが、実装する側にとっては疑問だらけです。
・どういう色に変わる？
・色の切り替えは一瞬？フェード？スライド？
・PCだけ？スマホではどうする？
こうした仕様を伝えるには、コメントだけでは足りません。
そこで活用したいのが、Figmaのプロトタイプ機能や、補足のアニメーションGIFや動画の共有です。
プロトタイプで簡易的に動作をつけておけば、開発側もイメージしやすくなりますし
「イメージに近い動きの参考サイト」を共有するだけでも大きなヒントになります。
ホバーの指示って、やり取りが噛み合わない原因になりがちですよね。慎重にいきたいところです。
また、どうしてもテキストで伝える場合は、「#0055ccから#0077ffに0.3秒で変化させたいです」など、
色の値とアニメーションの秒数までセットで書くと、手戻りが格段に減ります。
外注パートナーに伝えるなら？現場で使えるコツ
外部にコーディングを依頼する場合は、なおさらコメントの質が問われます。
特に「初めて依頼する相手」や「毎回メンバーが違う外注チーム」の場合は、社内以上に背景情報が伝わっていないことが多いです。
そこで意識したいのが、「一歩先回りするコメント」です。
「このセクションは、スマホで2カラムではなく縦並びに切り替わります」
「ここの背景はスクロール固定ではなく、ページと一緒に流れる想定です」
「画面幅768px未満ではナビゲーションをハンバーガー化してください」
このように、動作の条件や意図、デバイスごとの対応を明文化しておくことで、外注側も迷わず手を動かせます。
外注をスムーズに進めたいなら、Figmaのコメント欄を「メモ」ではなく「仕様書の一部」として扱う意識を持つと、連携の質が大きく変わってきますよ。
スムーズな実装は、伝え方ひとつで決まる
Figmaのコメントは、チームの意思疎通を支える大切なツールです。
特にコーディングや開発工程に入っていくときには、コメントの書き方ひとつで、実装スピードも完成度も左右されます。
デザインとコードの間にある“認識のズレ”は、言葉で防げることがほとんどです。
だからこそ、「見る人の立場で書く」「コメントだけに頼らず、仕様も整理する」「動きや条件を具体的に示す」ことが大切です。
そして、もし社内で手が足りない・細かい調整まで見られないというときは、信頼できる外注先と連携していくのも立派な選択肢です。
まとめと感想
Figmaのコメント欄は、見た目以上にチームの“クセ”や“相性”が表れる場所です。
言葉ひとつの曖昧さが、制作や開発のストップポイントになってしまうこともあれば、丁寧なコメントがそのままプロジェクト全体の流れをスムーズにしてくれることもあります。
「とりあえず」や「いい感じで」のような抽象表現も、背景や目的が共有されていれば立派な指示になりますし、逆に、数字や仕様がセットになっていなければ伝わらないことも多々あります。
コメントはメモではなく“次のアクションにつながるきっかけ”です。
そしてそのコメントが、社内だけでなく外注パートナーにも届くのであれば、なおさら一歩踏み込んだ丁寧さが求められます。
「Figmaのデザインはあるけれど、社内でコーディングまで手が回らない」
そんな状況こそ、信頼できる代行パートナーをうまく活用してみてください。
意図が伝わるコメントさえあれば、Figmaのデザインはきちんと“カタチ”になります。
実装フェーズの不安が減れば、デザインにももっと集中できるはずです。
コメントに気を配ることは、作業効率の向上にも、チームの信頼関係にも繋がっていきます。
Figmaを、ただのデザインツールで終わらせないために
――その第一歩は、「伝えたいことを、伝わる形で書くこと」かもしれません。
