【公開用サンプル】320本のnoteから、中核12本を選んで記事棚を整えた実例

今回、自分のnoteに設計図を作って分かったのは、記事棚は「これから書く記事のタイトル一覧」ではないということでした。

新しく書くものだけではなく、

• 何を残すか

• 何を直すか

• 何をつなぐか

• 何を今は触らないか

まで決める。

ここまで整理して、ようやく「記事棚の設計図」になります。

こんにちは。

小さな商売のnote発信サポート「ネタリエ」の綿樽 剛です。

元小売店経営者で、Webライターとして8年間、記事制作に携わってきました。

この記事は、ネタリエが提供する「note記事棚 設計図便」の公開用サンプルです。

実際に自分のnoteを対象として作成した設計図から、個別の管理情報を除き、どのような判断をしたのかを紹介します。

現在の設計図便では、この記事とまったく同じ本数や構造を当てはめるわけではありません。

その人のnoteに何があり、何が足りず、どこまで整える必要があるのかを見て設計します。

最初に決まったのは、新しく書く記事ではありませんでした

設計を始める前は、私も少し勘違いしていました。

記事棚の設計図とは、新しく書く記事のタイトルや構成を決めるものだと思っていたのです。

AIに尋ねれば、記事ネタは30個でも50個でも出てきます。

でも、私のnoteに必要だったのは、新しいネタを増やすことではありませんでした。

実際には、先に決まったのは次のことです。

• 書かない記事

• 作り直す記事

• 一部を追記する記事

• 末尾や内部リンクだけ直す記事

• そのまま残す記事

• 今回は触らない場所

新しい記事を考える前に、すでにある記事の役割を確認する必要があったからです。

当時、私のnoteには公開済みの記事が320本以上ありました。しかも、かなり高い頻度で記事が増えていました。

記事が少なくて困っているわけではありません。

むしろ記事が多いために、初めて来た人が、

「何をしている人なのか」

「最初にどれを読めばよいのか」

を判断しにくい状態になっていました。

必要だったのは、記事をさらに増やすことではありません。

320本の中から、今の仕事に関係する主要な道を選ぶことでした。

ここに、記事棚を設計する意味があります。

まず、記事を5つの役割に分けました

既存記事を、次の5つの役割で確認しました。

・検索などから読者と出会う入口記事
・読者の悩みを整理する記事
・人柄や考え方を伝える信頼記事
・サービスを検討する前に読む記事
・よくある質問に答える記事

始める前は、入口記事が足りないと思っていました。

検索から来てもらう記事が少ないから、仕事につながらないのだろうと考えていたのです。

ところが、実際に分類すると、入口記事はかなりありました。

読書エッセイが約80本。
AIニュースへのコメントが約45本。
業種別のnote集客記事が約47本。
資格の活かし方、映画考察、そのほかの検索記事もあります。

薄かったのは、入口ではありません。

人柄や判断基準を伝える信頼記事でした。

信頼記事として数えられたのは9本。しかも、そのうち2本は、現在の発信方針と合わなくなっていました。

頭の中だけで考えていたら、私はこれからも入口記事を増やし続けていたと思います。

分類してみたことで、

「もっと書く」ではなく、「違う役割を補う」

という判断に変わりました。

なお、別のnoteではFAQが足りないとは限りませんし、信頼記事を増やす必要があるとも限りません。

サービスページやプロフィール、外部サイトですでに判断材料がそろっていれば、新しい記事を作らないこともあります。

このケースでは、中核12本だけでは案内しにくいと判断しました

今回、320本以上の記事から、中核となる記事を12本選びました。

ここでいう12本は、全記事の目次ではありません。

このときの私のnoteで、読者にまず見せたい主要記事として選んだ12本です。

現在の設計図便でも、中核記事を整理するときに最大12枠程度を使うことがあります。

ただし、12本を埋めることは目的ではありません。

6本で十分なら6本。

既存記事とサービスページだけで足りるなら、新しい記事をほとんど作らない場合もあります。

私の場合は記事が320本以上あったので、12本を選んだだけでは、逆にその12本を見つけてもらえません。

そこで、このケースではハブ記事を4本置くという判断になりました。

ここでいうハブ記事とは、関連する記事を整理して、

「このテーマなら、まずここから読めます」

と案内する記事です。

今回設計したのは、次の4本でした。

このときの私のnoteでは、

固定記事
↓
ハブ記事
↓
個別記事

という形が合いました。

ただし、これが現在の設計図便の標準形という意味ではありません。

記事が少なければ、記事同士を直接つなぐだけで十分な場合があります。

既存マガジンが案内機能を果たしていれば、新しいハブを作らないこともあります。

