大阪で制作途中のWeb案件を引き継ぐ｜完成・確認待ち・未着手の一覧

大阪の制作会社が外注先へサイトの制作を頼んでいたところ、担当者が継続できなくなった。手元にはトップページのデザイン画像が一枚。下層ページ、スマートフォン用の調整、実装がどこまで進んでいるか分からず、元請の納期だけが迫る。この場面で次の制作者へ「このデザインの続きからお願いします」と渡しても、使える元データと承認済みの範囲が曖昧なら、作業を始める位置を決められません。

この記事は、制作会社・デザイナー・元請担当者が、途中で止まったWeb案件を別の制作パートナーへ相談する前の整理です。残った成果物を「完成」「確認待ち」「未着手」に分け、各行へ現物、確認者、利用条件、次の作業を書きます。その一覧を基に、引き継いで使える部分と再制作が必要な部分を再見積りします。本文の一覧と図は架空の案件例で、実際の納期や価格、受託可否を示しません。

「トップだけ完成」を、ファイルと確認状態へ分解する

みやあじよのWeb制作パートナー案内には、外注パートナーが対応できなくなり、トップページのデザインを基に下層ページと実装へ進んだ事例が載っています。LPは、デザイン、コーディング、CMS構築などの工程を相談できる範囲を示します。本稿では特定の案件を再現せず、次の制作者が着手点を判断するために、元請が何を確かめるかに絞ります。

最初に「完成したもの」を現物で探します。画像として書き出したトップページ、編集できるデザインファイル、共有リンク、画面の仕様書、支給された写真・文章は別物です。閲覧できるリンクがあることと編集できることも違います。どのファイルが現在の案で、いつ誰が確認したかを一行ずつ書きます。メールの添付やチャットのスクリーンショットだけで「確定」と判断せず、元請が顧客へ提示した版と返事を照合します。

「完成」は、見た目が整っているという意味にしません。少なくとも、その工程の成果物が開けること、対象範囲が分かること、必要な確認が終わっていることを別々に確認します。画面は仕上がっていても顧客が未確認なら「確認待ち」です。顧客がデザインを承認していても、下層ページの構成やスマートフォン表示が作られていなければ、それらは「未着手」です。進捗率の一つの数字より、工程ごとの状態が次の見積りに役立ちます。

完成・確認待ち・未着手を一枚の一覧へ置く

以下は、トップページ案が残った架空の企業サイト制作を想定した引継ぎ一覧です。実案件では画面、デザイン、実装、原稿、素材、検証を必要な粒度に分けます。一行に「下層ページ一式」とだけ書くと、作った画面と未着手の画面が混ざります。少なくとも、誰が現物を確認でき、何が次に必要かが分かる単位へ切ります。

表は左右にスクロールできます。

対象	現物・起点	状態	元請が確認すること	次の制作者へ渡す判断
トップページのデザイン	編集可能なファイルと提示版	完成または確認待ち	顧客の承認、素材の利用条件、対象の画面幅	そのまま使うか、再調整を見積るか
下層ページの構成	ページ一覧とラフ案	確認待ち	ページ数、原稿、共通部品が確定か	構成確認から着手する範囲
スマートフォン表示	ラフのみ、または現物なし	未着手	既存デザインの展開方針と確認者	デザイン工程として追加する
コーディングとCMS	作業環境とコードの有無を調査	未着手または一部作業中	使用環境、既存コード、機能の仕様	引継ぎか再実装かを分ける
フォーム・公開確認	要件と試験記録の有無	未着手	通知先、検証範囲、公開の承認者	完了条件と日程を再設定する

トップページデザインは完成、下層ページは確認待ち、実装は未着手と分け、利用条件と再見積りへつなぐ引継ぎ一覧 — 架空の制作途中案件を完成・確認待ち・未着手に分ける引継ぎ一覧。実ファイル、確認者、利用条件、残作業をそろえてから再見積りします。

一覧の状態は、元請が確認できた事実で更新します。以前の外注先から「ほぼ終わり」と聞いていても、開けるファイルがなく確認も残っていなければ、見積りでは「現物未確認」と別記します。反対に、書き出し画像しかなくても、顧客が配色や構成を承認した記録は次の制作者の参考になります。ただし、画像を編集可能なデザインデータと同じ作業量で扱いません。分からない行を「完成」へ寄せて納期を短く見せないことが大切です。

行には「保管場所」「最終更新日」「確認者」「不足するもの」を追加できます。制作会社が複数のファイル共有先を使っていたら、一つの一覧から現物に届くようにします。ファイル名に final とあっても最新版の根拠にはならないため、元請が提示した版との対応を確認します。制作が止まった時点の複製を保管し、調査中に誰かが上書きしないよう作業用の複製を分けます。実ファイルに個人情報や顧客の未公開資料が含まれる場合は、共有できる相手を案件の範囲で確かめます。

既存成果物を使えるか、作業できる権限を分ける

デザインファイルのリンクを受け取っただけで、別会社が改変・再利用できると決めることはできません。元請と以前の外注先、顧客との間で、制作物や写真、文章、フォントなどの利用条件を確認します。文化庁の著作権契約マニュアルも、著作物を使う契約で利用許諾と権利譲渡を区別しています。ここで一般的な権利の結論を出すのではなく、実際の契約と素材ごとの条件を関係者が確認し、次の制作者が使える範囲を元請から明示します。

