顧客Aの原稿確認を待ちながら、顧客Bの公開準備を進めていたところ、AとCの修正依頼が同じ日に届いた。各案件の予定表では間に合うはずでも、共通の制作担当が一度に対応できず、公開予定を組み直すことがあります。複数案件の委託では、作業量と同じくらい、判断が戻る時点の重なりを見ることが大切です。
この記事は、顧客へWeb施策を提案し、制作をパートナーへ委託するマーケター・コンサルタント・協業窓口向けです。案件ごとの確認待ち、次に決める人、先行できる作業を一覧にし、公開予定を調整する方法を示します。大阪で協業先を探す場合にも使える、地域に共通する整理方法です。
「確認待ち」を、決める内容と人に分ける
進捗欄に「お客様確認中」とだけ書くと、何が戻れば制作を再開できるのか分かりません。原稿の事実確認、デザインの選択、追加機能の範囲、公開の承認では、その後に必要な作業が異なります。確認をお願いした資料名だけでなく、相手に決めてほしいことを一文で記録します。
例えば、原稿を送った案件Aなら、「サービスの対象範囲を確定するため、顧客の事業責任者が説明文を確認する」と書けます。窓口担当者が受け取ったことと、判断する人が確認したことを分けるのが要点です。連絡先だけを記録しても、次の決定までの経路は見えません。
回答を受けたい日と、顧客が回答できると合意した日も分けます。依頼側の希望日を予定表へ入れただけで、その日に回答が来る前提にすると、後続の作業枠まで確約したように見えてしまいます。返答予定が未確認なら、その状態を表示し、日程を相談する担当を決めます。
確認依頼は、同じ資料の中でも判断単位で分けられます。会社概要の事実確認が終わっていて、サービス内容だけが未確定なら、案件全体を一つの待ち状態にする必要はありません。ただし、分けて進められるかは制作側が依存する箇所を確認し、確定した範囲を記録してから判断します。
相手が回答できる状態かも確かめます。比較する案の違い、決めてほしい範囲、回答しない場合に止まる箇所が伝わっていなければ、単に催促を増やしても判断材料は増えません。連絡の回数だけを管理するより、依頼文に不足する情報を補う担当を置きます。
内容のつながりと、担当者の重なりを別に見る
作業が止まる理由には、前の判断が必要な場合と、担当者の作業枠が埋まっている場合があります。原稿が決まらなければ画面を確定できないという関係と、原稿は決まっていても実装担当が別案件を進めているという関係です。両方を「遅れ」とまとめず、調整する相手を分けます。
Asanaの依存関係の解説は、先行する作業の完了を必要とする関係と、限られた担当者などの資源に左右される関係を区別しています。複数案件のWeb制作でも、内容上の順番と担当者の稼働を別に確認する参考になります。ツールを導入すれば納期を守れるという意味ではありません。Asanaのプロジェクト依存関係の解説
顧客の回答が届いたときも、制作がすぐ再開するとは限りません。回答内容を読み、追加の確認が必要かを確かめ、作業範囲を見直したうえで担当枠へ戻します。「回答あり」「制作に必要な判断がそろった」「作業再開が決まった」を分けておくと、同時に回答が来た場合の調整を説明しやすくなります。
逆に、制作担当に空きがあるからといって、顧客の事業判断を仮に埋めて進めることはできません。作業枠の都合と、内容が確定したかは別の条件です。確認待ちの理由を分けることで、顧客への確認が必要なのか、制作の順番を相談すべきなのかを判断できます。
案件横断の一覧は「次の判断」を中心に作る
案件ごとの詳細な工程表は残し、横断一覧には、同時進行を調整するための項目を絞ります。すべての修正点や議事録を貼り付けるのではなく、次の判断、止まる工程、先行候補、回答後に必要な担当を見えるようにします。詳細へ進むためのリンクも添えます。
以下は、架空の三案件を進める協業窓口の整理例です。実在する顧客、作業期間、納期、受入本数を示すものではありません。先行候補は自動的に着手してよい作業ではなく、依頼範囲と他の箇所への影響を確認するための候補です。
| 案件・現在地 | 次の判断と確認者 | 影響する後続工程 | 先行を相談できる作業 |
|---|---|---|---|
| A：原稿確認中 | 顧客の事業責任者がサービス対象の説明を確定 | 対象ページの画面確定と実装 | 確認済み会社情報の配置準備 |
| B：公開前確認中 | 顧客の公開責任者が公開対象と時点を判断 | 公開担当の作業枠と公開後確認 | 承認済み範囲の手順・確認項目整理 |
| C：追加要望を検討中 | 協業窓口と顧客が追加範囲を決定 | 制作側の見積・担当調整と対象箇所の制作 | 変更の影響を受けない素材の整理 |
実際の一覧には、公開希望日とその確定状況、回答予定日、確認依頼の記録、判断が戻った後の担当、最終更新日も持たせます。表を横に長くしすぎる場合は、案件の要約から詳細票へ進める形でも構いません。会議で比較する項目と、担当者だけが参照する細部を分けます。
Backlogの公式案内では、案件のチャートに加えて、個人が複数のプロジェクトを横断して自身の課題を見る仕組みが説明されています。また、チャートへ表示するために開始日・期限日などの情報が必要になることも示しています。案件別の状況と、担当者側の予定を別の見方で確かめる参考です。Backlogのガントチャート案内
そのため、日付未定の確認待ちが予定表から見えなくなっていないかも点検します。空欄を仮の日付で埋めて確定扱いにするより、未定の項目を別に抽出し、次に日程を確認する人を置きます。使うツールの表示条件を確かめ、画面にないことを作業がないことと取り違えないようにします。
一覧を更新する担当は、案件の窓口と一致している必要はありません。ただし、誰からの連絡を根拠に状態を変えたかは追えるようにします。チャットで相談中の案を確定欄へ移す前に、どの回答を正式な判断として扱うかを関係者でそろえます。
先行する作業は、後で変わる範囲を確かめて選ぶ
確認待ちの間に進める候補は、待っている判断が変わっても影響を受けないかで選びます。例えば会社情報が承認済みでも、サイト全体の構成が未定なら、ページの組み方に影響することがあります。「別ページだから独立している」と決めず、見出し、共通部品、入力機能などとの関係を制作側に確認します。
案件Aでは、確認済みの会社情報を整理することと、未確定のサービス説明を仮原稿で完成させることを分けます。前者を進められるか相談し、後者を進めるなら、その目的と後で作り直す可能性を共有します。先行した作業が最終承認済みの成果物になったように扱わないことが必要です。
追加費用や担当変更が関係する場合は、先行作業も依頼の範囲に含まれるかを確認します。制作側が空いた時間にできる作業と、今回の契約で頼んでいる仕事は一致するとは限りません。確認待ちを埋めるためだけに、不要な制作物を増やさないようにします。
ほかの案件へ一時的に担当を移す場合は、戻る条件も記録します。顧客の回答が来たら元の枠へ自動で戻れるのか、改めて予定を相談するのかを明確にします。待っている案件の担当がずっと専有されている前提も、回答当日に必ず空いている前提も置かない管理です。
公開希望日から、判断と作業の残りをたどる
公開予定は、最後の作業日だけで決まりません。掲載内容の判断、制作側の修正、表示・動作の確認、顧客の公開承認、実際の公開作業と公開後の確認が関係します。どこまで終わり、どの判断や担当枠が残っているかを案件ごとに確認します。
公開希望日が変えられないという相談を受けたら、理由と公開対象を顧客に確かめます。イベントや告知と関係するのか、全ページが必要なのかを整理し、制作側へ可能な選択肢を相談します。範囲を減らせば必ず間に合うとは限らず、必要な確認を省く理由にもなりません。
一部を後から公開する案が出た場合は、リンクや申込先などのつながりを確認します。ページを外しても、別のページからその機能を案内していれば、利用者の行動が途中で止まります。何を先に出すかだけでなく、その状態で何ができるかを顧客と制作側で確かめます。
案件Bの公開作業と、案件Aの回答後の修正が同じ担当へ集中する場合は、どちらを先に進めるかの決定者を置きます。顧客の要望を比較して制作側だけで優先順位を変えるのではなく、協業窓口が影響する予定を整理し、必要な相手と調整します。約束済みの条件を無断で動かさないことが前提です。
公開担当だけでなく、公開後の確認をする人の予定も見ます。作業自体の枠が取れていても、顧客の確認や連絡を受ける担当が不在なら、その時間に実施する条件がそろっているかを再検討します。休日対応や緊急対応が含まれるとは推定せず、依頼時の範囲に照らして相談します。
回答や追加要望が来たら、一覧と予定を一緒に直す
顧客から返信が来たときは、未決事項への回答なのか、新しい要望なのかを分けます。原稿の確認に対して、新しいサービスページを追加したいという話が届いたなら、確認完了だけで処理することはできません。決まったこと、残ったこと、追加で相談することを整理して制作側へ渡します。
案件Cで追加範囲が決まった場合も、決定した内容だけを一覧へ書いて終えません。必要な資料、制作側の再見積や担当調整、次の確認、公開予定への影響を更新します。回答を受けた日と、変更後の日程を関係者が確認した日を分けて残します。
日程の変更は、その案件の記録へ反映した後、同じ担当を使うほかの案件も点検します。Aの修正枠を後ろへ移した結果、Bの公開確認に重なっていないかを見るためです。ただし、顧客へ共有する資料には他社の案件名や内容を載せず、内部の横断表から必要な情報だけを切り出します。
会議では、全案件の経過を最初から説明するより、前回から変わった判断と、次に決める項目を先に確認します。各項目について、誰が何を確認し、いつ予定を更新するかを決めます。回答がない項目も、連絡済みか、相手の確認中か、依頼内容が不足しているかを見直します。
調整後は、元の希望日を消して新しい日だけを置くのではなく、変更理由と合意した予定を区別して残します。後から「遅れたのか、公開対象を変えたのか」を確認するためです。日付の変更回数だけで担当者を評価せず、何の判断が予定へ影響したかを振り返ります。
委託先へは、案件数と一緒に判断待ちの一覧を渡す
複数案件の相談では、「三件まとめてお願いしたい」という件数だけでは、必要な体制を判断できません。各案件の現在地、公開希望と確定状況、資料の準備、確認者、未決事項、先行候補をそろえます。制作側はその情報をもとに、担当できる範囲と予定を個別に検討します。
共有する一覧は、細かな作業日報の代わりではありません。顧客が決めることと、制作側が判断することをつなぐための資料です。詳しい修正指示やファイルの版は案件ごとの記録に置き、横断表から現在の資料へたどれるようにします。
まずは現在進んでいる案件について、次の判断、確認者、回答後の作業、担当枠への影響を書き出してください。公開予定を日付だけで並べる状態から、何がそろえば次へ進めるかを説明できる状態へ変えることが、協業の相談を具体化する第一歩になります。
参照資料：Asana「プロジェクト管理における依存関係」、Nulab「Backlog 101: Gantt charts」。2026年9月21日確認。依存関係と案件横断の表示の考え方を参照。特定ツールの契約条件や制作の納期を保証するものではありません。
