Figmaのデータを受け取って実装に進める場面では、指定の細かさや変更の伝わり方が案件によって大きく違うと感じることがあります。行き違いの原因の多くは、Figmaという道具の使い方ではなく、受け渡しの前に決めておく取り決めが無いことにあります。取り決めは指定の範囲・変わったときの伝え方・名前の付け方・確認の順番という4つに分かれ、どれも道具の機能とは別の話です。この記事では、データを受け取って実装する立場から、その4つの取り決めと作る順番を整理します。

1. つまずくのは道具ではなく取り決め

Figmaのファイルを開いた瞬間に、指定の細かさが案件ごとにまるで違うと感じることがあります。ある案件では余白の数値まで指定されているのに、別の案件では配色の使い分けすら決まっていない、という差です。この違いに戸惑った経験を持つ開発者は少なくありません。指定の粗さを、担当者の技量や案件の質の差として受け止めてしまう場面もあります。

この差は、Figmaという道具の熟練度から生まれるのではなく、受け渡しの前に取り決めを作っているかどうかから生まれます。UI・UXに関わる専門人材が在籍している企業は、日本では20.8%にとどまり、他国の55%から70%という水準と比べると低い状態です¹。

指定の粒度が案件ごとに揺れる理由

専門人材が常に在籍しているわけではないため、指定の理由をその場で説明できる人がいない案件も珍しくありません。指定の粒度が案件ごとに揺れる背景には、この体制の違いがあります。道具の機能を覚えるよりも、指定が届いていない部分をどう埋めるかという取り決めのほうが、実装を進めるうえでの差になります。

技術情報の収集についても、体系的な仕組みを持たず、個人の判断に任されている企業が多いという結果が示されています⁹。担当者ごとに参照する資料や慣習が違えば、Figma上の指定の残し方も自然とばらつきます。指定が薄い部分を放置するのではなく、どこまでが指定でどこから先は実装側の判断かを、案件に入る前に確かめておく発想に切り替えられます。

受け渡しの取り決めを4つに分けて考える

受け渡しでつまずく場面を整理すると、指定の範囲・変わったときの伝え方・名前の付け方・確認の順番という4つの取り決めに集約されます。どれか1つだけを整えても行き違いは残るため、4つをひとまとまりの取り決めとして扱う考え方です。1つの取り決めが抜けていると、他の3つを整えていても、その抜けた部分で確認の往復が発生します。

次の章からは、この4つを順番に見ていきます。まずは、Figma上でどこまでが指定でどこからが実装側の判断かという、範囲の線引きから確かめます。

図の作成：Remogu編集部。受け渡しの取り決めを4つに整理したもので、統計データではありません

2. どこまでが指定かを決める

Figma上に置かれた数値は、そのまま実装してよい指定なのか、参考程度の目安なのかが分からないまま作業が進むことがあります。この判断を都度その場で行うと、担当者ごとに解釈が変わり、あとから直しが発生します。同じファイルを見ていても、指定として受け取るか目安として受け取るかは、人によって割れます。

UI・UXに関わる専門人材が在籍している企業は日本で20.8%にとどまります¹。指定の理由を説明できる人がいつも近くにいるとは限らないため、指定の範囲を後から都度確認するのではなく、案件のはじめに項目ごとの扱いを取り決めておく方が、双方の手間が小さくなります。

指定されやすい項目と、実装側の判断に委ねられやすい項目を分けて見る

指定の範囲は、項目ごとに揺れの大きさが違います。主要な配色や基準となる余白の数値は指定として残っていることが多い一方、状態が変化したときの微妙な階調や、想定を超えた文字数への対応は、実装側の判断に委ねられやすい部分です。下の表は、その傾向を項目ごとに整理したものです。

項目	指定として残っていることが多い部分	実装側の判断に委ねられやすい部分
色	主要な配色とその適用箇所	状態が変化したときの微妙な階調
余白・間隔	主要画面の基準となる数値	例外的な並びでの調整幅
テキストの折り返し	想定される文字数の目安	実際の文言が想定を超えた場合の扱い
UI部品の見え方の変化	通常時と選択時の見え方	通信待ちやエラー時の見え方
画面幅ごとの見え方	主要な画面幅での配置	その中間の画面幅での挙動