外部のサービスページが十分に整理されていれば、固定記事を大きく作り直さないこともあります。

必要なのは「ハブを作ること」ではなく、

読者が何を見ればよいか迷わないこと

です。

12本は、全部を新しく書くわけではありませんでした

今回選んだ12本の内訳は、次のようになりました。

• 新しく書く記事　4本

• 現在の方針に合わせて作り直す記事　4本

• 情報を追記して育てる記事　2本

• 末尾の導線だけ直す記事　1本

• そのまま活かす記事　1本

新しく書く4本のうち、2本はすでに下書きが完成していました。

つまり、設計図を作ったあとに12本すべてをゼロから書いたわけではありません。

過去記事を使えるところは使う。

本文を変える必要がなければ、無理に直さない。

すでに役割を果たしている記事は、そのまま残す。

これは今の設計図便でも変わっていません。

むしろ現在は、

新規記事を作る前に、配置や追記だけで済まないかを先に確認する

という考え方を、より明確にしています。

案件によっては、

「新しい記事は1本だけ」

「今回は新規記事なし」

という設計になることもあります。

同じテーマの記事が3本あっても、統合しませんでした

振り分けを進めると、似た記事がまとまって出てきます。

私の場合、固定記事について書いた記事が3本ありました。

・固定記事そのものを、まだ作っていない人に向けた記事
・固定記事はあるけれど、「はじめまして」のまま止まっている人に向けた記事
・必要な要素は分かったけれど、書き始められない人に向けた記事

テーマは同じです。

しかし、読む人の状態が違います。

そこで、次の3点を比べました。

1．読者
その記事を読むのは、どの状態の人か。

2．悩み
その人は、いま何に困っているのか。

3．結論
読み終えたとき、何が分かっていればよいのか。

この3点がほぼ同じなら、重複です。

新しく書かず、既存記事を直します。どれかが違えば、別の記事として残せます。

固定記事について書いた3本は、読者の状態が違っていました。そのため、無理に統合せず、それぞれに役割を持たせることにしました。

記事棚の整理は、似た記事を機械的に減らす作業ではありません。同じ棚に置くのか、違う道に置くのかを判断する作業です。

棚に入れない記事にも、理由をつけました

320本の中から中核の12本を選ぶと、多くの記事が棚の外に残ります。

ただし、棚に入れないこ＝価値がないということではありません。

たとえば、読書エッセイや映画考察は、今回の主要導線には組み込みませんでした。

しかし、検索から読まれ、人柄や継続が伝わる記事として残します。

記事棚は、noteにある全記事の目次ではありません。

今回、読者に歩いてほしい主要な道です。棚の外に置く記事にも、その記事がどこで働くのかを決めました。

棚に入れない記事にも、理由をつけました

320本の中から中核12本を選ぶと、多くの記事が棚の外に残ります。

ただし、

棚に入れない＝価値がない

ではありません。

たとえば読書エッセイや映画考察は、このときの主要導線には組み込みませんでした。

それでも、検索から読まれたり、綿樽 剛という人間を知ってもらったりする記事として残します。

記事棚は、note全記事をきれいに分類し切るための目次ではありません。

今回、読者に歩いてほしい主要な道です。

この考え方も、現在の設計図便に引き継いでいます。

中核に入らない記事についても、

• 検索から読まれる記事として残す

• 関連記事として使う

• 別テーマの記事群として残す

• 現在は触らない

• 情報が古くなったら後で確認する

といった扱いを考えます。

このケースでは、固定記事を少しだけ直しました

当時の設計では、固定記事を全面的に書き直すことも検討しました。

しかし、確認した結果、本文の完成度は高く、全部を書き直す理由はありませんでした。

修正すると決めたのは、主に次の3か所でした。

• 設計図便のリンク先を、公開した販売記事へ差し替える

• ハブ記事4本への案内を追加する

• 案内の順番を整える

固定記事の冒頭や自己紹介、相談案内は残します。

直せる場所を全部直すのではありません。

読者が判断しにくい場所だけを直す。

これは現在も同じです。

ただし、今の設計図便では、固定記事そのものを必須にはしていません。

案件によっては、

• 今の固定記事をそのまま使う

• 別の記事を固定する

• 固定記事を作らない

という結論もあります。

今回は触らない場所も決めました

設計図には、「今回は触らない場所」も記載しました。

更新頻度と記事量

記事棚を整えるために更新を止めると、そのまま発信が止まる可能性があります。現在の更新ペースは維持します。

記事URL

URLを変更すると、過去に貼ったリンクが切れます。旧名義がURLに残っているものもありますが、今回は変更しません。

