各プロジェクトのアクション・ステップを他のプロジェクトから物理的に分離しておく

異なるプロジェクトのアクション・ステップを1つのリストに混在させることは、コンテキスト切り替えのコストを増やし、進捗を見えにくくする。

Why it works

プロジェクト間のコンテキスト切り替えは、プロジェクト同士がどれだけ異なるかに比例した認知的な負担を伴う。統合されたリストは、利用者がそれをスキャンするたびに、頭の中でプロジェクトによってフィルタリングすることを強いる——小さいが繰り返される認知的な税だ。プロジェクトごとの独立したコンテナはこの負担を取り除く。プロジェクトAに取り組んでいるときは、プロジェクトAのアクション・ステップだけが見える。これはまた、プロジェクトレベルの進捗を測定可能にする——プロジェクトのアクション・ステップのうち、どれだけの割合が完了したかを見ることができる。

How to do it

1. 各アクティブなプロジェクトに独自のページ、フォルダ、あるいはセクションを与える。
2. 各プロジェクト内で3バケツの構造を維持する：アクション・ステップ、リファレンス、バックバーナー。
3. そのプロジェクトに取り組んでいるときはプロジェクトレベルのリストを見直し、週次または隔週の計画セッションですべてのプロジェクトを見直す。

エビデンス

タスク切り替えのコストは、タスク同士の概念的な距離とともに増加する。関連する仕事を一つのコンテナに保つことは、コンテキスト切り替えの負担を減らすという原則と一致する。GTDも同じ理由で似たようなプロジェクトレベルの整理を使っている。 (mechanistic)

プロジェクトの分離という原則は切り替えコスト研究と一致している。各プロジェクト内の特定の3バケツ構造は、アクション・メソッドのデザイン上の選択である。

よくある間違い

「すべてのプロジェクト」のグローバルなリストだけを維持し、プロジェクトごとにタグ付けすること——タグはリストにアクセスするたびに追加のフィルタリングのステップを必要とし、物理的な分離より効果が低い。