制作進行管理のやり方｜「誰が今どこで止まっているか」を可視化する仕組み
「あの案件、今どうなってる？」と聞かれて即答できない。締切前日に、実はレビューが1週間止まっていたと判明する——制作進行管理がうまくいっていないチームで頻発する状況です。
問題は担当者の意識の低さではなく、止まっていることが見える仕組みが無いことにあります。本記事では、制作進行管理の基本から、「誰が今どこで止まっているか」を常時可視化する仕組みの作り方までを、工程設計のレベルまで踏み込んで解説します。
制作進行管理とは
定義と目的
制作進行管理とは、コンテンツや制作物が企画から公開までに通過する各工程を定義し、現在どの案件がどの工程にあり、誰が次のアクションを担っているかを追跡・統制する業務です。
目的は納期を守ることそのものではありません。遅れが発生した瞬間に検知し、手を打てる状態をつくることです。締切当日に遅延が判明する運用と、3日前に検知できる運用では、取れる打ち手の幅がまったく異なります。
スケジュール管理との違い
スケジュール管理は「いつまでに何を終えるか」という計画の話です。制作進行管理は「今その計画に対してどこまで進んでいて、どこで滞っているか」という実行中の状態の話です。
カレンダーやガントチャートは計画を描くには適していますが、実行中の詰まりを検知する用途には向きません。予定日が過ぎていることは分かっても、なぜ止まっているのか、誰の手元にあるのかが表現されないためです。
進行管理が機能しているチームの状態
うまく回っているチームには共通した特徴があります。次の3つの問いに、誰でも5秒以内に答えられる状態です。
- 今、着手中の案件は何件あり、それぞれどの工程にあるか
- 止まっている案件はどれで、誰の手元にあるか
- 止まってから何日経過しているか
「どこで止まっているか」が見えなくなる4つの原因
原因1：ステータスの粒度が実態と合っていない
「作業中」という1つのステータスに、執筆・図版制作・修正対応がすべて含まれていると、進捗が実態を表しません。3週間ずっと「作業中」のまま、という状態が生まれます。逆に細かすぎると更新されなくなるため、工程は5〜7段階が扱いやすい範囲です。
原因2：ボールの所在が定義されていない
進行管理で最も重要な情報は「今、誰がアクションを起こすべきか」です。多くの管理表は制作担当者だけを記録しているため、レビュー待ちの状態でも担当者欄には執筆者の名前が入り続け、実際にボールを持っているレビュアーが見えません。
原因3：待ち時間が記録されない
ステータスがいつ変わったかを記録していないと、滞留に気づけません。「レビュー中」という表示だけでは、昨日出したものなのか2週間放置されているのかが区別できないためです。
原因4：進捗情報がチャットや口頭に散っている
「今日中に返します」という会話がチャットの流れの中に埋もれると、管理表の情報は更新されないまま古くなります。最新の状態が管理表にあるのか会話にあるのか分からなくなった時点で、進行管理は機能を失います。
可視化に必要な3つの情報
複雑な仕組みは必要ありません。次の3つが常に埋まっていれば、「誰が今どこで止まっているか」は把握できます。
1. ボール保持者（誰が）
その案件を前に進めるために、次に行動すべき人物です。制作担当者とは別の欄として持つことが重要です。レビュー中ならレビュアー、素材待ちなら素材の提供元、承認待ちなら承認者の名前が入ります。
2. 現在の工程（どこで）
案件が今どの段階にあるかを示します。後述の工程設計に沿って、あらかじめ定義した選択肢から選ぶ形にします。自由記述にすると集計もフィルタもできなくなります。
3. 最終更新日（いつから）
現在の工程に入った日付です。ここから経過日数を自動計算すれば、滞留している案件が数値で浮かび上がります。実務上、この項目が最も効きます。ステータスが同じでも、2日経過と12日経過ではまったく意味が違うためです。
この3つに案件名・締切・制作担当者を加えた6項目が、制作進行管理の最小構成になります。
制作進行管理の仕組みを作る6ステップ
ステップ1：工程を分解する
まず自社の制作物が実際に通過している工程を洗い出します。理想の流れではなく、現実に起きている流れを書き出すことが重要です。差し戻しや複数回のレビューが実態としてあるなら、それも工程に含めます。
ステップ2：各工程の完了条件を定義する
工程名だけを決めても、人によって解釈がずれます。「執筆完了」とは初稿が上がった状態なのか、自己チェックまで済んだ状態なのか。各工程について、何を満たせば次に進むのかを1行で定義し、全員が参照できる場所に置きます。
完了条件が曖昧な工程は、必ず滞留の温床になります。「レビュー中」で止まる案件の多くは、レビュアーが何をどこまで見るべきか決まっていないことが原因です。
ステップ3：工程とボール保持者を紐づける
各工程に入ったとき、誰にボールが移るかをルール化します。「レビュー中に変更したら、担当者欄をレビュアーに書き換える」という運用を徹底することで、ステータスを見るだけで責任の所在が分かるようになります。
ステップ4：工程ごとの標準リードタイムを決める
各工程に何日かかるのが正常かを設定します。この基準があって初めて、遅延を客観的に判定できます。基準がないと「なんとなく遅い気がする」という感覚論になり、指摘するタイミングを逃します。
ステップ5：滞留を自動で検知する
標準リードタイムを超えた案件が一目でわかるようにします。スプレッドシートなら条件付き書式で該当行に色をつける、プロジェクト管理ツールなら期限超過のフィルタを保存しておく、といった実装で十分です。人の目視チェックに頼らないことが要点です。
ステップ6：定例では「止まっている案件」だけを扱う
全案件を上から順に読み上げる進捗会議は時間の浪費です。滞留フィルタで抽出された案件だけを扱い、それぞれについて「何を待っているか」「いつまでに動かすか」の2点を確認する形にすれば、会議は10〜15分で終わります。
工程設計の実例：SEO記事制作の場合
記事制作を例に、工程・完了条件・標準リードタイムを設計した例を示します。自社の実態に合わせて調整してください。
工程と標準リードタイム
- 1. 企画（1日）：テーマ・キーワード・想定読者が確定している
- 2. 構成案作成（2日）：見出し構成と各見出しの要点が書き出されている
- 3. 構成レビュー（1日）：レビュアーが承認、または修正指示を返している
- 4. 執筆（3〜5日）：初稿が完成し、執筆者の自己チェックが済んでいる
- 5. 原稿レビュー（2日）：内容・表記・事実確認のチェックが完了している
- 6. 修正対応（1〜2日）：指摘事項がすべて反映または回答されている
- 7. 入稿・公開設定（1日）：CMS登録、メタ情報、内部リンクの設定が完了
合計で11〜14営業日。この標準に対して各案件の実績を記録していくと、どの工程が慢性的に伸びているかが見えてきます。
差し戻しの扱い
修正対応後に再レビューが必要な場合、工程を戻すか進めるかで運用が分かれます。おすすめは「工程は戻さず、差し戻し回数をカウントする」方式です。工程を戻すと経過日数がリセットされ、滞留の実態が見えなくなるためです。差し戻し回数が2回を超える案件は、構成段階での合意が不十分だったサインとして扱えます。
止まりやすい3つのボトルネックと対処法
ボトルネック1：レビュー待ち
最も頻繁に発生する滞留です。レビュアーの多くは他業務と兼務しており、レビューは後回しにされやすいためです。対処法は次の3つです。
- レビュー依頼時に期限を明示する（「確認お願いします」ではなく「◯日までに」）
- レビュー観点を限定する（構成レビューでは文章表現を指摘しない、など）
- レビュー枠を週次で確保しておく（毎週◯曜の午前など）
ボトルネック2：素材・情報待ち
図版、データ、事例の許諾、専門家の確認など、自チーム外に依存する要素で止まるパターンです。これらは着手時点で必要素材を洗い出し、執筆と並行して依頼を出しておくことで滞留を大幅に減らせます。依頼が執筆完了後になっていると、待ち時間がそのままリードタイムに上乗せされます。
ボトルネック3：多段階の承認
承認者が3名以上いる場合、直列で回すと1人あたり2日でも6日かかります。並列で回せる承認は同時に依頼する、軽微な修正は事後報告で済ませる範囲を決めておく、といった設計で短縮できます。承認の段数そのものを見直せるなら、それが最も効果的です。
運用を定着させる4つのルール
1. 更新は担当者本人が行う
進行管理者がヒアリングして代理更新する運用は、管理者がボトルネックになります。ステータス変更は各担当者が行い、管理者は滞留の解消に集中する役割分担にします。
2. 管理表を唯一の正とする
チャットでの進捗報告を禁止する必要はありませんが、報告した本人が管理表も更新するルールにします。「管理表を見れば最新がわかる」状態が崩れると、誰も見なくなります。
3. 止まっていることを責めない
滞留の報告がネガティブに扱われる文化では、担当者はステータスを更新しなくなります。可視化の目的は問題の早期発見であって個人の評価ではない、という前提をチームで共有しておくことが、仕組みを機能させる土台になります。
4. 工程定義を定期的に見直す
実態と合わない工程を放置すると、更新が形骸化します。四半期に1度、標準リードタイムと実績を比較し、慢性的にずれている工程は定義を修正してください。
ツールの選び方
スプレッドシート
導入が容易で、条件付き書式による滞留の可視化も実装できます。案件数が月20件程度までなら十分に機能します。弱点は通知機能がないことと、ステータス変更日を手動で入れる必要がある点です。
プロジェクト管理ツール
カンバン形式で工程を列として並べれば、どの工程に案件が滞留しているかが視覚的に判別できます。担当者の変更通知や期限アラートも標準で備わっており、制作進行管理との相性は良好です。
CMS統合型の管理機能
下書き状態の記事そのものにステータスと担当者が紐づくため、管理表と実物の二重管理が発生しません。制作物がCMS上のコンテンツに限られる場合は、最も転記コストが低い選択肢になります。
選定の判断軸は、月間の案件数と関与するメンバー数です。月20件・3名を超えたあたりから、通知と自動集計のあるツールへ移行する効果が大きくなります。
よくある質問
Q. ステータスは何段階が適切ですか？
5〜7段階が実用的な範囲です。3段階以下では滞留箇所が特定できず、10段階を超えると更新の手間で運用が破綻します。まず7段階で設計し、使われていない工程があれば統合していく進め方が現実的です。
Q. 少人数のチームでも仕組みは必要ですか？
2〜3名でも効果があります。人数が少ないほど1人が並行して抱える案件数が多くなり、どれが止まっているかを記憶で管理するのが難しくなるためです。項目を6つに絞った簡易版でも、滞留の検知には十分機能します。
Q. 外部の制作パートナーが関わる場合はどう管理しますか？
管理表そのものを共有するか、社内の担当者が窓口となって代理でステータスを更新するかの2択です。重要なのは、外部に依頼している間も「ボール保持者：外部パートナー」として滞留日数がカウントされる状態にしておくことです。外部工程が計測対象から外れると、遅延の原因が特定できなくなります。
Q. 導入したのに更新されません。どうすればいいですか？
多くの場合、項目数が多すぎるか、更新するタイミングが決まっていないかのどちらかです。まず項目を6つまで削り、週次定例の冒頭5分を全員での更新時間に充ててください。更新が習慣化してから項目を増やす順序が有効です。
まとめ
制作進行管理の目的は、遅延をゼロにすることではなく、遅延を早く見つけることです。要点を整理します。
- 「ボール保持者」「現在の工程」「最終更新日」の3情報が可視化の核になる
- 制作担当者とボール保持者は別の欄として管理する
- 各工程に完了条件と標準リードタイムを設定し、遅延を客観的に判定する
- 滞留の検知は条件付き書式やフィルタで自動化し、目視に頼らない
- 定例では止まっている案件だけを扱い、待ち要因と再開日を確認する
- 止まっていることを責めない前提を共有し、正直な更新を促す
まずは自社の制作物が通っている工程を、実態のまま書き出すところから始めてください。理想の流れではなく現実の流れを可視化することが、制作進行管理の第一歩になります。