メディア企業7 件中 6 件目のシナリオ

7つ目のプラットフォームにクリップが届いたころには、そのニュースは終わっていた。

速報動画を7つの配信先に向けて、順番に、手作業で切り出すソーシャルデスク。4つ目あたりでニュースの旬を逃していました。

Ledgerfield Media·想定モデル:デジタル動画パブリッシャー、従業員90名、ソーシャルデスク12名参考シナリオ

概要

4 分で読めます6 / 7
セグメント
メディアデジタル動画パブリッシャー
チーム規模
12ソーシャルデスク、6ジャンル、4番組
チャンネル
7YouTube、TikTok、IG、FB、X、Threads、Snap
効果が出るまで
5 週間既存 CMS との API 連携
Placeholder

1本のカット、7つの配信先へ並行公開

API を起点にした配信と編集レビューArt pending: 1600×1000

01. 状況

以前のかたち

報道機関の配信の問題は時間の問題であり、このデスクは時間で負けていました。

16時12分に何かが起きます。映像チームは16時26分までに90秒のカットを用意します。そこからは競争で、デスクの仕事は、インターネットの他の全員が同じことを言う前に、そのカットを7つの配信先へ届けることです。

配信先ごとに求めるものが違います。ここは縦型、あちらは正方形、1つは 16:9。再生の85%がミュートされるプラットフォームには焼き込みの字幕を1つのスタイルで、別の場所では別のスタイルで。隣のプラットフォームより視聴者が20歳若い配信先には、それに合わせた見出しを。サムネイルは2つには必要で、残りには不要です。

そこでプロデューサーは7つのタブを開き、上から順に片づけていきます。最初のプラットフォームにクリップが届いたのは16時31分。7つ目に届いたのは17時4分ごろでした。

02. 摩擦

何を失っていたか

デスクの処理量は手作業のフォーマットで頭打ちになり、リストの最後のプラットフォームは常に負けていました。

完成したカットがすべての配信先で公開されるまでの中央値は38分でした。この数字は本当の損失、つまり「ばらつき」を隠しています。最初のプラットフォームには5分で、最後には38分で届くため、動きの速いニュースでは、後ろのプラットフォームは他社版を中心にすでに形成された会話の中へ投稿することになります。それらのチャンネルの数字は一貫して弱く、デスクは次第にそれを「あのプラットフォームはニュースに向かない」と読むようになっていました。「自分たちが最後に着いている」ではなく。

1週間で、デスクは約190本を公開していました。その数倍を生み出している動画ライブラリを抱えながらです。アーカイブ素材、つまり数年単位の寿命を持つ解説動画や番組の一部は、ほとんど再公開されませんでした。再公開のたびに速報と同じ手作業のフォーマットが必要で、速報がいつもキューを勝ち取るからです。

合計すると、12人のうち実質2人分が、すでに作られた素材のトリミング、字幕の付け直し、タイトルの付け直しに費やされていました。ニュースサイクル中の記者の時間が制約になるデスクにおいて、機械的な変換に2人分というのは、ニュースを扱えるかどうかと、きちんと扱えるかどうかの差そのものです。

What this was costing

  • 完成から7つの配信先すべてに届くまでの中央値38分
  • 最初と最後のプラットフォームの差約33分
  • 週あたりの公開本数≈190
  • 作り直しに使われるデスクの人員≈2 FTE

03. 変わったこと

作り直したワークフロー

デスクは7つのバージョンを作るのをやめ、7つのバージョンを確認するようになりました。

  1. API + webhooks

    報道側のシステムが、公開の引き金を引く

    既存の動画 CMS が、カットに完成の印が付いた時点で API を呼び出します。ファイルを書き出して別のツールへ入れ直す人はいません。クリップは、デスクがすでに使っているシステムから公開パイプラインへ入ります。Webhook が公開と成果のイベントを返すため、報道フロアのダッシュボードには、誰も報告しなくても配信状況が表示されます。

  2. 1回のアップロード → 各プラットフォーム版

    7つの配信先は、順番ではなく並行で作られる

    1本のマスターから、すべてのアスペクト比、字幕スタイル、プラットフォームごとの見出しとサムネイルが同時に生成されます。最初と最後のあいだにあった33分の差は消えました。7つ目は、6つ目を人が終えるのを待っていないからです。

  3. 承認ワークフロー

    編集者が、7本まとめて一度だけ確認する

    報道機関にとってここが要です。生成された見出しと字幕はあくまで案であり、デスクの編集者が7本すべてを1画面で見て、公開前に承認するか書き直します。デスクは速さを得ながら、社名を背負った見出しが誤って出るのを止めるチェックを手放しませんでした。

  4. クロスプラットフォーム分析

    同じニュースの成果を、配信先どうしで比べる

    1つのニュースの7プラットフォームでの成果が、1つのビューに並びます。それがデスクの思い込みを正しました。クリップが同時にすべての場所へ届くようになると、見限っていた2つの配信先が、上位と同じ水準の成果を出したのです。

報道機関にとって意味のある数字は、週あたりの投稿数ではありません。カットが用意できてから視聴者が目にするまでの分数であり、それはいまや制作のサイクルではなく確認のサイクルです。

04. 結果

何が、いつまでに動いたか

  • 完成から全配信先で公開されるまでの中央値

    38分6分

    6週目までに

  • 週あたりの公開本数

    ≈190≈415

    10週目までに、人員追加なし

  • 配信に戻したアーカイブ動画

    ≈04,100

    API 経由で3か月

  • 作り直しに使われるデスクの人員

    ≈2 FTE約0.4 FTE

    10週目までに

結果を生んだ要因についての、正直な注記

はっきり書いておくべき注意が2つあります。1つ目に、6分という数字は完成から公開までであり、編集者のレビュー時間は含みません。デスクはこれを意図的に残しており、判断の割れるニュースでは2〜4分が加わります。レビュー段階を外した報道機関はもっと速く投稿できますが、外すべきではありません。2つ目に、公開本数の増加はアーカイブの遡り公開によるところが大きく、旧作を出し切ったあとの新規素材の持続的な週次ペースは、415本より260本に近い水準に落ち着きました。

2つのプラットフォームはニュースに向かないと見限っていました。向いていなかったのではありません。毎回、30分遅れで着いていただけでした。

ソーシャル責任者(デジタル動画パブリッシャーの想定モデル)参考シナリオ

05. ここから学べること

他でも使える教訓

Useful whether or not you ever open NOWScale: these are the parts that generalise.

  • 中央値だけでなく、ばらつきを測る

    最初と最後の配信先が30分離れているなら、平均の公開時間は誰も経験していない状態を説明しています。損失があるのは、後ろの側です。

  • 弱いチャンネルではなく、遅いチャンネルではないか確かめる

    順番に手作業で公開する運用は、リストの下にあるものを構造的に不利にします。そのプラットフォームは自社のコンテンツに合わないと結論づける前に、到着時刻を揃えてもう一度見てください。

  • 制作は自動化し、編集のチェックは残す

    7本の見出しを作るのはフォーマット作業です。その見出しが世に出せるものかを判断するのは違います。速さは前者をなくすことから生まれ、リスクは後者までなくすことから生まれます。

  • アーカイブは、すでに支払い済みの在庫

    再公開のたびに速報と同じ手作業がかかり、速報が必ず勝つため、寿命の長い素材は眠ったままになります。再公開をほぼゼロコストにすれば、旧作のカタログが配信チャンネルに変わります。