よ〜んです。

先日、Next PDAを求めてという記事にて，私なりのアーキテクチャについてちらっとお話しをしたと思います。

アーキテクチャ

.
├── Inbox.md
├── knowledge
├── project
├── target
│   └── 2026.md
├── Tasks.md
├── template
├── Todo.md
└── weekly-note

knowledge

調べたことや面倒な手続きの手順など記録をしています。

俗に言う外部脳的なディレクトリです。

project

名前通り各プロジェクト（粒度はまばら）tasksの機能を使ってまとめてます。

タスクのデータの実体は後述するIndex.mdにあります。

各ページはだいたいこんな感じ、似たようなプロジェクトが多くなるとサブディレクトリを切って対応します。

# project-name
何をするか

---
```tasks 
not done
tags include #project-name
```

target

目標です。長期（だいたい5年スパン）、中期（1年）、短期（3ヶ月）で管理してます。

プロジェクトは目標を達成するためアクションって感じですが、こちらは定性的な物となっております。

template

各プロジェクトや週次ノートのテンプレートを管理してます。

Templatorは使用していません。

weekly-note

今週何をするかをタスクベースで見れるようにします。

dailyと悩みましたが、weeklyの方が予定の見通しがしやすいので、weeklyを採用中。

Inbox.md

ひたすらにMarkdown形式でタスクを起票する場所です。 ここは、tasksやtagsの機能を使用していますが、それらがなくてもMarkdown形式でデータを見る・残すことができます。

Tasks.md

こちらは、各タスクの整理を行う場所です。

タグがついてない、期日が設定されていないタスクを抽出し、それらが0になるようにしています

Todo.md

#todoがついているものを抽出しています。

運用

  1. Inbox.mdにタスク起票
  2. Tasks.mdで起票したタスクを整理
  3. 週一で全プロジェクトのレビュー
  4. 週一でタスクのディスパッチ

コンフリクト発生時

コンフリクトが起きるのはknowledge配下かInbox.mdのみとなる。(はず)

どちらも丁寧にコンフリクト対応するが、Inbox.md が コンフリクトしてる間は一時的に別のファイルを作ってタスクを起票する。

この記事を書いてる途中にふと、端末ごとに Inboxを別ファイルで運用し、整理のフェーズでまとめると良くね？と思ったりなどしました。

Community Plugin

かなり少ない部類と思ってます。

  • Dataview.js
    • これは不要になる予定、触っていて便利で楽しいが、触ることが目的となりそうなため。。。
  • Git
    • 端末間の同期のため
  • Periodic Notes
    • weekly-noteの生成のため
  • Tasks
    • タスク管理を行うため

まとめ

運用をかっちり決めずに、ゆるく情報を集約していくと自ずといい感じになっていきます。

誰かの助けになればと思います、ではでは