デザイン検討はコードで完結するのか──Figmaと使い分ける判断基準《綿貫佳祐のFigma思考ラボ｜Vol.14》

はじめに：デザイン検討はすべてコードで進めてよいのか

コーディングエージェントが進化するにつれて「デザイン検討もすべてコードで進めればよい」という意見を見かけるようになってきました。

私も、最初からコードでつくった方がよい場面は増えていると思います。実際に操作できる画面を作り、複数の案を比較することが、以前より格段に進めやすくなったからです。

私はFriends of Figma Nagoyaのリーダーを務め、この連載でもFigmaについて書いていますが、その立場にいるにもかかわらず、シチュエーションにあわせてコードから始めることもすすめています。

第10回の記事でも、実際に動いている画面が先にあり、Figmaでの検討が後から始まる制作フローについて触れました。このように、2026年10月現在、デザインはまずFigmaでつくるべきだという前提そのものが、見直されつつあるように思います。

ただ、すべてのデザイン検討をコードのみで進めるのが最適とも思いません。

今回は、決まった要素や条件の組み合せを確かめる場合と、問題の捉え方や解決方法から考え直す場合を分けて考えてみます。その違いから、Figma上でつくるのがよい場面、そうでない場面を整理していきます。

本記事で考えたいのは、「Figmaとコードのどちらが優れているか」ではありません。何を判断したいのかによって、つくるものや検討方法が変わる、という点です。

Figma公式の発信から、検討の進め方を考える

この問いを考える上で参考になるのが、FigmaのYuhki Yamashita氏によるWhat matters when anyone can buildという記事です。

この記事では、最初の案を改善し続けるだけでなく、異なる方向性の案を、実際に体験できるところまで具体化して比較する必要がある、といった考え方が示されています。

私がここから考えたいのは、案を何個つくったかに加えて、それぞれの案で何を重視し何を提供できるかです。

ボタンの位置や文字の大きさを変えた案が10個あっても、利用者が確認する情報や操作の流れは結局同じかもしれません。利用者の困りごとによっては、「この情報は操作を始める前に伝えるべきではないか」「この操作自体をなくせないか」と前提から考え直す必要もあります。

つまり、決まった要素の配置を比べることと、必要な情報や操作から考え直すことでは、検討する内容が違います。
その違いによって、比較のためにつくるものや、検証する動作内容も変わるのです。

ここからは具体例を使って、何を検討するために、何をどこまでつくるとよいかを考えてみます。

レシピアプリの調理画面で考えてみる

説明用の例として、レシピアプリを考えてみます。

まず、材料、調理手順、タイマー、次の手順へ進むボタンがある画面を配置するとします。目的は、利用者が「今何をすべきか」と「次に何をすべきか」を迷わず把握できるようにすることです。

必要な要素が決まっているならコードで比較しやすい

まずは、材料・手順・タイマーを表示する方針で、次の2案をつくるとします。

A：全手順を一覧にして、必要な場所を見返せる案

B： 現在の手順を大きく表示し、ボタンで次へ進む案

ここでは、コーディングエージェントに制作を依頼し、チームで実際に操作して比較します。

長い手順でも読みやすいか、前の手順へ戻れるか、タイマーを開始しやすいかなど、確認したい条件をコーディングエージェントに伝えて案をつくります。

既存の部品やデータを使えるなら、実際の表示や操作に近い状態で検討できます。この条件ならコードから始めるメリットが大きいでしょう。

以前であれば、こういった変更のアプローチはエンジニアへの依頼が必要だったかもしれません。しかし今コーディングエージェントを利用できる環境なら、デザイナーやPMだけで変更して確認することができます。

配置を変えるだけでは解決しないこともある

ここまでは、同じ前提の中で配置や操作を比較する検討でした。しかし、検討を進める中で「前提そのもの」を見直したくなることがあります。会議でこの案を見ているうちに「そもそも、利用者は調理中に画面を読み続けられるのか」という疑問が出たとします。

