正本を1つ決めたら、探す時間が減った

記事制作の仕組みを作ると、ファイルは少しずつ増える。

記事ごとのカルテ。

公開前の本文。

シリーズの一覧。

公開済み記事を確認するDB。

どれも必要だから作った。

ただ、同じことが二つの場所に書かれ始めると、次にどこを見ればよいか分からなくなる。

俺が決めたかったのは、全部を1つのファイルへ集めることではなかった。

情報の種類ごとに、今見る場所を1つにすることだった。

ファイルが増えると、同じ情報が並び始める

記事を作る前には、タイトルや書かないことを決める。

本文を書いたら、見出しや内部リンク候補が増える。

公開したら、URL、投稿ID、公開状態を確認する。

それぞれの時点で必要な記録は違う。

それなのに、記事の状態を本文の末尾にも、シリーズ一覧にも、DBにも書き始めると、少しずつ内容がずれる。

下書きではまだ公開前なのに、一覧だけ公開済みに見える。

シリーズの順番をDBに書こうとして、記事のURL確認まで混ぜてしまう。

たとえば公開したあと、draftにもseriesにもDBにも公開URLを書く。

あとでURLを直し、DBだけを更新すると、別の場所には古いURLが残る。

どちらが正しいかを確認する作業が、そこから始まる。

ファイルが多いこと自体が問題ではない。

同じ判断の答えを、複数の場所へ置くことが重くなる。

正本が決まっていないと、確認するたびに探す場所が増える。

正本は、1つのファイルではなかった

正本と聞くと、全部の情報を集めた大きなファイルを想像しやすい。

でも、記事制作では情報の種類まで同じではない。

今どの工程にいるか。

本文はどこまで書けたか。

シリーズの中で何本目か。

公開URLと投稿IDは何か。

これを1か所へ集めると、今度はそのファイルが何のためにあるのか分かりにくくなる。

だから俺は、情報の種類ごとに正本を分けている。

記事の判断と進行はarticle_state。

公開前の本文はdraft。

シリーズの並びはseries_s4.md。

公開済み記事のURLや投稿IDの照合はarticles.db。

1つのファイルにまとめるのではない。

1つの問いに対して、見る場所を1つ決める。

それが、この運用でいう正本だった。

自分の環境で置き換えるなら、ファイル名まで同じにする必要はない。

知りたいことと、見る場所の組み合わせだけを決めればよい。

知りたいこと	見る場所
今どこまで進んでいるか	制作管理ファイル
今の本文はどれか	下書き
シリーズの順番は何か	シリーズ一覧
公開URLは何か	公開記事台帳

記事の判断はarticle_stateに残す

記事の核、読者、書かないこと、停止した場所。

こうした制作中の判断は、article_stateに残す。

本文だけを読んでも、なぜその見出しにしたか、何をあえて書かなかったかまでは分からない。

逆に、カルテだけでは公開する本文にならない。

役割が違うから、本文とカルテを同じものとして扱わない。

1本の記事をカルテ1枚で回したときも、本文そのものではなく、判断と停止と引き継ぎが残った。

カルテ1枚で記事制作を回した記録は、その違いを確かめた実践記録である。

記事の状態を確認したいときは、本文を探さない。

article_stateを見る。

判断の正本を決めると、本文の中から経緯を掘り返さなくてよくなる。

本文、シリーズ、公開記録は別の場所に置く

draftは、公開前に直す本文の正本である。

まだ公開していないなら、まず本文を直す。

series_s4.mdは、S4の何本目で、次に何を扱うかを制作側で追うための記録である。

読者が記事を移動するための目次や前後ナビとは、役割が違う。

articles.dbは、公開後の記事をURL、投稿ID、公開状態と一緒に照合する台帳になる。

DBへ登録した記事をあとから追えるようになった話は、公開後にDBへ記録した実践記録に残してある。

ここで大切なのは、DBが記事制作のすべてを決めるわけではないことだ。

公開済みかを確かめるならDBを見る。

今書いている本文を直すならdraftを見る。

何を決めたかを確かめるならarticle_stateを見る。

情報の置き場所を分けるのは、情報を遠ざけるためではない。

必要なときに、迷わず取り出すためである。

正本の決め方は、3つだけでいい

最初に、その情報を更新する場所を決める。

記事の状態を変えたら、制作管理ファイルを更新する。

公開URLを変えたら、公開記事台帳を更新する。

次に、同じ答えを別の場所へ重ねて書かない。

本文の末尾やメモに、状態やURLの控えを増やし始めると、後でどれが正しいか迷う。

最後に迷ったら、この質問はどこを見れば分かるかを1つ決める。

自分の環境にarticle_stateやarticles.dbがなくても、この決め方は使える。

ファイル名ではなく、問いと見る場所を固定する。

それだけで、正本は作り始められる。

正本を1つ決めたら、探す時間が減った

記事制作の仕組みが増えると、見る場所も増える。

だから、全部を減らす必要があるように感じる。

でも、必要な記録まで消す必要はなかった。

記事の判断はarticle_stateに残す。

本文はdraftで直す。

シリーズの並びはseriesで見る。

公開済み記事の照合はDBで行う。

同じ情報を何度も書かない。

次に知りたいことごとに、見る場所を1つ決める。

それだけで、制作中にファイルを開く順番が少し静かになる。

俺が減らしたかったのは、記録の数ではなかった。

今の答えを探すために、同じことを何度も読み直す時間だった。