タスクはすべてtodoブロックを使用、変に分けない。使用するキーワードは以下の通り。

• WT：　他者依存。他者のタスク完了を検知する
• IF：　条件分岐。
  • 量が多い・ネストが深くなる場合は、別タスクのレコードとして切り分ける
• (繰り返しタスクは特にキーワードなし。)
• NEXT：　次のタスク作成タスク。タスクやって初めて次のタスクを決定できる場合。
• NOT：　やらない・省略可能と判断したタスクにつける。todoはTrueにする。

• タスクに関するメモはプレインテキストで。インデントして以下のように。

https://zenn.dev/tbpgr/books/8562293d519b8b/viewer/9387a2

上記zenn記事の「タスクばらし」を自分なりに改良した・Notionでどう実践するかを定めたもの。

これを実践すればソフトウェア開発（本質的に不安定なもの）において、認知負荷Down・作業効率UP・行き当たりばったり開発からの脱却、に貢献しそう。

この前提のタスク管理の方法についても記事にするかも。

• プロジェクトごとにDB作ってタスク管理している (親DBは共通)
• そのDBで「親アイテム・子アイテム」を使って作業のカテゴリを分けている
• その各カテゴリ内にレコード作って、具体的なタスクを記述している
• その具体的なタスクのページ内に、さらに具体的なタスクを書いている

また、作業中に得た知識などは知識簡易メモ用DBに軽く書いて、情報が溜まってきたらブログ記事にしている。

割り込みによるコンテキストスイッチはコストが大きい。特に1週間とか経ったらまじで忘れてるから確認に時間と認知リソースがかかるよね

小休止も割り込みと捉えるなら、ポモドーロと相性が良いと言える。

タスクを細分化するとシンプルになる。すると、他者の協力を得やすい。ならなら、簡単なタスクならやってくれるから・タスクの意図がわかりやすいから・内容の伝達も簡単だから。

1. シンプルなタスクばらし
2. 他者依存のあるタスクばらし
3. 条件分岐のあるタスクばらし
4. 繰り返しのあるタスクばらし

他者への依頼がないタスク・条件分岐しないタスク・繰り返さないタスク、のこと。

1. ゴールを明確にする
2. タスク細分化：「大きくても半日」くらいの感覚で良いらしい。俺は細分化しすぎてたかもなので意識。
3. 未経験の業務で推測が難しい場合、経験者に助言をもらう or 分割後にレビューもらう

他者へ依頼するタスク。

例：コードレビュー依頼、レビュー完了確認（その後の修正内容確認・レビュー修正は依存しない。修正自体は自己で完結するので）

依頼行為は相手に依存しないので、「相手が完了したことの検知」にフォーカスすれば良いだろう。

例）Notionではキーワード`WT：`でWaitingを伝える

「条件に対する結果がどうかの検知→Aの時はタスク1-1、1-2。Bの時はタスク2-1, 2-2」のこと。

例) 実現可能性調査

1. Project DBの中のカテゴリ内のタスクで、その中にテキスト書き込んでフローを書く.
2. キーワード`IF：〜〜〜なら`を書いてその下にインデントしてtodo書く。上記の通り。
3. 量が多いなら場合は：タスクを別レコードに切り分ける！！！ （トグル、子ページは決して使用しない。）

例）タスクばらし入門の執筆

• 1～6章全てに対して以下を実施する
  • アウトライン作成
  • 執筆
  • 推敲

上記の執筆の例で説明する：このルールは破っても別に問題なし

1. 最初のタスクばらし時では、1章のとこのみにタスク書く
2. 2章以降は、タスクを実施する際にコピペで追加しておく

1. タスク実施して初めて、次のタスクがわかるケース
2. 取り組んでいくうちに手順を減らせるとわかったケース

1. タスク実施して初めて、次のタスクがわかるケース

例）Notionではキーワード`NX：`を入れてNextを伝える

↓

1. 取り組んでいくうちに手順を減らせるとわかったケース

例）Notionではキーワード`NOT：`でやらないことを伝える

↓