AIで記事制作の運用を作っていると、仕組みは少しずつ増える。
記事ごとのカルテ。
公開前の本文。
公開済みの原稿。
変更前後の記録。
GOを待つ場所。
人間に残す判断。
増えたものだけを並べると、前より複雑になったように見える。
でも、俺の感覚は逆だった。
仕組みを増やしたあと、運用は前より静かになった。
理由は、作業を増やしたからではない。
迷う場所を減らす境界を作ったからである。
どこを見ればよいか。
どこへ戻ればよいか。
どこでGOを待つか。
何を人間が決めるか。
それが決まるたびに、AIも俺も、次に何を考えればよいかで迷わなくなった。
仕組みを増やしたのに、なぜ静かになったのか
最初は、仕組みが増えるほど運用も重くなると思っていた。
役割を分ければ、読むルールが増える。
記録を残せば、探すファイルが増える。
確認を丁寧にすれば、止まる場所が増える。
その見方だけなら、このシリーズでやったことは面倒を増やしたようにも見える。
ただ、増えたのは機能ではなかった。
境界だった。
今使うものと、履歴として残すもの。
正本と、補助的な記録。
変更前と変更後。
未確認の範囲と、確認済みの範囲。
AIへ任せる区間と、人間が最終判断を持つ場所。
この境界がないと、毎回考えることが増える。
これは今の情報なのか。
このファイルを直してよいのか。
変更後に戻せるのか。
次へ進めてよいのか。
仕組みを増やして重くなるのは、境界のないまま増えるときだった。
境界があれば、増えたものは運用を騒がせない。
次に見る場所だけが残る。
正本を決めると、探す場所が減った
最初に効いたのは、見る場所を決めることだった。
記事の状態はarticle_stateを見る。
本文はdraftを見る。
シリーズの並びはseriesを見る。
公開済みURLや投稿IDはDBで確認する。
要するに、記事の状態を知りたければここ、本文を直したければここ、公開後の事実を確認したければここ、と入口を固定した。
全部を1つの大きなファイルへ集めたわけではない。
問いごとに、正本を1つ決めた。
以前の記事「正本を1つ決めたら、探す時間が減った」で整理したかったのも、情報を減らす話ではなかった。
迷ったときに、どこを見るかを決める話だった。
正本が決まっていないと、確認するたびに複数の場所を見る。
draftにもURLがある。
seriesにも状態がある。
DBにも公開情報がある。
どれかが古くなったとき、正しいものを探す作業が始まる。
正本を決めると、この迷いが減る。
今の答えはどこか。
その問いに対して、見る場所が決まっている。
最新なのはどちらか、こっちも直す必要があるのか、と毎回比べ直さなくてよくなる。
情報が減ったのではない。
見る順番を考えなくてよくなった。
それだけで、制作中の頭の中はかなり静かになる。
archiveへ移すと、現役の場所が軽くなった
次に効いたのは、終わったものを現役の場所から外すことだった。
公開した原稿。
置き換えた旧稿。
不採用にした案。
どれも、消したいわけではない。
あとから理由を確認するかもしれない。
でも、今から直す原稿と同じ場所に並べ続けると、現役の場所が重くなる。
draftsに公開済み原稿が残っていると、次に作業してよいものが分かりにくい。
古いから消すのではない。
役目が終わったから、archiveへ移す。
この基準があると、残すか消すかで迷わなくなる。
残す。
ただし、今の作業場所には置かない。
それができると、過去を失わずに、現役の場所だけを軽くできる。
静かになったのは、ファイル数がゼロに近づいたからではない。
今見るべき場所に、今使うものだけが残ったからである。
beforeを残すと、変更が怖くなくなった
公開済みの記事やページを触るとき、怖いのは変更そのものではない。
何を変えたか分からなくなることだった。
画面が直ったように見えても、別の場所まで変えているかもしれない。
本文を直したつもりで、リンクや見出しまで動いているかもしれない。
だから、変更前の状態をbeforeとして残した。
変更後はafterとして残す。
二つを比べたdiffで、予定した場所だけが変わったかを見る。
これは、AIを信用しないための儀式ではない。
採用するか、戻すかを人間が判断できる状態を作るためだった。
beforeがあると、戻る場所が決まる。
afterがあると、今の状態が見える。
diffがあると、どこが動いたかを確認できる。
変更前に戻れると分かっているだけで、次の変更は落ち着いて見られる。
変更が怖くなくなったというより、変更後に何を見ればよいかが決まった。
それが静かさだった。
GOを小さくすると、任せられる範囲が広がった
小さく進めることも、ただ慎重にするためではなかった。
「一度に全部直さない。1か所ずつGOを出す」では、トップページのカードリンクを最初から4枚まとめて通さなかった。
一度に全部直すと危ない、という一般論を書きたかったわけではない。
未確認だったのは、WordPressを通ったあとにリンク構造がどうなるかだった。
だから、確認したい答えを得られる最小の範囲に絞った。
1枚で構造が成立するか。
PCとスマホで見えるか。
TabとEnterでも使えるか。
そこまで確認できれば、同じ構造の残りはまとめて進められる。
小さくしたのは、作業件数ではない。
未確認の範囲だった。
この考え方があると、GOの意味も静かになる。
全部を任せる合図ではない。
次の確認地点まで進めてよい、という許可である。
どこまで任せてよいかが決まると、AIへ渡す範囲も決めやすくなる。
人間に残す判断を決めると、AIに任せる区間が見えた
最後に残ったのは、人間が持つ判断だった。
前の記事「自動化しない仕事を先に決めた」では、公開、GO、採否を人間に残した。
公開は、外へ出してよいか。
GOは、次にどこまで任せてよいか。
採否は、記事の意味を変えてよいか。
この3つは、操作の難しさで分けたのではない。
結果を誰が引き受けるかで分けた。
人間に残す判断を決めると、逆にAIへ任せられる区間が見える。
本文を書く。
self_checkをする。
内容レビューとSEOレビューを並べる。
auditで整合を見る。
その区間は、止めずにまとめて進められる。
止める場所が決まっているからである。
どこでAIを止めるかを、毎回その場で決めなくてよくなった。
人間の仕事を増やしたのではない。
人間が持つ判断を先に決めたから、止めなくてよい区間をAIへ渡せた。
静かになったのは、AIが全部やるようになったからではない。
人間が戻る場所が、はっきりしたからだった。
静かな運用とは、何もしないことではなかった
このシリーズを振り返ると、やったことは多い。
正本を決めた。
archiveへ移した。
beforeを残した。
GOを小さくした。
人間に残す判断を決めた。
並べると、仕組みは増えている。
それでも、運用は前より静かになった。
なぜなら、それぞれが次の迷いを減らしているからである。
どこを見るか。
どこへ置くか。
どこへ戻すか。
どこまで進めるか。
どこで人間が決めるか。
この問いに答えがあると、毎回考え直さなくてよい。
静かな運用とは、何もしないことではない。
必要な場所で止まり、必要のない場所では止まらずに進むことだ。
仕組みを増やしても、迷う場所を増やさなければ、運用は重くならない。
次に見る場所、戻る場所、GOを待つ場所が決まっている制作環境だった。
だから最後に、前より静かになった。
コメント