エンジニアのためのPARAメソッド：行動によって知識を整理する
トピックではなく、アクションでノートを整理する。
トピック別にノート整理するのは理にかなっているように思えます。しかし、PostgreSQLに関するノートが5つの異なるフォルダに散らばり、今日の課題に必要な特定のノートが見つからない状況に陥ると、その方法は通用しなくなります。
問題の根源は自制心の欠如ではありません。トピックベースの整理法が、間違った問いを投げかけていることにあります。「これは何についての情報か？」という問いは図書館には適していますが、エンジニアにとってより適切な問いは「これを使って何をするか？」です。これがPARA（プロジェクト・領域・リソース・アーカイブ）の前提です。
PARAは、Tiago Forteが彼のBuilding a Second Brain フレームワークの組織化の柱として考案した、シンプルな4つのカテゴリ（バケツ）システムです。すべての情報は、プロジェクト（Projects）、領域（Areas）、リソース（Resources）、アーカイブ（Archives）の4つに分類できます。各カテゴリは異なるアクション可能性（実行の可能性）のレベルを表し、この区別が各ノートの保存場所を決定します。
本ガイドでは、エンジニアリングの業務——コードベース、ドキュメント、学習資料、およびアクティブなプロジェクト作業と長期的な参照資料の間での緊張関係——に特化してPARAを適用する方法を解説します。
トピックベースの整理法の課題
多くのエンジニアは、コードをドメイン別に整理するのと同じように知識も整理します。
databases/
postgresql/
redis/
api/
rest/
graphql/
devops/
kubernetes/
terraform/
この構造は閲覧時には理にかなっています。しかし、特定のタスクに必要なものを探す際には崩壊します。データベース移行の安全性に関する有用なノートを記憶しているものの、それが databases/postgresql/ なのか devops/deployments/ なのか api/versioning/ なのか、あるいは一時的な場所に保存したためどこにもないのか、判断に困ることがあります。
トピックフォルダは、文脈を理解する前に知識の所属場所を決定することを強要します。PARAはその決定を先送りにし、「何についての情報か」を問う代わりに、「今何に使っているか」を問います。
4つのバケツ（カテゴリ）
プロジェクト（Projects）
プロジェクトとは、定義された結果を持つ、アクティブで時間限定の作業です。
エンジニアにとってのプロジェクトとは以下のようなものです：
課金サービスをキューv2へ移行
PostgreSQLを14から16へアップグレード
認証サービスの再設計に関するアーキテクチャ決定記録（ADR）を作成
パブリックAPIにレート制限を実装
分散トレーシングに関する記事を投稿
すべてのプロジェクトには完了状態があります。終了したら、そのプロジェクトはアーカイブへ移動します。アクティブに作業していないものは、プロジェクトではありません。
重要な制約：プロジェクトノートには、そのプロジェクトに必要なものだけを含めるべきです。参照資料はリソースに属します。再利用可能な概念は、あなたのゼッテルカステン（Zettelkasten）や個人ノートに属します。プロジェクトノートは作業用の文書であり、知識の蓄積庫ではありません。
領域（Areas）
領域とは、締切のない継続的な責任範囲です。
エンジニアの領域には以下が含まれます：
システムアーキテクチャ
インフラストラクチャの信頼性
コードレビューの品質
キャリア開発
API設計基準
セキュリティ体制
オンコール（当直）の責任
メンタリング
領域には終了がありません。あなたはインフラストラクチャの信頼性について常に責任を持ちます。キャリア開発についても常に気を使います。プロジェクトと領域の違いは、領域には退出基準（終了条件）がないことです。それらは完了するものではなく、維持管理するものです。
有用なルール：それを「リリースする」か「チケットをクローズする」かを想像できるなら、それはプロジェクトです。単にあなたの役割の一部であれば、それは領域です。
リソース（Resources）
リソースとは、後で役立つかもしれないと期待して収集した参照資料です。
エンジニアにとってのリソース：
APIドキュメントのブックマーク
チートシート
ベンチマーク結果
サードパーティシステム用のアーキテクチャ図
再視聴したいカンファレンスの講演
ライブラリドキュメント
研究論文
興味のあるブログ記事
リソースには、現在の作業におけるアクティブな居場所がありません。それらは、いつか必要になると期待して収集されます。ここでの重要な規律は、リソースがプロジェクトを装わないようにすることです。Kubernetesのドキュメント の集まりはリソースです。「プラットフォーム移行のためにKubernetesを学ぶ」という進行中のタスクはプロジェクトです。
アーカイブ（Archives）
アーカイブには、もはやアクティブでないすべてのものを含めます。
アイテムがアーカイブへ移動する条件：
- プロジェクトが完了またはキャンセルされた
- 責任範囲が変更された
- 資料が古すぎて有用ではなくなった
- 保持したいが、アクティブなバケツには必要ないもの
アーカイブは削除ではありません。それは、アクティブな寿命を終えたもののための、低摩擦のストレージです。ルールはシンプルです：ある情報がアーカイブにあるかどうか疑問に思ったとしても、それで構いません。アーカイブの内容を緊急に必要となることは稀です。
エンジニアの現場でのPARA
ObsidianにおけるエンジニアのPARA構造の具体的な例が以下に示されています：
Projects/
billing-queue-migration/
postgresql-16-upgrade/
rate-limiting-rfc/
blog-distributed-tracing/
Areas/
architecture-standards/
infrastructure/
on-call-runbooks/
career-development/
Resources/
api-references/
database-cheatsheets/
benchmark-results/
conference-notes/
Archives/
2025-q4-projects/
deprecated-services/
old-runbooks/
フォルダ構造自体は絶対のものではありません。重要なのは、現在の作業との関係性に基づいてノートを適切なカテゴリに配置する規律です。
典型的なエンジニアの知識の配置
多くのエンジニアは、区別されていないノートの山から始めます。PARAへの移行には、単一の監査パスが必要です：
プロジェクト — チケット、締切、または現在取り組んでいる納品物があるもの。
領域 — あなたの役割を定義する定期的な責任。
リソース — 特定のプロジェクトを念頭に置かず収集した参照資料。
アーカイブ — それら以外のすべて。
実践的なルール：疑わしい場合は、アーカイブに放り込みます。後でいつでも取り出すことができます。プロジェクトフォルダが過密になることは、アーカイブが未使用であることよりも有害です。
PARAとZettelkasten：実践的なハイブリッド
PARAとZettelkasten は、しばしば競合するシステムとして比較されます。しかしそれらは競合していません。それらは異なる問題を解決するものです。
Zettelkastenはアイデアのためにあります。それは原子論的な概念を捕捉し、意味によってそれらをリンクし、接続から理解が創出されることを可能にします。Zettelkastenのノートはプロジェクトに縛られません——それらはどのアクティブなバケツにも属しません。冪等性（Idempotency）に関するノートは、過去も未来も含め10個の異なるプロジェクトに適用されます。
PARAはアクションのためにあります。それは、現在アクティブに作業していること、責任を持っていること、または後で使うために収集していることを中心に、作業コンテキストを整理します。
実践的なハイブリッド構成：
Projects/
billing-queue-migration/
migration-plan.md
open-questions.md
→ Zettelkastenへのリンク: [[Idempotency keys turn retries into safe operations]]
→ Zettelkastenへのリンク: [[Outbox pattern separates persistence from delivery]]
Areas/
architecture-standards/
current-adr-index.md
→ Zettelkastenへのリンク: [[Database constraints are concurrency control]]
Resources/
benchmark-results/
q1-2026-postgres-benchmarks.md
このモデルでは、PARAフォルダは作業文書とコンテキストを保持します。Zettelkastenノートは再利用可能な知識を保持します。プロジェクトノートはZettelkastenの概念へリンクします——プロジェクトは概念を使用しますが、それを所有しません。
これは、PARAにZettelkastenの役割をさせようとするよりも耐久性があります。プロジェクトは終了しますが、概念は残り続けます。
一般的な失敗パターン
過剰なアーカイブ化
一部のエンジニアは、削除することに罪悪感を覚えるものを何でも溜め込むゴミ箱としてアーカイブを使います。アーカイブが大きくなりソートされなくなると、その価値を失います。アーカイブには、整然とした状態の完了した作業を含めるべきであり、ソートされていないノートの墓場ではありません。
定期的なアーカイブのスキャン（四半期ごとが適しています）が、それを管理可能な状態に保ちます。重複を削除し、統合します。アーカイブする前に、古いプロジェクトノートに、リソースまたはZettelkastenノートとして保持する価値があるものがまだ含まれているかどうかを問いかけます。
領域（Areas）がゴミ箱化する
領域が剪定されずに成長すると、トピックベースのフォルダシステムのように見えてきます。3年分のソートされていないノートを含む databases/ という名前の領域は、責任ではありません——それは単なる山です。
各領域をコンパクトに保ちます。領域とは、あなたが能動的に責任を負っているものを表すものであり、広く関心を持っているトピックではありません。関心はリソースへ、責任は領域へ。
見直しなしのリソースの成長
リソースは収集しやすく、忘れやすいものです。Resources/ 内のブックマークの山で、400個のソートされていないリンクがある状態は、ブックマークマネージャーよりも使いにくいです。リソースは軽やかにキュレートされるべきです——古い資料を削除し、シグナル（有用な情報）を残します。
週間レビューの省略
PARAは、プロジェクトフォルダの10分間の週間レビューと最も相性が良いです。各アクティブなプロジェクトについて：
- これはまだアクティブですか？
- 次の具体的なアクションは何ですか？
- アーカイブへ移動するものがありますか？
そのレビューなしでは、プロジェクトは古いエントリを蓄積し、システムはあなたの作業の現状を把握するための価値を失います。
Obsidianでの実装
Obsidian は、フォルダが4つのバケツに直接マッピングされ、Dataviewクエリがプロジェクトのステータスを自動的に表示できるため、PARAに自然に適合します。
基本的なセットアップ：
vault/
├── Projects/
├── Areas/
├── Resources/
├── Archives/
└── Zettelkasten/ ← 概念ノート、自由にリンク
アクティブなプロジェクトノートを表示するための単純なDataviewクエリ：
LIST FROM "Projects"
WHERE !contains(file.path, "Archives")
SORT file.mtime DESC
タグは、ファイルを移動せずにステータスをマークできます：
tags: [project, active]
tags: [project, paused]
tags: [project, done]
プロジェクトが完了したら、done タグを付け、フォルダを Archives/YEAR-QN/ へ移動します。シンプル、監査可能、元に戻せます。
プレーンファイルでの実装
Obsidian を使用する必要はありません。PARAは、プレーンなMarkdown を使用したGitリポジトリでも同等に動作します：
knowledge/
projects/
2026-billing-migration/
README.md
migration-plan.md
decisions.md
areas/
architecture/
adr-index.md
resources/
databases/
postgres-16-release-notes.md
archives/
2025/
feature-x-launch/
Gitは履歴、差分、検索、移植性を提供します。これがパーソナルシステムには十分すぎることもあります。
PARAが理にかなう場合
PARAは以下の状況に適しています：
- 同時に複数のアクティブなプロジェクトを抱えている場合
- 今日の作業に関連するものを素早く見つけたい場合
- フォルダに親和性があり、ツールに依存しないシステムを望む場合
- 再利用可能なアイデアのためのZettelkastenまたは概念ノートレイヤーと組み合わせる場合
PARAは以下の場合はあまり有用ではありません：
- 明確なバケツのない単一の長期プロジェクトに取り組んでいる場合
- アクティブな納品物がない研究志向の作業を主に行っている場合
- 明示的な分類よりも創発的な構造を好む場合
アクティブなプロジェクト作業と長期的な学習の両方を行うエンジニアにとって、PARAとZettelkastenの組み合わせはほとんどのケースをカバーします：PARAはコンテキストのために、Zettelkastenは思考のために。
意思決定フレームワーク
新しいノートが届いたとき、以下の問いを順番に投げかけます：
- これは、私が能動的に目指しているものと関連していますか？ → プロジェクト
- これは、私が所有する継続的な責任の一部ですか？ → 領域
- これは、後で必要になるかもしれない参照資料ですか？ → リソース
- これは完了または非アクティブですか？ → アーカイブ
- これは、どのプロジェクトにも縛られない再利用可能な概念またはアイデアですか？ → Zettelkasten
これが意思決定ツールの全体です。5つの選択肢。各選択肢に1つのルール。1つのノートあたり約10秒かかります。
結び
PARAが機能するのは、それがエンジニアが実際に知識を使用する方法——閲覧のためではなく、行動のため——に適合しているからです。あなたは databases/ に何が収められているかを見るためにノートを開くわけではありません。あなたは今、特定の課題に取り組んでおり、関連する資料を素早く表面化させる必要があるためにノートを開きます。
アクティブなプロジェクトと参照資料を分離し、それら両方を完了した作業から分離する規律は、パーソナルナレッジベースを維持する認知負荷を軽減します。パーソナルナレッジマネジメント の基盤および概念レベルのノートのためのZettelkastenと組み合わせることで、PARAは、重要な時にすべてを見つけられるようにする組織的な支柱を提供します。
バケツごとに1つのフォルダから始めましょう。既存のノートを分類するための1回の監査を実行し、プロジェクトを週に1回レビューしましょう。残りは自然に続くでしょう。
