コンテンツ制作の遅れを確認｜企画・執筆・確認・公開を可視化

記事制作の工程表や原稿が置かれたオフィスデスクと、制作途中の滞留を表現したコンテンツ制作リードタイム監査のアイキャッチ

「記事制作が遅い」と感じたとき、原因はライターの執筆時間とは限りません。構成の確認を待っている、複数部署の承認で止まっている、修正が何度も往復している。このように、実際には「誰も作業していない時間」が公開を遅らせているケースがあります。

企画から公開までの日数だけを見ていても、どの工程で止まっているのかは分かりません。そのため、コンテンツ制作のリードタイム監査では、工程ごとに「作業時間」「待ち時間」「差し戻し回数」「担当者」「仕掛かり記事数（制作途中にある記事の本数）」を分けて記録します。

この記事では、企画・構成・執筆・編集・確認・公開のどこで記事が滞留しているかをデータで確認し、改善の優先度を決めるまでの方法を解説します。記録の手順、遅れの原因の見分け方、架空の数値例、月次で確認する項目の順に進めます。

制作工程・役割分担・品質管理の全体像から確認したい場合は、先に「コンテンツ制作・運用体制とは？編集フロー・役割分担・品質チェックの仕組みを体系的に整理」をご覧ください。

リードタイムは「総日数」だけでなく中身を分けて見る

この節では、リードタイムの中身を分けて見る理由と、監査で使う指標を整理します。

コンテンツ制作のリードタイムは、記事の制作を開始してから公開されるまでの経過時間として測定できます。ただし、総日数だけを記録しても、遅延の原因までは分かりません。

たとえば、企画から公開まで20日かかった記事が2本あったとします。1本目は執筆に12日かかり、それ以外の工程は短時間で完了しているかもしれません。一方、2本目は執筆そのものは3日で終わっているものの、社内確認で10日間止まっている可能性があります。

どちらも「20日」という結果は同じですが、必要な対策は異なります。1本目なら執筆の進め方、2本目なら確認の進め方が改善の対象になります。

こうした違いを見分けるために使えるのが、カンバンガイドの指標です。2025年版のカンバンガイドは、作業フローを管理する基本的な指標として次の4つを挙げ、継続的に確認することをフロー管理の基本としています。

WIP：開始済みで未完了の作業数
スループット：一定期間に完了した件数
作業項目の年齢：作業開始から現在までの経過時間
サイクルタイム：開始から完了までの経過時間

コンテンツ制作でも、同じ考え方を応用して「何本が制作途中にあるか」「1本が完成するまで何日かかるか」を分けて確認できます。さらに工程別の待ち時間と差し戻しを記録すると、改善箇所を特定しやすくなります。

次の表は、リードタイム監査で見る6つの指標をまとめたものです。

指標	何を測るか	分かること
総リードタイム	制作開始から公開までの日数	記事公開までの全体速度
工程別経過時間	各工程へ入ってから次工程へ進むまで	滞留している工程
実作業時間	担当者が実際に作業した時間	作業そのものの重さ
待ち時間	工程内で作業されず止まっていた時間	承認待ち・着手待ち
差し戻し回数	前工程へ戻った回数	手戻りが多い工程
WIP	制作途中の記事本数	同時進行しすぎていないか

表のうち、特に区別したいのが「実作業時間」と「工程別経過時間」です。「担当者が何時間働いたか」と「記事が何日間その工程に存在したか」は、別の数字として扱います。

企画から公開までの総リードタイムを実作業時間と待ち時間に分解し、差し戻しとWIPも確認する考え方を示した図

記事制作の総日数だけでは遅延原因は分かりません。実作業時間と待ち時間を分け、差し戻しや制作途中の記事数も確認します。

記事制作は、執筆以外のどこで遅れるのか

この節では、遅れが執筆以外の工程で起きた例を見たうえで、遅れの原因を4つに分けます。

記事制作では、原稿を書く時間よりも、工程間の受け渡しや確認待ちがリードタイムを長くする場合があります。

ツクレルSEOが公開した株式会社ウェブクルーへのインタビューでは、外部ライターへの修正依頼などによって、企画から記事公開まで約2か月かかる場合があったとされています。ツール導入後も編集工数自体は大きく変わらなかった一方、外部への修正依頼を待たずに本文生成や修正ができることがリードタイム短縮につながったと説明されています。

この例から、制作速度は「文章を書く速度」だけでは測れないことが分かります。

外注先との修正往復が滞留要因になっている場合は、納品条件・根拠・品質・修正責任を発注前から固定すると原因を切り分けやすくなります。具体的な基準は「外注記事の受入れ基準を作る方法」で整理しています。

