TODO管理のステータス設計の正解を調べた

todo / in_progress / done で足りなくなった

自作のTODO管理CLIを、todo / in_progress / done の3ステータスで運用しています。シンプルで気に入っていました。

ところがある日リストを眺めると、数週間動いていないタスクが2つ。1つは相手の返事待ちで止まっている依頼。もう1つは、読みかけのまま再開の目処が立たない分厚い技術書。どちらも同じ todo の顔をして並んでいます。

blocked を足そうか。いや on_hold か。pending や waiting を持つツールも見かけます。考えているうちに、これは「どの名前にするか」ではなく「そもそも増やしていいのか」という問題に見えてきました。

そこで、タスク管理手法の古典である GTD と、Jira / Linear / Notion / Asana / Todoist / Things の公式ドキュメントを一通り調べました。この記事はその報告です。先に言えるのは、この論点はツール設計の世界でほぼ決着がついていて、答えは「ステータスはいくつが正解」という数の話ではなかった、ということです。

GTD では「返事待ち」と「塩漬け」は別の枝

最初に当たったのは GTD です。GTD（Getting Things Done）は David Allen が2001年の同名の書籍で提唱したタスク管理手法で、Todoist や Things など現行ツールの設計にも影響を与え続けている古典です。骨格はシンプルで、気になることをすべて書き出し、「今アクションできるか？」を起点とするフローチャート（公式のワークフロー図）で1件ずつ振り分けていきます。今回の論点に関わる部分だけ抜き出すと、こういう構造です。

この図を見て、冒頭の悩みに何十年も前から名前が付いていたことを知りました。「止まっているタスク」の置き場（黄色の2つ）が、フローチャートの別々の枝に用意されているのです。

• Waiting For: 実現してほしいが、次のアクションの責任が他者にあるもの。「actionable = yes」側、委譲の出口
• Someday/Maybe: 今はやると決めていないもの。「actionable = no」側、保留の出口

Waiting For は「いつから待っているか」の日付を記録し、週次レビューで「催促する」「状況を確認する」という自分のアクションに変換します。一方 Someday/Maybe の存在理由は、リソースを割く約束のストレスなしにアイデアを捕捉できること。唯一のコミットは「週次で見直す」ことだけです。

冒頭の2タスクを当てはめると、返事待ちの依頼は Waiting For、読みかけの本は Someday/Maybe。きれいに腑分けできてしまいました。

ならステータスを2つ足せば終わりでしょうか。自分もそう思いかけたのですが、ツール側の設計を見ると話はそう単純ではありませんでした。

主要ツールはなぜ「3分類 + α」に収束するのか

次にツール側です。各ツールのデフォルト構成を並べると、名前も数もバラバラに見えて、骨格が同じであることに気づきます。どれも「未着手 / 進行中 / 完了」という3つの大分類に集約できるのです。

ツール	デフォルトのステータス	「未着手 / 進行中 / 完了」との対応
Jira	To Do / In Progress / Done	そのまま3分類
Notion	To-do / In Progress / Complete の3グループ	そのまま3分類（グループ内の細分だけ自由）
Linear	Backlog / Unstarted / Started / Completed / Canceled	未着手を2つに割り、完了に中止を足した拡張
Asana / Todoist	complete / incomplete	さらに粗い2分類

しかもこの骨格は、偶然の一致ではなくベンダーが意図的に守っているものでした。Notion のヘルプには "You can't change the three main categories."（3つのメイングループは変更できない）と明記されています。自由にステータスを足せる Jira ですら、公式ドキュメントで「ステータスの追加は複雑性を増やす。ワークフローはリーンに保て」と警告している。Linear に至っては、カテゴリの種類と順序をシステムレベルで固定した理由を "Flexible software lets everyone invent their own workflows, which eventually creates chaos as teams scale."（柔軟なソフトウェアは各自にワークフローを発明させ、スケール時にカオスを生む）と言い切っています。

では、この3分類に入らない「止まっている」という情報を、各ツールはどう扱っているのか。ここが調べていて一番面白かった部分です。どのツールも Blocked をデフォルトステータスに持っていません。

• Jira: フラグ（Flagged = Impediment）で表現
• Linear: blocked by の関係リンクで表現
• Todoist: @waiting_for ラベルで表現（GTD 公式ガイドの推奨）

なぜステータスにしないのか。「工程のどこにいるか」と「止まっているか」を掛け合わせてみると分かります。

	To Do（未着手）	In Progress（進行中）
順調	これから着手する	作業中
止まっている	着手前に先方の回答待ち	実装途中で仕様の確認待ち

「止まっている」は、どの工程にいても起こり得ます。つまりこの2つは独立した軸です。ここで Blocked を1本のステータス列に混ぜてしまうと、「In Progress で止まった」タスクは Blocked に上書きされて「どの工程で詰まったのか」という情報が消えます。だから各ツールは、工程は3分類のステータスで持ち、止まっているかどうかは直交する印（フラグ・リンク・ラベル）で足す。見出しに書いた「3分類 + α」は、この構造のことです。

