大阪の制作会社が外注先へ修正を依頼するとき

顧客から「問い合わせ画面の文言を直したい」と連絡が入った。元請の担当者が外注先へ画面の画像を送り、翌日には別の担当者から「前の案に戻してほしい」という連絡が届く。どちらも同じ画面の話でも、見ているデザインの版が違えば、一方の修正で他方の確定事項を消してしまいます。複数の案件が並行する制作会社なら、なおさら「最新のほうでお願いします」だけでは起点を特定できません。

この記事は、大阪で制作工程の一部を外注する制作会社・デザイナー・元請担当者に向けた、一件の修正指示と版の受け渡しの設計です。修正依頼番号、案件と画面、作業の起点となる版、確認した人、反映先を一つの票でつなぎます。大阪固有の制作慣行を前提にする話ではありません。実在案件の連絡ミスや改善成果も示しません。

みやあじよのWeb制作パートナーは、制作会社・デザイナーに向け、部分的なデザインやコーディング、必要に応じたヒアリング・ディレクションなどを案内しています。この記事では、どの工程を外へ任せるかという契約前の整理よりも、合意した工程を進める途中で修正が入ったときに、元請と制作パートナーが同じ対象を見て判断する方法を扱います。実際に任せる範囲と顧客への窓口は、案件ごとに確定します。

「最新版」の前に、何の版かを分ける

Web制作では、デザインファイルの版、実装したファイルの版、確認用サイトに表示された版、顧客が承認した内容が同時に存在します。デザインの更新日時が新しくても、実装済みとは限りません。確認用URLが同じでも、ページの中身が差し替わっていれば、昨日の承認対象と今日の表示は別です。修正依頼には「最新」と書く代わりに、どの状態を起点に変えるかを指せる情報が必要です。

まず案件を識別します。案件名は社内で重複しないIDでもよく、外注先に共有できる呼び名を決めます。次に対象画面をURL、ページ名、画面の状態で指定します。問い合わせフォームなら入力画面と送信完了画面は別です。同じページのパソコン表示とスマートフォン表示で修正が異なる場合も、対象を分けて記録します。画面の画像だけでは、どのURL・どの時点か分からないことがあります。

版の記録には、閲覧用画像のファイル名だけでなく、開ける元データや確認用URLとの対応を含めます。Figmaの版履歴の案内では、特定時点の版を確認し、名前と説明を付け、版へのリンクを共有できることを示しています。これはデザインの起点を指す手段の一例です。Figmaの利用やプランを前提にせず、共有フォルダーで管理する場合も「何を見ればその版と分かるか」を決めます。リンクの閲覧権限も確認します。

修正依頼番号を付け、起点版と反映先を同じ行に置く

以下は、説明用の案件Aで問い合わせ画面の文言を直す修正票の設計例です。実在の顧客や標準的な承認条件を表すものではありません。単なる作業メモではなく、元請が顧客の判断を受け、制作パートナーが着手し、戻った版を確認するまでの所在を一行で追うために使います。

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

票に残す項目	記入例	なぜ必要か
修正依頼番号	A-R017	同じ画面に複数の連絡が届いても一件ずつ識別する
案件・画面	案件A／問い合わせ完了画面／スマートフォン	別案件や入力画面へ反映しないため
起点版	デザインD04、確認用画面P12	どの状態から直す指示かを特定する
変える内容	完了メッセージの一文を承認済み原稿に差し替える	「文言を調整」の解釈を残さないため
確認者と状態	元請が原稿を確認、顧客の掲載判断は未了	コメントと正式な承認を分けるため
反映先	まず確認用画面。公開への反映は別判断	テスト中の変更を本番へ先に出さないため

修正依頼番号A-R017から起点版D04、確認版P13、反映先への関係を示す管理票の図 — 一件の修正票を追う設計例です。実際の版名、確認者、公開判断は案件ごとに確定します。

番号の付け方は短ければよく、特定の管理ツールを導入する必要はありません。ただし同じ番号を別案件で使うなら案件IDと組み合わせます。番号の目的は担当者の評価ではなく、メール、チャット、画面案、確認結果のどれを見ても同じ修正へ戻れることです。依頼文には番号と票への入口を入れ、画像だけを単独で転送しないようにします。

修正前の文言や表示、変更後の原稿、対象外の箇所も票へ添えます。外注先へ「ボタンを少し目立たせる」と伝えるだけでは、色、位置、文言のどれを変えるか分かりません。元請が顧客の目的を確かめ、対象画面と具体的な変更候補へ落とします。外注先に設計案を求める場合は、その依頼を「確定した実装指示」と分け、提案を誰が選ぶかまで記録します。

指示が競合したら、時刻の新しさだけで採用しない

同じ画面へ、顧客担当者から「説明を短くしたい」、別の確認者から「注意書きを残したい」という連絡が来ることがあります。後に届いたメッセージを自動的に正式指示へすると、確認権限の違いや、別の版を見た回答を見落とします。修正票では、それぞれがどの画面・版への意見か、誰の判断が必要かを並べ、採用、保留、取り下げを元請が確定します。

顧客と直接打合せする制作パートナーがいても、会話で出た案をそのまま別の作業指示へ増やさないようにします。提案の内容、対象版、元請に戻す質問を残し、顧客の掲載内容に関わる判断は決められた確認者へ戻します。元請が取りまとめ役を担うなら、その役割は連絡を止めることではなく、矛盾した情報を一つの確定元へ整理することです。

