PMのためのFigma×デザインシステム活用術

U S AU S A TR AI NI N G W ORK S HOP PMのための Figma × デザインシステム活用術 手を動かさないPMが、進行管理の武器としてFigmaとデザインシステムを使いこなすために PM・PMO・ディレクター向け研修テンプレート

AGENDA 本日の内容 01 Why：PMがFigma×デザインシステムを理解する意味 02 What：デザインシステムの成熟度をPM視点で見る 03 How：合意形成・影響範囲・レビュー会の設計 04 How：仕様書作成におけるPMの役割（Notion×Figma） 05 よくある落とし穴 06 まとめと次のアクション PMのためのFigma×デザインシステム活用術 2

WHY デザインシステムがあるとPMの何が楽になるか 見積もり精度が上がる スコープ変更に強くなる QAコストが下がる コンポーネント単位で工数を トークン変更の影響範囲を 再利用部品が多いほど 積み上げられ、ブレが減る 参照数から把握できる 検証すべき組合せが減る デザインシステムは「デザイナーの資産」ではなく、PMにとっての進行管理ツールでもある。 PMのためのFigma×デザインシステム活用術 3

WHY Figmaを理解しているPMは「通訳」になれる デザイナーへの依頼 「このボタンの色を変えて」ではなく「このVariableの値を変えて」と伝えられ、手戻りが減 る エンジニアへの説明 「デザイン通りに」ではなく「Dev Modeのこの値を見て」と具体的に指示できる 経営層への報告 Figmaのプロトタイプを見せながら、言葉だけに頼らない合意形成ができる 炎上の予防 変更履歴・コメントが残るため「言った言わない」のトラブルを未然に防げる PMのためのFigma×デザインシステム活用術 4

WHAT デザインシステムの成熟度をPM視点で見る 確認ポイント 未成熟（要注意） 成熟している Components数 画面ごとに作り直されている 一覧化され再利用されている Variables整備 色・余白が直値で散在 トークン化され一元管理 命名規則 連番やファイル固有の名前 Atomic Design等で統一 Dev Mode活用 デザイナーのみが使用 エンジニアも日常的に参照 成熟度が低いほど、見積もりの振れ幅と手戻りリスクは大きいと考えてよい。 PMのためのFigma×デザインシステム活用術 5

WHAT Figma上にある「進行管理」の材料 Version History Comments いつ・誰が・何を変更したかの記録。マイルストーン 合意形成のやり取りそのものが残る、議事録代わりの 確認に使える 一次情報 Dev Mode Status Components / Variables 各画面が「実装待ち／実装中／完了」のどこにあるか 数と更新頻度から、デザインシステムの運用負荷が見 可視化できる える PMのためのFigma×デザインシステム活用術 6

HOW Figmaで合意形成を「記録」する 1 決定事項はコメントに残す 口頭やチャットで決めたことも、該当フレームにコメントとして転記する習慣をつける 2 重要な節目でバージョンに名前を付ける 「クライアント承認版」「v2実装着手」など、Version Historyに意味のある名前を残す 3 変更の理由をセットで記録する 「何を」だけでなく「なぜ変えたか」をコメントに添えると、後から振り返れる PMのためのFigma×デザインシステム活用術 7

HOW スコープ変更の影響範囲を見極める 確認すべき問い この変更は単一画面か、共通コンポーネントか？ そのコンポーネントは何画面で使われているか？ トークン変更なら、影響を受ける色・余白は他にある か？ PMのためのFigma×デザインシステム活用術 見積もりへの反映ルール 単一画面の変更 → 通常の追加工数として見積もる 共通コンポーネントの変更 → 参照画面数×確認工数を上乗せす る トークン変更 → デザイナー・エンジニア双方に全体影響のレビ ューを依頼する 8

HOW デザインレビュー会：誰が何を見るか 参加者 確認する観点 Figma上の見る場所 PM 要件充足・スケジュール影響 User Flow、Version History デザイナー UI一貫性・デザインシステム準拠 Components、Variables エンジニア 実装難易度・Dev Mode値の妥当性 Dev Mode、Auto Layout構造 ステークホルダー 事業要件との整合・見た目の印象 プロトタイプ（Present） PMの役割は「全員の観点が抜け漏れなく出たか」を確認し、論点を仕様書（Notion）に落とすこと。 PMのためのFigma×デザインシステム活用術 9

HOW 仕様書作成：Notion×FigmaとPMの役割 Notion：PMが主導する領域 Figma：デザイナー・エンジニアが主導 背景・目的の合意形成 画面デザイン・インタラクション 優先順位・スケジュールの意思決定 実装の技術的な詳細 受け入れ基準の最終承認 コンポーネント設計 PMは両方の中身を「作る」人ではなく、両者がズレていないかを確認し、決定を下す人。 PMのためのFigma×デザインシステム活用術 10

PITFALL PMがハマりがちな落とし穴 デザインシステム導入を丸投げする 「デザイナーに任せた」で終わらせ、効果測定もROIの説明もしない Figmaを見ずに口頭報告だけで進捗管理する Dev Mode Statusや画面の実態を見ず、報告を鵜呑みにして認識がズレる コンポーネント粒度を無視して一律見積もりする 新規コンポーネントと既存流用を同じ工数で見積もり、全体が破綻する PMのためのFigma×デザインシステム活用術 11

SUMMARY まとめと次のアクション 今日のポイント デザインシステムはPMの見積もり・QA精度を左右する Figma上の履歴・コメントは、PMにとっての一次記録 次のアクション 1 2 になる PMの役割は「作る」ことではなく「ズレを確認し決め る」こと PMのためのFigma×デザインシステム活用術 3 担当プロジェクトのFigmaファイルのComponents数 を数えてみる 直近のスコープ変更が何画面に影響したか、参照数で 確認してみる 次回のデザインレビュー会で「誰が何を見るか」を役 割分担してみる 12

RESOURCES 参考リソース Figma公式：Version History ガイド 変更履歴の確認・復元方法の公式リファレンス Figma公式：Dev Mode ドキュメント エンジニア視点での実装状況確認の公式ガイド 本シリーズ「一流エンジニアのデザインシステム×Figma活用術」 実装者向けの詳細編。エンジニアとの会話で用語を揃える際に参照 うさうさ研修工房｜PM・PMO・ディレクター向け研修コンテンツ PMのためのFigma×デザインシステム活用術 13