デザイナーから届いた指定書を前に、どこまで指定どおりに手を動かし、どこから自分の判断で形を変えてよいのかで迷う場面があります。指定に理由が書き添えられているときと、結果だけが示されているときとでは、実装側が持つ判断の重さがまったく違います。この記事では、判断の所在がどこで分かれるのかを、指定の性質から順に整理します。受け渡しの現場でくり返し起きる迷いを、判断の型として持ち帰れるようにまとめました。

1. 判断は二択ではない

指定の背後にある体制の違い

受け渡された指定に沿って手を動かしていると、指定どおりに進めるべきか、自分の判断で形を変えてよいのかで迷う場面が出てきます。指定書の文言だけを追いかけていても、この迷いは解けません。

日本でUI・UXに関わるデザイナーが在籍している企業は20.8%にとどまり、他国では約55%から約70%という水準です¹。指定の背後に専任の担当者がいない体制も珍しくなく、渡された情報だけでは意図の全体を読み取れない場面が生まれます。

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

利用する側が優先しているもの

実装側の判断は好みで動かすものではなく、利用する側が置いている前提とすり合わせるものです。利用する側の企業は、システムの品質を最も優先する事項として捉えています⁵。

見た目の再現度よりも、動作の安定や使い続けられることが評価の軸になりやすいということです。指定の意図に迷ったときは、この優先順位を判断の物差しに置き直すと選びやすくなります。

指定を「勝手に決める」か「全部そのまま受ける」かの二択で捉えると、この物差しを使う場面を見落とします。実装側に求められているのは、どちらか一方を選ぶことではなく、指定の性質を見分けることです。

この見分け方は、案件ごとに繰り返し使える型になります。関わる案件が変わっても、指定に理由が付いているかどうかを最初に見るという手順そのものは変わりません。

指定を出す側の体制や優先順位は、案件によって異なります。判断の型を持っておくと、体制の違う相手と組むときも、確認する順番だけは崩さずに進められます。

たとえば、余白の広さだけが指定され、その理由が書かれていない場面があります。ここで確認したいのは余白の数値そのものではなく、その余白がどんな見え方を支えようとしているのかという前提です。数値を守ることと、意図をくみ取ることが、同じ行動とは限りません。

指定の理由が書かれているかどうかを最初に確認する習慣をつけておくと、迷う場面に出会ったときの最初の一歩が決まります。何を見ればよいかが分かっているだけで、判断にかかる時間は変わります。

指定の文言を追いかけるより、指定が守ろうとしている前提を見るほうが、判断の芯が通ります。次の章では、その前提が言葉として残っているかどうかで対応がどう分かれるかを整理します。

2. 理由が付いているかで分かれる

指定に理由が書かれているかどうかは、実装側が持てる判断の範囲を大きく左右します。ここでは、理由がある指定とない指定で何が変わるのかを比較します。

作る側が意識してきたこと

実装側は、標準的なデータの形式をそろえることや外部との接続のしやすさに関心を向けてきました。APIの活用や標準的なデータの形式をそろえることは、作る側を中心に意識が高いという傾向があります³。

この意識の高さは、指定に理由が添えられている場面で力を発揮します。理由が分かれば、形を保ったまま実現方法だけを選べるからです。指定の意図を壊さずに済むという意味で、実装側にとって動きやすい状況です。

作る側の意識の高さは、渡された指定をそのまま鵜呑みにしないという姿勢にもつながります。理由が書かれていない部分に気づいたら、それを推測で埋める前に、確認できる相手を探すという選択も残っています。

標準的なデータの形式に沿って実現方法を選べる場面が多いほど、指定の意図から外れずに済みます。この積み重ねが、次に似た指定を受けたときの判断の速さにつながります。

理由の有無で変わること

一方で、モジュール性やデータモデルを意識した設計に取り組む企業は、特に利用する側を中心に依然として少ないという実態があります²。設計の意図が言葉として残らないまま指定だけが渡される場面が生まれる理由の一つです。