判断に委ねられた部分こそ、先に言葉で残しておく

右側の欄に並ぶ項目は、指定が無いことが問題なのではありません。誰の判断に委ねるかが決まっていないことが問題です。実装側の判断で進めてよいと最初に取り決めておけば、都度確認する手間が減ります。逆に判断の権限がどちらにも無いまま進めると、完成後にやり直しが起きやすくなります。誰も判断していないまま形になった部分は、あとから見返したときに理由を説明しづらくなります。

取り決めの文書は長くある必要はありません。表の右側にある項目について、実装側の判断で進めてよいという一文があるだけで、確認の往復は目に見えて減ります。次の章では、この取り決めた内容が変わったときの伝え方を見ていきます。

出典：総務省「令和7年版 情報通信白書（デジタル活用の動向）」（2025年7月）をもとに作成

3. 変わったときの伝え方を決める

指定の範囲を決めても、途中で内容が変わる場面は出てきます。問題になりやすいのは変更そのものではなく、変更がどう伝わったかという部分です。ファイルが更新されているのに気づかず、古い指定のまま実装を進めてしまうことがあります。気づいたときには複数の画面に手直しが広がっている、という展開も珍しくありません。

モジュール性やデータモデルを意識した設計に取り組む企業は、利用する側を中心に依然として少ない状態です³。設計の土台がその都度組み直されやすい環境では、変更の影響範囲が読みにくく、伝え方を仕組みとして決めておく必要が大きくなります。

気づかれやすい伝え方と、見落とされやすい伝え方

同じ変更でも、伝え方によって気づかれる確率は大きく変わります。ファイルを更新するだけで済ませると、通知に埋もれて見落とされがちです。変更箇所をコメントで指し示し、影響する画面をまとめて共有すると、見落としは減ります。下の表は、変更の種類ごとに伝わりやすい方法を整理したものです。

変更の種類	気づかれやすい伝え方	見落とされやすい伝え方
色の置き換え	ファイル内のコメントと合わせて知らせる	ファイルの更新だけで済ませる
文言の変更	変更箇所をコメントで指し示す	全体の見た目に大きな差が出ないため気づかれにくい
レイアウトの調整	影響する画面をまとめて共有する	一部の画面だけ直して他を後回しにする
UI部品の追加	追加した理由も合わせて伝える	追加した事実だけを伝える

API連携の意識が高くても、伝え方までは揃わない

APIの活用や標準的なデータの形式をそろえることは、作る側の企業を中心に意識が高いという結果があります²。ただし、これはデータの受け渡し方についての傾向であり、変更が起きたときにどう知らせるかという運用の型までは含みません。仕組みが近くても、伝え方の取り決めは別に必要になります。

変更の伝え方を取り決めるときは、誰が・いつ・どの範囲を知らせるかの3点をあらかじめ言葉にしておくと、後から曖昧になりません。次の章では、この伝え方とも関わる、名前の付け方の揃え方を見ていきます。

4. 名前の付け方を揃える

Figma上のレイヤー名と、実装側で使う名前が一致していないと、変更が起きるたびにどこを指しているのかを探す時間がかかります。名前の付け方は地味な取り決めですが、確認の回数に直結します。

モジュール性やデータモデルを意識した設計に取り組む企業は、利用する側を中心に依然として少ない状態です³。設計の単位が事前に整理されていない環境では、Figma側の名前と実装側の名前が別々に育ちやすく、あとから揃えるほど直しの量が増えます。

呼び方の起点をどちらに置くか決める

名前を揃えるとき、Figma側の呼び方に実装側を合わせるのか、実装側の呼び方にFigma側を合わせるのかを、案件のはじめに決めておきます。どちらが正しいかという話ではなく、片方を起点にすると決めておくことが目的です。起点が決まっていないと、修正のたびにどちらの呼び方を残すかで小さな確認が繰り返されます。小さな確認は1回ずつは短くても、案件全体で積み重なると無視できない時間になります。

