制作進行管理のやり方|工程・次の担当・滞留日数を追う管理表

公開日:
最終更新日:
カテゴリ: マーケティングDX, コンテンツマーケティング
著者: 与謝秀作
制作進行管理は、原稿、デザイン、動画などの成果物が、どの工程にあり、次に誰が何をするかを追う仕事です。「担当A・進捗50%」だけでは、執筆中なのか、確認待ちなのかが分かりません。制作担当、現在の工程、次アクション担当、工程に入った日時を分けて記録しましょう。
目的は人を監視することではなく、待ちや判断の不足を見つけ、必要な支援と日程調整を行うことです。以下の工程と日数は架空の設計例です。制作物の性質、確認範囲、外部との約束に合わせて書き換えてください。
制作進行管理で見る工程と待ちを決める
まず、成果物が完成するまでの流れを、実際の仕事に沿って並べます。ブログなら依頼、構成、執筆、原稿レビュー、修正、公開準備という流れが考えられます。デザインや動画では工程が変わるため、他チームの状態名をそのまま使うより、受け渡す成果物と確認の役割から決めます。
工程を細かくするのは、その区切りで担当が変わる、判断が必要になる、日程に影響する待ちが生じる場合です。作業中の小さな操作まで状態にすると更新負担が増えます。一方、「進行中」一つでまとめると、レビュー待ちと素材待ちを見分けられません。
見たい状態 | 分ける理由 | 記録する情報 |
|---|---|---|
制作中 | 実作業を進める担当がいる | 次の成果物と提出予定 |
レビュー待ち | 判断する人へボールが渡った | 確認範囲、確認者、回答期限 |
外部素材待ち | 担当の作業だけでは進まない | 必要素材、依頼先、再確認日 |
修正中 | 指摘への対応が必要 | 対象版、必須指摘、再提出日 |
成果物や作業の抜けが多い場合は、先にWBSの作り方で対象範囲と完了証拠を整理します。工程表は、存在する仕事の流れを追う表であり、作るべきものの範囲を自動的に決めるものではありません。
制作担当・次アクション担当・工程開始日時を分ける
制作担当は原稿やデザインを作る人、次アクション担当は今必要な行動をする人です。レビューに入ったからといって制作担当をレビュー担当へ上書きすると、修正時に誰へ返すかが見えなくなります。全体責任者が必要な案件は、その人も別項目で持ちます。
時刻も分けます。現在の工程に入った日時は、今の待ちを測る基点です。最終の実質更新日時は、回答や判断が最後に記録された時刻です。メモの表記を直した日だけを基点にすると、長く続くレビュー待ちが短く見えてしまいます。
項目 | 意味 | 架空例 |
|---|---|---|
制作担当 | 成果物の制作を担う人 | 執筆A |
次アクション担当 | 今必要な行動をする人 | 商品担当C |
現在の工程 | 実際に置かれている段階 | 原稿レビュー待ち |
工程開始日時 | その工程へ入った時刻 | D6 09:00 |
最終実質更新日時 | 回答・判断・作業進展の記録時刻 | D7 16:00 |
次の期限 | 回答または完了を合意した時点 | D9 12:00 |
日付のみで管理する場合と時刻まで扱う場合を混ぜないでください。国内外の担当がいる場合はタイムゾーンも合意します。期限は依頼者が入力しただけでは確約にならないため、受け手の確認と必要な作業枠を押さえます。
工程ごとの開始条件と完了条件を定義する
状態を進める条件を、成果物の有無と確認結果で表します。「だいたい完成」「確認中」といった言い方を減らし、何を渡したら次へ進むか、誰の確認が必要かをそろえます。ただし条件の数だけ作業を分割する必要はなく、一つの成果物に複数のチェックがある場合はチェック項目として残せます。
工程 | 開始条件 | 完了条件 | 次アクション担当 | 期限の決め方 |
|---|---|---|---|---|
構成レビュー | 構成と出典候補を提出 | 必須指摘へ回答し必要な承認を得る | レビュー担当 | 事前に確認枠を合意 |
執筆 | 構成と範囲が合意済み | 原稿・出典・自己確認がそろう | 執筆者 | 実測と難易度を基に合意 |
原稿レビュー | 確認する版が特定済み | 事実・表記・権利の必要確認が終わる | レビュー担当 | 確認範囲ごとに枠を確保 |
公開準備 | 必要な承認が完了 | 公開用の体裁・参照リンク等を確認 | 公開担当 | 公開前の必要時間を確保 |
レビューを依頼するときは、対象版、確認してほしい点、回答期限、必須指摘の返し方をセットにします。複数部門の確認が必要なら、窓口が指摘をまとめるのか、各部門が直接返すのかも決めましょう。並行確認できる範囲と、前の回答が必要な範囲を分けます。
一つの制作案件を記入例と履歴で追う
現在値の台帳と、変化を残す履歴を分けると、今の状態を見ながら、以前どこへ戻ったかも追えます。台帳は最新の工程と次の行動を表示し、履歴は日時、変更前後、理由、対象版を追加していきます。原稿の修正回数だけを数えて品質を決めつけないことも大切です。
ID | 日時 | 工程の変化 | 制作担当 | 次の担当 | 理由/次の期限 |
|---|---|---|---|---|---|
C-01 | D1 09:00 | 執筆→レビュー | 執筆A | レビューB | 原稿v1を提出、D3に回答 |
C-01 | D3 16:00 | レビュー→修正 | 執筆A | 執筆A | 出典追記、D4に再提出 |
C-01 | D4 15:00 | 修正→再レビュー | 執筆A | レビューB | 原稿v2、D5に確認 |
C-01 | D5 16:00 | 再レビュー→修正 | 執筆A | 執筆A | 商品条件の変更を反映、D6に再提出 |
C-01 | D6 09:00 | 修正→原稿レビュー | 執筆A | 商品担当C | 商品条件の変更を確認、D9に回答 |
架空例では、初回の工程記録をD1 09:00、現在をD8 09:00とし、D1〜D8は連続する暦日、時刻は同一タイムゾーンと仮定します。通算は7暦日、直近の原稿レビュー開始D6 09:00からは2暦日です。D7にメモを編集しても、工程開始をD7へ変える必要はありません。通算の時間と直近工程の時間を両方残すと、差し戻しで以前の待ちが消えません。
AtlassianのKanban指標の説明は、着手から完了までの経過時間や仕掛かり数を区別しています。制作へ応用する場合も、7日経過したことと7人日働いたことは別です。実作業工数を知りたいなら、別に作業時間を記録してください。
差し戻し・外部待ち・承認待ちを処理する
差し戻しは、実際に必要になった工程へ戻します。「戻ると進捗が悪く見える」という理由でレビュー中のまま修正すると、今誰が動くべきかが曖昧になります。戻った理由を、出典不足、依頼範囲の変更、新しい事実、表現調整などに分け、責任の押し付けではなく改善に使います。
待ちの理由 | 決めること | 対応者 | 再確認 | 日程への影響 |
|---|---|---|---|---|
事例掲載の許諾待ち | 代替事例で進めるか延期するか | 責任者A | D9 | 公開日と案内を更新 |
確認者が不在 | 代理者へ依頼できるか | 確認責任者B | D8 | 確認品質と権限を確認 |
外注先の素材が不足 | 不足分と受領条件を確定 | 外注窓口C | D8 | 後工程の着手条件を見直す |
外部待ちは「先方待ち」とだけ書かず、何を依頼済みで、誰が回答し、いつ再確認するかを記します。取引先との共有・変更の合意はベンダーマネジメントの進め方を参照できます。判断が必要な問題は課題管理表へIDでつなぎ、工程のメモ欄だけに埋めないようにします。
滞留を見つけ、日程と工程を見直す
週次などの確認では、長く同じ工程にあるもの、回答期限を過ぎたもの、同じ理由で戻るものを見ます。何日で確認対象にするかは制作物と工程ごとに決め、固定の2日や3日をすべてへ適用しないでください。数字が大きい順に人を責めず、確認範囲、依頼の明確さ、同時進行数、外部条件を確かめます。
表計算で工程開始日時をG2に置くなら、日付の経過は次の式で表示できます。時刻を含む差は小数の日数になるため、整数の経過日を表示したい場合の例です。空欄を日付と誤認しないようにします。
=IF(ISNUMBER(G2),INT(NOW()-G2),"")
営業日で管理するなら休日と営業日の定義を別に決めます。経過日が増えた行を色分けすることはできますが、条件付き書式は通知や作業の再開を保証しません。期限、次アクション担当、確認する場面を合わせて運用します。
振り返りでは、どの工程に待ちが多かったかと、何を変えたら次回の判断がしやすくなるかを残します。確認範囲を明確にする、レビュー枠を先に取る、着手する件数を減らすなど、変更を小さく試して効果と負担を確かめてください。




