編集パイプラインを組み直す: 公開までのリードタイムを短くする

編集のリードタイムを短くしたい——多くのメディアで語られる願いだ。書く速さを上げようとすると、質が落ちる。人を増やそうとすると、費用が跳ねる。だが、実際に時間を溶かしているのは、書く工程ではなく、その前後の待ちであることがほとんどだ。

待ちを可視化する

まず、1本の記事が構想から公開まで、どの工程で何日を過ごしているかを1週間だけ計測する。書く時間は意外に短い。ネタ会議までの待ち、レビュー担当が忙しくて滞留、画像作成の待ち——ここに時間が溜まっている。書く工程を10%短くするより、待ち時間を50%削るほうが総リードタイムには効く。

並行化を疑う

「原稿ができてから画像を作る」「校正が終わってから見出しを決める」——こうした慣習は、多くの場合、順序ではなく習慣で決まっている。原稿の骨子ができた段階で画像発注に入れれば、待ち時間はまるまる縮む。私たちは案件ごとに「並行できる工程」を書き出し、順序が慣習になっているだけの直列を洗い出している。

順序は必要でも、直列である必要は多くない。

承認の数を削る

「念のため」で増やした承認者は、たいてい価値を追加していない。実質的なフィードバックを返している人が誰かを、直近3か月の履歴で確認する。返していない人は、通知の対象から静かに外していく。関わっていることと、意思決定に必要であることは違う。品質の関所を通す条件の考え方は別記事を参照。

編集フローと自動化

編集のリードタイム短縮は、自動化と組み合わせるとさらに効く。CMSへの入稿、フォーマット確認、公開通知——反復の部分を自動化し、判断の部分に人が集中する。基礎はクリエイティブワークフローの自動化で扱った。

速さと質は対立しない

「速くすると質が落ちる」は、書く時間を削ったときの話だ。待ちを削っても、書く時間は変わらない。むしろ、余裕を持って書く時間が確保できるようになるので、質は上がることのほうが多い。

反論: 手続きを軽くすると事故が増える

手続きの重さと事故の少なさは、単純比例しない。事故の多くは、手続きが多すぎて誰も読まなくなった結果として起きる。「軽くしても事故が増えない設計」を追うほうが現実的だ。ただし、法的な確認や外部との契約に関わる工程は例外で、ここは軽くしてよい理由がほぼない。境界を明確にして扱う。

参照

• Anderson, David J. “Kanban: Successful Evolutionary Change for Your Technology Business.” Blue Hole Press, 2010.
• Reinertsen, Donald G. “The Principles of Product Development Flow.” Celeritas, 2009.

編集フローの再設計は、書く力そのものよりも先に効く。原稿を短時間で仕上げる訓練より、待たない工程を作るほうが、たいてい早く成果が出る。