「新しい記事を出して」
自動記事工場が出勤した。まず記事の一覧を確認。次に検査の進捗、翻訳の状況、公開待ちの一覧を確認。台帳を作り直して保存し、全体の数字が合っているか確認する。
準備に約23分。肝心の記事処理には入れなかった。
これは匿名化した実行記録の一例。全体の状態を整えるのに約8分、保存に約15分かかり、そのまま処理が強制終了した。すべての工場が毎回23分かかるという話ではない。
全員が朝礼に出て、出勤簿にハンコを押し、何も作らず帰った。しかも無人の自動工場で。
記事より先に、管理するための表が増える
台帳は「どの仕事がどこまで終わったか」を書く表だ。最初は便利だったはず。「原稿あり」「確認済み」「公開待ち」と分かれば、同じ記事を二度作らずに済む。
ところが、原稿一覧、確認済み一覧、翻訳待ち一覧、公開待ち一覧、担当ごとの進捗表……と増えていく。表同士が食い違うと困るので、今度は表を照合するための表が必要になる。
「記事は？」 「台帳を更新中です」 「終わった？」 「台帳の更新履歴を確認中です」
経理部がロボットを作ったら、ロボットまで経理部に就職してしまった。
台帳を守るため、工場を止める
もっと困るのは、記事と関係のない進捗表を書き換えただけでも、「公開するデータが変わった」と判断される場合だ。公開担当が作り直している途中に別の表が更新され、最初からやり直す。
そこで「公開中はほかの担当者が書き込まない」という待機が生まれることさえある。
台帳を更新すると公開が止まる。公開を守るために台帳の更新を止める。
スーパーがレジ待ち人数を数え直すためにレジを閉めた。誰も買い物できないのに、行列の集計だけ完璧だ。
分業したつもりが、全員台帳係
本来は単純でいい。書く担当は原稿を保存する。公開担当はその原稿を必要な範囲だけ確認して、読める場所へ届ける。見張り担当は本当にページが開けるか確かめる。
ところが全員が同じ巨大な表を直し、最新版を待つなら、その表が止まると全員止まる。
十人雇っても、ハンコを押す窓口が一つなら行列が長くなるだけだ。
「台帳は全部いらん」で大丈夫？
巨大な進捗表や同じ情報のコピーは削れる。でも、記録を一切なくすのは別の話。
最低限、どの記事のどの版をすでに公開したかは分かるようにしたい。途中で止まったときの再開場所も必要だ。これがないと、同じ記事を二度公開したり、古い版で新しい原稿を上書きしたりする。
ただし、公開済みのページや既存の保存場所から分かるなら、別の表へ何度も書き写す必要はない。
新しい記事が来たら、その記事だけ調べる。変わっていない一覧は作り直さない。監視や集計が遅れても、合格した記事の公開を人質にしない。
工場の成績は台帳を何回更新したかではなく、読者が新しく読めるようになった記事の数で決まる。
「本日の報告：台帳の整合性100点。記事の公開0本」
そんな満点は、もういらない。
