MANIARUでは、実際に試した過程をPROJECTに残し、そこで分かったことをCATEGORYの記事として整理しています。
最初は、実験の記録も方法の解説も同じ記事にまとめればよいと考えていました。しかし記事が増えると、時系列で読みたい人と、必要な方法だけを知りたい人では、求めている入口が違うことが分かりました。
そこで、PROJECTを実験の一次記録、CATEGORYを再利用できる知識として分け、由来が明確な記事だけを相互につなぐ形にしました。この記事では、MANIARUで現在使っている記事設計と、実際のクロスリンクを整理します。
なぜPROJECTとCATEGORYを分けたのか
PROJECTの記事には、何を作ろうとしたか、どの順番で進めたか、途中で何が起きたか、その時点でどう判断したかを残します。PROJECT 001 — MANIARUを作る。では、コンセプト決めから公開後の改善までをSTEPとSPECIALに分けて記録しています。
この流れは、サイトがどのようにできたかを追うには役立ちます。一方で、特定の実装方法だけを知りたい人にとっては、長い経緯の中から必要な箇所を探すことになります。
反対に、方法だけを整理すると読みやすくなりますが、どのような状況で必要になり、実際にどう使ったのかが見えにくくなります。そこで二つの記事に同じ役割を持たせず、実験と知識を分けることにしました。
PROJECTは実験の一次記録
PROJECTに残すのは、完成後に整えた手順だけではありません。試したこと、起きたこと、判断したこと、残った課題を、その実験の流れに沿って記録します。
成功した部分だけを切り出すと、なぜその方法を選んだのかが分からなくなります。うまくいかなかった方向や、あえて直さなかった部分も、次の判断に使える情報です。
PROJECTは、あとから振り返ったときに実験の前提と経緯を確認できる場所にしています。
CATEGORYは再利用できる知識
CATEGORYでは、PROJECTなどの実体験から、別の場面でも使える方法や注意点を取り出して整理します。
たとえば、あるサイト改善の中で使ったCSSを、そのPROJECTだけの話として終わらせず、同じUIを作るときに確認できる記事へまとめます。読者はPROJECT全体を読まなくても、目的に合う知識へ直接進めます。
MANIARUでは、AI、BUILD、WEB、CODE、GROW、MONEYを知識への入口として使っています。CATEGORYは実験を置き換える記事ではなく、実験から取り出したマニュアルです。
CATEGORY記事として切り出す基準
実験の中で分かったことを、すべて別の記事にするわけではありません。MANIARUでは、次のような場合にCATEGORY記事として整理します。
- PROJECTの外でも使える方法や判断基準がある
- 一つのテーマとして説明できるだけの具体的な経験がある
- 読者がその知識だけを探す場面が想像できる
- 元の実験と分けても、事実関係や前提を失わない
逆に、その場だけの細かな変更や、まだ再利用できる形まで理解できていない内容は、PROJECTの記録に留めます。記事数を増やすことより、切り出す意味があるかを優先しています。
PROJECTからCATEGORYへ進む導線
PROJECTの記事から生まれたCATEGORY記事がある場合、記事末尾にLEARN FROM THIS EXPERIMENTを表示します。日本語では「この実験からまとめたマニュアル」としています。
これは一般的な関連記事の一覧ではありません。その実験から、どの知識を取り出して整理したのかを示すための導線です。
PROJECTを読んで経緯を理解したあと、具体的な方法を確認したいときにCATEGORYへ進めます。実験の流れと、再利用するための説明を一つの記事へ詰め込まずに済むようになりました。
CATEGORYからPROJECTへ戻る導線
CATEGORY側には、対応する実験がある場合だけFROM THE PROJECTを表示します。日本語では「この方法を実際に試した記録」です。
方法だけでは判断しにくいときに、どのような問題から必要になり、実際のサイトでどう使ったのかをPROJECTで確認できます。
CATEGORYの記事に実体験の全文を繰り返す代わりに、一次記録へ戻れるようにしました。これにより、知識の出どころも分かります。
SPECIAL S03から生まれたWEBとCODEの記事
現在の実例は、PROJECT 001のSPECIAL S03 / UX IMPROVEMENTです。
S03には、公開後に見つかった問題を調べ、PROJECTハブとナビを整えた一連の改善を記録しています。この一つの実験から、二つのCATEGORY記事を作りました。
- 公開したWordPressサイトを実際に使ってUXを改善してみた：公開後の観察と改善判断をWEBの知識として整理
- CSSのposition: stickyで追従サイドナビを作る。実装して分かった注意点：追従ナビの実装で分かった技術的な注意点をCODEとして整理
S03の末尾からは、この2記事へ「LEARN FROM THIS EXPERIMENT」で進めます。WEBとCODEの記事からは、それぞれ「FROM THE PROJECT」でS03へ戻れます。
同じ実験でも、サイト運営の判断とCSSの実装では、あとから再利用する場面が異なります。一つのPROJECTから複数の知識を分けて整理できた例です。
すべてを自動で関連付けない
PROJECTとCATEGORYが同じ言葉を含んでいても、それだけではクロスリンクを付けません。実際にその実験から知識を取り出したと確認できる記事だけを明示的につなぎます。
自動で大量の関連記事を表示すると、由来を示すリンクと、テーマが近いだけのリンクが混ざります。MANIARUでは、クロスリンクを「どこから生まれた知識か」を示すものとして使いたいため、数を増やすより関係の明確さを優先しました。
今回の記事もBUILDに属しますが、直接対応するPROJECT記事はありません。そのため、CATEGORYだからという理由だけで「FROM THE PROJECT」は付けていません。
同じ内容を二度書かないための役割分担
PROJECTでは、その実験に固有の状況と判断を中心に書きます。CATEGORYでは、別の場面で使うときに必要な考え方や手順へ焦点を移します。
共通する事実は必要な範囲で触れますが、同じ説明をそのまま繰り返しません。詳しい経緯はPROJECTへ、使い方はCATEGORYへリンクすることで、それぞれの記事が担う範囲を保ちます。
記事制作の進め方そのものを仕組みにした例は、既存のBUILD記事ChatGPT＋Work＋共通ルールでWordPress制作フローを作ってみたでも記録しています。今回の設計は、その制作フローで増えていく記事をどう整理するかという次の仕組みです。
PROJECTが増えても同じ考え方でつなぐ
今後PROJECTが増えても、先にCATEGORY記事を作ることを目的にはしません。まず実験を行い、一次記録を残し、そこから再利用できる知識が見つかったときに整理します。
反対に、PROJECTを伴わないCATEGORY記事もあります。すべての記事を同じ形へ合わせるのではなく、実際の由来に応じて必要なリンクだけを付けます。
実験をそのまま終わらせず、分かったことを取り出し、別の場面でも使える形へ整える。そして、知識から元の実験も確認できるようにする。
PROJECTとCATEGORYを分けてつないだことで、MANIARUの「試したことを、誰かのマニュアルに。」を、記事の構造としても表せるようになりました。