Figma「Comments」を制する者はプロジェクトを制す！ステークホルダーからのフィードバックを「資産」に変えるプロジェクトマネジメント術
開発プロジェクトを率いるテックリードの皆さん、日々のデザインレビューやステークホルダーからのフィードバック、どう捌いていますか？ Figmaでのデザイン作業は順調でも、コメントの管理がブラックボックス化してしまったり、意図しない箇所に手戻りが発生したり……。その「散らばるフィードバック」こそが、開発スピードを鈍化させる隠れた要因なのです。
この記事では、Figmaの「Comments」機能を単なるコメントツールとしてではなく、プロジェクトマネジメントの強力な武器として使いこなすための実践的なテクニックを伝授します。開発者とデザイナーの連携を劇的にスムーズにし、プロジェクト全体の生産性を底上げする、まさに「現場で震えるほど役立つ極限の知見」を、私の経験を惜しみなく注ぎ込んで解説します。
1. 散らばるフィードバックの弊害と、Figma Commentsによる「集約」という名の解決策
「あの件、Slackで言ったんだけど…」「メールで送ったレビュー、どこいったっけ？」
こんなやり取りに心当たりはありませんか？ コメントが特定のコミュニケーションツールに偏ったり、担当者間で共有されていなかったりすると、以下のような弊害が生まれます。
- 情報伝達漏れ・認識齟齬: 重要なフィードバックが見落とされ、意図しない実装になったり、手戻りが発生したりします。
- 進捗管理の困難さ: 誰がどのフィードバックに対応しているのか、ステータスはどうなっているのかが不明瞭になり、進捗管理が煩雑になります。
- デザイナーの精神的負担: 複数のチャネルからのフィードバックを追うのは、デザイナーにとって大きなストレスです。
- 開発者側の混乱: どのデザインの、どの箇所に対するフィードバックなのかを特定するのに時間がかかり、開発効率が低下します。
解決策：Figma Commentsを「唯一無二のフィードバック集約ハブ」にする
Figma Commentsの真価は、デザインファイルと直接紐づいた状態でフィードバックを記録・管理できる点にあります。これを徹底することで、上記のような弊害を根本から解消できます。
- ビジュアルコンテキストの維持: デザインの特定要素にピンポイントでコメントできるため、誰が見ても「何についてのフィードバックか」が明確です。
- 一元管理: 全てのフィードバックがFigma上に集約されるため、情報が散逸しません。
- トレーサビリティの確保: コメントの作成者、日時、解決状況が記録され、議論の経緯を追跡できます。
隠れたキーボードショートカット：フィードバックの「投稿」を加速させる
フィードバックの入力自体がストレスになっていませんか？ 以下のショートカットを使いこなせば、投稿スピードが格段に向上します。
- `C` キー: コメントモードへの切り替え。マウスカーソルがコメントアイコンに変わります。
- `Esc` キー: コメントモードの解除、またはコメント編集モードの終了。
- `Enter` キー: コメントの投稿（編集モード時）。
- `Cmd + Enter` (macOS) / `Ctrl + Enter` (Windows): コメントの投稿と同時に、コメントモードを解除。これは個人的に最も多用するショートカットです。レビュー中にサクサクコメントを残し、すぐにデザイン操作に戻れるため、思考の断絶を防ぎます。
神プラグイン：フィードバック管理をさらに強化する
Figmaの標準機能だけでも強力ですが、プラグインを組み合わせることで、さらに洗練されたフィードバック管理が可能になります。
- Trello / Asana / Jira Sync (公式・非公式):
- 目的: Figma上のコメントを、既存のタスク管理ツールに自動的に同期・タスク化します。
- メリット: 開発者は普段使い慣れたツールでフィードバックを確認・対応でき、デザイナーはFigma上でステータス管理ができます。
- 選定ポイント: チームが現在利用しているタスク管理ツールとの連携がスムーズで、設定が容易なものを選びましょう。
- Content Reel:
- 目的: ダミーテキストや画像などを簡単に挿入できます。
- メリット: コメントで具体的なテキスト例や画像例を示したい場合に、迅速に準備・共有できます。
- 活用例: 「このコピーは短くした方が良い」というフィードバックの際に、修正案のコピーをContent Reelで生成してコメントに添付すると、意図が伝わりやすくなります。
- Autoflow:
- 目的: 要素間の接続線（フロー）を簡単に描画できます。
- メリット: ユーザーフローや要素間の関係性をコメントで説明する際に、視覚的に分かりやすく伝えることができます。
- 活用例: 「このボタンの遷移先は、この画面のこのセクションになるはず」といった説明を、Autoflowで描いた線とコメントで補強すると、誤解が減ります。
2. コメントの「未解決」から「解決」へ：デザインレビューの生命線
コメントが蓄積されるだけでは意味がありません。重要なのは、そのステータスを明確にし、着実に「解決」に導くフローを確立することです。
基本フロー：未解決 → 解決
1. コメント投稿: デザイナー、開発者、プロダクトマネージャーなど、関係者がFigma上でコメントを投稿します。この時点では「未解決」状態です。
2. 担当者による対応: コメントの内容を確認し、対応が必要な担当者（主にデザイナー）が、デザイン修正や確認を行います。
3. ステータス変更: 対応が完了したら、コメントのステータスを「解決済み」に変更します。
運用を劇的に改善する「解決」フローの徹底
- コメントの「解決」は「対応完了」の証:
- デザイナーは、デザイン修正が完了し、Figma上に反映されたことを確認してからステータスを「解決済み」に変更してください。
- 開発者は、Figma上のコメントステータスを「解決済み」になっていることを確認し、実装に着手・完了した際に、必要であればコメントを返信する（例：「実装完了しました！」）ことで、コミュニケーションをクローズさせます。
- 未解決コメントは「対応待ち」のリスト:
- Figmaのコメントパネルで「未解決」フィルタリングすることで、デザイナーが取り組むべきタスクリストとして機能します。
- ステータスを「解決済み」にするたびに、このリストが整理され、「今、何に集中すべきか」が明確になります。
- 「解決済み」コメントの活用:
- 過去の「解決済み」コメントは、議論の経緯や過去の仕様決定の記録として参照できます。
- 「なぜこのデザインになったのか？」という疑問が生じた際に、過去のコメントを遡ることで、意思決定の背景を理解するのに役立ちます。
誰が、いつ、何を対応したのか？ 記録を「資産」にする
Figma Commentsは、デフォルトで「誰が」「いつ」コメントを投稿・解決したかの記録を残します。これを意識的に活用しましょう。
- コメント投稿時の「@メンション」: 特定の担当者に通知したい場合や、議論を促したい場合は、`@`に続けてユーザー名を入力してメンションします。これにより、関係者の見落としを防ぎます。
- 解決時のコメント: 単にステータスを「解決済み」にするだけでなく、「修正完了しました」「仕様変更しました」などの短いコメントを添えることで、対応内容の記録としても機能します。
3. SlackやJira連携による通知・タスク化の自動化：開発ワークフローとのシームレスな融合
Figma Commentsを独立したツールで終わらせず、開発ワークフローに組み込むことが重要です。ここで活躍するのが、各種ツールとの連携です。
Slack連携：リアルタイムな情報共有と迅速なレスポンス
多くの開発チームはSlackを日常的に利用しています。Figmaのコメント通知をSlackに飛ばすことで、関係者はデザイン変更やフィードバックの発生をリアルタイムに把握できます。
設定例（Zapierなどの連携ツールを利用する場合）:
Zapier (または類似の連携ツール) の設定例
トリガー: Figma – New Comment
アクション: Slack – Send Channel Message
トリガー設定
figma_triggers:
- event: new_comment
# 対象FigmaファイルID（複数指定可能）
file_ids:
- “YOUR_FIGMA_FILE_ID_1”
- “YOUR_FIGMA_FILE_ID_2”
# コメントに特定のキーワードが含まれる場合のみトリガー（オプション）
# keyword_filter: “#urgent”
Slack通知設定
slack_actions:
- channel: “#design-feedback” # 通知を送信するSlackチャンネル
message_template: |
【Figma New Comment】
File: {{figma.file.name}}
Commenter: {{figma.comment.author.name}}
Status: {{figma.comment.is_resolved | default: “Unresolved”}}
Link: {{figma.comment.url}}
> {{figma.comment.content}}
Thread:
{{#each figma.comment.replies}}
- {{this.author.name}}: {{this.content}}
{{/each}}
# メンション設定（オプション）
# mention_users:
# – “@channel” # 特定のユーザーやグループをメンション
- コメント: `figma.comment.url` を含めることで、Slackから直接Figmaの該当コメントに飛べるようにします。`is_resolved` の表示で、未解決かどうかも一目で分かります。
- ポイント: 通知チャンネルを「#design-feedback」のような専⽤チャンネルに設定し、関係者全員が購読するようにします。緊急度が高いコメントには、特定のキーワード（例: `#urgent`）を付けるルールを設けると、通知の優先度を管理しやすくなります。
Jira連携：デザインフィードバックを「開発タスク」に昇華させる
デザインフィードバックが開発タスクに繋がる場合、Jiraのようなチケット管理システムとの連携は不可欠です。
設定例（Jira連携プラグインまたはZapierなどを使用）:
// Jira連携プラグイン (またはZapier) の設定例
{
“trigger”: {
“type”: “figma_comment_created”,
“filters”: [
{
“field”: “figma_file_id”,
“operator”: “in”,
“value”: [“YOUR_FIGMA_FILE_ID_1”]
},
{
“field”: “comment_status”,
“operator”: “equals”,
“value”: “unresolved” // 未解決コメントのみをタスク化
}
]
},
“action”: {
“type”: “create_jira_issue”,
“project_key”: “PROJ”, // Jiraプロジェクトキー
“issue_type”: “Task”, // またはBug, Storyなど
“summary_template”: “[Figma Feedback] {{figma.comment.content | truncate: 50}}”, // Jiraチケットのサマリー
“description_template”: “Figma上のフィードバックです。\n\nComment: {{figma.comment.content}}\nLink: {{figma.comment.url}}\nFile: {{figma.file.name}}\nAuthor: {{figma.comment.author.name}}\n\n対応後、Figma上でコメントを解決してください。”,
“assignee_field”: “designer_jira_username”, // デザイナーのJiraユーザー名 (設定で動的に割り当てることも可能)
“labels”: [“figma”, “ux-feedback”] // Jiraチケットに付与するラベル
},
“post_processing”: {
// Jiraチケット作成後、Figmaコメントのステータスを「対応中」などに変更する（オプション）
“update_figma_comment_status”: “in_progress”
}
}
- コメント: `summary_template` には、コメント内容の一部を自動的に含めることで、Jira上で一目で内容を把握できるようにします。`description_template` には、Figmaへのリンクを必ず含めます。
- ポイント:
- 未解決コメントのみをタスク化: 解決済みのコメントを誤ってタスク化しないように、トリガー条件を「未解決」に限定します。
- 担当者の割り当て: Jiraの担当者フィールド（`assignee_field`）に、デザインレビュー担当者（通常はデザイナー）のJiraユーザー名を自動で設定するようにします。これにより、誰が対応すべきかが明確になります。
- ラベルの活用: `labels` を活用して、Figma由来のフィードバックであることを識別しやすくします。
- 双方向連携: Jiraでタスクがクローズされたら、Figmaのコメントステータスも自動的に「解決済み」に更新されるような連携も検討すると、さらに効率が上がります。
4. デザイナーの精神的負担を減らすコミュニケーションのルール作り
フィードバックは、建設的であると同時に、受け取る側（デザイナー）の精神的な負担を最小限に抑える配慮が必要です。
コミュニケーションの「質」を高めるルール
- 「なぜ？」を添える: フィードバックをする際は、単に「ここを変えてほしい」だけでなく、「なぜ」そう思うのか、その背景にある目的やユーザーへの影響を説明するように心がけましょう。
- 悪い例: 「ここのボタンの色、もっと目立つようにして」
- 良い例: 「このボタンはCTA（Call to Action）なので、ユーザーにクリックを促すために、もう少しコントラストを強くしたいです。具体的な提案として、現在の#666666から#000000に変更するのはどうでしょうか？」
- 具体的な代替案の提示: 可能であれば、具体的な修正案や代替案を提示すると、デザイナーは対応しやすくなります。「こうすべき」という一方的な指示ではなく、「こうするのはどうだろう？」という提案の形が望ましいです。
- デザインの意図の尊重: デザイナーが意図を持ってそのデザインにした可能性を常に考慮し、まずはその意図を確認する姿勢を持ちましょう。
- コメントは「建設的」に: 批判的な言葉遣いは避け、あくまで「より良いプロダクトを作るため」という共通の目的意識を持ってフィードバックを行います。
- 「解決済み」ステータスの尊重: 一度「解決済み」になったコメントは、安易に蒸し返さないようにします。もし再度検討が必要な場合は、新たなコメントとして提起するか、議論の場を設けます。
デザイナー側の「受け止め方」のルール
- フィードバックは「コード」ではなく「データ」: デザインへのフィードバックは、あなた自身への批判ではありません。プロダクトを改善するための「データ」として客観的に受け止めましょう。
- 優先順位付け: 全てのフィードバックに即座に対応する必要はありません。プロジェクトの目標、緊急度、影響度などを考慮して、対応の優先順位をつけましょう。Figmaのコメントパネルで「未解決」フィルタリングし、リスト化して優先順位をつけるのが効果的です。
- 不明点はすぐに確認: フィードバックの意図が不明瞭な場合は、曖昧にしたまま進めず、すぐにコメントで質問するか、口頭で確認しましょう。
- 「解決済み」への感謝: フィードバックをくれた方々への感謝の気持ちを忘れずに。「解決済み」にする際に、「ご指摘ありがとうございます！」といった一言を添えるだけでも、コミュニケーションは円滑になります。
まとめ：Figma Commentsを「プロジェクトの羅針盤」に
Figmaの「Comments」機能は、単なるコメントツールではありません。今回ご紹介したような運用フローや連携、コミュニケーションルールを確立することで、
- フィードバックの「見える化」と「一元管理」
- 迅速かつ正確な意思決定
- 開発者・デザイナー間の認識齟齬の解消
- タスク管理ツールとのシームレスな連携による業務効率化
- デザイナーの精神的負担軽減とチーム全体の士気向上
といった、プロジェクトマネジメントにおける多くの課題を解決し、開発スピードを劇的に向上させる強力な武器となります。
ぜひ、この記事で紹介したテクニックを参考に、Figma Commentsを「プロジェクトの羅針盤」として活用し、チーム全体の生産性を最大化してください。あなたのプロジェクトが、よりスムーズに、より速く、そしてより良いプロダクトを生み出せるようになることを心から願っています。