手がふさがっていたり、濡れていたりして、画面を操作する余裕がないかもしれません。
「調理中に画面で必要な情報を探してもらう」という前提から考え直すと、別の解決方法も出てくるはずです。

• 調理前に、必要な材料と作業をまとめて確認してもらう
• 時間になったら、タイマー表示を「火を止める」などの作業案内に切り替える

上記のような検討の結果、これらの案では、利用者にいつ何を確認してもらうかという前提から変わりました。

簡単な画面や操作の流れを並べて考える

必要な画面や操作から考え直すとき、Figmaの操作に慣れたチームなら、簡単な画面や操作の流れを並べ、その場で変更しながら検討できます。

たとえば、ユーザーが「調理前に確認する案」では、材料の一覧と最初に済ませておく作業を並べ、「調理中に案内する案」では、現在の作業とその後に表示する作業案内を並べます。

チームはそれを見ながら、どの時点で何を伝えるかを考えられます。「この作業は調理前にまとめた方がよい」「この画面はなくてもよい」といった意見が出れば、デザイナーが情報を移したり画面を削除したりして、その場で確認できます。

この検討では、各画面の動作までつくる必要はありません。コーディングエージェントに別の解決方法を提案させ、コードで簡単な案をつくることもできます。

どちらを使うかは、どちらがチームで案を変更し、確認しやすいかで判断します。

動かさないと分からないことは動かして確かめる

タイマー表示を作業案内に切り替える場合、表示内容や文字の大きさは切り替わる前後の画面を並べて検討できます。
しかし、調理中の利用者がその変化に気づけるかは実際に試さなければ分かりません。

この段階では、コーディングエージェントに時間経過で表示が切り替わる試作を依頼し、ユーザーテストのように試します。

利用者が案内に気づきにくければ、表示を目立たせるか、情報を伝える方法から考え直すかを検討しましょう。

次の判断のために、何をどこまでつくるか

ここまで見てきたように、重要なのは、次の判断のために何を確かめたいのかです。確かめたいことが決まれば、必要な試作の形や検討方法も見えてきます。

自分たちの仕事でも、次の5点を確認すると、検討方法を選びやすくなります。

確認すること	レシピアプリの例で考えること
何を検討し直すか	材料や手順の配置を比べたいのか、調理中に画面を読む前提から考え直したいのか
どこまでつくれば判断できるか	簡単な画面や操作の流れで十分か、時間経過による表示の切り替えまで必要か
変更内容がどこまで決まっているか	表示条件をまとめて依頼できるか、案を見てから次の変更を考えたいか
誰がどう変更し、確認するか	参加者が直接編集する方が進めやすいか、コーディングエージェントに依頼する方が進めやすいか
環境を変える手間はどれくらいか	別の環境で案をつくり直し、決めた変更を反映する手間をかける価値があるか

これらは、担当者の習熟度や、すでに用意されている環境も関係します。Figmaの操作に慣れていなければ、コーディングエージェントに依頼する方が早い場合もあります。

逆に、変更内容を指示文で説明するより、その場で選んで動かす方が早い場合もあるでしょう。すでにコードで検討が進んでいるなら、Figmaへ移す手間と、決めた変更をコードへ反映する手間も考えます。環境を変えることで得られる利点が小さければ、コードで続ける方がよいでしょう。

手順の表示を比較している途中で「調理前の準備に課題がある」と気づくように、検討する内容は変わります。次に判断したいことが変わったら、つくるものと検討方法も見直します。

まとめ

今回のポイントを整理します。

Figmaを使うかどうかは、自分たちが何を確認したいかから考えるのがよいです。簡単な画面で判断できることはそこで検討し、実際の動作が必要ならつくって確かめる。
そのときの検討に合った方法を選ぶことが大切です。

著者プロフィール

文：綿貫佳祐