レビュー工程でも同様のことが起こります。英国政府のGOV.UKでは、コンテンツ制作チームの拡大に伴い、非緊急コンテンツのレビューから公開までが従来の1〜2日程度から、一時期は約2週間まで長くなった事例が紹介されています。レビュー工程でコンテンツが何度も往復する状態も発生していました。

これらの例を踏まえると、コンテンツ制作のリードタイムを改善するには、遅れの原因を次の4つに区別する必要があります。

作業そのものに時間がかかっている
次の担当者が着手するまで待っている
承認者が判断するまで止まっている
差し戻しによって同じ工程を繰り返している

この区別ができて初めて、ライターを増やすのか、承認方法を変えるのか、構成段階の品質を上げるのかを判断できます。

リードタイム監査は5ステップで進める

この節では、記録の手順を5ステップで説明します。コンテンツ制作のリードタイム監査は、現在使っているタスク管理ツールやスプレッドシートでも始められます。最初から高度なシステムを導入する必要はありません。

ステップの順序には理由があります。測る範囲と工程の分け方を先にそろえておかないと、後から記録を集めても記事同士を比べられないためです。すべての記事で、同じ開始点・終了点・工程を記録します。

記事制作のリードタイム監査を開始終了の固定、工程統一、3つの日時記録、差し戻し記録、遅延比較の5ステップで示した図

リードタイム監査では、開始・終了の基準をそろえたうえで、各工程のIN・START・OUTと差し戻しを記録し、遅延記事を比較します。

STEP1｜開始点と終了点を固定する

最初に、「いつからいつまでを制作期間とするのか」を決めます。記事によって測定の開始点が違うと、記事同士を比較できません。構成案の作成開始から測る記事と、ライターへの発注日から測る記事が混在すると、数字の意味が変わってしまいます。

新規記事制作であれば、たとえば次のように固定します。

開始：記事企画が承認され、制作対象として確定した日時
終了：記事が本番環境で公開された日時

なお、「公開予定日から何日遅れたか」は、リードタイムとは別の指標です。リードタイムは実際の制作速度を、予定日との差は納期の遵守状況を測るものなので、分けて管理します。

STEP2｜制作工程を同じ細かさにそろえる

次に、記事制作を工程に分解します。一般的なSEO記事であれば、最低限、次の6工程があれば監査できます。

企画
構成・調査
執筆
編集
校正・事実確認・承認
CMS入稿・公開

取材記事であれば「取材調整」「取材」「監修」を追加して構いません。

工程の分類は、すべての記事で同じにします。記事によって「編集」「確認」「承認」の意味が変わる状態では、工程間の比較ができないためです。

STEP3｜各工程に入った日時・着手した日時・完了した日時を記録する

工程別の滞留を調べるには、完了日だけでは情報が足りません。最低限、次の表の3つを記録します。

記録項目	意味
工程IN	前工程が終わり、この工程で対応可能になった日時
作業START	担当者が実際に作業を開始した日時
工程OUT	作業・確認が終了し、次工程へ渡した日時

この3点があれば、次のように分けられます。

工程経過時間＝工程OUT − 工程IN

着手待ち時間＝作業START − 工程IN

作業期間＝工程OUT − 作業START

工程経過時間は、先の表の「工程別経過時間」と同じものです。着手待ち時間は、「待ち時間」のうち着手までの分にあたります。

厳密な作業時間を取得できない場合は、作業開始日と終了日だけでも構いません。最初から完全なデータを求めるより、全記事で同じ記録を残すことを優先します。

STEP4｜差し戻しの回数と理由を記録する

記事が前工程へ戻ったときは、その回数を残します。たとえば、次のように進んだ記事があるとします。

構成 → 執筆 → 編集 → 執筆へ差し戻し → 編集 → 確認 → 構成まで差し戻し

この記事を「編集に時間がかかった」とだけ記録すると、原因を取り違えます。実際には、前の工程へ何度も戻っていたことが遅れの理由かもしれないためです。

差し戻しの理由も分類しておくと、改善しやすくなります。

検索意図のずれ
構成不足
情報不足
事実誤認
表現・トンマナ
法務・専門確認
依頼内容の変更
承認者間の意見不一致

同じ理由が繰り返されている場合、個別記事の問題ではなく、制作ルールや前工程の設計に問題がある可能性があります。

STEP5｜中央値と遅い記事を分けて見る

平均リードタイムだけで判断すると、一部の極端に遅い記事に数字が引っ張られます。そこで、最低限、次の3つを確認します。

