なぜ私たちはToDoリストを捨てたのか

最終更新日：2026年8月19日

ほとんどのタスク管理ソフトの中心にあるのは、考えつくかぎりのタスクをすべて溜め込む、従来型のToDoリストです。しかしToDoリストは、タスク管理システムによる統括を必要とするほどタスクの内側に潜む複雑さを、そもそも扱うためのものではありませんでした。

私たちがたどり着いた答えは、タスクツリーが支える入れ子のチェックリストです。この記事は、そのための最初の論考です。

長いToDoリストが心にのしかかるのには、認知的な理由があります。心理学者のE.J. MasicampoとRoy Baumeisterは、未完了のタスクは具体的な計画を立てるまで頭に割り込み続け、いま取り組んでいることから注意を奪うことを見出しました。計画を立てた時点で、その心のざわめきは消えていきます。

フラットなToDoリストはタスクを書き留めるだけで、計画は決して抱えられません。そこがまさに限界です。単なるリストではなくきちんとしたタスク管理ツールを使うべき最大の理由がここにあります。タスクだけでなく、計画そのものを保持してくれるからです。

ToDoリストはどんな役割を果たすのか？

タスクを書き出し始めるのは、自分でうまく管理できないほどタスクが増えたときです。書いたり図にしたりすれば、いわば「目に見えるもの」になり、優先順位づけも完了までの追跡もしやすくなります。

つまり、ToDoリストはタスクを覚えておく（追跡する）ことと、比べる（順位づけする）ことを助けてくれるのです。

ToDoリストが役割を果たせなくなるのはいつか？

タスクの数が増えると、延々と続くリストを眺めても、タスクを比較して優先順位をつける助けにはあまりなりません。結果として残るのは、どれも同じくらい重要に見えるタスクの長い並びです。

同じくらい重要なタスクが大量に並んだリストでは、タスクを追跡し順位づけすることが再び難しくなります。

「比べられない」タスクを書き並べて不均質なリストをつくると、タスクを比較したり順位づけしたりするのが難しくなります。ここで「比べられない」とは、規模も文脈もあまりに違いすぎて、比較や順位づけに意味がないという意味です。

たとえばToDoリストに「書籍Xをn ページ読む」と「自家用操縦士の免許を取る」の両方があるとしたら、この読書のタスクがどの文脈に属しているかを理解しないかぎり、両者は比較可能になりません。

仮に「明日締め切りのプロジェクト」のために、まず書籍Xのそのn ページ分の内容を頭に入れる必要があると思い出せたなら、そこで初めて「明日締め切りのプロジェクト」と「自家用操縦士の免許を取る」の優先度を比べられます。

つまり不均質なリストは、それぞれのタスクにまつわる文脈をすべて記憶しておくことを私たちに要求しますが、それはまず無理な話です。

ToDoリストの有用性を否定する道筋をすべて洗い出すことはしませんが、少なくとも次のことは言えます。タスクの数が、どれも同じくらい重要に見えてしまうほど多くなったとき、あるいはリストが不均質になったとき、ToDoリストはもう十分ではありません。

従来のタスク管理システムに書き込むタスクは、こうした限界にぶつかるのか？

規模が大きく期間の長いタスクは、実行できるようにするために、より扱いやすいアクションアイテムへ分解することが避けられません。

大きなタスクのいくつかが分解され展開されていく一方で、ライフサイクル上まだその段階まで進んでいないものも残ります。こうして私たちは、気づかないうちに不均質なリストをつくり出してしまいます。

リスト内のすべてのタスクが分解されて均質な状態になるまで、混乱は続きます。そしてその時点では、膨れ上がったToDoリストは、同じくらい重要なタスクが延々と並ぶ長大なリストになっているでしょう。

タスク管理システムによる統括を必要とするタスクは、たいてい規模が大きく期間も長いものです。そうしたタスクを従来型のToDoリストに入れれば、リストは必然的に不均質になり、タスクはやがてどれも同じ重要度を帯びるようになります。それは暗黙のうちに、タスクの重要性を薄めてしまうということです。

タスク管理ソフトはToDoリストの限界にどう対処しているのか？

こうした限界があるため、広く採られている解決策は、大もとのToDoリストをいくつかの別のリストに分けることです。たとえば「兄弟」関係のタスクは「子タスク」と呼ばれる別のリストに置かれ、「親」のタスクは「セクション」やそれに類する名前のリストに割り当てられます。

もっと柔軟なシステムなら、子タスク自身がさらに子タスクを持てるようになっており、これは実質的に自分自身に別のリストを無限に付け足していくことです。この仕組みは、下図のような階層構造を生み出します。

任意のタスクや別の子タスクに、子タスクのリストをさらに付け足せる柔軟さがあれば、いつでもタスクを「ズームイン」して分解できます。この過程が階層を生み、その階層が今度はタスク同士の依存関係を示してくれます。

こうして、同じくらい重要なタスクが並ぶフラットなリストという問題は解消されました。そしてタスクの階層が手に入ったので、各階層のタスクが均質になるように整理することもできます。

入れ子のチェックリストとは何か？

同じ考え方は、入れ子のToDoリスト、階層的なタスクリスト、ツリー構造のToDoリストなど、いくつもの呼び名で語られます。大切なのは呼び名よりも約束のほうです。つまり、タスクがどこに属しているかを見失わずに、いつでもそこへズームインできるということです。

しかし入れ子のタスクリストをどう見せるか？

どれほど柔軟なタスク管理ツールでも、深さに制限のない階層構造は許してくれますが、入れ子のリストを見せることはUI設計の観点からはまるで現実的ではありません。

