データ・KPI

コンテンツ制作のリードタイムは、待ち日数で測る

用語

MA（マーケティング自動化ツール）

公開 2026年10月18日

事例記事1本の公開に10日かかった。会議では「もっと早く書けないか」という話になります。

でも、たとえばその10日のうち、実際に手を動かしていたのは2日だったとします。

残りの8日は、開発の手が空くのを待っていた。法務の確認を待っていた。外注先からの戻りを待っていた。

この場合、書く速さを上げても、待っている8日は1日も縮みません。 測るべきは作業の日数ではなく、待ちの日数です。

置いた材料は、出るまで買い手には存在しない

この数字にこだわる理由は、買い手の側にあります。

ワンマーケティングが2025年9月30日〜10月1日に全国の経営者・役員・購買/契約担当者600名に聞いた調査では、営業担当者と初めて面談した時点で「ほぼ決まっている」が29%、「いくつかの候補に絞り込まれている」が56%でした。合わせて85%です（「BtoB購買プロセス白書2025」、2025年11月発表）。

この調査から言えるのは、買い手の多くが営業に会う前に候補を絞っている、というところまでです。公開が数日早ければ受注が変わる、とまでは言えません。

ただ、時期が決まっている材料は話が別です。

価格改定の説明、展示会の前に置く事例、制度改正への対応。こうした材料の公開が遅れると、その間は営業が初回面談で同じ説明をし直すことになります。

原稿まで書けていても、公開されていなければ、買い手から見れば無いのと同じです。公開までの日数は、制作チームの内部効率だけの話ではありません。

「10日かかった」の中に、10日分の作業はない

公開リードタイムを1本の数字で見ていると、打ち手は作業を速くする方向にしか出てきません。

ライターを増やす。AIで下書きを作る。テンプレートを整える。

どれも作業日を縮めます。待ち日には触りません。

待ち日が生まれる場所は、たいてい作業の外にあります。

軽微な修正でもエンジニアの改修枠に並ぶ。確認者が会議続きで1週間空かない。デザインの外注先が月末にまとめて返す。

どれも、書き手がどれだけ速くても変わらない。

そして厄介なことに、待ち日は誰の評価表にも載りません。待っている間、誰も怠けてはいないからです。

測るのは3つ：日数、待った日数、待った相手

難しい仕組みは要りません。1本ごとに、次の3つを書き出します。

企画から公開まで、何日かかったか
そのうち、待っていた日が何日か
誰を、何を待っていたか

3つ目が一番大事です。

「待ちが長い」で止めると、また全員で「早くしよう」と言い合う会議になります。「開発の改修枠を待っていた」「法務の確認を待っていた」まで書くと、話す相手が決まります。

数え方は先に1行で決めておきます。

開始は依頼チケットを作った日（なければ企画が通った日）、終了は公開日、日数は営業日。待ち日は、原稿が制作担当以外の手元にあった日で、2か所を同時に待った日は1日と数えます。

日付は記憶ではなく、すでにある記録から拾います。タスク管理ツールのステータス変更履歴、確認を依頼したメールやチャットと返ってきた日、CMSの更新履歴。

記憶で書くと、声の大きい人が挙げた待ちの相手がそのまま結論になります。

並べるのは、事例記事どうし、ブログどうしのように同じ種類で最低3本です。種類が違えば確認のルートが違うので、待ちの相手がばらけるのは当然です。1本だと偶然に左右されます。

待ちの相手が揃ったら、最初に直す場所が決まる

3本並べて、同じ相手で止まっていたら、そこが最初に直す場所です。待ちの原因が複数ある組織のほうが普通ですが、全部を一度に直す必要はありません。一番多い1か所から手を付けます。

昨年、あるグローバルブランドでは、キャンペーンページ1本の公開に数週間かかっていました。

コンテンツが無かったのではありません。文言1つの修正にも開発工程が必要だったからです。

CMSとテンプレート、運用フローを組み直して、マーケター自身が公開できるようにしました。企画から公開までのリードタイムは約70〜80%短縮し、いまは即日から数営業日で出ています。

B2Bの会社ではありません。ただ、文言の修正が開発の改修枠に並ぶ構造は、B2Bの企業サイトでもよく見ます。

止まっている場所が1か所に集まっていれば、そこを工程から外すだけで日数はまとまって縮みます。

公開権限を渡すときは、触ってよい範囲を先に分けます。文章と画像の差し替えはマーケが出せる。テンプレート、URL、埋め込みフォームは触らない。

URLやフォームが変わると、MA（マーケティング自動化ツール）の自動化の条件、リダイレクト、メールや広告に貼ったリンク、過去のページ別レポートが切れることがあります。変えるときはMAの担当者が影響を確かめてから、という線を引いておきます。

確認を外すのではなく、確認が要る範囲を先に決める

待ちの相手が法務や上長の確認だった場合、確認そのものを外すのは筋が悪いです。価格や他社比較を載せる記事で確認を飛ばせば、後でもっと大きな手戻りになります。

直すのは確認の範囲です。どの変更なら確認なしで出してよいか、どの種類の記述（価格、他社比較、顧客名、数字を使った主張）なら確認が要るかを、1枚に決めておく。

誤字の修正と、価格の書き換えを、同じ列に並べないことです。

この1枚は、マーケが作って、確認する側（法務や事業責任者）が承認します。マーケだけで決めた範囲は、一度事故が起きると全件確認に戻るからです。

確認が要る区分は、紙で決めるだけでなく、CMSの公開権限を持つ人を絞るなど、運用の側でも止まる形にしておきます。公開済みページの修正も同じ線に乗せます。

確認者の側から見ても、全部が回ってくるより、見るべきものだけが回ってくるほうが早く返せます。

決裁者が決めるのは、待ちの相手ごとの打ち手

上がってきた3本の結果で、上長が判断することは変わります。

開発待ちが重なっていれば、ライターの増員ではなく、CMSやテンプレートの改修を予算に乗せる。法務や上長の確認待ちなら、確認が要る範囲の1枚を、確認者の承認付きで作るよう指示する。外注の戻り待ちなら、契約の納期と戻しの回数を見直す。

増員を承認するのは、待ちが少なく、作業日そのものが詰まっている場合です。

今週、直近の3本で数えてみる

直近に公開した同じ種類のコンテンツを3本選んで、上の3つを書き出してください。タスク管理ツールやメールに日付が残っていれば、15分ほどで終わります。

日付が残っていなければ、まだ「待ち」を記録できていない段階です。

新しい入力欄は作りません。いま使っているタスク管理ツールに「確認待ち（相手名）」のステータスを1つ足し、切り替えた日時が自動で残るようにします。

担当者に日数を書かせる運用にすると、3本目あたりで途切れます。

地味な作業です。でもここが動くと、後ろの工程が全部軽くなります。

公開リードタイムを買い手の検討とつなげて見る考え方は、レベニューアーキテクチャとはの「案件化前」の部分でまとめています。