増やした先にあるもの

では、この収束を無視して増やすとどうなるか。実例があります。Atlassian のパートナー企業が自社の Jira を監査したところ、70 を超えるステータスが見つかりました。In Review / Under Review / Being Reviewed が同居する世界です。最終的に 8 まで削減されました。

理論的な裏付けもあります。Hick の法則によると、選択肢が n 個あるときの判断時間は log₂(n) に比例して増えます。ステータスを1つ増やすことは、タスクに触れるたびに「これはどれに当たるか」という n 択の分類クイズを自分に課すことと同じです。しかも境界が曖昧な選択肢（On Hold と Blocked の違い、など）は1回あたりの判断コスト自体も押し上げます。

やっかいなのは、追加は一瞬でできるのに削除は難しいという非対称です。既存タスクの移行を考えると、一度増えたステータスはまず戻りません。実務者の経験則は「7以下、理想は4〜6、まず3から始めよ」でした。

判定基準は2つ

ここまでの材料で、冒頭の問いに答えが出せます。ステータス設計の正解は数ではなく、増やす前に通すべき2つの判定基準でした。

1. その状態は、取るべきアクションが違うか。waiting なら「催促する」、someday なら「定期的に再判断する」。アクションが同じなら、それは別ステータスではなくただのラベルで足ります
2. その状態を見直す運用がセットで存在するか。レビューのないステータスは、どんなに正しく分類してもタスクの墓場になります

GTD が Waiting For と Someday/Maybe を週次レビューとセットで定義しているのも、Linear が固定カテゴリの上でしか自由を認めないのも、この2条件の言い換えとして読めます。逆に、この2条件を満たさないステータス（とりあえずの On Hold など）は放置される場所になる、というのが実務者の一致した見解でした。

もう1つ、ツール横断で共通していた設計判断があります。ステータスには「タスクがどの置き場にいるか」だけを表現させ、どの置き場のタスクにも付き得る修飾（blocked のような「止まっている」印）は直交軸（フラグ・ラベル・リンク）に逃がすこと。ステータス1本に全部詰め込まないことで、どの工程で詰まりやすいかの分析も守られます。

で、正解のステータスは何なのか

ここまでの材料を組むと、答えは使う場面で2つに割れました。

チームの開発ツールなら、ツール各社の公式見解のままが正解だと思います。「未着手 / 進行中 / 完了」の3分類を核に、必要なら工程を細分して総数は7以下。止まっているかどうかはフラグや関係リンクで持つ。

個人のタスク管理なら、自分の答えは次の5つです。

ステータス	意味	取るべきアクション
todo	やると決めている。未着手	着手する
in_progress	作業中	進める
waiting	次のアクションの責任が他者にある	週次レビューで催促要否を判断
someday	やるとはまだ決めていない	週次レビューで再開か削除かを判断
done	完了	なし

「さっき、止まっているかどうかは直交軸に逃がせと言ったのに、waiting をステータスにするのか」と思われたかもしれません。ここの区別の基準は、それが置き場か、修飾かです。GTD のワークフロー図を思い出してください。Waiting For と Someday/Maybe は枝の出口、つまりタスクの置き場として定義されていました。置き場は1タスクに1つしかないので、ステータス（タスクが今どこにいるか）と同じ構造をしています。一方 blocked は、どの置き場のタスクにも付き得る修飾です。だから blocked をステータスにすると壊れるけれど、waiting と someday はステータスにしてよい。

マトリクスの言葉で言えば、「In Progress の途中で返事待ちになった」という工程の記憶は確かに消えます。チームでボトルネック分析をするなら致命的です。ただ、個人のリストでやりたいのは催促と再判断だけで、そこは「何を待っているか」のメモ1行で足ります。

冒頭の2タスクのその後

というわけで、CLI に waiting と someday を足しました。順序だけは判定基準の2を律儀に守り、先に週次レビューの手順へ「waiting の催促」と「someday の再判断」を書き加えてから、ステータスを実装しました。逆だと、増やした瞬間に墓場が2つできるだけなので。

返事待ちの依頼は waiting になり、何を待っているかのメモと一緒に、週次レビューで催促要否を確認する対象になりました。読みかけの技術書は someday に落として、週次レビューのたびに「まだ読みたいか」を問い直すことにしました。興味を失っていたら消します。罪悪感なく消せるようになることが、Someday/Maybe の一番の効能だと思っています。

あなたのリストで数週間止まっているそのタスクは、催促すれば動くものですか。それとも、実はもう手放してよいものですか。

参考リンク（一次情報）

• GTD Weekly Review Checklist（David Allen Company 公式）
• Todoist 公式の GTD ガイド（@waiting_for ラベル運用）
• Best practices for workflows in Jira（Atlassian 公式）
• Linear Method（公式）
• Notion: Status プロパティ（公式ヘルプ）
• How to simplify and improve your Jira workflows（New Verve Consulting、70超→8の実例）
• Thou shalt not have a Blocked status in Jira（Kit Friend）
• Shape Up: Show Progress（Basecamp、ステータス不要論）