利用の条件と、ファイルへのアクセス権限も別です。Figmaの公式共有案内では、ファイルの共有先と閲覧・編集の権限を分けています。ファイルのバージョン履歴の案内も、作業の起点となる版を確かめる手掛かりです。Figmaを使っている案件なら、リンクが開けるか、どの版から編集するか、誰が編集権限を付与できるかを確認します。別のデザインツールなら、そのツールで同じ事実を確認すれば十分です。

コードがある案件では、受け取った圧縮ファイルと作業中のリポジトリが同じ内容かを確かめます。GitHubの組織リポジトリ権限の案内は、閲覧、書込、管理など役割を分けています。次の制作者に必要な権限を作業に合わせて付け、所有権の移管や管理権限の付与を、作業開始のための当然の条件にしません。GitHubを使わない案件にも、共有先の管理者、書き込み方法、元に戻す方法を確認する考え方を当てはめられます。

写真・文章など支給素材は、デザインファイルに配置されていることと公開できることを分けます。仮素材、購入素材、顧客提供、以前の外注先が作ったものを区別し、元データと掲載条件を確認します。使えない素材があるなら、レイアウトを引き継げても差し替え作業が発生します。素材を変えた影響でデザイン確認をやり直す必要があるかも、元請と顧客が決めます。未確定の素材を含む画面を「完成」の一語で渡さないようにします。

再見積りは、残作業と確認作業を分けて依頼する

次の制作パートナーへの相談では、「トップはあるので下層だけ」という依頼より、一覧と未決事項を渡す方が具体的です。トップの調査、既存デザインの調整、下層の制作、スマートフォン展開、実装、CMS設定、検証を分けます。既存物が使えるかの確認作業も時間がかかるため、無償の前提にしません。一方で、全ページを最初から作り直すかどうかも、現物を見ずに決める必要はありません。

見積り依頼には、対象ページと機能、提供できるファイル、未承認の箇所、支給素材、確認する人、希望日程を同じ形で伝えます。未確定項目は「要件がない」ではなく「誰がいつ決めるか」を書きます。たとえばブログ機能の追加希望が途中で出たなら、既存のデザインの引継ぎとは別の変更です。追加内容、必要な画面、入力項目、検証の範囲を整理し、再見積りの対象として区別します。仮の納期だけを守るために仕様を未確定のまま実装へ進めないようにします。

元請の見積りと外注先の見積りで含まれる工程が違う場合もあります。顧客への説明、原稿の回収、デザインの最終承認、公開作業を誰が担うかを並べます。「実装だけ」の見積りに原稿作成や顧客との直接調整を含めたつもりで進めると、途中で作業範囲が増えます。Web制作パートナーLPには必要に応じたヒアリングやディレクションも案内されていますが、個別案件で含まれるかは相談と見積りで決めます。LPの事例を標準の納期や費用にはしません。

顧客の確認と制作の再開点を一つにそろえる

次の制作者が着手する前に、元請が顧客へどこまで説明するか決めます。外注先の交代そのものより、予定していた画面、費用、日程、確認方法にどんな影響があるかが重要です。顧客が承認していないデザインを「承認済み」として引き継がず、確認待ちの欄へ戻します。新しい制作者へ顧客の未整理な要望を直接送り、元請が異なる指示を出す状態も避けます。顧客の判断を受ける人を決め、確定した変更だけを一覧へ反映します。

引継ぎ後の最初の成果物は、必ずしも完成した下層ページである必要はありません。トップの元データを開けるか、共通部品がどこまで作られたか、スマートフォン案がない場合にどの確認が必要かをまとめた差分メモでも、続きの作業範囲を確定できます。元請はそのメモを見て、既存デザインを維持するか、直す範囲を広げるかを決めます。作業の再開点を関係者が同じ言葉で説明できるまで、古い納期だけを新しい担当者へ引き継ぎません。

公開環境がすでにある場合、調査と本番更新も分けます。閲覧や検証のために必要な情報と、本番を変更できる権限は異なります。テスト環境、バックアップ、公開承認者、切替日の連絡方法を、作業の範囲に入るときに確認します。まだデザインだけの段階なら、ドメインや本番サーバーの管理権限を最初から渡す必要があるとは限りません。必要な時点で元請と所有者が権限を確認する方が、責任の所在を追いやすくなります。

次の担当が迷わない受入条件を残す

一覧の最後には、各工程を何で受け入れるかを書きます。下層デザインなら対象画面と確認する画面幅、実装なら主要な表示とフォームの動作、CMSなら入力者が更新する項目などです。過去の外注先が作った部分を新しい制作者が検証する範囲も分けます。「全体の品質を保証」と曖昧にせず、引き継いだもの、作り直したもの、今回検証したものを区別します。成果物を受け取った元請は、顧客へ提示する版と実装する版が一致するか確認します。

大阪で協業先を探すこと自体と、大阪固有の契約慣行や料金を結び付ける必要はありません。外注前の工程分担を扱う既存記事は最初に渡す資料と受け取る成果物を整理します。制作データの回収を扱う記事は運用中サイトの契約・権限・Webデータを広く確認します。本稿は、制作中に担当が離れた時点の現物を三状態へ分け、次の制作パートナーと再見積りする場面に限定しました。状態が変わったら一覧を更新し、口頭の「もうできています」だけに戻さないことが次の引継ぎにも役立ちます。

確認待ちの行には、返答の予定日と、返答が遅れたときにどの作業まで先へ進められるかも書きます。たとえばトップの配色が未承認なら、共通部品の実装を確定しない一方、必要なページ一覧の確認は進められるかもしれません。後工程へ影響する判断を先に見つけ、元請が顧客へ優先して確認します。納期に間に合わせるために承認を省くのではなく、確認と制作をどう並べ直すかを一覧から説明できる状態にします。