Access
このタスクはいつ、どこで行えるか（アクセスできるか）。
Background
このタスクの存在理由、実施理由、その他発生時の事情。
仕事術ではよく「WHYを考えよ」というが、タスクに関してそうする場合に注目するのがこれである。また盤外戦を行うときにもインプットになる。
Control
このタスクは誰が制御（干渉）できるのか。
これも盤外戦時に役に立つ。誰が制御できるのかが分かれば、結局「そのタスク自体をどうにかすることはできるのか」も分かる。たとえば直属上司であれば相談や交渉などで盤外戦に勝てよう。これが取引先の重役となれば、どうすることもできまい。
ちなみに「自分も制御できる」ことは多い。個人タスク管理であればたいていはそうであろう。もちろん私たちは怠け者なので、たいていは「やらない」「サボる」という方向に倒されるのであるが。何にせよ、このControlについてタスク管理で扱うことができれば、あなたは「このタスクは私自身でも制御できる」と気づくことができ、「サボらないために制御権を手放そう」と考えることができる。具体的には、独学ではなく習い事に参加できよう。当たり前に聞こえるかもしれないが、このような当たり前の営みを積み重ねることで、少しずつ忘迷怠を減らせるのである。
Design
このタスクはどうあるべきなのか。
あるタスクTがあるとき、Tの望ましい戦略や在り方を設計することもあるが、その設計内容もまたコンテキストだと言える。ものづくりを行う者は設計書（小説で言えばプロットだ）の重要性を理解しているだろうが、同じことがタスクについても言える。そのタスクをどう攻略するかという設計――デザインは、明示的に言語化しておいた方が後々役に立つ事が多い。もちろん、細かいタスク一つ一つについて、いちいち書いていてはきりがないためバランスは要る。
Environment
このタスクの前提となっている環境。
道具的制約、場所的制約、個人や組織や界隈や業界の文化などはこれにあたる。たとえば「使いたいSaaSがあれば事前に申請して許可を取ること」というルールがあったとすれば、「～～の許可を取る」というタスクは発生するであろう。このタスクのEnvironment Contextは「その会社ではSaaSを無許可では使えない」「事前に許可をもらわないといけない」などになる。また、関連として、「昔は自由に使えていたが、ウイルスに感染したやらかしがあって以来セキュリティが強化されてしまった」のようなBackgroundがあるかもしれない。
Following/Follower
このタスクと関連のあるもの。
具体的には依存関係であり、このタスクが依存しているものと、このタスクに依存しているものである。なお、ここで言っている依存とはタスク間の依存関係ではない。例を上げると、「AさんにXXXの許可を取る」というタスクTは、そもそもAさんにコンタクトを取れないといけないので「Aさん」に依存していると言える（AさんをFollowしている）。また、先輩のBさんは許可制を疎ましく思っているとしよう。この場合、Bさんの機嫌はタスクT（の成否）に依存していると言えよう。このとき、「Bさん」はTに依存していると言える（BさんはFollowerである）。
タスク管理というとタスクだけに注目しがちだが、現実はそのタスクに依存している何か、またはそのタスクが依存している何かというものがある。何かが「人」であることも多い。この現実に目を向けず、担々とタスク管理をしているだけでは、現実は上手くいかないことがある。
---
使い分け
個人タスク管理では Access を、プロジェクトタスク管理であれば Background と Design を使うのが基本である。
それ以外はタスクそのものと向き合うために「あると便利」なものであり、どこまで拡充するかは悩みどころであろう。反面、文芸的タスク管理などコンテキストを重視する潮流では、意識的に重視することになるだろう。
---