【納期だけを見て進めるな】デザイン未確定のまま開発を進めると過剰工数が爆発する理由と「分離発注」の防衛策

「納期が近いから、デザインは途中でも先に組んでほしい」「社内でデザインするから、開発だけ安くお願いしたい」。現場ではよく出る言葉です。急いで受けたくなる気持ちは分かります。未確定のまま納期だけを見て着手することが、必ず炎上する最短ルートだ、とは言い切れませんがトラブルが起こる可能性は非常に高いと言えます。
起きやすいのは、修正の境界が無く、動く画面を見てから要件が書き換わることです。工数が膨らむ条件は、再現できます。

結論です。デザインと開発を分ける発注そのものが悪、ではありません。危険なのは、Webのルールが共有されないまま、確定前に実装を始めることです。開発側が身を守り、発注側の予算超過を減らすには、修正と仕様変更の条件を契約に書くこと。着手時点のデザインを Snapshot（複製・固め）して、後から静かに変わったファイルを「元の合意」と取り違えないことです。回数や Snapshot が無いと必ず爆発する、という話ではありませんが、無いと、誰の責任かが見えなくなります。

この記事では、フリーランスのWebディレクター兼エンジニアとして、分離発注で開発だけ受けるときの防衛を整理します。インハウスのデザイナーや担当者を一方的には責めません。紙の仕事と Web の仕事の前提が違う、という構造の話です。赤字化した、利益を確保した、といった個別の話ではありません。

分離発注が危うくなりやすい、不都合なリアル

受けてはいけない、と一律には言いません。デザインが揃い、挙動が決まり、修正の費用条件があるなら、開発だけでも回せます。危ういのは、次が重なるときです。

理由1：費用を抑えるための分離ほど、工程の責任者がいない

「自社でデザインして安くしたい」は合理的です。ただし、費用削減が目的の案件ほど、Webの工程（何をいつ確定するか）を見る人がいないことがあります。経験が無い担当者が握っている、と決めつけません。握っている人が、レスポンシブとフォーム状態の確定まで見ていない、が問題です。ディレクションが無い分離は、実装者がその穴を無償で埋める形になりやすい。

理由2：紙の固定レイアウトと、Webの可変は前提が違う

印刷物が主のデザイナーを貶しません。判に収める思考は、その仕事では正しい。Webでは、ホバー、モーダル、エラーと送信中、フォントの拡大、ブレークポイントでブロックが組み変わる。その一覧がカンプに無いと、実装側が仮決めします。仮決めは、後から「イメージと違う」の材料になります。思考の違いであり、能力不足の話ではありません。足りないのは、動く状態の指示です。

理由3：PCとSPが、つながりの無い一枚絵だけになる

PCとSPでルールが揃っていない。SPはお任せ、で先に組む。上がってきた SP が、余白も階層も別物。実装後に覆る、はよくある話です。恐怖、と煽るつもりはありません。確認すべきは、同じコンポーネントが両幅でどう折れるか、例外ページはあるか、です。一枚絵だけでは、一貫性の検証ができません。

理由4：テスト環境を見てから、デザインを決める

コードにして初めて、担当とデザイナーが画面を共有する。そこから「やっぱり変えたい」が続く。動くものを見て直すこと自体は、普通の改善です。泥沼になるのは、それが仕様変更だと名前が付かず、初回見積の範囲に吸収されるときです。工数が無限、とは言いません。上限が契約に無い、が正確です。

「担当者の満足」は、事業の満足ではない

担当者が、動く画面を見ながら直せて満足していても、追加の予算と遅れが出れば、事業側は失敗になり得ます。担当者＝クライアント、と同一視しない。プロの側が、「費用と納期を増やしてでも、今から変えるか」を判断できる材料を出す。ブレーキは冷たい対応ではなく、発注者が選べる制約です。満足を止めることが目的ではありません。満足のコストを、隠さないことです。

過剰工数を抑える、2つの防衛策

防衛策1：見積と契約に、修正回数と仕様変更の条件を書く

「デザイン確定後の見た目調整は〇回まで」「確定後のレイアウト変更、ブレークポイント追加、コンポーネントの作り直しは、追加見積の対象」。回数の数字は案件で変える。ゼロ回が正義、ではありません。境界が無いことが、無償のやり直しになります。口頭の「軽く直します」は、後から解釈が割れます。なので書面に残す。

防衛策2：Fix した時点の Figma（または書き出し）を複製してロックする

開発中に、共有中の元ファイルが静かに更新されることがあります。悪意と決めつけません。担当が直した、デザイナーが直した、どちらでも、実装の参照が動くと同じ症状です。着手日にファイルを複製する。または PDF / 画像を日付付きで保存する。権限を閲覧にする。Figma のバージョン履歴だけに頼ると、どの版が合意かで揉めます。Snapshot は技術というより、「この版が契約上のデザイン」と指差せる運用です。元を直しても、複製側へ自動では反映しない、と先に伝える。

未確定で着手した場合 vs、境界を書いて進めた場合

悪い例：SP は後出し、で先行実装する

「あとで SP を出します」を信じて PC だけ組む。上がってきた SP が情報設計から違う。書き直しと遅れが出る。赤字化、とは書きません。起きるのは、見積の前提が消えることです。後出しを受けるなら、SP 到着後に再見積する、と最初に書く。

良い例：Fix の定義を先に置く

PC / SP が揃い、ナビ・フォーム・モーダルの状態が書き残っている。その版を Snapshot する。追加要望は、追加見積か、次フェーズか、を選んでもらう。
予定の範囲が残るか、が成果です。毅然、より、条件を先に共有する、です。

分離発注（開発のみ）リスク回避チェックシート

まとめ：納期より先に、何が固まっているか

納期だけを優先した先行開発は、担当も事業も制作側も、後から高く付くことが多い。誰も幸せにしない、とは言えませんがそうなる確率は高い。
高く付く条件は、確定前の実装と、変更の無料化です。仕様を固めてから動くことが唯一の方法、とも言いません。
固めた定義と、変わったときの費用を先に置くことが、予算と工数を守る側に寄ります。

開発のみの受け方、UI の確定の切り方、契約文言の相談は、相談・お問い合わせからどうぞ。