1. 仕様の丸投げが招く「利益減少」と「スケジュール遅延」の悪循環
「デザインはできたので、あとはコーディングお願いします！」
──そう言われて作業に入ってみると、実は重要な仕様が何も決まっていない。
現場ではこれが思いのほか頻繁に起こります。
本来、デザインとあコーディングは別の工程ですが、
仕様が曖昧なまま渡されると、
その不足分を補うのはコーダーの役割になってしまいがちです。
そして、ここから“悪循環”が始まります。
（１）隠れていた技術要件が後から見つかる
たとえば「1ページだけの静的LP」と聞いていたのに、カンプを確認すると“新着情報”のブロックがあり、クリックすると投稿ページが必要そうな構成に見える──。
こうなるとコーダーは「これは静的HTMLでは成立しない」と判断します。
・投稿機能が必要
・となるとWordPressなどCMSの導入が必要
・WordPressを入れるなら、初期セットアップやテーマ調整も必要
・投稿ページ、アーカイブページのレイアウトも決める必要がある
……という具合に、当初の「1ページ」では収まらなくなるのです。
（２）想定のズレが“見積もり差額”としてのしかかる
デザイナーとクライアントが「10万円くらいでいけるはず」と思っていたのに、
実際に必要な工数を積み上げると、
その倍以上になることも珍しくありません。
仕様が増える → コーダーの作業が増える → 見積もりに上乗せが必要
この上乗せ分はデザイナーの利益率を圧迫します。
（３）スケジュールも同時に崩れていく
仕様が増えた分だけ作業期間も延びます。
デザイナーもコーダーも、その案件に拘束される時間が長くなり、
次の仕事に着手するタイミングが後ろ倒しに。
その結果、
・全体の生産性が落ちる
・クライアントへの納期もずれ込む
・信用にも影響する
という、まさに負の連鎖に突入します。
仕様の丸投げは、デザイナーの利益率とプロジェクト全体のスケジュールの
両方を確実に損なう行為です。
だからこそ「どこまで決める？」「どこからがコーダーの領域？」を
事前に明確にしておくことが重要なのです。
2. フッター・リンク先・追従ヘッダー…よくある仕様の“抜け漏れ”とは？
デザインが一通り完成したように見えても、
いざコーディングに進もうとすると「決まっていない仕様」が
次々に発覚することがあります。
そして、その多くは“デザイナーが気付きにくいけれど、
実装では必ず必要になる要素”です。
ここでは 現場で頻出する“抜け漏れ” を押さえておきましょう。
（１）フッターのリンク先が決まっていない
フッターは「とりあえずデザインに入れておく」パーツの代表格ですが、
リンク先をどうするかが決まっていないケースが非常に多いところです。
・利用規約
・プライバシーポリシー
・特定商取引法
・お問い合わせ
・会社概要
これらのページが存在しない場合、
・そもそも誰が作る？
・どの内容を掲載する？
・リンクは空欄のままでよい？
など、判断が必要になる項目が山ほどあります。
(2)主導ボタン（CTA）をクリックした後の導線が未決定
「資料請求」「予約」「お問い合わせ」など、
CTA ボタンだけ先にデザインされていて、
その先の導線（遷移先のページ）が用意されていない。
これもよくあるパターンです。
・フォームを新しく作るのか
・別サービスのフォームに飛ばすのか
・外部サービスとつなぐなら、どんな項目が必要なのか
こうした情報なしではコーダーは作業を開始できません。
(3)追従ヘッダー（固定ヘッダー）の仕様が曖昧
デザインの静止画では「追従かどうか」が判別できません。
そのため、以下の点が明確でないと実装できないのです。
・固定表示なのか
・スクロールすると縮むのか
・背景は透過か、下地色を変えるのか
・スマホ時は固定か、通常表示か
これらは挙動の話なので、デザイナー側が説明し忘れがちですが、
コーダーからすると実装コストに直結する非常に大きなポイントです。
(4)メニュー・アコーディオンなど「動き」が未定義
スマホメニューの開閉や、アコーディオンの挙動など、
静止画だけでは決定できない仕様は意外と多いものです。
・開閉時のアニメーション速度
・折りたたまれた状態の高さ
・開く位置（右側？ 左側？）
・アイコンは「＋／−」か「∨／∧」か
ここが曖昧だと、
「思っていたのと違う」「やっぱり別の動きにしてほしい」
と後から修正が発生してしまいます。
(5)よくある抜け漏れは“小さな項目のようで大きな工数”
これらの要素は、デザイン上は目立たないことが多く、
つい後回しにされるのですが、
実装の工数に直結するものばかりです。
そして、抜け漏れた仕様は後から必ず戻ってきます。
・手戻りが発生
・スケジュールが圧迫
・コーダーの負担が増える
・デザイナーの利益率が下がる
──まさに「1. 仕様の丸投げが招く「利益減少」と「スケジュール遅延」の悪循環」で書いた悪循環につながるわけですね。
3. 静止画のカンプでは伝わらない“動き・挙動”こそ事前に決めるべき理由
デザインカンプはあくまで「静止画」です。
視覚的なレイアウトを伝えるには十分ですが、
実際のサイトでは必ず“動き”が発生するため、
静止画だけではコーダーが判断できない領域が多くあります。
ここを曖昧なまま進めると、
「思っていたのと違った」「やり直してほしい」という手戻りの原因になり、
制作時間・コストのどちらにも深刻な影響を与えてしまいます。
（１）スクロール時の動きは静止画では判断できない
スクロールに連動する挙動は、実装の手間が大きく変わる領域です。
たとえば：
・セクションがふわっとフェードインする
・ヘッダーが縮む／背景色が変わる
・要素が右からスライドしてくる
・数字がカウントアップするアニメーション
こうした動きは、静止画だけでは全く読み取れません。
「ただ表示されているだけ」に見えるからです。
その結果、コーダーは “動きなし” と判断して見積もりを出しますが、
後から「実は動かしたい」と分かると追加工数が発生し、
見積もりがズレてしまいます。
(2)ホバー時・クリック時のリアクションも要確認
静止画では hover（マウスオーバー）時の変化は表現できません。
・ボタンが大きくなる
・色が変わる
・下線がスッと伸びる
・アイコンが回転する
これらは“地味だけど意外と工数がかかる”動きです。
また、
・クリックして開くのか
・ホバーしただけで開くのか
・スマホではどうするのか
こうした挙動もデザインの仕様として決めておく必要があります。
(3)アコーディオンやモーダルなどは仕様の詳細が不可欠
以下のようなUIは、見た目より“動きの仕様”が重要です。
・アコーディオン
・ハンバーガーメニュー
・モーダルウィンドウ
・タブ切り替え
たとえばアコーディオンひとつでも、実装方式は複数あります。
・最初から全部閉じておく？
・一つだけ開いた状態から始める？
・複数同時に開ける？
・開閉のアニメーション速度は？
ここを事前に決めておかないと、
「やっぱりこうしてほしい」が何度も発生し、
作業が長期化します。
(4)動きは“作る前に決める”ほど効率が良くなる
挙動が後から発覚すると、
コーダーは既に書いたコードを大きく書き換える必要があり、
手戻りのコストがとても高くなります。
・HTML の構造を変える必要がある
・CSS の組み直しが必要
・JavaScript を追加で書く必要がある
・他の動作に影響が出る可能性も
つまり、
動きを後から追加するほど、
負担とリスクは雪だるま式に増えていくのです。
(5)「動き」はサイト全体の印象に直結する重要要素
もうひとつ大きなポイントがあります。
動きは“ブランド感”や“高級感”を演出する要素でもあること。
静止画では伝わらないけど、
実際のサイト体験では“動き”が印象の大部分を占めていることが多いのです。
だからこそ、
・どう動くのか
・どれくらいの速度で
・どんな曲線で
・どのタイミングで
を事前に決めることが、
「期待通りのサイトを作る」ためには欠かせません。
4. デザインとコーディングの領域を誤解して発生するトラブル
制作現場では、デザイナーとコーダーが互いに担当する領域を誤解していることで、本来必要のないトラブルや手戻りが生まれることがよくあります。
これはどちらかが悪いわけではなく、
“何をどこまでデザイナーが決めるべきか”
が曖昧なまま進行することが原因です。
(1)「デザインされていない部分」は、コーダーが勝手に判断するしかない
デザイナーが作るカンプは、必ずしもページの全てをカバーしていません。
たとえば：
・404ページ
・投稿一覧ページ
・ブログのカテゴリ・タグページ
・プライバシーポリシー、特商法などの“地味なページ”
・ページングや検索結果ページのデザイン
・スマホのメニュー開閉時のUI
・追従ヘッダーの中身と高さ
これらがカンプに含まれていないケースは珍しくありません。
しかし、ページとして実装する以上、最終的に形にしないといけないので、
コーダーは「最低限の一般的なUI」や「サイト全体の統一感」をベースに、
自分なりに判断して実装するしかありません。
その結果——
・「思ってたデザインと違う」
・「急に野暮ったくなる」
・「統一感がない」
という問題が発生し、やり直しにつながります。
(2)デザイン領域の“線引き”が曖昧だと、認識の齟齬が増える
よくある誤解として、
「デザインが必要なのはオシャレなページだけでいい」
「地味なページはコーディング時にうまくまとめてくれるだろう」
という思い込みがあります。
しかし実際には、
ページの“中身の有無”ではなく、“実装の必要性”で判断するべきです。
たとえば特商法ページは文字しかありませんが、
・行間
・文字サイズ
・余白
・見出しの階層
・フッターとの区切り
など、細かいデザインが必要です。
このあたりをデザイナーが言語化・明示していないと、
コーダーは“仕様の穴”に気づいてしまい、追加質問が増えます。
(3)結果として、デザイナー自身の「利益率」が下がる
領域の誤解が生む最大の問題は、
そのままデザイナーの利益を削ることにつながる点です。
・想定していないページが後から必要と判明する
・結果として作業ボリュームが増える
・デザイナーの見積もりは増やせない
・追加分を自腹で吸収することになる
という“負のスパイラル”が起きてしまいます。
さらに、スケジュールも伸びるため、
次の案件に取りかかる時間も遅れ、生産性が落ちます。
(4)誰がどこまで決めるべきか、最初に線引きしておくとトラブルは激減する
領域の誤解を防ぐための一番の方法は、
「デザイナーがどのページまで責任を持つか」
を明確にすること。
おすすめは以下のようなリストアップです。
・デザイン作成が必要なページ
・デザインの必要はないが、体裁指示が必要なページ
・コーダーに判断を任せる部分
・動きや挙動の仕様を決める部分
この線引きを事前にするだけで、
質問の回数も、手戻りも、大幅に減ります。
5. デザイナーが自分で決めるべきことを理解していないと無駄が増える
Web制作は「デザイン → コーディング → 公開」という流れで進みますが、
この中で デザイナーが“決めきれていない”領域があると、
制作全体に無駄が生まれます。
これはデザイナーの能力ではなく、
「何を自分が決定すべきなのか」が明文化されていない
業界構造にも原因があります。
(1)デザイナー自身が“決定者”であることを自覚していないケースが多い
デザイナーは、クライアントの意図を汲み取り、
ページの構成・UI・見た目・導線を整理する“設計者”でもあります。
しかし実際には、
・クライアントの判断待ちが多すぎる
・自分が決めてよい範囲がわからない
・仕様の抜け漏れを「コーダーに聞けばいい」と思ってしまう
・追加で必要になった仕様を“後出し”にしてしまう
といった行動が積み重なり、制作工程が混乱します。
すると結局、
一番苦労するのはデザイナー自身です。
(2) 「何となくのイメージ」だけで進めると、後からどんどん仕様が増える
トラブルに発展する典型例は次の3つです。
1. ページ数を把握する前に見積もる
2. “願望”だけ聞いて、実装部分のヒアリングが抜ける
3. 動き・遷移・リンク先など、実装必須の部分を決めずに進める
こうしてあいまいな認識のまま進めると、
制作後半で次の“地雷”が爆発します。
・必要なページが追加で判明
・クライアントが後から「このページもほしい」と言い出す
・デザイナーが過小見積もりしていた部分の工数が跳ね返る
・コーダーから追加見積もりが上がってくる
・デザイナーの利益が削られ、納期も延びる
つまり、
決めるべきことを最初に決めていないほど、後から苦しくなるのです。
(3)“決めるべきことが明確なデザイナー”は作業が驚くほどスムーズ
デザイナーが「ここまで自分が決める」と理解していると、
制作工程は格段にスムーズになります。
たとえば以下のように整理しているデザイナーは強いです。
・作成すべきページ数の洗い出し
・ブログ・ニュース・LPなどの構造把握
・フッターやヘッダーメニューのリンク先
・カンプに含めるページと、体裁指示だけでよいページの整理
・アニメーション・挙動の設計
必要に応じてワイヤーフレームの段階でクライアントと合意
こうした準備があるだけで、
「想像できていなかった仕様」が途中で発覚しにくくなり、
見積もりの正確性も上がります。
(4)“仕様の棚卸し”をしてからデザインに入るべき
本来、デザインは
すべての仕様が整理された後に着手すべき作業です。
しかし現場では、クライアントに急かされたり、
「予算が少ないからとりあえず作りたい」と言われたりして、
仕様整理の前にデザインに入ってしまうことが多いです。
結果として、
・デザインを描き直す手戻り
・コーダーへの追加質問
・後出し仕様でコスト増
という無駄が積み重なり、利益率がどんどん低下します。
(5)デザイナーは“仕様の管理者”であり、プロジェクトの舵取り役でもある
デザインは見た目を作るだけの作業ではなく、
サイト全体をどう運用し、どう表示し、どう動かし、
どう導線を作るかを決める役割です。
そのため、
・何を決めるのか
・誰が決めるのか
・どこまでデザイナーが責任を負うのか
この3つを明確にすることで、
クライアントにも、コーダーにも、迷惑をかけず、
自分の利益も守れるようになります。
6. ユーザーの操作を想像すれば、決めるべき仕様が自然と見えてくる
仕様が抜けやすいのは、「画面の見た目」に意識が集中してしまい、
ユーザーがどのように操作するかが後回しになりがちだからです。
逆に言えば、ユーザーの一連の行動を“追体験”しながらデザインすると、
必要な仕様が自然と浮かび上がります。
たとえば、こんな視点です。
(1)“どのタイミングで何をしたくなるか”を考える
・商品ページを見たユーザーは、比較したい？カートに入れたい？レビューを読みたい？
・記事ページを読んだユーザーは、次の記事に進みたい？それとも戻りたい？
こうした行動を想定しておくと、
・パンくずの有無
・グローバルナビや追従ボタンの必要性
・CTA（行動喚起）の配置
といった細かい仕様の抜け漏れが減ります。
（２）“迷いポイント”を先回りして潰す
ユーザーが迷いやすい箇所には、意外と細かな仕様が必要になります。
例：
・「入力フォームのエラーはリアルタイム？ 送信後？」
・「入力例はプレースホルダー？」
・「パスワードの表示／非表示切り替えは必要？」
・「戻るボタンでどこへ戻る？」
ユーザーが迷いそうなところを想像すると、
デザイン段階で決めるべき仕様がたくさん見えてきます。
（３）“最悪のケース”も想定する
・スマホの片手操作では届かないボタン
・スクロールしないと気づけない重要情報
・読み込みが遅いと途中で離脱してしまう導線
など、理想的な操作ではないケースも考えると、設計がより強固になります。
ここまで想像できているデザインは、依頼時点で仕様が整理されているため、
コーダーとのやり取りが最小限で済み、修正や再実装を減らせます。
7. まとめ
コーダーに「仕様の決定」を丸投げしてしまうと、
ほぼ確実に金額の増加・納期の遅延・コミュニケーションの負担
という三重苦が発生します。
一方で、デザインの段階で
・必要な機能
・想定されるユーザーの操作
・動き・遷移・リンク先
・デザインとコーディングの境界
を押さえておくと、案件全体の流れが一気にスムーズになります。
仕様をきちんと決めることは、
クライアントにとってはコスト最適化、
デザイナーにとっては利益確保、
コーダーにとっては無駄のない実装
という “三方よし” の状態を作るための鍵。
そして何より重要なのは、
「ユーザーがどう動くか」を想像し続けること。
これができていれば、決めるべき仕様は自然と見えてきます。
デザインをつくる前にほんの少し立ち止まり、
“画面の向こうのユーザーの行動” を思い描く。
その積み重ねが、ミスのない設計と、気持ちよく動くサイトを生み出します。
