機能 #1012
未完了タスクやチケットの「優先度」とは何？
0%
説明
Redmine のデフォルトの「低め」「通常」「高め」「急いで」「今すぐ」ですら使いこなせていないのに、 Vikunja (#805#note-16) で再び「低」「中」「高」「至急」「大至急」(それから未設定) に直面する羽目になってしまった。
一体どう使うものなんだこれは。
NO nop_thread さんが3ヶ月前に更新
- 説明 を更新 (差分)
NO nop_thread さんが3ヶ月前に更新
- 説明 を更新 (差分)
- 前回確認日 を 2026/04/06 にセット
NO nop_thread さんが3ヶ月前に更新
- 説明 を更新 (差分)
NO nop_thread さんが3ヶ月前に更新
- 関連している 機能 #805: 小さな TODO の管理方式の検討 を追加
NO nop_thread さんが11日前に更新
- 前回確認日 を 2026/04/06 から 2026/07/02 に変更
https://mastodon.cardina1.red/@lo48576/116355146519552820 (スレッド) でだいぶ考えが進んだ。
優先度は1次元の指標¶
タスクの順位付けについては、複数の基準が考えられる。
- 必要性の有無あるいは高さ
- 緊急性の高さ (締切の近さ)
- 行動予定の順序
- 残作業量
タスク管理やチケット管理の仕組みにありがちな「優先度」というメタデータは、こういった基準のうち何らかの指標を前提にタスクを順位付けするものといえる。
一発で終わる TODO¶
中断なしで一発で終わる TODO、たとえば「トイレットペーパーを買う」とか「食器を洗う」とかその程度のものについては、「優先度」は概ね「次の行動順」であると捉えて良い。
概ねとしたのは、優先度が高くとも特定の状況にならないと実行可能な扱いにならない場合もあるからである。
トイレットペーパーをスーパーで買うと決めているなら、「食器を洗う」より優先度が高いとしても自宅でトイレットペーパーの購入タスクは一旦無視される。
逆にスーパーで食器を洗うことも、優先度に関係なくありえないとしてよい。
持続するタスク¶
しかし、この「次の行動順」モデルは一定以上の期間にわたって (典型的には日を跨いで) 進行状態が続くタスクや一時中断のありうるタスクについてはうまく適用できそうにない。
たとえば「今日はこのチケットを10%進行したから続きは明日やる」という状況を考えるとき、チケット着手直前には「次の行動順」の最前線にいるからタスクの “優先度” は最高になっており、逆に「続きは明日」として中断したその瞬間には行動順はかなり後ろに追いやられているので “優先度” が一気に下がるはずである。
そしてなにより、その「明日」が来るといつの間にかそのタスクの “優先度” は上がっているべきということになる。
つまり「“優先度” とはすなわち次の行動順」モデルから考えると、“優先度” は作業によらずとも時間経過や状況の変化に伴って自動的に評価値が変化していく方が自然ではないかということである。
あるタスクの “優先度” が下がれば他のタスクは繰り上がるし、作業できる人が誰も着手しなかったものは勝手に優先度が高くなるのが妥当だろう。
こういった行動を伴わない “優先度” 変化は他のモデルでもありえて、たとえば「締切の近さ」を指標にするならタスクの優先度は基本的に時を経るごとに勝手に上昇していくべきである。
工数割当説¶
ここで有力なのが、“優先度” を「工数をいかに優先的に割り当てるべきか」という指標であるとする考え方である。
この指標は「次にどの作業をするか」「今どのようなタスクを進行・中断したか」のようなマクロな変化に乱されず、ある程度大局的なコスト配分を表現するので、たしかに手動設定して自動では変化しない “優先度” メタデータの扱いとしては実に都合が良いように思われる。
ただし、こういったコスト配分は必ずしも1日の中などの小さな規模での行動について即座に決定を与えるものではなく、マネージャがタスクをどう割り振るかを考える際の、組織規模の運営において必要になる指標である。
つまり個人が自分の管理をするには使いづらい。
また、これを “優先度” と呼ぶと、一発で終わる TODO と同じ用語で別の概念を指すことになり、紛らわしくもある。
NO nop_thread さんが11日前に更新
個人的な生活管理における規模の境界¶
工数割当の観点での “優先度” は中長期的な配分の指針ではあるが、個人が1日を具体的にどう使うかの管理については絶妙に役立たない。
これは一発で終わる TODO における “優先度” が概ね行動順序というミクロかつ決定的な指標として使えるのとは対照的だ。
このようなねじれがあると、では当然その中間では何が起きるのか、連続的にあらゆる規模のタスクで破綻なく使えるのか、という辺りは当然気になってくる。
だが、私の私生活管理における個人的な見解としては、実はこれについてはあまり心配する必要がない。
なぜなら私の場合は「一発で終わる TODO」と「状態を持ちうる (ある程度の期間持続したり中断などもありうる) タスク」はそれぞれ別のシステムで管理しているからだ。
一発で終わる TODO¶
「一発で終わる TODO」は以下のようなものとされ、テキストであったりありがちな TODO 管理アプリだったりによって管理される。
最近は Vikunka を使っている (#805#note-16)。
- 状態を「開始前」「完了」しか持たない。
- 「中止」や「却下」はタスク削除によって表現する。
- 「実行中」があるとしても、まさにその瞬間はタスク管理システムを操作していないはずで、操作できる状態になった頃には完了しているはずなので (なぜなら中断がないから)、システム上で表現できる必要がない。
- 単純で、ログやコメントを残す必要がない。
- やるか、やらないか、それだけである。
- 逆に「トイレットペーパーを買う」だけであっても何をどこで買うかなどの検討が必要なら、検討フェーズは中断がありえてログやコメントを残す価値があるかもしれない十分複雑なタスクなので、これは TODO ではなくチケットで管理する。
状態を持ちうるタスク¶
- 状態を「開始前」「完了」以外にも持つ。中断などがありうる。
- 中断があり複数が同時に進行するということは、スケジューリングが必要になるということである。
- まさにそれこそが、 TODO のような「次やること」の指標が欲しい理由であり、 “優先度” がそうでない何かのためにできていることがつらい理由でもある。
- 中断があり複数が同時に進行するということは、スケジューリングが必要になるということである。
- ログやコメントを残しておきたい場合が多い。
- 検討や意思決定は特にログを残したい。
- 作業ログを残したい場合もこれに該当する。
- 「やるだけ」の TODO では基本的にログや振り返りを残すほどの深みが出ることはほとんどない。
- もしあっても、どこか別のドキュメント管理の場に「知見」とか「tips」のような生活の知恵として残しておく形で済ますのが妥当。
境界を跨ぐとき¶
たとえば「思っていたより重いタスクだったので TODO からチケットにする」のようなことはありうるが、そうなったらチケットを作れば良いだけである。
逆に重いと思ってチケットを立てたら一瞬で終わったということもありうるが、このときも素直にチケットを閉じれば良い。
軽いタスクと重いタスクが2つのシステムに分かれていることの不都合は、スケジューリングが難しくなるという点にあると考えられる。
「次に何をするか」を考えるとき、 TODO 管理とチケット管理の2つのシステムを同時に見なければ理想的な判断ができなかったり重要なことを見落したりする可能性がある。
個人的には、私生活の管理という文脈で言えば、この辺りは時間の余裕とか気分で決めればそれなりに回せると思っている。
たとえば腰を椅子に落ち着けていない状態で何かやることあるなら済ませようなどと考えているなら TODO を見るだろうし、椅子に腰掛けた状態で次は何をしようと思っているならチケットを漁ることになるだろう。
そうは言っても、そもそも一覧を見ること自体を忘れたりしていろいろ見落としがちではあるので、この辺りを一貫したインターフェースで扱えると嬉しいというのはかなりある。
それについては 機能 #486: 統合通知チャネルの選定 や 機能 #528: Redmine のチケットを bot にリマインドさせたい あたりでじわじわと何か考えたいとは思っているが、まずは一発で終わる TODO の管理が安定してくるのを待とうということにしている。
これまで複数の微小タスク管理メソッドを使ってきたが、どれも絶妙に定着しなかったからである。
使わないものが綺麗に統合されても嬉しくないので仕方がない。
NO nop_thread さんが11日前に更新
まあそれはそれとしてまだ考えることは残っていて、まだまだ実運用を安定させるには遠いかもしれない。
- Redmine の “優先度” を工数割当の観点での優先度とするなら、具体的な行動計画や直近の実行計画はどのようにする？
- TODO 管理が生活に定着しない、あるいは使いづらいのは何故？