指定に理由が付いているかどうかは、指定書の書式だけでは判断できません。理由が省かれているのか、そもそも検討されていないのか、あるいは前提が別の資料にあるのかによって、実装側が確かめる相手も変わります。ここでは、理由がある指定とない指定とで、実装側の役割や確認すること、変えてよい範囲、記録に残すことがどう違うかを整理します。

観点	理由が付いている指定	理由が無い指定
実装側の役割	形を保ったまま実現方法を選ぶ	判断そのものを引き受ける
確認すること	理由の妥当性	前提や利用する側の意図
変えてよい範囲	手段や実現方法	見た目や構成を含む場合がある
記録に残すこと	選んだ手段とその根拠	推測した前提と選んだ理由

理由が付いている指定では、実装側の役割は手段を選ぶことに絞られます。理由が無い指定では、この役割の範囲そのものが変わります。次の章では、理由が無いときに実装側が持つことになる判断を具体的に見ていきます。

3. 理由が無いときに来る判断

理由が付いている指定では実装側は手段を選びます。理由が無い指定では、その先の判断までもが実装側に委ねられます。ここでは、理由が無いときに実装側が実際に持つことになる判断を具体的に見ていきます。

図の作成：Remogu編集部。判断の所在の違いを整理したもので、統計データではありません

専任者がいない場面で起きること

実装側に判断が委ねられやすいのは、そもそもUI・UXに関わる専任のデザイナーが少ない体制が背景にあります。日本でこうした担当者が在籍している企業は20.8%にとどまります¹。指定を出す側に確認できる相手が限られる場面では、実装側が判断を引き受ける機会が増えます。

判断を引き受けること自体は良くも悪くもありません。ただし、何を根拠に判断したのかが残らないまま進むと、後から同じ場面が来たときに毎回考え直すことになります。

確認する対象を先に決めておく

技術情報の収集は体系的な仕組みを持たず、個人に委ねられている企業があります⁹。指定に添える理由も、担当者個人の知識の範囲で書かれることになりやすく、書かれなかった前提が抜け落ちたまま渡されることがあります。

この抜け落ちが起きたとき、実装側が持つ判断は「指定を守るか変えるか」ではなく、「抜けている前提をどう補うか」です。下の表のように、理由が無い場面で実装側が確かめる対象を先に決めておくと、判断が揺れにくくなります。理由が無い指定は、担当者の知識がそのまま言葉にならなかった結果である場合があるという前提に立つと、確かめる相手や資料を絞りやすくなります。

確認する対象を決めておくと、記録に残す内容も自然に定まります。何を確かめ、何が分からなかったのかを短く書き添えるだけで、次に同じ場面に立つ人の助けになります。同じ確認を二度くり返さずに済むという意味でも、この記録は役に立ちます。

理由が無い指定に何度も出会う場合は、確認する相手や資料をあらかじめ一覧にしておくと、その都度探す手間が減ります。指定を出す側にとっても、聞かれる内容がいつも同じであれば、答えやすくなります。

場面	実装側が持つ判断	確認する対象
見た目の一部が指定と異なって見える	変えてよい範囲かどうか	過去のやり取りや近い指定
複数の実現方法が考えられる	どれを選ぶか	品質を優先する前提
指定が想定していない端末や場面がある	対応するかどうか	実際の端末の使われ方
情報の一部が欠けている	補って進めるかどうか	情報が作られた経緯

理由が無い指定に出会ったときは、まず何を確認すれば判断できるのかをこの表の型で当てはめてみます。次の章では、端末の使われ方という別の前提を見ていきます。

4. 端末の前提を合わせる

使われ方の偏りを踏まえる

指定書に書かれた画面が、実際にどの端末で見られるのかは、指定そのものには書かれていないことがあります。スマートフォンの利用率は74.4%で、パソコンの46.8%を27.6ポイント上回っています⁶。

