Figmaからコードへ：デザインから開発までの完全ワークフロー
Figmaからのコーディングは、デザインをウェブサイトに写すだけの作業ではありません。FigmaのUIデザインを、レスポンシブで機能的、かつ拡張性の高いデジタルプロダクトに仕上げるまでの全工程を解説します。
Figmaからコードへ：デザインが承認された後、実際には何が起きているのか？
デザイナーがついにこう言う瞬間をご存じでしょう。
「Figma、できました。」
クライアントは言います。
「承認します！」
みんな満足です。
開発者が画面を見て、こうつぶやくまでは。
「よし……じゃあ、これをコードで作らないと。」
そこからが本当の仕事の始まりです。
Figmaのデザインを動くウェブサイトにするのは、見たものをそのまま写すほど単純ではないからです。
実は、美しいFigmaの画面と公開されたウェブサイトの間には、たくさんの工程があります。
では、舞台裏では何が起きているのでしょうか？
難しい専門用語抜きで、順を追って見ていきましょう。
そもそも「Figmaからコードへ」とは？
こう考えてみてください。
Figmaは設計図です。
コードは実際の建物です。
Figmaが伝えるのは、
「ウェブサイトはこういう見た目にすべき」ということ。
コードが解決しなければならないのは、
「どうすれば実際に動くようにできるか？」ということです。
たとえば、Figmaに美しいログインページが描かれているとします。
そこには次のものが見えます。
- メールアドレス入力欄
- パスワード入力欄
- ログインボタン
- パスワードをお忘れの方
- Googleでログイン
シンプルに見えますよね？
しかし開発者は、さらに次のことを確実にしなければなりません。
ボタンが実際に機能すること。
フォームが入力エラーを検知すること。
パスワードが安全に扱われること。
ユーザーが実際にログインできること。
これが、ウェブサイトのように見えるものと本物のウェブサイトの違いです。
では、Figmaが承認された後に何が起きるのか？
流れは次のとおりです。
Figma → 計画 → コーディング → テスト → ウェブサイト公開
しかし、この矢印の中では多くのことが起きています。
一つずつ見ていきましょう。
ステップ1：まだコードは書かない。まずデザインを理解する
多くのプロジェクトがつまずくのは、ここです。
開発者はFigmaファイルを受け取ると、すぐにコーディングを始めてしまいます。
でも、ちょっと待ってください。
コードを書く前に、目の前にあるものを理解する必要があります。
確認すべきことは次のとおりです。
- ページはどのような構造になっているか？
- 繰り返し使われている要素はどれか？
- どのフォントが使われているか？
- どんな色が使われているか？
- 余白はどのくらいか？
- モバイルではどうなるのか？
- 操作できる要素はどれか？
Figma上では10種類の別々の要素に見えるものが、実は1つの再利用可能なコンポーネントであることもあるからです。
それを早い段階で見抜けば、後で何時間も節約できます。
ステップ2：再利用できるパーツを見つける
ウェブサイトを構築していると想像してください。
同じボタンが次のように登場することに気づきます。
トップページ → 6回
料金ページ → 4回
お問い合わせページ → 2回
そのボタンを12回コーディングしますか？
そうしないことを願います。
代わりに、再利用可能なボタンコンポーネントを1つつくります。
そうすれば、クライアントから
「ボタンを少し大きくできますか？」
と言われても、修正は1回だけ。
すべての箇所に反映されます。
だからこそ、開発者はデザインの見た目だけを見ているわけではありません。
デザインの裏にある仕組みを探しているのです。
ステップ3：デザインシステムを把握する
ここからは細部に入ります。
どのフォントが使われているか？
ブランドカラーは何か？
ボタンの角はどのくらい丸いか？
セクション間の余白はどのくらいか？
見出しはどのような見た目か？
カードはどのような見た目か？
これらがウェブサイトのデザインシステムの一部になります。
いわば、ウェブサイトのルールブックです。
場当たり的に
「ここは18pxくらいかな？」
と決めるのではなく、開発者は一貫したシステムに従うことができます。
そしてこの一貫性は、ウェブサイトが5ページから50ページへと成長したときに、非常に重要になります。
ステップ4：Figmaの画像はどう扱う？
ここで興味深いポイントがあります。
Figmaで見えるものすべてを、画像として書き出すべきではありません。
初心者はこう考えがちです。
「これはボタンっぽいから、画像で書き出そう。」
しかし、優れた開発はそうではありません。
ボタンは本物のボタンとして構築すべきです。
テキストはテキストのままにすべきです。
カードはコードで構築すべきです。
本当に画像である必要がある写真やイラストだけを、個別に書き出します。
なぜでしょうか？
本物のウェブサイト要素は、
レスポンシブで、
クリックでき、
アクセシブルで、
編集できるからです。
そして、保守もはるかに簡単です。
ステップ5：技術を選ぶ
ここで開発者は問いかけます。
「私たちは何をつくろうとしているのか？」
シンプルな企業サイトなら？
HTML、CSS、JavaScriptで十分かもしれません。
モダンなウェブアプリケーションなら？
ReactやNext.jsのほうが適しているかもしれません。
モバイルアプリなら？
FlutterやReact Nativeでしょう。
大規模なSaaSプロダクトなら？
考えるべきことはずっと増えます。
- フロントエンド
- バックエンド
- データベース
- API
- 認証
- セキュリティ
- 拡張性
つまり、Figmaのデザインがすべてを決めるわけではありません。
決めるのはプロダクトの要件です。
ステップ6：デザインをコンポーネントに分解する
ここから面白くなってきます。
次のように考えるのではなく、
「このページをつくらなければ。」
開発者はこう考え始めます。
「このページは何で構成されているのか？」
たとえば：
これらはそれぞれ、再利用可能な構成要素にできます。
レゴブロックに少し似ています。
レゴで何かをつくるたびに、すべてのブロックをゼロからつくったりはしません。
既存のブロックを使って、より大きなものを組み立てます。
これこそが、コンポーネントベース開発の本質です。
ステップ7：まず構造をつくる
ここでようやくコーディングを始めます。
それでも開発者は通常、最初から細部にこだわるわけではありません。
まず、
構造をつくる。
次に、
スタイルを適用する。
そして、
インタラクションを追加する。
最後に、
すべてをテストする。
家を建てる場面を想像してください。
壁を建てる前にカーテンの色を選ぶ人はいません。
考え方は同じです。
まず構造、細部は後から。
ステップ8：Figmaどおりの見た目に仕上げる
ここからデザインに合わせていきます。
フォントサイズ。
色。
余白。
ボタン。
カード。
画像。
枠線。
影。
すべてが形になり始めます。
ただし、重要なルールがひとつあります。
ピクセルをただ写すのではなく、その意図を理解すること。
なぜでしょうか？
Figmaでは1440pxのデスクトップ画面が描かれているかもしれません。
しかしユーザーが使っているのは、
1366pxのノートPC
1024pxのタブレット
390pxのスマートフォン
かもしれません。ウェブサイトは、そのすべてで機能する必要があります。
ステップ9：そしてモバイル対応へ…
ここからが腕の見せどころです。
美しいデスクトップデザインでは、
1行に3枚のカードが並んでいます。
では、スマートフォンではどうなるでしょうか？
おそらく、
1行に1枚のカードにする必要があるでしょう。
デスクトップのナビゲーションは、
ホーム | 会社概要 | サービス | お問い合わせ
モバイルでは？
ハンバーガーメニューになるかもしれません。
大きなメインビジュアルは？
サイズや位置を調整する必要があるかもしれません。
これをレスポンシブデザインと呼びます。
そしてこれこそ、Figmaからのコーディングが単なる「コピー＆ペースト」ではない最大の理由のひとつです。
開発者は判断しなければなりません。
「画面サイズが変わったとき、このデザインはどう振る舞うべきか？」
ステップ10：すべてを実際に動くようにする
ここからウェブサイトは本物のプロダクトになり始めます。
Figmaのボタンには、
ログイン
と書かれているかもしれません。コードは、実際にユーザーをログインさせる必要があります。
検索バーは実際に検索できなければなりません。
フォームは実際に送信できなければなりません。
ドロップダウンは実際に開かなければなりません。
決済ボタンは実際に決済システムにつながらなければなりません。
ダッシュボードは実際にデータを表示しなければなりません。
ここで、UIデザインとソフトウェア開発の違いがはっきりします。
Figmaは体験を見せます。
コードは体験をつくり出します。
ステップ11：バックエンドと接続する
シンプルな例で考えてみましょう。
フードデリバリーの注文アプリを想像してください。
Figmaに描かれているのは、
レストラン → 料理 → カート → 注文手続き → 決済
わかりやすく見えます。
しかし、その画面の裏側では？
多くのことが起きています。
アプリケーションは次のことを把握する必要があります。
- ユーザーは誰か？
- 何を注文したか？
- カートには何が入っているか？
- 合計金額はいくらか？
- 注文はどこに送られるべきか？
- 決済は成功したか？
- 注文のステータスはどうなっているか？
ここで、API、データベース、バックエンドシステムの出番です。
ユーザーに見えるのはインターフェースです。
その裏にあるテクノロジーが、すべてを動かしているのです。
ステップ12：Figmaと現実の比較
さあ、誰もが大好きな工程です。
Figmaのデザインを開きます。
ウェブサイトを開きます。
2つを並べて比較します。
すると突然……
「あれ？なんで見た目が違うんだろう？」
たとえば、
Figmaの見出し → 48px
ウェブサイトの見出し → 42px
Figmaの余白 → 24px
ウェブサイトの余白 → 16px
ボタンが少し大きすぎるかもしれません。
画像の位置がずれているかもしれません。
モバイルのレイアウトが窮屈に感じられるかもしれません。
こうした細部が重要です。
そこで開発者は、完成したプロダクトを元のデザインと比較し、調整を加えます。
これをデザインQAと呼びます。
ステップ13：実機でテストする
自分のノートPCでは完璧に見えるウェブサイトも、他の人のスマートフォンではまったく崩れてしまうことがあります。
だからこそテストします。
確認するのは、
スマートフォン
タブレット
ノートPC
デスクトップ
そして、さまざまなブラウザでの確認も忘れずに。
チェックするポイントは次のとおりです。
- レイアウトの崩れ
- テキストのはみ出し
- 小さすぎるボタン
- 不自然な表示の画像
- 開かないメニュー
- 動作しないフォーム
なぜなら、
「自分のPCでは動く」はテスト戦略ではないからです。
ステップ14：高速化する
さて、ウェブサイトの見た目は良くなりました。
きちんと動きます。
でも、速いでしょうか？
読み込みにいつまでもかかる美しいウェブサイトは、決して良い体験とはいえません。
そこで開発者は、次のような要素を最適化します。
- 画像
- フォント
- コード
- スクリプト
- コンポーネント
- 読み込みの挙動
目的はシンプルです。
ウェブサイトを速く感じさせること。
ユーザーは、Figmaファイルがどれほど美しかったかには関心がありません。
関心があるのは、ウェブサイトがどれだけ素早く動いてくれるかです。
ステップ15：アクセシビリティを忘れない
見落とされがちなポイントがもうひとつあります。
ウェブサイトは、できるだけ多くの人が利用できるものであるべきです。
つまり、次のような点を考慮する必要があります。
- 色のコントラスト
- キーボード操作
- 読みやすいテキスト
- アクセシブルなフォーム
- 画像の代替テキスト
- フォーカス状態の表示
デザインが完璧に見えても、一部のユーザーにとっては操作しにくいことがあります。
優れた開発とは、単に見た目を良くすることではありません。
誰にとっても使いやすくすることなのです。
AIはどうなのか？
ここからが興味深いところです。
AIを使えば、開発者はデザインをはるかに速くコードに変換できます。
たとえば、次のようなものを生成できます。
- HTML
- CSS
- Reactコンポーネント
- Tailwindのコード
- UIの構造
素晴らしく聞こえます。
実際、素晴らしいものです。
しかし、落とし穴があります。
生成されたコードが、そのまま良いコードであるとは限りません。
誰かが次の点を確認する必要があります。
モバイルで動作するか？
アクセシブルか？
安全か？
保守しやすいコードか？
プロダクトが成長しても動き続けるか？
AIは開発を速くしてくれます。
しかし、優れたエンジニアリングには今も人間の思考が必要です。
Figmaからのコーディングで最も多い間違い
それは、こう考えることです。
Figma → コピー → ペースト → 完成
プロの開発はそうではありません。
実際のプロセスは、むしろ次のようなものです。
Figma
↓
理解する
↓
計画する
↓
コンポーネントを構築する
↓
コードを書く
↓
レスポンシブ対応する
↓
バックエンドと接続する
↓
テストする
↓
デザインと比較する
↓
最適化する
↓
公開する
こうして見ると、「Figmaをウェブサイトにしてほしい」というシンプルな依頼も、それほど単純には見えなくなるはずです。
デザイナーが開発者の負担を減らすためにできること
デザイナーが開発者になる必要はありません。
しかし、いくつかの工夫で受け渡しは格段にスムーズになります。
次のものを活用しましょう。
- オートレイアウト
- コンポーネント
- 一貫した余白
- 適切なレイヤー名
- 明確なタイポグラフィ
- レスポンシブなデザイン
- 整理されたアセット
そして最も重要なのは、
見ただけではわからないことを説明することです。
ホバー時にボタンが変化するなら、それを示しましょう。
モバイルでメニューの挙動が異なるなら、それを伝えましょう。
クリックするとカードが展開するなら、それを記録しておきましょう。
しっかりしたコミュニケーションは、不要な修正にかかる何時間もの手間を省いてくれます。
開発者がプロセスをより良くするためにできること
開発者にも果たすべき役割があります。
ただ次のように聞くのではなく、
「CSSはどこですか？」
こう聞きましょう。
「このコンポーネントは、なぜこのようにデザインされているのですか？」
プロダクトを理解しましょう。
再利用できるパターンを探しましょう。
早い段階からモバイルを意識しましょう。
デザイナーと話しましょう。
元のFigmaと照らし合わせてテストしましょう。
そして、最後になってから何かが動かないと気づくような事態は避けましょう。
「Figmaからコードへ」の本当の意味
Figmaからのコーディングの本質は、デザインを変換することではありません。
アイデアを、人々が実際に使えるものへと形にすることです。
Figmaファイルは、アイデアが目に見える形になる場所です。
コードは、アイデアが機能する形になる場所です。
そしてその2つの間にあるすべての工程が、デザインを本物のデジタルプロダクトへと変えるのです。
ですから、次に誰かがこう言ったら、
「とりあえずFigmaをウェブサイトにしてくれればいいから。」
その言葉の裏で、どれほど多くのことが起きているか、もうおわかりでしょう。
優れたデジタルプロダクトは、ただデザインされるだけではありません。
丁寧に考え抜かれ、つくり上げられるのです。
新着記事を見逃さない
RSSフィードを購読すれば、新しい記事が自動でリーダーに届きます。メール登録もアルゴリズムも不要です。
Feedly、Inoreader、NetNewsWireなど、あらゆるRSSリーダーに対応しています。 フィードを直接表示