基本的な考え方
- タスクは「管理すること」自体にリソースを取られるので、できるだけ手元から離すことでリソースの空きを作る
- マルチタスクは細かいシングルタスクの連続と考え、タスクとタスクの切り替えコストを下げることを意識
- 時間はなにをしても同じように流れてしまうので、業務中に時間を使うことはすべてタスクとして扱う
使うツール
テキストエディタを使用する
ExcelやTodoアプリは管理に手間がかかるので使わない。
ベースの理論
Getting Things Doneの理論がベースになっている。
真似たというよりはやっていたことがこの理論だったので、完全一致していない点はあしからず。
やり方
- タスクを細分化しテキストエディタに行単位で書き出す（後述のフォーマット参照）
- タスクのボリュームを見積もる
- タスクの制約を見極める
- a. タスク全体の期日はいつか
- b. 自分が対応したあとに誰がいつまでになにをする必要があるか
- c. そもそもその期日は本当にデッドなのか
- 優先順に並べる 下記が優先順の判断軸（状況に応じて変えて良い）
- a. 期日が近く、規模が小さい、後続に誰か待っている
- b. 期日に余裕があり、規模が小さい、後続に誰か待っている（すきま時間で対応しちゃう）
- c. 期日が近く、規模が大きい、後続に誰か待っている
- d. 期日に余裕があり、規模が大きい、後続に誰か待っている
- e. aで後続がいない
- f. bで後続がいない
- g. cで後続がいない
- h. dで後続がいない
- i. 期日がない
- MTGスケジュールなどを加味して稼働する時間で今日やる範囲を決める
- タスクを消化したら行を削除する、または完了済みなどの領域に移動する
- 新しいタスクが追加されたら1からもう一度
フォーマット
【大分類①】【小分類】タスク内容[期日]
└
└
└
【大分類②】【小分類】タスク内容[期日]
【大分類③】【小分類】タスク内容[期日]
記載例
【〇〇案件】開発からのチケットA対応[7/18]
└★開発Tに回答[7/13] ←これが対象のタスク
└☓☓チームに共有
└チケットクローズ
【業務外】飲み会のお金を送金する[7/13]
【UI改善案件】☓☓チームからのSlack問い合わせに回答する[7/13]
【〇〇案件】開発からのチケットBを回答[7/16]
【〇〇案件】開発からのチケットCを回答[7/16]
【〇〇案件】開発からのチケットDを回答[7/16]
【チーム内改善】振り返りの整理をする[8/20]
優先順の並び替え例
↓タスクをひとつ対応した場合
【業務外】飲み会のお金を送金する[7/13]
【UI改善案件】☓☓チームからのSlack問い合わせに回答する[7/13]
【〇〇案件】開発からのチケットBを回答[7/16]
【〇〇案件】開発からのチケットCを回答[7/16]
【〇〇案件】開発からのチケットDを回答[7/16]
【〇〇案件】開発からのチケットA対応[7/18]
└開発Tに回答[7/13] ←優先度高を消化したのでここに移動
└☓☓チームに共有
└チケットクローズ
【チーム内改善】振り返りの整理をする[8/20]
分類するときの注意
分類することをゴールにしないこと。きれいに分類することより、分かりやすい、管理しやすいを心がけて分類する。
いかに管理にリソースを使わず、進捗感をだすか。
補足：脳の仕様との関係
思考するときに活性化する脳部位の特色として、容量がとても小さいので、できるだけこの部位の容量を空けることを意識する。
また、タスクで不明瞭なところがあると不安に駆られ思考する脳部位の容量を圧迫することになるので、不明瞭な状態を可能な限り解消していくと、タスクの進捗が良くなる。