プロジェクト
インボックスから仕分けられた「直近やること」を入れる箱
プロジェクトは GTD の中で最も太りやすく、最も高頻度に更新される箱
それだけに、このプロジェクトを上手く管理できるかどうかが、そのまま GTD の成否に繋がります。
GTDだと、望んでいる状態のことをprojectと呼ぶらしい?
/opencursor/ゆるいタスク管理の抑えどころ#60ceccef99d3f40000ba2bc4
一方GTDを噛み砕くでは、単に直近やるタスクをprojectと呼んでいる
これでは次に取るべき行動との違いがあまりないようなtakker.icon
ブレイクダウンできているかどうかくらいしか違いがない
ああ、ちょっと書き方紛らわしかったですねsta.icon
プロジェクトと次に取るべき行動の違い
こうなんじゃないか?
やるやらない仕分けで
2分ルールを適用できるものは即実行
具体的な操作の場合はそのまま次に取るべき行動に入れる
いくつかの操作に分けたほうがいい場合は、その場で分けて入れる
具体的な操作だとしても、「それを実行すべきか疑わしい場合」「その操作で変化したい先の状態がよくわからない」場合はprojectに放り込む
それ以外もprojectに放り込む
ブレイクダウンにて
break down待ちproject listをどんどん処理していく
始状態と終状態を明確にするのが一番重要
終状態は「望んでいる状態」に相当する
始状態から終状態にたどり着く為のアプローチをタスクとして捉え、次に取るべき行動に入れていく
簡単なprojectなら一個の操作で十分
慣れている操作は端折っていい
e.g. ミルクを買う
買い物になれている人なら「財布のお金を確認する」「エコバッグを用意する」「靴を履く」「歩く」などの操作をいちいち明確にして次に取るべき行動に入れたりしなくていい
そんなことしたら逆に時間がかかってしまう
review (GTD)でこれらの慣れている操作を一旦全部書き出して、操作のrefactoringをするのはあり
普段しないこと、する必要のないこと、したら逆に面倒なことはレビューでじっくり考えればいい
複雑なprojectの場合は、複数の操作の組み合わせだけでなく、複数のアプローチも用意しておくと良さそう?
始状態と終状態は、制約条件や外部からの攪乱によって変化する
もしかしたらその終状態になる必要がなくなっているかもしれない
終状態に行く解がなくなっている可能性もある
これはreview (GTD)で点検する
終状態になるための操作・解はさらに大きく変化する
例:/opencursor/ゆるいタスク管理の抑えどころ#60ceccef99d3f40000ba2bcf
終状態が変化しなくても、とれる解が変わることは往々にしてありうる
(アプローチ|解)とそれを構成する操作を導き出す上で、佐藤の問題構造図式が役に立ちそう
操作をより詳細にモデル化している
制約と外部環境の攪乱によって変化することも折り込み済み
始状態に直接作用を加えるのではなく、始状態に至る操作、投入した入力、制約条件、外部攪乱から考える
https://i.kakeru.app/50adf15a0abb07aa60099bb5cbbc8c70.svg https://dev.kakeru.app/50adf15a0abb07aa60099bb5cbbc8c70
❌始状態$ Sを入力して終状態$ E=f(S)を出力する
✅始状態$ Sを出力している函数$ S=g(A)を、終状態$ Eを出力する別の函数$ E=g'(A')に変える
変える操作は$ \mathcal{F}:(g,A)\mapsto(g',A')と定義できる
どちらがいいと言うことではなく、どちらの状態もあり得る?
たとえば始状態「机にはがきと切手がある」から終状態「机に切手を貼ったはがきがある」に移行するには、始状態に操作「はがきに切手を貼る」を適用するだけでいい
そもそも始状態に至るまでの過程がなければ、この図は適用できない?
そもそも何もしていない場合とか
やろうとしているけど、何らかの制約条件や外乱で何もできなかった場合は除く。その場合ならこの図を適用できる
この箱の性質:
table:table
観点 難易度 説明
重要度 ★★★ 重要。GTD の中心となる箱です。
理解の難易度 ★☆☆ 易しい。コンセプト自体はそこまで難しくありません。
運用の難易度 ★★☆ まあまあ難しい。少なくとも工夫は必要です。
入れるとき:
table:table
観点 説明
何を入れる? 直近やると決めたもの
いつ入れる? やるやらない仕分け(数日に一回)、週次レビュー(週に一回)
どこから入れる? インボックス
出すとき(別の箱に移すとき):
table:table
観点 説明
いつ出す? 日時レビュー(一日一回)、週次レビュー(週に一回)
どこに出す? カレンダー、連絡待ち、次に取るべき行動
ステップ名で言うと? ブレイクダウン
書き換えるとき:
table:table
観点 説明
いつ書き換える? 日時レビュー(一日一回)、週次レビュー(週に一回)
何を書き換える? 各プロジェクトの状況(進捗や所感など)
どのように書き換える? 古い状況を今の状況に上書きする
プロジェクトの実現例
プロジェクトに入れるものの具体例
Projectの実現例 (sta)
q-多数のプロジェクトから今できそうなプロジェクトを上手く抽出するには
q-どんなタグを使えばよい
q-どんなタグを使えばよい一般論ではなくて具体的に教えて
q-タグは何個くらい使うのが良い
q-タグの運用について調べたいんだけどどんなキーワードを使えばよい
q-タグの操作をサポートした手段ツールとして何がある
q-タグを付けるのが面倒だが抽出はできるようにしたいタグ以外の手段はないか
q-タグは複数個つけても良い
q-やるやらない仕分けの際これは予定だと明らかにわかることもカレンダーではなくプロジェクトに入れるべき
/taskmanagement/「プロジェクト」をどう解釈するのかの違い
/taskmanagement/GTDのプロジェクトとプロジェクト管理
#Project