中央値
遅い記事群
最速・最遅の記事

運用を安定させたい場合は、80％の案件が何日以内に完了しているかを見る「80パーセンタイル」などを併用する方法もあります。

たとえば中央値が12日でも、20％の記事が40日以上かかっているなら、「平均的には問題ない」と判断してはいけません。遅延記事だけを抽出し、共通する工程・担当・記事タイプ・差し戻し理由を確認します。

改善する工程は、長さだけでなく4パターンで見極める

この節では、遅れの状態を4パターンに分け、パターンごとに優先する対策を決めます。

工程別の日数を並べると、一番長い工程から手をつけたくなります。しかし、改善の優先度は長さだけでは決まりません。遅れの出方によって、有効な対策が違うためです。次の表の4パターンに分類すると、判断しやすくなります。

状態	主な特徴	優先する対策
作業時間が長い	着手後も長時間必要	テンプレート化、自動化、分業
待ち時間が長い	工程INから着手まで止まる	担当固定、通知、期限設定
差し戻しが多い	前工程との往復が多い	完了条件、ブリーフ、チェック基準改善
WIPが多い	多数の記事が同時進行	着手本数制限、優先順位整理

記事制作の遅延原因を作業時間、待ち時間、差し戻し、WIP過多の4タイプに分類し、それぞれの改善方法を示した図

制作が遅れる理由は一つではありません。作業時間、待ち時間、差し戻し、WIP過多のどれが原因かによって改善方法を変えます。

4つのうち、特に注意したいのがWIPです。制作本数を増やそうとして大量の記事を同時に着手すると、編集者や確認者の前に記事が積み上がり、結果として各記事の待ち時間が増えることがあります。

生産管理分野の研究でも、WIPを制御することで仕事がシステム内を通過する時間を短縮できる一方、条件によってはスループットとのトレードオフが生じることが報告されています。コンテンツ制作と製造業は同一ではありませんが、「同時進行数を増やせば必ず速くなるわけではない」という工程管理上の示唆は参考になります。

架空例｜18日かかる記事でも、実作業は8日しかない場合がある

ここからは、記録したデータの読み方を、架空の記事制作データで確認します。実在の記事の数値ではなく、監査方法を理解するための例です。

ある記事が企画確定から公開まで18日かかったとします。工程は、STEP2の6工程に沿って分けています。

工程	工程経過	実作業	待ち時間
企画確定・引き渡し	1日	1日	0日
構成・調査	3日	2日	1日
執筆	4日	3日	1日
編集	3日	1日	2日
社内確認・承認	6日	0.5日	5.5日
入稿・公開	1日	0.5日	0.5日
合計	18日	8日	10日

企画確定から公開まで18日かかった架空の記事制作例を、実作業8日と待ち時間10日に分け、社内確認で5.5日待っている状態を示した図

図は、架空例の18日を実作業と待ち時間に分けたものです。

この記事では、18日のうち実作業は8日にとどまり、残る10日は待ち時間です。待ち時間のなかで最も長いのは、社内確認・承認の5.5日です。最大の改善対象は執筆速度ではなく、この確認・承認の待ち時間だと分かります。

執筆を20％高速化しても、削減できる期間は限定的です。

確認・承認の待ち時間を縮める改善候補は、次のとおりです。

確認担当者を固定する
確認期限を設定する
法務・事業・編集の確認項目を分ける
同じ内容を複数人が順番に確認する構造を見直す
軽微な修正と公開停止レベルの問題で承認経路を分ける

コンテンツガバナンスに関するDigital.govの解説でも、専門家確認や正式承認が必要な条件、コンテンツの所有者・責任者を明確にすることが品質管理に重要だとされています。確認担当者の固定や承認経路の分け方を考えるときの参考になります。

このように、リードタイム監査は「もっと速く書く方法」を探す作業ではありません。記事が動いていない時間を見つける作業です。

改善の優先度は「待ち時間×発生件数×影響記事数」で決める

ボトルネックを見つけても、すべてを同時に改善する必要はありません。次の3つの軸で優先順位を決めます。

1件あたり何日遅らせているか
どの程度の頻度で発生しているか
何本の記事へ影響しているか

たとえば、

「月1本だけ発生する5日の遅延」

より、

「月20本で毎回2日発生する確認待ち」

を先に直した方が、編集部全体の改善効果は大きくなる場合があります。前者は1件あたりの遅れが大きくても影響する記事は少なく、後者は1件あたりの遅れが小さくても多くの記事に及ぶためです。

簡易的には、次の式で比較できます。

改善影響度＝ 1記事あたりの平均待ち時間 × 対象記事数

