インボックスから仕分けられた「直近やること」を入れる箱

プロジェクトは GTD の中で最も太りやすく、最も高頻度に更新される箱

それだけに、このプロジェクトを上手く管理できるかどうかが、そのまま GTD の成否に繋がります。

GTDだと、望んでいる状態のことをprojectと呼ぶらしい？

一方GTDを噛み砕くでは、単に直近やるタスクをprojectと呼んでいる

これでは次に取るべき行動との違いがあまりないような

ブレイクダウンできているかどうかくらいしか違いがない

ああ、ちょっと書き方紛らわしかったですね

こうなんじゃないか？

やるやらない仕分けで

2分ルールを適用できるものは即実行

具体的な操作の場合はそのまま次に取るべき行動に入れる

いくつかの操作に分けたほうがいい場合は、その場で分けて入れる

具体的な操作だとしても、「それを実行すべきか疑わしい場合」「その操作で変化したい先の状態がよくわからない」場合はprojectに放り込む

それ以外もprojectに放り込む

ブレイクダウンにて

break down待ちproject listをどんどん処理していく

始状態と終状態を明確にするのが一番重要

終状態は「望んでいる状態」に相当する

始状態から終状態にたどり着く為のアプローチをタスクとして捉え、次に取るべき行動に入れていく

簡単なprojectなら一個の操作で十分

慣れている操作は端折っていい

e.g. ミルクを買う

買い物になれている人なら「財布のお金を確認する」「エコバッグを用意する」「靴を履く」「歩く」などの操作をいちいち明確にして次に取るべき行動に入れたりしなくていい

そんなことしたら逆に時間がかかってしまう

review (GTD)でこれらの慣れている操作を一旦全部書き出して、操作のrefactoringをするのはあり

普段しないこと、する必要のないこと、したら逆に面倒なことはレビューでじっくり考えればいい

複雑なprojectの場合は、複数の操作の組み合わせだけでなく、複数のアプローチも用意しておくと良さそう？

始状態と終状態は、制約条件や外部からの攪乱によって変化する

もしかしたらその終状態になる必要がなくなっているかもしれない

終状態に行く解がなくなっている可能性もある

これはreview (GTD)で点検する

終状態になるための操作・解はさらに大きく変化する

例：/opencursor/ゆるいタスク管理の抑えどころ#60ceccef99d3f40000ba2bcf

終状態が変化しなくても、とれる解が変わることは往々にしてありうる

(アプローチ|解)とそれを構成する操作を導き出す上で、佐藤の問題構造図式が役に立ちそう

操作をより詳細にモデル化している

制約と外部環境の攪乱によって変化することも折り込み済み

始状態に直接作用を加えるのではなく、始状態に至る操作、投入した入力、制約条件、外部攪乱から考える

❌始状態Sを入力して終状態E=f(S)を出力する

✅始状態Sを出力している函数S=g(A)を、終状態Eを出力する別の函数E=g'(A')に変える

変える操作は\mathcal{F}:(g,A)\mapsto(g',A')と定義できる

どちらがいいと言うことではなく、どちらの状態もあり得る？

たとえば始状態「机にはがきと切手がある」から終状態「机に切手を貼ったはがきがある」に移行するには、始状態に操作「はがきに切手を貼る」を適用するだけでいい

そもそも始状態に至るまでの過程がなければ、この図は適用できない？

そもそも何もしていない場合とか

やろうとしているけど、何らかの制約条件や外乱で何もできなかった場合は除く。その場合ならこの図を適用できる

この箱の性質:

入れるとき:

出すとき（別の箱に移すとき）:

書き換えるとき: