MANIARUの知識CATEGORYが30記事になった時点で、次の目標を50記事に決めました。ただし、残り20本を思いついた順に埋めるだけでは、似た記事が増えたり、根拠の弱いテーマを選んだりする可能性があります。
そこで、公開済み30記事を一度棚卸しし、「すでに書いたこと」と「まだ記事にしていないこと」をCATEGORYごとに分けました。この記事では、その知識マップから20本の候補を作り、制作順を決めた記録をまとめます。
30記事をタイトルだけで数えない
棚卸しを始めた時点の内訳は、AI 6、BUILD 6、CODE 6、GROW 4、MONEY 1、WEB 7でした。合計は30記事です。
最初に、各記事のCATEGORY、タイトル、公開URL、slugを一覧にしました。記事数だけでなく、何を解決する記事なのか、どの実験や改善から生まれたのかを確認するためです。
同じWordPressを扱っていても、画面の使いやすさを考えたWEB記事と、コードの仕組みを理解するCODE記事では役割が異なります。タイトルの単語が近いだけで重複と判断せず、読者が持ち帰れる知識まで見て分けました。
CATEGORYごとに書いたことと空白を並べる
次に、公開済み記事を短いテーマへ置き換えました。たとえばCODEなら、sticky、現在見出しの判定、PCとモバイルの目次共通化、wp_slash()、自動ログアウト、コメントのゴミ箱処理です。
その横に、実制作では使ったものの、まだ単独の記事にしていないテーマを置きました。検索語の取得、メインクエリの調整、投稿メタの配列、CSS Gridなどです。
| CATEGORY | 公開済み記事から見えた軸 | 未記事化だった主なテーマ |
|---|---|---|
| AI | 指示書、役割分担、再開、品質監査 | 変更範囲、思考量、完了条件 |
| WEB | UX、目次、著者、画像、HOME導線 | 検索UI、文字、進捗、favicon |
| CODE | sticky、見出し判定、WordPress関数 | 検索クエリ、配列メタ、Grid |
| BUILD | 制作工程、バックアップ、業務フロー | 標準機能との境界、自動化、記録固定 |
| GROW | 計測、発信、実利用、知識への変換 | 記事優先順位、内部リンク、番号管理 |
| MONEY | 収益化前のDay 0 | 新しい実績が確認できるまで保留 |
この形にすると、記事が少ないCATEGORYを機械的に増やすのではなく、MANIARUで実際に試したのに説明し切れていない部分が見えるようになりました。
候補ごとに「違い」と「根拠」を書く
未記事化テーマを見つけても、そのまま制作には進みません。20本の候補それぞれに、次の項目を付けました。
- CATEGORYと通し番号
- 仮タイトル
- 読者が解決できること
- 確認に使う一次資料
- 既存記事との違い
- 関連するPROJECTとCATEGORY
- 基礎・実践・応用の難易度
特に重視したのは「既存記事との違い」と「一次資料」です。違いを一文で説明できなければ、既存記事へ追記する方が自然かもしれません。実装、作業記録、公式資料のどれにも根拠がなければ、実体験の記事としてはまだ弱いと判断できます。
MONEYは数合わせで増やさない
開始時点でMONEYは1記事だけでした。数を均等にするなら、優先して増やすCATEGORYに見えます。
しかし、今回の棚卸しでは新しい収益実績を確認できませんでした。そこでMONEYの記事は追加せず、Day 0の次に記録できる事実が生まれるまで保留にしました。
記事数の少なさは、そのまま欠点ではありません。実績がない状態で一般論を増やすより、数字や判断材料がそろってから記録する方が、MANIARUの実験として意味があります。
20本を一つの順番へ並べる
候補を決めたあと、同じCATEGORYが長く続かないようにしながら、基礎から応用へ進める順番を作りました。関連する記事同士は、先に基礎となる方を公開します。
実際の最初の並びは、検索画面のUX、スレッドコメント、WordPress標準機能と独自実装の境界、AI作業の変更範囲、文字の実測、検索語の取得でした。WEB、CODE、BUILD、AIを行き来しながら、PROJECT 002やサイト改善で確認した事実を知識へ変えています。
この順番は固定された目次ではありません。制作直前にも重複と資料を確認し、根拠が弱ければ候補を差し替える条件を残しました。計画を守ることより、公開する理由を説明できることを優先します。
公開前に四つの質問で確認する
次の記事へ進む前に、次の四つを確認できる形にしました。
- 既存記事と解決する問題が重なっていないか
- 実体験か一次資料で事実を確認できるか
- 読者が記事を読んだあとに確認できる結果があるか
- 関連する記事へ無理なくつなげられるか
四つすべてを満たすことだけを目的にはしませんが、答えに詰まる項目があれば、タイトルや範囲を見直します。これにより、「書けそうだから書く」から「今のMANIARUに必要だから書く」へ判断を変えられました。
知識マップを制作中の確認表として使う
30記事の棚卸しで作った表は、企画時だけの資料ではありません。1本公開するたびに、CATEGORY番号、公開URL、関連リンク、残りの候補を確認するために使っています。
たとえば、最初に公開したWEB 08「WordPressの検索画面を整える」では検索全体の導線を扱い、その後のCODE 08「WordPressの検索語を安全に表示する」では検索語の取得と表示へ範囲を絞りました。知識マップに役割の違いを書いていたため、近いテーマでも同じ説明を繰り返さずに済みました。
記事数ではなく知識の空白から次を決める
PROJECTから知識を取り出す考え方は、GROW 04「PROJECTからCATEGORY記事を増やす」で整理しました。今回行ったのは、取り出した知識をCATEGORY全体へ並べ、次に埋める空白を決める作業です。
30記事を一覧にしたことで、すでに説明したこと、まだ説明していないこと、今は書かないことを分けられました。50記事という数は制作を進める目安ですが、テーマを選ぶ理由にはしません。
次に書く記事を知識マップから決める。これを制作前の小さな工程に加えたことで、MANIARUの実験を、重複の少ない知識として蓄積しやすくなりました。