この式では、遅れが発生した頻度と影響した記事の本数をまとめて「対象記事数」として数えます。

これはSEO上の基準ではなく、編集部内で改善対象を並べるための管理指標です。

差し戻しの場合は、

差し戻し回数 × 再作業時間 × 発生記事数

を見ることで、どの修正原因を先に直すべきか判断できます。

記事更新SLAと制作リードタイム監査は分けて管理する

新規記事制作のリードタイムと、公開済み記事を更新する期限は、混同しない方が管理しやすくなります。この記事では、公開済み記事の確認・更新に設ける対応期限の取り決めを「更新SLA」と呼びます。

新規制作では、「企画が確定してから何日で公開されたか」を測ります。

一方、記事更新では、「情報変更や検索下落などを検知してから何日以内に確認・更新するか」を管理します。

同じ「何日」という指標でも、目的が異なります。新規制作の監査は、制作工程のボトルネックを見つけるためのものです。更新SLAは、公開済みコンテンツの異常や陳腐化に対して、対応期限を管理するためのものです。

管理表も分けておくと、編集部の「制作能力」と「保守対応能力」を混同せずに評価できます。

月1回のリードタイム監査で確認する7項目

リードタイムは、一度測って終わりではありません。記事数や担当者、承認者が変われば、ボトルネックも変わるためです。月次で次の7項目を確認すると、制作フローの変化を捉えやすくなります。

総リードタイムの中央値
工程別経過時間
工程別待ち時間
差し戻し回数
差し戻し理由
制作途中のWIP
公開本数・スループット

前月よりリードタイムが伸びた場合も、すぐに担当者個人の生産性を問題にしないでください。記事タイプが難しくなった、監修記事が増えた、承認者が増えた、制作途中の記事数が増えたなど、条件の変化を先に確認します。

また、通常記事、取材記事、専門家監修記事を同じ母集団で比較すると、監修工程が必要な記事ほど不利になります。記事タイプ別に数字を分けて比較してください。

まとめ｜遅れの中身を分け、動いていない場所を探す

コンテンツ制作のリードタイムを改善するには、「記事1本に何日かかったか」だけでなく、その日数の中身を分けて見る必要があります。

まず、企画確定から公開までの開始点・終了点を固定します。そのうえで、企画、構成、執筆、編集、確認・承認、公開といった工程ごとに、次の項目を記録します。

工程へ入った日時
実際に着手した日時
完了した日時
差し戻し回数
差し戻し理由
担当者

分析では、実作業時間と待ち時間を分け、中央値、遅延記事、WIP、スループットを確認します。

制作が遅い原因が承認待ちなら、ライターを増やしても大きな改善にはつながりません。差し戻しが多いなら、構成案や制作指示の品質を見直します。

最初は直近10〜20本程度の記事でも構いません。現在の制作履歴を工程別に並べ、「記事が最も長く動いていない場所はどこか」を確認するところから始めてください。

参考文献・データ元

この記事で参照した情報を確認できます。

The Kanban Guide 2025｜Kanban Guides。WIP、スループット、作業項目の年齢、サイクルタイムの定義確認に使用。The Kanban Guide
カンバンガイド 2025年5月版｜Kanban Guides。フロー指標の日本語定義確認に使用。カンバンガイド
「SEO記事制作のリードタイムが大幅短縮」｜ツクレルSEO／株式会社マイナビ、2025年4月。企画から公開まで約2か月を要した事例と、修正待ちに関する実務例の確認に使用。ツクレルSEO導入事例
Crafting quality content throughout its lifecycle｜Digital.gov、2024年11月。コンテンツガバナンス、所有者、専門家確認、承認設計の確認に使用。Digital.gov
Iterating on the GOV.UK content review process｜GOV.UK、2016年9月。レビュー工程の滞留と制作量増加に伴う公開遅延事例の確認に使用。GOV.UK content review process
Thürer, M., Li, S. S., Yang, C., Qu, T., Huang, G. Q. “Does Regulating Work-In-Process Increase Throughput and Reduce Cycle Times?” 2023. WIP制御と通過時間・スループットの関係を考察する補助研究として使用。DOI: 10.1007/978-3-031-43670-3_45。Hong Kong Polytechnic University研究情報

‹ 親記事: コンテンツ制作・運用体制とは？編集フロー・役割分担・品質チェックの仕組みを体系的に整理

コンテンツ制作の遅れを確認｜企画・執筆・確認・公開を可視化

リードタイムは「総日数」だけでなく中身を分けて見る

記事制作は、執筆以外のどこで遅れるのか