この差は、指定が想定していた画面と、実際に使われる端末との間にずれを生みやすい要因です。理由が書かれていない指定に出会ったときは、まずこの前提がそろっているかを確認する価値があります。

画面の幅や余白の指定が、狭い画面での見え方まで想定しているとは限りません。実際の使われ方に合わせて調整する余地を残しておくと、後から手戻りが起きにくくなります。指定の数値をそのまま当てはめる前に、狭い画面での見え方を試しておく価値があります。

指定に幅を持たせる余地があるかどうかも、この前提から考えられます。表示の崩れに強い作り方を選べるかどうかは、実装側が持てる判断の一つです。

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

働き方の広がりも前提に含める

新しい働き方の実現に向けた取組は、全社的な広がりを見せています⁸。テレワークのような働き方の広がりは、画面を見る場面や時間帯の幅を広げる要因にもなります。

働き方が広がるほど、画面を見る環境も一様ではなくなります。指定が想定していなかった環境が後から出てくることを前提に、余白や配置には多少の幅を持たせておきたいところです。

端末や働く場所の前提は、指定書が作られた時点で止まっています。実装側が実際の使われ方を持ち寄ることで、指定の前提を今の状況に合わせて更新できます。

指定が作られた時期によっては、こうした前提が十分に反映されていないこともあります。実装側が端末や利用場面の前提を確認する役割を担う場面が増えているのは、この背景があるからです。

端末の前提は、指定書の文面ではなく実際の使われ方から読み取るものです。次の章では、品質を最優先に置くという、もう一つの前提を見ていきます。

5. 品質が最優先という前提

優先順位のずれが起きる理由

利用する側の企業は、システムの品質を最も優先する事項として捉えています⁵。見た目の再現度が高くても、動作が不安定であれば評価は上がりません。

この優先順位は、指定の細部を判断する場面でも基準になります。理由が書かれていない部分ほど、この優先順位に沿って埋めることになります。品質を優先するという前提は、見た目の完成度だけでなく、時間が経ってからの安定にも及びます。指定された見た目を保ちながら、その先の使われ方まで意識する視点が求められます。

一方で、データ利活用に関する方針を明確にしている企業は少なく、対応の遅れが目立ちます⁷。優先順位は分かっていても、それを支える方針や体制が追いついていない場面があるということです。

対応の遅れが目立つという実態⁷は、方針が定まりきる前に指定が渡ってくる場面があることも示しています。実装側が確認する価値があるのは、この方針がどこまで固まっているかという点です。

方針が固まっていない段階で渡された指定は、後から前提が変わることも想定しておきたいところです。変更が入ったときにどこまで作り直しになるかを、あらかじめ見立てておくと落ち着いて対応できます。

見た目を優先した進め方との違い

見た目の再現度を優先する進め方と、品質を優先する進め方とでは、同じ指定を前にしても途中で選ぶ手段が変わります。下の表は、それぞれの優先順位でどこに時間を使い、迷ったときに何を基準にするかを整理したものです。指定に理由が書かれていない場面ほど、この基準の置き方が判断の分かれ目になります。

観点	見た目を優先する場合	品質を優先する場合
時間の配分	細部の再現に多く割く	動作確認や検証に多く割く
迷ったときの基準	指定書の見た目に合わせる	安定して使い続けられるかで選ぶ
変更への向き合い方	見た目を崩さない範囲で調整する	前提を確認してから調整する

どちらの優先順位も指定書には明記されないことがあります。判断に迷ったときは、利用する側が置いている優先順位を先に確かめておくと、途中の判断がぶれにくくなります。次の章では、作らないという選択も含めて判断の幅を広げます。

6. 作らない選択もある

一部を組み合わせで済ませる考え方

ノーコードやローコードは、一部の利用を含めると全体の約4割の企業が取り入れています⁴。指定のすべてを個別に作り込まなくても、組み合わせで実現できる部分があるという前提です。

