AIエージェントの運用で記事を1本回せるようになると、次は別のものが増え始める。
止まる場所を書くルール。
記事ごとのカルテ。
下書き、レビュー、公開後の記録。
ひとり編集長だけで始めたときより、できることは増えた。
でも、増えたものを全部そのまま使い続けると、今度は読む場所が増える。
どれが今のルールなのか。
どれが終わった記録なのか。
まだ必要になるか分からないものは、どこに置けばいいのか。
S4で考えたいのは、新しい仕組みの作り方ではない。
作った仕組みを、次の記事でも重くしない方法である。
仕組みを作ると、次に増えすぎる
最初は、記事を止める場所だけを決めれば足りる。
繰り返すうちに、同じルールをAGENTS.mdへ残す。
仕事が重くなれば、researcherやwriterのように役割を分ける。
ここまでは、前のシリーズで進めてきた流れである。
ただ、役割やルールが増えると、残った記録も増える。
使っている指示。
公開前のカルテ。
公開済み記事の、制作時の下書き。
変更前後を比べた施工記録。
どれも作ったときには必要だった。
だからといって、すべてを毎回の制作で読む必要はない。
増えたものを残すことと、増えたものを現役に置き続けることは別だった。
仕組みは、作ったあとにも整理がいる。
今使うものだけを現役に残す
今の記事を作るときに、次の判断へ直接使うものがある。
たとえば、どこで止まるかを書いたルール。
今回の記事で何を書くかを決めたカルテ。
まだ公開していない本文。
これは、次の工程を進めるために読む。
だから現役に残す。
一方で、前の記事で使った確認項目まで、毎回の入口に並べる必要はない。
前の記事のために作ったものが、次の記事の判断を助けるとは限らないからである。
俺は、繰り返すルールだけをAGENTS.mdへ残した。
会話で一度しか使わなかった文まで残すと、次に読むものが増えると分かったからだ。
繰り返すルールだけをAGENTS.mdへ移したのも、仕組みを増やすためではない。
次の記事で、同じ判断を探さないためだった。
現役に残すのは、今の制作を動かすものだけでよい。
履歴として残すものを決める
現役ではなくなっても、消してよいとは限らない。
公開後の施工では、変更前の状態、変更後の状態、差分、確認結果を残している。
何を変えたかが後から分からなくなると、戻す場所も分からなくなるからだ。
公開済みになった本文も同じである。
下書きとしては役目を終えている。
それでも、公開時点で何を確認したかをたどる記録にはなる。
現役の場所に置いたままなら、進行中の記事と混ざる。
消してしまえば、確認した経緯まで失う。
だから、終わったものは現役から外し、履歴として残す。
ここで大切なのは、履歴を増やすことではない。
今の制作で見るものと、必要になったときだけ見るものを分けることである。
archiveをどう分け、いつ移すかは、次の記事「終わったファイルは消さずにarchiveへ移す」で詳しく扱う。
まだ決めないものは保留する
仕組みを作っていると、先に決めたくなるものがある。
新しい役割。
細かい保存ルール。
次に使うか分からないテンプレート。
でも、まだ困っていない仕事まで現役のルールに入れると、確認する場所だけが増える。
前のシリーズで、最初から役割を並べなかったのも同じ理由だった。
まだ重くなっていない仕事は、役割にもルールにもしていない。
保留は、決めるのを忘れるための場所ではない。
使う必要が出たときに、もう一度判断するための状態である。
今の制作を進めるものでもない。
履歴として確定したものでもない。
その間に置くことで、見通しが少し軽くなる。
全部に名前を付けなくても、記事は進む。
増えた仕組みを、全部は残さない
仕組みを増やすと、複雑になるように見える。
実際、役割、ルール、カルテ、記録は増えた。
でも、毎回その全部を使うわけではない。
今の記事を動かすものだけを現役にする。
終わった判断は、履歴として残す。
まだ必要か分からないものは、保留する。
この三つを分けると、増えた仕組みが一度に目の前へ出てこない。
俺が減らしたかったのは、ファイルの数だけではなかった。
次に何を見ればいいか迷う時間だった。
正本をどこに置くかは、「正本を1つ決めたら、探す時間が減った」で決める。
終わったファイルをどうarchiveへ移すかは、次の記事で決める。
その前に必要なのは、増えたものを全部残す必要はないと決めることだった。
コメント