受け渡しとレビュー

受け渡し（ハンドオフ）は、デザインをエンジニアに渡して実装してもらう段階です。Figma の Dev Mode では、エンジニアが寸法・トークン・書き出した素材を確かめられます。ただし数値だけでは「なぜそうするか」「データが違ったらどうなるか」は伝わらないので、メモ（注釈）とプロトタイプで補います。

このチェックの項目を、チームのテンプレートとしてデザインのファイルに置いておくと、毎回の抜けが減ります。項目ごとの書き方は、この章の次のトピックで扱います。

数値（大きさ・色・余白）は Dev Mode などで読み取れますが、決まりは見た目に出ません。注釈には、見た目に出ないことを書きます。

注釈は、画面の横に番号つきで書くと対応が分かりやすくなります。長くなる決まりは、別の仕様の文書にまとめてリンクしてもかまいません。

Figma の Dev Mode は、エンジニアがデザインを読むための表示です。寸法・余白・使っているトークン・書き出す素材を確かめられます。

Dev Mode が自動で出す CSS などのコードは参考程度で、そのまま使われることは多くありません。実際には、デザインシステムの部品とトークンで組み立てます。だからこそ、デザイン側でも部品とトークンを正しく使うことが大事です。

「ふわっと出る」では、人によって思い浮かべる動きが違います。動きは数値で伝えます。

時間とイージングも、motion.duration.short・motion.easing.standard のようにトークンにすると、画面ごとに値がばらばらにならず、実装でも同じ名前で使えます。複雑な動き（イラストのアニメーションなど）は、専用の形式（Lottie など）で書き出す方法もあります。

画像やアイコンなどの素材は、使う場所に合った形式と大きさで渡します。素材の形式は表示の速さにも響きます（詳しくはパフォーマンスの章）。

どこまでデザイナーが書き出し、どこから実装で自動で変換するかは、チームによって違います。最初に決めておくと、同じ画像が何度も書き出し直されることを防げます。

デザインレビューのタイミングは1回ではありません。①ラフの段階で実現性を相談、②受け渡しの前に仕様をエンジニアと読み合わせ、③実装中にプレビュー環境（プルリクエストごとに作られる確認用の環境など）で実物を触って確認、④リリース前に最後の確認、の流れが基本です。③がいちばん効果があります。実装が終わってからの指摘は直すのが大変なので、途中の段階で見せてもらうようにお願いしておきます。

レビューで指摘するときは、「デザインと違う」だけでなく、「どの状態・どの幅で」「何がどう違うか」を、スクリーンショットと一緒に伝えます。重要度（リリース前に必須か、後でよいか）も添えると、エンジニアが優先順位をつけやすくなります。

重要度の目安として、「使えない・誤解する」（例：ボタンが押せない、エラーが伝わらない）は必須、「見た目が少し違う」は後でよい、とチームで基準をそろえておくと、話し合いが短くなります。違いの原因がデザインの書き漏れだったときは、受け渡しのチェックリストに足して、次から防ぎます。

Web の開発では、エンジニアの変更はプルリクエスト（変更の提案）として出され、レビューを通ってから本番に公開されます。その途中で、変更を実物で確かめられるプレビュー環境が使えることが多いです。

アプリの場合は、テスト用の配布の仕組み（iOS の TestFlight など）で、開発中の版を自分の端末に入れて確かめます。どちらも、エンジニアに「確認用の URL や版ができたら教えてほしい」と頼んでおくと、実装中のレビューが回りやすくなります。