古い指示を取り消すときも、記録を消すだけでは後から届いたファイルの意味が分からなくなります。「A-R017はA-R019に置換」「A-R018は保留」のように、どの番号が現行かを示します。制作担当が既に手を付けたか、確認用画面へ反映したかで戻し方が変わるため、取り消し連絡には現在の作業状態も付けます。未確定のまま別の画面へ横展開しないことを、各担当が確認します。

たとえば顧客が旧版D03の画像に丸を付けて返してきた場合、丸の位置だけを新版D04へ移すと、D04で確定した別の修正を消すおそれがあります。元請は「D03へのコメント」として保存し、D04でも変更したい意図が同じかを顧客へ尋ねます。そのうえでD04を起点とする新しい依頼番号を発行するか、既存依頼の条件を更新するかを決めます。旧画像を受け取った時刻が新しいことは、旧デザイン全体を復活させる理由にはなりません。

返ってきた版で、実装確認と掲載承認を分ける

制作パートナーから修正版を受け取る際は、依頼番号だけでなく、作業に使った起点版、変更した画面、戻したファイルや確認用URL、未反映の項目をそろえます。元請が「A-R017のどの指示が反映され、何が保留か」を照合できる状態にします。画像が一枚届いたことと、リンク・フォーム・別幅の画面まで確認済みであることは違います。受け取る対象と確認範囲を依頼票に対応させます。

GitHubの変更レビュー資料は、コミット、変更ファイル、差分を見てコメント、承認、変更依頼を行う方法を示しています。実装をGitHubで管理する案件なら、どの差分を確認したかを残す例になります。ただしコードのレビューで「問題なし」となっても、顧客が掲載する原稿や公開日時を承認したことにはなりません。逆に顧客が画面の見た目を了承しても、外注先が別の版を実装した可能性は残ります。元請は両方を同じ依頼番号へ結び付けます。

コメント、修正依頼、承認も同じ状態にしません。GitHubのレビュー判断の説明でも、コメント、承認、変更依頼は異なる判断として扱われます。自社の表でも「受信」「回答待ち」「修正済み」「元請確認済み」「顧客確認済み」を区別し、必要な承認者が誰かを決めてください。すべての画面に同じ承認段階を義務付けるのではなく、変更の影響に合わせます。

確認が終わった版には、誰がいつ、どのURL・画面を見たかを残します。たとえば「確認用P13のスマートフォン表示を元請が確認」と「顧客が掲載文言を承認」は別の記録です。確認後に文言をもう一度変えたなら、承認した版と現在の版が同じか再点検します。保存時刻だけを承認の証拠にせず、対象と判断を短く記録することが重要です。

受入確認も依頼番号に合わせます。文言の差し替えなら、指定した画面の文章だけでなく、改行やリンク先が旧版に戻っていないか見る。共通部品を変更したなら、その部品を使う別画面も対象にする。修正票に「対象外」とした箇所が変わっていないことも確かめます。指示と結果が合わない場合は、見つけた画面、確認版、期待した状態、実際の表示を同じ番号へ追記し、別の口頭依頼として増やさないようにします。

確認版から反映先へ渡すときの取り違えを防ぐ

修正票の「反映先」は、最初の確認用画面だけで終わりません。公開を含む依頼なら、確認済みの版から何を本番へ反映するか、作業担当、公開を判断する人、公開後に確認する画面を決めます。確認用サイトと本番のURLが似ていても、どちらを更新したかは操作結果で確かめます。単に「反映済み」と書くと、確認用画面だけの更新なのか、公開まで済んだのか分かりません。

反映後は、依頼番号に対応する箇所と周辺の影響を確認します。共通ヘッダーの修正なら他ページ、フォームの文言なら送信前後、画像の差し替えならスマートフォン表示も見る、といった範囲を決めます。意図した版と異なったときに、どの確認版へ戻るかも残しておきます。ただし、戻せる仕組みや公開作業をパートナーの標準対応として推測せず、今回の依頼範囲と環境に合わせて確認します。

公開作業を元請が行う案件でも、外注先の完了報告に「確認版P13を納品」と書くだけでは、どのファイルや設定を移すか足りないことがあります。納品物の一覧と確認版の対応、反映しない試案、公開前に元請が確認する点を添えて受け取ります。後日同じ修正を別ページへ展開するときも、元の依頼番号を複製して済ませず、対象画面と起点版を新たに指定します。

複数案件を同時に扱う場合は、修正票の見出しと保存場所に案件識別子を付けます。外注先が閲覧できる場所へ、別の顧客名や未公開資料を混ぜない権限設計も必要です。一覧で横断して見るのは「どの依頼が保留か、次に誰が確認するか」までにとどめ、詳細な原稿や画面は案件ごとの場所へ戻します。日程や担当枠の横断調整は別の記録で扱い、個別の修正票を巨大な工程表へしない方が、確定版を探しやすくなります。

継続する協業の相談へ、修正票を持ち込む

まず一つの実案件で、最近届いた修正連絡を一件選び、番号、画面、起点版、確認者、反映先を埋めてみてください。空欄が残れば、外注先へ作業を渡す前に元請が決めること、顧客に戻して確認すること、制作パートナーと相談することが見えます。指示が契約済みの範囲を越えるなら、票を埋めるだけで追加作業を確定させず、範囲と条件を別に相談します。

既存の外注前の工程分担の記事は、何を任せ、何を受け取るかを決めるためのものです。本稿の修正票は、その工程が始まった後に届く個別の変更を追います。大阪で制作パートナーを探す場合も、地名だけで対応速度や契約条件を推測せず、現在の案件と修正票から相談したい工程を具体化してください。