記事末尾の標準導線

自己紹介、無料点検記事、メルマガの3つは維持します。各記事には、その手前に「この記事から次に読む主出口」を1つだけ追加します。

プロフィール短文

対象、肩書き、経歴、仕事の方法が短い文章に収まっています。

ここは一文字も変えません。変えない場所を決めることも設計です。

変えない場所を決めることも設計です。

あれもこれも直そうとすると、結局どれも公開できなくなります。

記事棚設計図には、公開する順番も入っています

記事棚設計図を受け取っても、どこから着手するか分からなければ、また止まります。

そのため、12本には公開・再整備する順番をつけました。

前半には、すでに下書きが完成している記事や、末尾を直すだけの記事を置いています。

ゼロから書く記事は後半です。

今回、最初に行う作業は次の3つになりました。

1．完成している下書き2本を公開する
2．固定記事から設計図便の販売記事へリンクをつなぐ
3．業種別シリーズの入口記事から、ハブ4へ進めるようにする

これを今月中に終える。

その後、ハブ1の「記事棚とは何か」を作ります。

12本すべてが完成するまで、記事棚が動かないわけではありません。

販売記事と公開用サンプルを公開し、固定記事からリンクをつないだ時点で、ひとつの道が動き始めます。

設計図は、完成まで長く待つ計画書ではありません。届いた日から、できる作業に取りかかるための順番表でもあります。

だいたい1ヶ月くらいかけてコツコツ設計図に沿って記事棚を整備していきます。

記事棚を作って分かったこと

自分のnoteを設計して分かったのは、足りなかったのは記事数ではなかったということです。

入口記事は、すでにたくさんありました。

不足していたのは、誰が書いているのかが分かる記事でした。

• どのような基準で仕事をしているのか。

• AIをどこまで使い、どこを人間が判断するのか。

• 何を引き受け、何を引き受けないのか。

• 迷ったとき、何を基準に決めるのか。

そうした記事が薄かったのです。

そのため、今回、新しく書く記事には信頼の役割を多めに持たせました。

ちなみに、この記事もその1本です（笑）

設計図便の内容を説明するだけではなく、実際に自分のnoteへ適用し、どのような判断をしたのかを見せる役割があります。

ただし、別のnoteを診断したら、まったく違う結果になると思います。

記事が5本しかない人に、同じ12本と4ハブを作る必要はありません。

外部のサービスページが整っている人なら、noteに追加する記事は少なくてもよいかもしれません。

FAQが十分なら、FAQ記事は不要です。

記事棚は、型に合わせるものではなく、今あるものから必要な道を作るものだと考えるようになりました。

自分で設計図を作ることもできます

この記事で行った整理は、自分でもできます。

今回の私のnoteでは、まず既存記事を役割ごとに確認し、似た記事は「読者・悩み・結論」で比べました。

そのうえで、今の仕事に関係する中核記事を選び、必要なところだけハブを作り、固定記事や内部リンクの役割も見直しています。

すでに似た記事があるなら、新しく書かず、その記事を活かした方がよい場合もあります。

方法そのものは隠していません。

自分で記事棚を整理してみたい方には、考え方と手順をまとめた教科書があります。

👉 【完全版】仕事につながる note の育て方（1,500円）

教科書では、記事の役割分け、既存記事の棚卸し、設計カードなどを使って、自分で記事棚を考えられるようにしています。

今回の私のnoteでは、320本以上の記事を整理した結果、中核12本とハブ4本という形になりました。

これは正解の型ではなく、私のnoteで出た一つの答えです。

自分で進められそうなら、設計図便を利用する必要はありません。

一方で、実際に自分の320本を整理してみると、方法を知っていることと、自分の記事を判断できることは別だと感じました。

自分が書いた記事には思い入れがあります。

役割が重なっていても、

「この一本も残したい」

「何とか主要な道へ入れられないか」

と考えてしまいます。

記事が増えるほど、確認するだけでも時間がかかります。

そんなときに、外から一度整理するのが「note記事棚 設計図便」です。

設計図便で整理するのは、記事タイトルだけではありません。

• 現在のnoteに何を担わせるか

• どの記事を中核として残すか

• 既存記事をどう活かすか

• どこを少し直せばよいか

• 固定記事やハブが本当に必要か

• note以外に置いた方がよい情報は何か

• 新しく記事を書く必要があるか

• 今は触らなくてよい場所はどこか

• 最初にどこから着手するか

まで整理します。

自分で進めたい方は教科書を。

記事が多くて絞りきれない、第三者の視点で今あるものを整理してほしい方は、設計図便を使ってください。