前回、投稿を仕組みにした。
WordPressへの下書き保存までは自動、公開は俺が押す。
それで一つ片づいた。
でも記事が増えていくと、次に必要になったのは、内部リンクの設計だった。
「見つけやすさ」が壊れ始めていた。
記事が増えてきたら、次に壊れるのは「見つけやすさ」だった
記事を管理する台帳、articles.dbで記事を管理できるようになった。
WordPressに下書き保存するスクリプト、post_draft.pyで下書き保存も仕組みになった。
投稿の工程は片づいた。
でも記事が増えるほど、別の問題が出てきた。
どの記事にどのリンクを張ったか、俺自身が覚えていられなくなった。
10本くらいまでは頭の中で足りていた。
このシリーズが8本目に近づいたあたりで、もう無理だった。
書いた記事は増える。
でも記事同士のつながりは、増えた分だけ手作業で追いつかせるしかなかった。
目次は読者のため、内部リンクは構造のためだと思っていた
最初、目次と内部リンクは別のものだと思っていた。
目次は読者が本文を探しやすくするための機能。
内部リンクは、前の記事や関連記事に飛ばすための機能。
役割が違うから、別々に考えていた。
記事を書き終えるたびに、内部リンクをどこに張るか、そのつど考えていた。
貼り忘れに気づいたのは、あとから読み返したときだった
記事を書いた時点では、次の記事がまだ存在しない。
だから内部リンクは、その場で完結しない。
あとからつなぐ場所を残しておく必要があった。
読み返して気づいたことがある。
内部リンクを、その場の思いつきで張っていた記事があった。
原因は単純だった。
内部リンクを「本文を書きながら考えるもの」にしていたからだ。
書くことと、つなげることを、同じタイミングでやっていた。
その場で貼る、をやめることにした
書きながら内部リンクを考えるのをやめることにした。
理由は、書く作業とつなげる作業は、そもそも判断の種類が違うからだ。
書く作業は、その記事の中で何を伝えるかを決める作業。
つなげる作業は、シリーズ全体でどの記事とどの記事が結びつくかを決める作業。
同じ人間が同じタイミングでやると、どちらかが手を抜かれる。
たいてい、つなげる方が抜かれた。
内部リンクは編集長が決め、施工はjissouに渡した
以前、記事を書く前に設計書を作ることにした。
今回もその考え方の延長だった。
だから役割を分けた。
内部リンクをどこに張るかを決めるのは、編集長（henshucho）の仕事にした。
実際に本文へ差し込む作業は、実装担当のjissouに渡すことにした。
決める人と、貼る人を分けた。
このカルテ、つまり記事ごとの状態管理ファイルに、henshuchoが「入れるリンク」「受けるリンク」「前後ナビ」を書く欄を作った。
writer、つまり本文を書く担当は、そこに書かれた方針を読んで本文に反映するだけになった。
自分でリンク先を思いつく必要がなくなった。
H2構成も、本文を書く前に決めるようにした
目次も、内部リンクと同じ問題を抱えていた。
見出しの構成を、記事を書きながらその場で組み立てていた。
毎回同じような判断を、毎回一からやり直していた。
目次も内部リンクと同じで、「本文を書く前に決めておくもの」に変えた。
H2構成そのものを、henshuchoが発注の段階で先に決める。
writerは、決まった構成に沿って書くだけになった。
目次と内部リンク、どちらも「読者のための機能」である前に、「サイトの骨格」だった。
記事の集まりが、導線を持った瞬間にサイトになった
記事が増えることと、サイトになることは、別の話だ。
記事を10本書いても、それぞれが単体で完結していたら、ただの記事の集まりのままだ。
どの記事から入っても、次に読むべき記事へ自然につながる。
その導線ができたとき、初めてサイトになる。
導線は、書いたあとに思いつきで足すものじゃない。
先に設計して、あとから機械的に流し込むものだ。
まだ全部はつながっていない。次は実装エージェントで仕組みにする
正直に書くと、まだ全部の記事がつながっているわけじゃない。
内部リンクの方針は決めた。
でも実際に本文へ差し込む作業は、まだ人間が確認しながら進めている部分がある。
その施工を担当するのが、実装エージェント（jissou）だ。
jissouがどういう役割を持っているかは、次の記事「実装エージェントを作った。AIに全部やらせず、担当を分ける」で書く。
サイトとは、迷わせない設計のことだった
目次と内部リンクは、記事を書くたびに考える作業じゃなかった。
先にサイトの骨格を決めて、あとから機械的に流し込む。
決める人と、貼る人を分ける。
それができたとき、ブログは記事の集まりから、サイトになった。
サイトとは、読者を迷わせない設計のことだった。
コメント