とはいえ、階層に沿ったタスクをすべて見せないままでは、タスクを見守るために必要な文脈をたやすく失ってしまいます。たとえば次のようなタスク構造を考えてみましょう。

「Complete A」の下にある「Get Report B2–1」は、「Complete B」の下にある「Do Report B2–1」が終わっていることを前提としています。しかし入れ子のリストを表示する制約から、妥協した表示はこうなります。

または

どちらの場合でも、「Review A3」が「Do B2」に対して持つ依存関係は完全に見落とされます。それは表示から隠れた子タスクのリストに属しているからです。

一方のタスク階層の子タスクが、もう一方の子タスクに依存している——そう示すべき文脈を、どちらの表示も伝えてくれません。

要するにユーザーが目にしているのは、依然として大もとのままのToDoリストであり、それが今度は複数に増えただけで、タスクの文脈も関係も示されていないのです。

ツリー構造はタスク本来の階層をどう保つのか？

必要な階層をつくるためにリストをつなげていく方法の問題は、リストが別々の存在として保たれてしまうことです。文脈を伝えるのに必要な数だけリストを表示するのは、ユーザーインターフェースの制約を考えれば実現できません。

そこで私たちは、この階層はツリー構造で表したほうがうまくいくと考えました。子タスクはタスクの子ノードになります。タスクを取り出すとき、その文脈全体をかたちづくる親と子のタスクノードも一緒に取り出されるのです。

この構造のもとでは、タスクとその依存関係がタスク管理システムのなかで明確に示されます。タスクをまとめる機能と入れ子のリストでこれがどう働くかはQuireのタスクをまとめる機能と入れ子の考え方のすべてで詳しく掘り下げており、実際のチームでの使い方は実例で見るQuireのサブリスト活用6パターンでご覧いただけます。

Quireは入れ子のタスクリストをどのように扱っているのか？

Quireではすべてのタスクが子タスクを持て、その子タスクもまた自分の子タスクを持てます。だからひとつのプロジェクトは、別々のリストの積み重ねではなく、ひとつのツリーになります。 タスクを開けば親と子が一緒に取り出され、枝をまたぐ依存関係も見えたままで、枝ごとドラッグしたり、いま取り組んでいない枝を折りたたんだりできます。

これが、リストを積み重ねることとツリーを育てることの違いであり、リストではなくタスクツリーがQuireの背骨になった理由です。

タスクは最初、計画もなく、完了までの道筋を探るための知識もない、ざっくりした目標として始まることがあります。目標を達成するために必要な手順は、考えを重ね、協力し合うなかで初めてかたちになっていきます。

タスクが進むにつれて計画を立て整理していくとき、ツリーのノードとして表されたタスクは、下図のようにドラッグ＆ドロップで依存関係に沿って簡単に組み替えられます。

タスクで画面が散らかって集中を失わないように、いま手元のタスクに関係のないタスクツリーは、ただ折りたたんでしまえばいいのです。関連する小技として、ドリルダウンを使えば、ほかを手作業で折りたたむ代わりに、ひとつのタスクとその子タスクだけにズームインできます。

ToDoリストは目標をより「目に見えるもの」にしてくれますが、タスク管理ソフトの背骨になるためのものでは決してありませんでした。

入れ子のToDoリストは、チームワークと協働を必要とするプロジェクトのタスクのような、より複雑な仕事に論理的な階層を与えてくれます。しかし入れ子のリストはやはり別々のリストであり、タスクの文脈を分断してしまいますし、その文脈をユーザーインターフェース上でうまく表示することもできません。

ツリー構造の階層は、タスクがライフサイクルのなかでどう育っていくかを自然にとらえることがわかります。タスク同士の関係を、鳥の目で見渡せるようにしてくれるのです。

タスク管理システムの背骨としては、タスクツリーのほうが優れています。この考え方があなたにも役立つかどうか、ぜひ聞かせてください。Quireを無料で始めて、タスクツリーを試してみてください。

ツリー構造は、より大きな絵の一片です。GTD、カンバン、タイムブロッキングとどう組み合わさるかは長く使えるタスク管理システムのつくり方をご覧ください。

よくある質問

ToDoリストは本来、何のためのものですか？

タスクを目に見える形にすることで、覚えておくことと優先順位づけを助けてくれます。ほどよい数のタスクのために作られたもので、本格的なタスク管理システムが扱う複雑な仕事のためのものではありません。

タスクが積み上がるとToDoリストが機能しなくなるのはなぜですか？

リストが長くなるほど、すべてが同じくらい重要に見えてきて、順位づけが成り立たなくなります。規模がまったく違うタスクを混ぜると、リストを公平に比較することはできなくなります。

入れ子のリストでも問題が完全には解決しないのはなぜですか？

入れ子のリストはひとつのタスクの文脈を複数の別々のリストに分断し、それらをすべて同時に見せることは現実的ではありません。別の枝にあるタスク同士の依存関係は、やはり見落とされます。

ツリー構造はフラットなリストよりどう優れているのですか？

タスク本来の階層を保つので、タスクを開けばその親ノードと子ノードも一緒に表示されます。依存関係は見えたままで、ドラッグ＆ドロップや枝の折りたたみで集中を保てます。

入れ子のチェックリストとは何ですか？

各項目が自分自身の子項目を持てるToDoリストで、一列のフラットな並びではなく親と子の階層をかたちづくります。小さなステップはつねに、それが仕えるより大きなタスクに結びついたままです。

Quireは入れ子のタスクリストをどのように扱っていますか？

すべてのタスクが子タスクを持て、その子タスクもまた自分の子タスクを持てるので、プロジェクトはひとつのツリーになります。タスクを開けば親と子も一緒についてきますし、作業しながら枝ごとドラッグしたり折りたたんだりできます。