Obsidianへ記録を増やすうちに、同じテーマの資料、事実、自分の考え、手順が同じ場所へ集まると、ノートを何に使うのか判断しにくくなりました。
そこで僕は、「ObsidianのVault直下は、情報の役割ごとに分ける」で書いたように、Vault(ノートの保管場所)の最初の階層を主題ではなく情報の役割で分けています。
この記事では、現在のVaultから私的な内容を除き、記録の置き場を決める考え方と、最初から細かく作りすぎないための構成例をまとめます。読書メモを自分の考えへ変える手順や、主題を分類する番号は別の話として、ここでは第一階層だけを扱います。
まず全体像
第一階層で答えるのは、「何について書かれたノートか」ではなく「このノートを何に使うか」です。主題による分類は、それぞれの置き場の内側で行います。
主題だけで分けると、使い方の違う情報が混ざった
例えば、同じプログラミング言語について書いたノートでも、外部記事の要約、用語の定義、エラーを直した手順、自分なりの設計判断では役割が違います。
これらを「プログラミング」という主題だけで同じ場所へ置くと、あとで参照するときに、出典を確認したいのか、手順を再利用したいのか、自分の考えを育てたいのかをファイル名や本文から判定し直すことになります。
僕は、この判定を毎回繰り返さないために、最初のフォルダを役割で分けました。主題が変わっても、外部資料は外部資料、手順は手順、自分の考えは自分の考えとして扱えます。
僕は最初の置き場を、情報の状態ではなく用途で決める
現在のVaultには運用用のフォルダもありますが、記録を残すための中心は次の役割です。
| 役割 | 入れるもの | 置き場を決める問い |
|---|---|---|
| フラッシュメモ | その場で生まれた未整理の気づき | まだ置き場を決められない短い記録か |
| 外部資料 | 書籍、記事、論文などの要約・引用・出典 | 内容の中心が外部ソースにあるか |
| 事実・用語 | 客観的に参照したい定義や技術情報 | 後から辞書のように引きたいか |
| 手順・実践知 | How-to、Tips、トラブルシュート | 同じ作業で再利用したいか |
| 体系化した理解 | 原理、構造、複数の知識をまとめた説明 | まとまりとして繰り返し読みたいか |
| 自分の考え | 1ノート1焦点で残す洞察や判断 | 自分の考えとして育てたいか |
| アイデア | 作品案、機能案、試したい発想 | まだ実行計画ではない可能性か |
| 計画・プロジェクト | タスク、設計、進行中の作業 | 行動や進捗を管理するものか |
| 外部向け成果物 | 公開する記事、資料、作品 | 外部の誰かへ届けることが決まっているか |
僕は、文章の長さや完成度を置き場の基準にしていません。長文でも外部資料の要約なら外部資料です。短文でも、焦点がはっきりした自分の判断ならZettelとして残せます。
入口のメモと、残すノートを分ける
思いついた時点では、情報の役割まで決まらないことがあります。僕は、まだ整理できない内容をフラッシュメモへ置き、あとで役割が分かった時点で移します。
ただし、すべての短い記録を独立したファイルにはしません。1行で終わる観察は一つのメモへ追記し、同じ話題が増えたときや、独立して育てたい焦点ができたときに切り出します。
外部資料は、未整理だから入口へ置くのではなく、要約や引用そのものを残す役割として独立させます。自分の考えが生まれた場合も、元資料を書き換えて置き換えず、別の役割のノートとして残します。
知識と自分の考えを一つにまとめない
僕のVaultでは、参照する事実、再利用する手順、体系として読む理解、自分の考えを分けています。
事実や用語は、誰が読んでも同じ対象を指せるよう、参照性を重視します。手順や実践知は、次に同じ問題へ遭遇したとき、そのまま行動へ移せる粒度で残します。複数の知識を原理や構造としてまとめ直したものは、体系化した理解として置きます。
Zettelは、その中で自分の思考を残す役割です。僕は1ノート1焦点に絞り、詳しい背景説明や大きな知識の塊は、事実・手順・体系の側へ分けています。
僕の運用では、ここを分けることで、自分の考えを後から修正しても、参照している事実や手順まで同時に書き換えずに済みます。逆に、技術情報を更新するときも、自分が当時どう考えたかを別の記録として残せます。
アイデア、計画、成果物も同じ場所にしない
アイデアは、実行するか決まっていない段階でも残します。計画は、実際に進める作業や進捗を扱います。成果物は、外部の誰かへ届けることが決まった記事や資料です。
完成度の高い長文だから成果物にするわけではありません。Vault内で繰り返し参照する体系的なノートなら、外部公開を決めるまでは知識の側に置きます。
この区別によって、発想を残しただけのノートが進行中の計画に見えたり、内部向けに整理した知識が公開可能な成果物に見えたりすることを避けています。
最初から現在のフォルダ数をまねなくてよい
現在の僕のVaultには、用途を細かく区別するためのフォルダがあります。しかし、最初から同じ数を用意することは勧めません。
これからVaultを作るなら、僕は次のような最小構成から始めます。
Vault/
├─ inbox/ # 未整理のメモ
├─ sources/ # 外部資料
├─ reference/ # 事実・手順・体系化した知識
├─ thoughts/ # 自分の考え
├─ ideas/ # アイデア
├─ projects/ # 計画と進行中の作業
└─ output/ # 外部向け成果物
reference/の中で、用語を探したい場面と手順を再利用したい場面が増えてから、事実・手順・体系へ分けます。分類を先回りして作るのではなく、「同じ場所にあるため判断しにくい」という問題が繰り返されたところだけ分割します。
一方、僕の運用では、外部資料と自分の考え、アイデアと計画、内部知識と外部成果を早い段階から分けています。役割の違う情報を同じノートへ混ぜると、あとから分離するときに、どこまでが出典で、どこからが自分の判断なのかを読み直す必要があるためです。
僕は置き場に迷ったら、次に使う場面を考える
役割の境界には、どちらにも置けそうなノートがあります。僕はその場合、内容の由来だけでなく、次に何のために開くかで判断します。
- 出典を確かめるために開くなら、外部資料
- 作業を再現するために開くなら、手順・実践知
- 自分の判断を考え直すために開くなら、Zettel
- 実行する項目を確認するために開くなら、計画
- 誰かへ渡すために開くなら、成果物
判断が変われば、僕はノートを別の役割へ移します。フォルダは過去から将来までの置き場を固定する分類ではなく、現在の使い方を表す置き場として扱っています。
まとめ
僕は、ObsidianのVault直下を主題ではなく情報の役割で分けています。入口、外部資料、参照知識、自分の考え、アイデア、計画、成果物を分け、同じテーマについて集めた情報でも、次にどう使うノートかをフォルダで示しています。
これから同じ構成を試すなら、最初から細かな分類を作る必要はありません。僕なら、外部資料と自分の考え、アイデアと計画、内部知識と外部成果のような境界から作り、置き場に迷うことが繰り返された部分だけ細分化します。