意識の高さと、実際にそろっているかは別の話

APIの活用や標準的なデータの形式をそろえることは、作る側の企業を中心に意識が高いという結果があります²。しかし意識の高さと、実際に名前が揃っているかどうかは別の話です。標準的な形式を扱う意識があっても、Figma上の名前と実装側の名前は自動的には一致しません。名前を対応づける作業は、意識とは別に、誰かが手を動かして残す必要があります。

名前の対応表を1枚用意し、変更が起きるたびに更新していく方法は手間がかかるように見えますが、確認のやり取りにかかる時間を積み上げて比べると、対応表を持つ方が早く進みます。次の章では、この名前の取り決めとも関わる、確認する順番を見ていきます。

5. 確認の順番を決める

受け渡しの確認は、何から見るかによって手戻りの量が変わります。細部の数値から確認を始めると、後で全体の構成が変わったときに、確認した内容がまるごと無駄になることがあります。反対に、全体から入ると細部の調整は最後にまとめて片づけられます。

利用する側の企業は、システムの品質を最も優先する事項として捉えているという結果があります⁴。品質を優先するなら、細部よりも先に、全体の構成と主要な画面から確認する順番の方が、後戻りの少ない進め方になります。

大きな枠から確認すると、直しの手間が小さくなる

確認する順番は、全体の構成、主要な画面、例外的な状態、細部の数値という流れが後戻りを抑えます。大きな枠を先に固めておくと、細部の調整は枠の中だけで完結し、やり直しの範囲が広がりません。下の表は、順番ごとに起こりやすいことを整理したものです。

確認する順番	内容	後回しにしたときに起こりやすいこと
全体の構成	画面同士のつながりと導線	個別の画面を直したあとに構成ごと変わる
主要な画面	使用頻度の高い画面の指定	細部を詰めたあとに主要画面の解釈違いが分かる
例外的な状態	エラーや空の状態の指定	開発の終盤で想定外の状態が見つかる
細部の数値	余白や文字サイズの微調整	大枠が変わるたびに細部をやり直す

データの利活用の方針が固まっていない案件ほど、順番が効く

データ利活用に関する方針を明確にしている企業は少なく、対応の遅れが目立つという結果が示されています⁸。方針が固まっていない案件では、途中で全体の構成が変わる可能性がもともと高いため、先に細部を詰めてしまうと、やり直しの起点が読みにくくなります。

確認の順番を先に取り決めておけば、方針が途中で変わったときも、どこまでの確認が生きていてどこからやり直すかがすぐに分かります。次の章では、確認の前提となる、見る端末のそろえ方を見ていきます。

6. 見る端末の前提を合わせる

Figma上の画面をパソコンの大きな画面で確認し続けていると、実際の利用場面とのずれに気づきにくくなります。確認する端末の前提をそろえておくことも、受け渡しの取り決めの一つです。制作の場では大画面で見ていても、実際に触れる場面はそれとは違う端末であることが多くあります。

スマートフォンの利用率は74.4%で、パソコンの46.8%を27.6ポイント上回っています⁷。この差を踏まえると、パソコンの大きな画面だけで確認を終えるのではなく、スマートフォンでの見え方を確認の起点に置く方が、実際の利用場面に近づきます。

確認する画面幅を、案件のはじめに言葉にしておく

どの画面幅で確認するかを取り決めておかないと、パソコンでは問題なく見えていたものが、スマートフォンでは文字が詰まって見えるといった食い違いが起きます。確認する画面幅の候補をいくつか決め、そのすべてで見え方を確かめる順番を、案件のはじめに言葉にしておきます。

専門人材が近くにいない前提で、取り決めを明文化する

AI・データ解析の専門家が在籍している企業の割合も、日本では20.6%にとどまり、他国の65%から80%という水準と比べると低い状態です¹⁰。専門の知見を持つ人が近くにいない前提に立つと、端末の前提のような細かな取り決めほど、言葉にして残しておく価値があります。

