ディレクション辞書

目次 ／ ツール ／ 効率化

Figma（仕様の受け渡し）

項目番号 122

10秒でわかる！要点まとめ

1. 概要：デザインから、実装と検収へ渡す

Figmaには、画面遷移を線で繋いで動くデモを作る「プロトタイプ」と、要素の寸法・色・フォント・余白をコードとして読み取れる「Dev Mode（開発モード）」があります。

どちらもエンジニア向けの機能に見えますが、ディレクターが仕様を受け渡す局面でこそ効きます。

2. なぜ重要なのか：言葉で書いた挙動は、必ずズレる

「ここのボタンを押すとモーダルが出て、閉じると元の位置に戻る」。文章で書くと長くなり、そのわりに解釈が割れます。プロトタイプで実際に触ってもらえば、この説明はまるごと不要になります。

これは要件定義の質に直結します（049 要件定義、028 UI設計）。クライアントの合意を取る場面でも、静止画を見せて「いい感じですね」と言われたあとに揉めるより、動かして確認したほうが、期待値のズレが起きません。

Dev Modeについても同じです。要素をクリックするだけでサイズ・色・余白の数値が出るので、「これ何ピクセルですか」とデザイナーに聞く往復がなくなります（045 フロントエンドエンジニアとのコミュニケーション）。

3. 実務のポイント：Figmaに書けないものを見極める

  1. プロトタイプは「主要導線だけ」：全画面を繋ごうとすると破綻します。合意を取りたい導線に絞ります。

  2. 状態を網羅する：正常系だけ作って渡すと、エラー時・空データ時・長文時の挙動が抜けます。崩れるのはたいていこの3つなので、フレームとして用意します。

  3. Figmaは仕様書ではない：画面に現れない条件（バリデーションのルール、権限による出し分け、通知の送信条件、データの保持期間）は、Figmaには書けません。053 コーディング仕様書作成 や 049 要件定義 に必ず別途書きます。「Figmaを見てください」で済ませると、実装漏れになります。

  4. どれが確定版かを示す：Dev Modeで「準備完了」の印を付けるなどして、実装してよいフレームを明示します。検討中のものが混ざったまま渡すのが、最も多い事故です。

  5. 検収の基準にする：確定したフレームは、そのまま検収時の照合対象になります（063 校正、020 検収・請求・契約不適合責任）。

4. スキルアップのヒント：自分でプロトタイプを組んでみる

デザイナーに頼む前に、ラフなワイヤーで自分でプロトタイプを組んでみてください。画面遷移を繋ぐ作業をすると、「この画面から戻る導線がない」といった穴が、驚くほど見つかります。

要件定義の段階でこれをやると、デザインに入る前に穴を潰せます。絵の美しさは要りません。繋がっていれば十分です。