実装側にとっては、どこまでを個別に作り、どこから組み合わせで済ませるかも判断の一つです。指定に理由が書かれていない場合は、この境目も含めて確認する対象になります。

組み合わせで済ませるかどうかを判断する場面では、後からの変更のしやすさも合わせて考えます。個別に作り込むほど自由度は増えますが、その分だけ後の調整にも手間がかかります。

どちらを選ぶかの正解は指定書には書かれていません。品質を優先するという前提に立ち戻り、更新のしやすさと作り込みの度合いをてんびんにかけて選びます。

組み合わせで済ませる判断は、見た目だけでなく、その後の更新のしやすさにも関わります。ここも、品質を優先するという前提と合わせて考える部分です。

人材不足という制約を前提に置く

デジタル化の課題として、人材不足を挙げる企業の割合が最も大きくなっています¹⁰。指定を出す側の体制に余裕が無い場面では、判断を持ち帰って進める場面がこれまで以上に増えます。

作らない選択を含めて判断するという発想は、手を抜くこととは違います。限られた体制の中で、どこに力を割くかを実装側が一緒に考える役割です。

人材不足という制約は、実装側だけの事情ではありません。指定を出す側も同じ制約の中で動いているという前提に立つと、判断を持ち帰る場面を前向きに引き受けやすくなります。

限られた体制を前提に置くと、指定に書かれていない部分は「漏れ」ではなく「委ねられた範囲」として見えてきます。この見え方の違いが、判断を引き受ける姿勢を後押しします。

組み合わせで済ませる部分と、個別に作り込む部分を分けて考えると、判断の範囲が整理しやすくなります。次の章では、ここまでの判断を確かめる順番をまとめます。

7. 判断の所在を確かめる順番

確かめる順番を決めておく

ここまで見てきた判断は、指定に出会うたびに一から考え直すものではありません。確かめる順番を先に決めておくと、迷う時間そのものが減ります。

まず理由が付いているかどうかを見ます²。次に、標準的なデータの形式やAPIの活用など、作る側が意識してきた前提³に照らします。理由が見当たらないときに初めて、実装側が判断を引き受けます。

図の作成：Remogu編集部。確認の順番を整理したもので、統計データではありません

この順番を踏まえたうえで、現場でよく挙がる疑問を2つ取り上げます。

理由が書かれていない指定にはどう対応しますか

前提を推測できる別の資料や、近い指定が無いかをまず確認します。見当たらない場合は、品質を優先する前提⁵に沿って手段を選び、選んだ理由を記録に残します。記録があれば、次に似た場面が来たときの確認が早くなります。

判断の理由はどこまで詳しく残せばよいですか

何を優先してその手段を選んだかが分かる程度で足ります。指定と異なる部分がある場合は、その範囲と理由を短く添えておくと、後から確認する側も追いやすくなります。

指定と異なる実装をしても良い場面はありますか

理由が無い指定で、実際の端末の使われ方や品質を優先する前提と食い違う場合です⁶。その場合も、変更した範囲と理由を残しておくと、後から確認する側が判断の経緯を追えます。

判断の順番が整理できたら、次はその判断を活かせる案件に触れてみることです。自分がこれまで担ってきた判断の範囲と、案件ごとの前提を照らし合わせてみましょう。

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

出典・参考情報

＊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 総務省「令和7年版 情報通信白書（デジタル活用の動向）」使う道具の偏り（2025年7月・2026年8月確認）
＊7 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」方針の遅れ（2025年4月・2026年8月確認）
＊8 総務省「令和7年版 情報通信白書（デジタル活用の動向）」取組の中身（2025年7月・2026年8月確認）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」知識の持ち方（2025年4月・2026年8月確認）
＊10 総務省「令和7年版 情報通信白書（デジタル活用の動向）」最大の課題（2025年7月・2026年8月確認）