researcher、writer、レビュー役、画像、公開後施工。
名前だけを並べると、記事を書く前から小さな会社を作る話に見える。
今の仕組みだけを見ると、最初から全部の役割を用意しないといけないように見える。
でも、今から同じ仕組みを作るなら、完成済みの編集部を再現する必要はない。
以前の記事「最初からAI社員を作らない。コピペでひとり編集長を起動する」で置いたのは、雑メモを企画へ整理し、GOを待つひとり編集長だった。
そこから記事を回し、重くなった仕事だけを役割として切り出していけばいい。
最初から編集部を作らなかった
最初からAI社員を増やすと、誰に何を頼むかを決める仕事が先に始まる。
researcherには何を調べさせるのか。
writerにはどこまで決めさせるのか。
レビュー役は、どこまで直してよいのか。
まだ1本も記事を回していない段階では、その答えはなかった。
だからS3では、まずひとり編集長だけで始める形にした。
雑メモを渡し、企画案で止まり、人がGOを出す。
その流れが動くかを確かめる方が、役割表を完成させるより先だった。
編集部は、最初に用意するものではなかった。
役割を増やす前に、詰まった仕事を見る
役割を分ける理由は、仕事の名前ではない。
ひとり編集長の中で、何が混ざり始めたかである。
本文を書く前に、別の根拠を確認したくなる。
本文を書いてから、別の視点で直す範囲を決めたくなる。
公開したあとに、DBや目次の仕事が残る。
この仕事を同じ流れで進めると、次に誰が何を確かめるのかがぼやける。
俺が見たのは、AIが足りない場面ではなかった。
判断の種類が混ざる場面だった。
調査と本文は、必要になってから分けた
競合分析だけを本文の前に置いた記録がある。
書く前に、上位記事が実装Tipsへ偏っていると分かり、運用設計という切り口が残った。
この確認は、本文を書く仕事とは別だった。
一方でwriterには、カルテに残した主張、H2構成、書かないことを渡し、本文だけを担当してもらった。
本文が書けるようになると、構成や差別化の判断がどこにあるかも見えた。
調べることと書くことは、どちらも必要だった。
ただ、同じ役割に混ぜたままにする理由はなかった。
判断を重ねる仕事は、レビューとして分けた
本文ができたあとも、仕事は終わらなかった。
内容を読んで、記事の核から外れていないかを見る。
SEOを見て、入口を整えるために本文の考え方まで薄くしていないかを見る。
この二つは、本文を書いた本人とは別の視点が必要だった。
レビューで見たかったのは、AIがどれだけ賢いかではない。
どこまで直してよいかだった。
本文の正しさと、読者の入口を同じ判断にしない。
それも、仕事を分けた理由の一つだった。
画像と公開後施工も、別の重さになった
記事の画像は、本文ができたあとに同じ案件の続きとして作る。
画像を作る判断と、公開後にサイトを整える判断まで、ひとり編集長へ戻すと仕事がまた重くなる。
だから、画像が重くなったらcreative_directorへ渡す。
公開を押すのは人間に残し、公開後にDB、目次、series、前後ナビ、本文内リンク、archiveが残ったら、公開後施工としてjissouへ渡す。
先に役職を作ったのではない。
記事を1本回したあとに残った仕事へ、あとから名前を付けた。
役割は増やすものではなく、詰まりを切り出すもの
AI社員の数が多いほど、記事制作が進むわけではない。
まだ困っていない仕事まで分けると、確認する項目だけが増える。
俺が役割を考えるときは、先に四つを見る。
その仕事は、本文とは別の根拠が必要か。
本文を書いた人とは別の判断が必要か。
外部操作や公開後の確認が残るか。
同じ説明を、次の記事でも繰り返しているか。
どれかが残ったときだけ、役割にする理由ができる。
役割は、詰まりの名前だった。
ひとり編集長を使い続けたら、編集部になった
最初は、ひとり編集長から始めた。
S3-3からS3-5では、どこで止まり、誰が公開を決めるかを分けた。
前の記事「毎回のコピペが面倒になったら、AGENTS.mdに移す」では、繰り返す判断をAGENTS.mdへ残した。
今の編集部だけを見ると、最初からこの形を作らないといけないように見える。
でも、読者が同じ順番で作る必要はない。
ひとり編集長で記事を回す。
重くなった仕事だけを切り出す。
また回して、次に重くなった仕事を分ける。
AI社員の数を増やすことが目的ではない。
ひとり編集長を使い続けると、必要な仕事だけが残り、それが編集部になる。
コメント