「記事制作が遅い」と感じても、原因がライターの執筆時間とは限りません。構成確認を待っている、複数部署の承認で止まっている、修正が何度も往復しているなど、実際には「作業していない時間」が公開を遅らせているケースがあります。
制作工程・役割分担・品質管理の全体像から確認したい場合は、[コンテンツ制作・運用体制とは？編集フロー・役割分担・品質チェックの仕組みを体系的に整理](https://rebranding.co.jp/media/content-production-operations/)を先に確認してください。
コンテンツ制作のリードタイム監査で重要なのは、企画から公開までの日数だけを見るのではなく、工程ごとに「作業時間」「待ち時間」「差し戻し回数」「担当者」「仕掛かり記事数」を分けて記録することです。
この記事では、企画・構成・執筆・編集・確認・公開のどこで記事が滞留しているかをデータで確認し、改善優先度まで決める方法を解説します。
コンテンツ制作のリードタイム監査では「総日数」だけを見ない
コンテンツ制作のリードタイムは、記事の制作を開始してから公開されるまでの経過時間として測定できます。ただし、総日数だけを記録しても、遅延の原因までは分かりません。
たとえば、企画から公開まで20日かかった2本の記事があったとします。
1本目は執筆に12日かかり、それ以外の工程は短時間で完了しているかもしれません。一方、2本目は執筆そのものは3日で終わっているものの、社内確認で10日間止まっている可能性があります。
どちらも「20日」という結果は同じですが、必要な対策は異なります。
カンバンガイドでは、作業フローを管理する基本的な指標として、開始済みで未完了の作業数であるWIP、一定期間に完了した件数であるスループット、作業開始から現在までの経過時間、開始から完了までのサイクルタイムを挙げています。コンテンツ制作でも、同じ考え方を応用して「何本が制作途中にあるか」「1本が完成するまで何日かかるか」を分けて確認できます。
実際のコンテンツ制作では、さらに工程別の待ち時間と差し戻しを記録すると、改善箇所を特定しやすくなります。
| 指標 | 何を測るか | 分かること |
|---|---|---|
| 総リードタイム | 制作開始から公開までの日数 | 記事公開までの全体速度 |
| 工程別経過時間 | 各工程へ入ってから次工程へ進むまで | 滞留している工程 |
| 実作業時間 | 担当者が実際に作業した時間 | 作業そのものの重さ |
| 待ち時間 | 工程内で作業されず止まっていた時間 | 承認待ち・着手待ち |
| 差し戻し回数 | 前工程へ戻った回数 | 手戻りが多い工程 |
| WIP | 制作途中の記事本数 | 同時進行しすぎていないか |
重要なのは、「担当者が何時間働いたか」と「記事が何日間その工程に存在したか」を別の数字として扱うことです。
記事制作の総日数だけでは遅延原因は分かりません。実作業時間と待ち時間を分け、差し戻しや制作途中の記事数も確認します。
なぜ記事制作は執筆以外の工程で遅れるのか
記事制作では、原稿を書く時間よりも、工程間の受け渡しや確認待ちがリードタイムを長くする場合があります。
外注先との修正往復が滞留要因になっている場合は、納品条件・根拠・品質・修正責任を発注前から固定すると原因を切り分けやすくなります。具体的な基準は[外注記事の受入れ基準を作る方法](https://rebranding.co.jp/media/outsourced-content-acceptance-criteria/)で整理しています。
ツクレルSEOが公開した株式会社ウェブクルーへのインタビューでは、外部ライターへの修正依頼などによって、企画から記事公開まで約2か月かかる場合があったとされています。ツール導入後も編集工数自体は大きく変わらなかった一方、外部への修正依頼を待たずに本文生成や修正ができることがリードタイム短縮につながったと説明されています。
つまり、制作速度を見るときは「文章を書く速度」だけでは不十分です。
レビュー工程でも同様のことが起こります。英国政府のGOV.UKでは、コンテンツ制作チームの拡大に伴い、非緊急コンテンツのレビューから公開までが従来の1〜2日程度から、一時期は約2週間まで長くなった事例が紹介されています。レビュー工程でコンテンツが何度も往復する状態も発生していました。
コンテンツ制作のリードタイムを改善するには、次の4つを区別する必要があります。
- 作業そのものに時間がかかっている
- 次の担当者が着手するまで待っている
- 承認者が判断するまで止まっている
- 差し戻しによって同じ工程を繰り返している
この区別ができて初めて、ライターを増やすべきなのか、承認方法を変えるべきなのか、構成段階の品質を上げるべきなのかを判断できます。
リードタイム監査は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パターンに分類すると判断しやすくなります。
| 状態 | 主な特徴 | 優先する対策 |
|---|---|---|
| 作業時間が長い | 着手後も長時間必要 | テンプレート化、自動化、分業 |
| 待ち時間が長い | 工程INから着手まで止まる | 担当固定、通知、期限設定 |
| 差し戻しが多い | 前工程との往復が多い | 完了条件、ブリーフ、チェック基準改善 |
| WIPが多い | 多数の記事が同時進行 | 着手本数制限、優先順位整理 |
制作が遅れる理由は一つではありません。作業時間、待ち時間、差し戻し、WIP過多のどれが原因かによって改善方法を変えます。
特に注意したいのがWIPです。
制作本数を増やそうとして大量の記事を同時に着手すると、編集者や確認者の前に記事が積み上がり、結果として各記事の待ち時間が増えることがあります。
2025年版のカンバンガイドでも、WIP、スループット、作業項目の年齢、サイクルタイムを継続的に確認することがフロー管理の基本とされています。
生産管理分野の研究でも、WIPを制御することで仕事がシステム内を通過する時間を短縮できる一方、条件によってはスループットとのトレードオフが生じることが報告されています。コンテンツ制作と製造業は同一ではありませんが、「同時進行数を増やせば必ず速くなるわけではない」という工程管理上の示唆は参考になります。
架空例｜18日かかる記事でも実作業は7日しかない場合がある
ここでは監査方法を理解するため、架空の記事制作データを使います。
ある記事が企画確定から公開まで18日かかったとします。
| 工程 | 工程経過 | 実作業 | 待ち時間 |
|---|---|---|---|
| 企画確定・引き渡し | 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日の待ち時間です。
この場合、執筆を20％高速化しても、削減できる期間は限定的です。
最大の問題は、社内確認・承認工程の5.5日の待ち時間です。
改善候補は、
- 確認担当者を固定する
- 確認期限を設定する
- 法務・事業・編集の確認項目を分ける
- 同じ内容を複数人が順番に確認する構造を見直す
- 軽微な修正と公開停止レベルの問題で承認経路を分ける
といった方法になります。
コンテンツガバナンスに関するDigital.govの解説でも、専門家確認や正式承認が必要な条件、コンテンツの所有者・責任者を明確にすることが品質管理に重要だとされています。
このように、リードタイム監査は「もっと速く書く方法」を探す作業ではありません。
記事が動いていない時間を見つける作業です。
改善優先度は「待ち時間×発生件数×影響記事数」で決める
ボトルネックを発見したら、すべてを同時に改善する必要はありません。
次の3軸で優先順位を決めます。
- 1件あたり何日遅らせているか
- どの程度の頻度で発生しているか
- 何本の記事へ影響しているか
たとえば、
「月1本だけ発生する5日の遅延」
より、
「月20本で毎回2日発生する確認待ち」
を先に直した方が、編集部全体の改善効果は大きくなる場合があります。
簡易的には、
改善影響度 ＝ 1記事あたりの平均待ち時間 × 対象記事数
として比較できます。
これはSEO上の基準ではなく、編集部内で改善対象を並べるための管理指標です。
また、差し戻しの場合は、
差し戻し回数 × 再作業時間 × 発生記事数
を見ることで、どの修正原因を先に潰すべきか判断できます。
記事更新SLAと制作リードタイム監査は分けて管理する
新規記事制作のリードタイムと、公開済み記事を更新する期限は混同しない方が管理しやすくなります。
新規制作では、
「企画が確定してから何日で公開されたか」
を測ります。
一方、記事更新では、
「情報変更や検索下落などを検知してから何日以内に確認・更新するか」
を管理します。
同じ「何日」という指標でも目的が異なります。
新規制作の監査は、制作工程のボトルネックを見つけるためのものです。
更新SLAは、公開済みコンテンツの異常や陳腐化に対して、対応期限を管理するためのものです。
管理表も分けておくと、編集部の「制作能力」と「保守対応能力」を混同せずに評価できます。
月1回のリードタイム監査で確認する7項目
リードタイムは一度測って終わりではありません。
記事数や担当者、承認者が変わればボトルネックも変わります。
月次で次の7項目を確認すると、制作フローの変化を捉えやすくなります。
- 総リードタイムの中央値
- 工程別経過時間
- 工程別待ち時間
- 差し戻し回数
- 差し戻し理由
- 制作途中のWIP
- 公開本数・スループット
前月よりリードタイムが伸びた場合も、すぐに担当者個人の生産性を問題にしないことが重要です。
記事タイプが難しくなった、監修記事が増えた、承認者が増えた、制作途中の記事数が増えたなど、条件の変化を先に確認します。
また、通常記事、取材記事、専門家監修記事を同じ母集団で比較すると、監修工程が必要な記事ほど不利になります。
記事タイプ別に数字を分けて比較してください。
まとめ
コンテンツ制作のリードタイムを改善するには、「記事1本に何日かかったか」だけではなく、その日数の中身を分解する必要があります。
まず、企画確定から公開までの開始点・終了点を固定します。
そのうえで、企画、構成、執筆、編集、確認・承認、公開といった工程ごとに、
- 工程へ入った日時
- 実際に着手した日時
- 完了した日時
- 差し戻し回数
- 差し戻し理由
- 担当者
を記録します。
分析では、実作業時間と待ち時間を分け、中央値、遅延記事、WIP、スループットを確認します。
制作が遅い原因が承認待ちなら、ライターを増やしても大きな改善にはつながりません。差し戻しが多いなら、構成案や制作指示の品質を見直す必要があります。
最初は直近10〜20本程度の記事でも構いません。
現在の制作履歴を工程別に並べ、「記事が最も長く動いていない場所はどこか」を確認することが、制作リードタイム改善の第一歩です。
参考文献・データ元
- The Kanban Guide 2025｜Kanban Guides。WIP、スループット、作業項目の年齢、サイクルタイムの定義確認に使用。The Kanban Guide 参考元URL: https://kanbanguides.org/the-kanban-guide/
- カンバンガイド 2025年5月版｜Kanban Guides。フロー指標の日本語定義確認に使用。カンバンガイド 参考元URL: https://kanbanguides.org/ja/the-kanban-guide/2025.5/pdf/kanban-guide.v2025.5.ja.pdf
- 「SEO記事制作のリードタイムが大幅短縮」｜ツクレルSEO／株式会社マイナビ、2025年4月。企画から公開まで約2か月を要した事例と、修正待ちに関する実務例の確認に使用。ツクレルSEO導入事例 参考元URL: https://seo.tsukrel.jp/article/1433/
- Crafting quality content throughout its lifecycle｜Digital.gov、2024年11月。コンテンツガバナンス、所有者、専門家確認、承認設計の確認に使用。Digital.gov 参考元URL: https://digital.gov/2024/11/12/crafting-quality-content-throughout-its-lifecycle
- Iterating on the GOV.UK content review process｜GOV.UK、2016年9月。レビュー工程の滞留と制作量増加に伴う公開遅延事例の確認に使用。GOV.UK content review process 参考元URL: https://insidegovuk.blog.gov.uk/2016/09/28/iterating-the-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研究情報 参考元URL: https://research.polyu.edu.hk/en/publications/does-regulating-work-in-process-increase-throughput-and-reduce-cy/