確認する端末が揃っていれば、指定の範囲や伝え方の食い違いも、同じ画面を見ながら話し合えます。次の章では、ここまでの4つの取り決めをどの順番で作っていくかを見ていきます。

出典：総務省「令和7年版 情報通信白書（デジタル活用の動向）」（2025年7月）をもとに作成

7. 取り決めを作る順番

ここまで見てきた4つの取り決めは、すべてを一度に揃える必要はありません。案件のはじめにどの順番で言葉にしていくかを決めておくと、限られた時間の中でも抜け漏れが少なくなります。順番を決めずに手をつけると、話しやすい項目から埋めてしまい、影響の大きい項目が後回しになりがちです。

ノーコードやローコードは、一部の利用を含めると全体の約4割の企業が取り入れています⁵。使う仕組みが案件によって違えば、指定の粒度や名前の管理方法の前提も変わるため、まず指定の範囲から取り決め、その次に伝え方、名前の付け方、確認の順番へと進める流れが土台になります。

クラウドやAPIの導入は片側だけで進んでいることがある

クラウドやAPIの導入は、作る側の企業を中心に比較的進んでいます⁶。作る側の仕組みが先に整っていても、利用する側の体制が同じ速さで整うとは限らないため、指定の範囲と伝え方の2つを早い段階で取り決めておくと、双方の前提の差を埋めやすくなります。仕組みの整い方に差があること自体は珍しくなく、差があることを前提に取り決めを作るほうが現実的です。

名前の付け方と確認の順番は、指定の範囲と伝え方が固まったあとに取り決める方が、話がかみ合いやすくなります。呼び方の起点や確認の流れは、何を指定するかが決まっていないと具体的に言葉にしづらいためです。

4つの取り決めを一通り作ったあとは、案件が進む中で見直す機会を設けておきます。取り決めを自分たちで整えられる体制は、稼働する場所を選ばない働き方とも相性の良い進め方です。案件の90%以上がフルリモート可能です。

図の作成：Remogu編集部。取り決めを作る順番の一例を整理したもので、統計データではありません

指定が無い部分は、どちらの判断で進めることが多いのですか

指定の範囲を取り決めておけば、指定が無い部分は実装側の判断で進めてよいと最初から決めておけます。取り決めが無いまま進めると、都度確認が必要になり、確認する側にも答える側にも手間がかかります。判断の権限をどちらに置くかを最初の1回で言葉にしておけば、以降は同じ確認を繰り返さずに済みます。

名前の付け方は、デザイン側と実装側のどちらに揃えるとよいのですか

どちらに揃えても進められますが、案件のはじめにどちらを起点にするかだけを決めておきます。途中で起点を変えると、対応表の更新が追いつかなくなり、名前の食い違いが積み重なります。起点を決めたあとは、変更のたびに対応表へ反映する担当も合わせて決めておくと、対応表そのものが古くなりません。

確認の順番を変えると、進め方はどう変わるのですか

全体の構成と主要な画面から確認すると、細部の調整はその枠の中だけで完結します。逆に細部から確認を始めると、あとで全体が変わったときに、確認した内容ごとやり直すことになりやすくなります。順番を先に取り決めておけば、どの段階まで確認が済んでいるかも共有しやすくなります。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 総務省「令和7年版 情報通信白書（デジタル活用の動向）」設計する人の不在（2025年7月・2026年8月確認）
＊2 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」つなぎ目の意識（2025年4月・2026年8月確認）
＊3 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」境界の不在（2025年4月・2026年8月確認）
＊4 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」評価の軸（2025年4月・2026年8月確認）
＊5 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」書かない選択（2025年4月・2026年8月確認）
＊6 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」進んでいる領域（2025年4月・2026年8月確認）
＊7 総務省「令和7年版 情報通信白書（デジタル活用の動向）」使う道具の偏り（2025年7月・2026年8月確認）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」方針の遅れ（2025年4月・2026年8月確認）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」知識の持ち方（2025年4月・2026年8月確認）
＊10 総務省「令和7年版 情報通信白書（デジタル活用の動向）」専門家の不在（2025年7月・2026年8月確認）