task-ops

ToDoリストが続かない理由|書く場所が増えているだけかもしれない

2026年9月10日 ・ Pinateca編集部

ToDoリストが続かない、という相談は、個人の習慣づくりの話として語られることがほとんどです。ところが、チームの進行をとりまとめている立場で同じ悩みを抱えている場合、原因はたいてい本人の意志の外側にあります。書く場所が増えていること、1行の大きさがそろっていないこと、書いたあとに開く理由が無いこと。この3つが重なると、どれだけ真面目な人が担当しても、リストは2週間ほどで止まります。

この記事では、ToDoリストが続かない状態を意志の問題として扱わず、置き場と粒度と見返しの3つに分けて見立て直します。そのうえで、いま使っている道具のどこで詰まっているのかを見極め、次に何を変えればよいかを決められるところまでを扱います。読み終えたときに、道具を替えるべきなのか、道具はそのままで運用の線引きだけを変えればよいのかを、自分のチームについて判断できる状態を目指します。

「続かない」の正体は、意志ではなく置き場の数

続かないという言葉は、努力の量を指しているように聞こえます。しかし現場で起きていることを分解すると、努力の量ではなく、同じ仕事の情報がいくつの場所に散っているかで、続くかどうかがほぼ決まります。場所が1つなら、更新は1回で済みます。場所が3つあれば、更新は3回必要になり、3回のうち1回でも抜ければ、そのリストは信用できないものに変わります。信用できないリストは、開かれなくなります。

書く場所は、増えることはあっても減らない

チームで働いていると、書く場所は自然に増えます。最初はチャットの投稿だけだったものが、忘れそうだからと表計算に一覧を作り、締切が見えないからとカレンダーに入れ、社外の相手が絡むとメールの文面にも同じ内容が書かれます。それぞれに理由があって増えているので、誰も間違ったことはしていません。問題は、増えた場所を減らす判断が、誰の担当にもなっていないことです。

よく聞くのは、道具を新しく入れたのに古い場所が生き残り、結局2つの場所を並行して更新することになった、という話です。新しい道具の使い勝手が悪かったのではなく、古い場所を閉じる決定をしなかったことが原因になっています。2つの場所を同時に正しく保つ運用は、参加人数が増えるほど破綻します。5人ならなんとか回っても、20人になると誰かが必ず片方だけを見て動きます。

意志の問題にすると、対策が精神論で止まる

続かない理由を意志に置くと、出てくる対策は「毎朝チェックする習慣をつける」「終業前に必ず更新する」といった、行動の呼びかけになります。呼びかけは最初の1週間だけ効きます。忙しい日が2日続くと止まり、止まったリストは古い情報を表示し続け、古い情報を見た人が別の場所で確認を取り、その確認のやりとりが新しい置き場を1つ増やします。悪循環の入口はここです。

とりまとめる立場の人が最初にやるべきなのは、メンバーに更新を促すことではありません。更新しなければならない場所の数を数えて、減らせるかどうかを判断することです。数えるだけで、続かない理由の大半が見えます。

個人のToDoとチームのタスクは、そもそも別の道具

もう1つ、混同されやすいのが、個人のToDoとチームのタスクを1つのリストで扱おうとすることです。個人のToDoは、自分だけが分かればよく、書き方も並べ方も自由で、終わったら消してよい性質のものです。チームのタスクは、他の人が読んで意味が通り、誰が持っているかが分かり、終わったあとも履歴として残る必要があります。要求が違うので、同じ形式で書くと必ずどちらかが破綻します。

個人のToDoに他人の依頼を混ぜると、依頼した側からは見えないので進捗の問い合わせが増えます。逆にチームの板に個人の細かい手順を全部書くと、他の人にとって関係のない行が並び、板を開いても自分に関係する情報が探しにくくなります。この2つを分けるだけで、続かない感覚がかなり軽くなることがあります。

原因1 置き場が分かれている

ここからは3つの原因を1つずつ扱います。最初は置き場です。実務では、これが最も頻度が高く、そして最も直しやすい原因です。

同じ仕事が、気づくと3つの場所に書かれている

ある案件について、どこに何が書かれているかを実際にたどると、次のような分かれ方をしていることがよくあります。

置き場 そこにある情報 起きやすいこと
チャット 依頼の経緯、細かい判断、最新のやりとり 流れて見つからない、検索しても前後の文脈が拾えない
表計算の一覧 全体のタスク名と担当と期日 更新が特定の1人に集中する、開くと編集がぶつかる
カレンダー 締切と打ち合わせ タスクの中身が書けず、日付だけが独り歩きする
メール 社外との合意事項 社内の人が読めない、担当が変わると引き継がれない

この4つがそろっている状態は珍しくありません。それぞれが必要だから存在していますが、同じタスクの情報が4か所に分かれていると、正しい状態を知るために4か所を突き合わせる必要が出ます。突き合わせは、とりまとめる人の時間を静かに削っていきます。

分かれた置き場は、探す時間と二重更新を生む

置き場が分かれることの実害は、2つの形で出ます。1つは探す時間です。「あの件、どうなってたっけ」と聞かれてから答えるまでに、チャットをさかのぼり、表計算を開き、メールを検索する。1回あたりは5分程度でも、日に何度も起きれば、進行の仕事のかなりの割合を占めます。

もう1つは二重更新です。表計算の期日を直したのに、チャットに書いた古い期日はそのまま残ります。後から参加した人が古い方を読んで動き、手戻りが発生します。手戻りが起きると、次からは念のため両方を確認するようになり、確認の手間がさらに増えます。二重更新は、間違いを生むだけでなく、正しい情報を確かめるコストまで押し上げます。

情報を1か所に寄せる価値は、便利さの話ではなく、この確かめるコストを消すことにあります。1か所しかなければ、そこに書いてあることが正しい、という前提を全員が共有できます。

置き場を1つに寄せるときの、現実的な線引き

とはいえ、チャットもカレンダーもメールも無くすことはできません。現実的な線引きは、すべてを1つにすることではなく、一次情報をどこに置くかを1つに決めることです。

  • 一次情報の置き場: タスクの現在の状態、担当、期日、判断の結果。ここに書いてあるものが正しい、と全員が合意する場所を1つだけ決める
  • 話す場所: チャット。相談や雑談はここでよい。ただし決まったことは一次情報の置き場に書き写す
  • 予定の場所: カレンダー。打ち合わせの時間はここでよい。タスクの期日は一次情報の置き場を正とする
  • 社外との記録: メール。合意した内容の要点だけを一次情報の置き場に転記する

この線引きの肝は、「チャットに書いただけでは決まったことにならない」という共通認識を作ることです。ルールとしては1行で済みますが、定着には時間がかかります。とりまとめる人が、チャットで決まった話を見つけたらその場で一次情報の置き場に書き写し、「こちらに書いておきました」と返す。これを何度か繰り返すと、周りも同じ動きをするようになります。

原因2 粒度が合っていない

置き場を1つにしても続かない場合、次に疑うのは1行の大きさです。粒度がそろっていないリストは、見た目は整っていても、実際には使えません。

「サイト改修」と「バナーの色を直す」が同じ行に並ぶ

粒度がそろわないリストには、数か月かかる大きな塊と、10分で終わる細かい作業が同じ並びで置かれています。この状態には2つの困りごとが同時に発生します。

大きな塊のほうは、何をすれば終わりなのかが決まっていないので、いつまでも完了になりません。完了しない行がリストの上に居座り続けると、リスト全体が動いていないように見えます。動いていないように見えるリストは、開く気持ちを削ぎます。

細かい作業のほうは、数が多すぎて埋もれます。10分で終わる作業を全部書くと行数が膨れ、本当に気にすべき大きな話が見えなくなります。書いた本人以外には意味が分からない行も混ざり、他の人が読んでも状況がつかめません。

粒度がそろわないと、終わらないタスクが居座る

とりまとめる立場から見て厄介なのは、粒度の大きい行が「進捗率」で報告されるようになることです。サイト改修が70%です、という報告は、聞いた側には何も伝えません。残りの30%に何が入っているのかが分からず、それが1日で終わるのか2週間かかるのかも判断できません。

進捗率が出てくるのは、多くの場合、タスクが大きすぎて「終わった」「終わっていない」で言えなくなっているサインです。報告の仕方を直すより、行の大きさを直すほうが早く解決します。

1行の大きさをそろえる基準

粒度をそろえる基準は、チームごとに決めればよいものですが、次の考え方が扱いやすいです。

  • 1行は、担当が1人に決まる大きさにする。2人以上でやる話なら、それは複数の行に分かれる
  • 1行は、終わったかどうかを他の人が見て判断できる大きさにする。判断できないなら、条件が書かれていない
  • 1行は、数日で終わる大きさにする。1か月かかるものは、途中で状況が変わって行の意味自体が変わる
  • 大きい塊は、板の上では「まとまり」として扱い、実際に動かすのは分けたあとの行にする

最後の点が実務では効きます。「サイト改修」のような塊は消す必要はありません。塊は塊として置いておき、そこにぶら下がる形で数日単位の行を作る。塊の行は状況の目印として使い、動かすのは下の行だけ、と決めると、リストは動いて見えるようになります。

粒度の基準を決めたら、それを板の中の見えるところに1行で書いておくことをおすすめします。口頭で共有した基準は3週間で忘れられます。書いてあれば、新しく入った人にも同じ基準が伝わります。

原因3 見返す機会が無い

3つ目は、書いたあとの話です。置き場をそろえ、粒度をそろえても、開く理由が無ければリストは古くなります。古くなったリストは、意志ではなく設計の問題で死にます。

書いたあとに開く理由が無いリストは、必ず古くなる

書く行為には目的があります。忘れないため、共有するため、証拠として残すため。ところが、書いたあとに開く場面が用意されていないと、書いたこと自体が目的になり、内容が現実とずれていても誰も気づきません。

現場でしばしば出るのは、月初に立てた計画表が、月末に一度も開かれないまま次の月を迎えるという話です。計画表そのものが悪いのではなく、開く場面が予定に入っていないことが原因です。人は、予定に入っていないことを継続的にはやりません。

見返しを、予定のほうに埋め込む

見返しを続けるための一番確実な方法は、見返す時刻を予定として固定することです。習慣に頼らず、時間を先に取ります。

  • 朝の10分: 今日動く行だけを確認する。全部は見ない
  • 週に1回30分: 動いていない行を拾い、行の大きさが適切かを見直す
  • 月に1回: 終わった行を片付け、残った塊の意味が今も有効かを確認する

この3層にすると、毎日全部を見る必要がなくなります。毎日全部を見る運用は、行数が増えた時点で必ず破綻します。頻度と範囲をずらすことで、負荷を一定に保てます。

週に1回の見直しでは、進んでいる行より、動いていない行に時間を使うほうが有効です。動いている行は放っておいても進みます。2週間動いていない行には、たいてい理由があります。他の人の返事待ちだったり、そもそも誰が持っているのか曖昧だったり、やらなくてよくなっていたり。理由を1つずつ潰すのが、とりまとめる人の実際の仕事です。

誰かが見ている状態を作る

個人のToDoが続かない大きな理由は、見る人が自分しかいないことです。チームのタスクでは、これを逆手に取れます。他の人が見る場所に置いてあれば、更新されていないこと自体が目立ちます。目立てば、誰かが聞きます。聞かれれば、更新されます。

そのためには、板が読まれる状態になっている必要があります。開いた瞬間に自分に関係する行が分かること、状態が色や列で一目で分かること、更新に手間がかからないこと。この3つが欠けていると、見られる場所であっても実際には見られません。

道具の使い勝手の話がここで初めて出てきます。置き場と粒度と見返しの設計を整えたうえで、それでも運用が重いなら、道具の側に原因がある可能性が出てきます。逆に言えば、設計を整えないまま道具を替えても、同じ問題が新しい道具で再現します。

デジタル化は、道具を入れることと業務を見直すことの両輪

道具の入れ替えだけで問題が解決すると考えると、たいてい期待は外れます。この点は、公的機関が中小企業のデジタル化について整理してきた内容とも重なります。

業務のデジタル化は、道具を導入することだけでは効果が出にくく、業務の進め方そのものを見直すことと組み合わせて初めて成果につながる。中小企業向けの各種資料でも、IT導入と業務プロセスの見直しをあわせて進めることの重要性が繰り返し示されている。 出典: chusho.meti.go.jp

ToDoリストが続かない問題に置き換えると、業務の進め方の見直しにあたるのが、置き場を1つに決めることと、粒度の基準を決めることです。この2つを決めずに道具だけを替えると、新しい道具の中に古い運用がそのまま持ち込まれます。

立て直しの手順

見立てが済んだら、順番に手を入れます。全部を一度に変えるとチームが混乱するので、順番が重要です。

ステップ1 いま書いている場所を全部書き出す

最初にやるのは、削減ではなく棚卸しです。1つの案件を選び、その案件に関する情報がどこに書かれているかを全部挙げます。チャットのチャンネル、表計算のファイル、カレンダー、メール、紙のメモ、個人の手帳まで含めます。

このとき、とりまとめる人が1人で書き出さないことです。メンバーに「この件、どこ見て動いてる」と聞くと、把握していなかった置き場が出てきます。全員が同じ場所を見ていると思い込んでいたのに、実は3種類に分かれていた、というのはよくある話です。

ステップ2 一次情報の置き場を1つ決める

棚卸しで出てきた場所のうち、どれを一次情報の置き場にするかを決めます。決め方の基準は、機能の多さではありません。全員が抵抗なく開けること、更新に手間がかからないこと、他の人の状態が見えることの3つです。

すでに使っている道具の中から選べるなら、それが最も安全です。新しい道具を入れる判断は、既存の道具で無理だと分かってからで遅くありません。決めたら、それ以外の場所は一次情報ではないことを明示します。「表計算は参照用で、正しいのは板のほう」と言い切ります。

ステップ3 粒度の基準を1行で決めて、板に書いておく

次に、1行の大きさの基準を決めます。前の章で挙げた基準のうち、自分のチームで守れそうなものを1つか2つ選び、板の見える場所に書きます。全部を守らせようとすると誰も守りません。

実務でよく機能するのは「1行は担当が1人に決まる大きさ」という基準です。これだけで、責任の所在が曖昧な行がかなり減ります。担当が決まらない行は、そもそもタスクではなく相談事項なので、別の扱いにします。

ステップ4 見返す時刻をカレンダーに入れる

見返しの時間を予定として確保します。とりまとめる人が1人でやる時間と、チーム全員で見る時間を分けます。全員で見る時間は、長くする必要はありません。週に15分でも、全員が同じ画面を見て状態を確認する時間があると、板が現実とずれにくくなります。

この時間で、進んだ話をする必要はありません。動いていない行だけを順に見て、詰まっている理由を確認する。それだけで十分に機能します。

ステップ5 2週間後に、続いているかを「場所の数」で測る

立て直しがうまくいったかどうかは、更新回数や達成率ではなく、置き場の数で測ります。2週間後に、同じ案件の情報が何か所に書かれているかを数え直します。減っていれば設計は効いています。減っていなければ、古い場所を閉じる決定が足りていません。

達成率で測ると、数字を良く見せるために小さい行を大量に作る動きが出ます。場所の数で測ると、そういう歪みが起きません。測るものを間違えないことが、続く運用を作るうえで意外に重要です。

道具を替えるべきときと、替えなくていいとき

設計を整えたうえで、それでも運用が重い場合に、道具の入れ替えを検討します。ただし、替えなくてよい場合を先に確認しておくほうが安全です。

いまの道具のままでよい場合

次のような状態なら、道具を替える理由はほとんどありません。

  • 板やリストを開けば、全員が自分に関係する行をすぐ見つけられている
  • 更新が特定の1人に集中していない
  • 社外の相手や、たまにしか関わらない人でも、招待して見てもらえている
  • 課金の単位や上限が、チームの人数の増減に対して無理なく収まっている

これらが満たされているなら、続かない原因は道具ではなく運用側にあります。運用の見直しを先にやったほうが、コストも学習の手間もかかりません。

替えることを検討したほうがよい場合

一方で、次のような詰まり方は、運用の工夫では解消しにくい性質のものです。

  • 人数が増えるたびに費用が跳ね、必要な機能を使うために上位のプランへ動かざるを得ない
  • 板の数や履歴の保存に制限があり、案件が増えると古い板を消す判断を迫られる
  • 社外の相手を招くたびに、費用や権限の設計を考え直す必要がある
  • 画面が日本語で統一されておらず、たまにしか触らない人が用語で迷う

料金の考え方については、プラン設計そのものが道具ごとに違います。人数で課金するもの、機能で段階を分けるもの、保存量で区切るものがあり、どれが自分のチームに合うかは人数の増減の見込みで変わります。区切り方の考え方は料金で整理していますが、ここでは機能で絞らず、区切るのは人数とボードの数だけという設計もあることを押さえておけば十分です。機能で段階を分けない設計だと、少人数のうちから必要な機能が全部使える代わりに、人数が増えたときの上がり方が読みやすくなります。

いま使っている道具ごとの、詰まりやすいところ

道具を替えるかどうかを判断するには、いま使っているものの得意と不得意を、感情を挟まずに見るのが早道です。どの道具にも、その形が向いている使い方があります。

カードを列で動かす形の板に慣れているチームなら、その考え方はそのまま活かせます。列で状態を表す運用の利点と、板が増えたときに起きることを整理したものがTrelloとの比較です。いま列で回せているなら、その運用を捨てる必要はありません。

タスクの依存関係や担当の割り当てを細かく設計したい場合の考え方はAsanaとの比較にまとめています。細かく設計できることは強みですが、設計した通りに全員が入力してくれるかは別の問題です。入力する人が増えないと、進捗の表はすぐ嘘になります。

文書とタスクを同じ場所で扱いたい場合の整理はNotionとの比較にあります。自由度が高い道具は、作り込むほど作った人しか運用できなくなる傾向があるので、とりまとめる人が1人しかいないチームでは注意が必要です。

全社的な進行管理まで含めて設計したい場合の観点はmonday.comとの比較、開発の課題管理と進行管理をつなげたい場合はBacklogとの比較、日本語の画面で軽く始めたい場合はJootoとの比較で、それぞれ向き不向きを整理しています。どれか1つに絞る前に、いくつかの観点をまとめて眺めたい場合は比較の一覧から入るのが早いです。

板でできることの範囲そのものを先に確認したい場合はできることに一覧があります。ここで正直に書いておくと、リポジトリ機能はありませんし、自動化や外部サービスとの連携の豊富さで勝負する設計にもなっていません。画面は日本語のみで、自動で取り込めるのは今のところTrelloからだけです。開発のソース管理まで1つにまとめたい、あるいは多数の外部サービスと自動でつなぎたいという要件が中心なら、その要件を満たす道具を選ぶほうが結果的に早く済みます。

移行するときに、実際につまずくところ

道具を替えると決めた場合でも、移行の途中でつまずくと、置き場が一時的に2つに増えます。これが最も危険な状態です。移行期間が長引くほど、続かない状態に逆戻りしやすくなります。

つまずきやすいのは次の3点です。

1つ目は、古い場所を閉じる日を決めていないことです。移行の計画に「いつから新しい場所だけを使うか」を入れないと、両方が生き残ります。日付を先に決め、その日以降は古い場所を編集できない状態にするのが確実です。

2つ目は、過去の情報を全部持っていこうとすることです。終わった案件まで移そうとすると作業量が膨らみ、移行そのものが止まります。動いている案件だけを移し、終わったものは古い場所を参照用として残す割り切りで十分な場合がほとんどです。既存の板を手作業で作り直すのが負担になる場合は、取り込みの手順をTrelloからの移行で確認できます。

3つ目は、社内の承認が必要なのに、その確認を後回しにすることです。社外の相手やメンバーの情報を扱う以上、どこに保管されるのか、誰が見られるのかを説明できる状態にしておく必要があります。この観点の整理は安全性の考え方にまとめています。導入の相談で毎回聞かれる論点なので、先に目を通しておくと社内の説明が短く済みます。

移行の細かい疑問についてはよくある質問に、料金の変更や解約の扱いを含めて回答をまとめています。移行の前に不明点をつぶしておくほうが、途中で止まるリスクを下げられます。

続かない状態を、板の考え方から見直す

最後に、ここまでの3つの原因を、板にまとめるという考え方から整理し直します。

板型のタスク管理は、列で状態を表し、カードでタスクを表す形式です。この形式が続かない問題に効くのは、3つの原因それぞれに対応する仕掛けが最初から入っているからです。

置き場については、板が1枚あれば、その案件の情報はそこに集まります。カードを開けば、依頼の経緯も、担当も、期日も、最後のやりとりも同じ場所にあります。突き合わせが要らなくなるので、確かめるコストが消えます。逆に言えば、板を案件ごとに増やしすぎると、この利点は薄れます。板の枚数は、チームが把握できる範囲に抑えるほうがよく、増やすかどうかの判断は費用の設計とも関わります。

粒度については、カードが1枚という形が、大きさをそろえる圧力になります。1枚のカードに書ける情報の量には自然な上限があり、書ききれないほど大きい話は分けたくなります。列を移動させるという操作も、状態が「終わった」「終わっていない」ではっきりする大きさを求めます。形式が粒度を導く、というのが板型の地味な利点です。

見返しについては、列に並んだカードの位置そのものが状態を表すので、開いた瞬間に何が動いていないかが分かります。表計算の一覧では、動いていない行を見つけるのに更新日時の列を追う必要がありますが、板では左端の列に長く居座っているカードが一目で分かります。週に1回の見直しで見るべき対象が、探さなくても目に入る状態になります。

そのうえで、板にすれば自動的に続くわけではないことも書いておきます。板を作っただけで古い置き場を閉じなければ、置き場は増えます。カードを作るだけで大きさをそろえなければ、動かないカードが左端に溜まります。見返す時間を予定に入れなければ、板も古くなります。道具は、決めたことを守りやすくするための形であって、決めること自体を肩代わりしてくれるものではありません。

ToDoリストが続かないと感じたときに最初に数えるべきは、更新をさぼった回数ではなく、同じ仕事が何か所に書かれているかです。その数が減れば、続けるための努力は自然に小さくなります。努力が小さくなれば、忙しい週でも止まりません。続く仕組みとは、意志が強い人を前提にしない仕組みのことです。

Q1. ToDoリストが続かないのは、結局やる気の問題ではないのですか?

やる気の差で説明できる範囲は限られます。同じ仕事の情報がチャットと表計算とカレンダーに分かれていると、更新が3回必要になり、1回抜けただけでリスト全体が信用できなくなります。まず、その案件の情報が何か所に書かれているかを数えてください。場所の数が減れば、続けるために必要な努力も自然に減ります。

Q2. 個人のToDoとチームのタスクは、同じリストで管理してよいですか?

分けたほうが安全です。個人のToDoは自分だけ分かればよく、終われば消してよいものです。チームのタスクは他の人が読んで意味が通り、誰が持っているかが分かり、履歴として残る必要があります。要求が違うので同じ形式に押し込むと、個人の細かい行が板を埋めるか、依頼が個人のメモに埋もれるかのどちらかになります。

Q3. タスクの1行は、どのくらいの大きさで書けばよいですか?

担当が1人に決まり、終わったかどうかを他の人が見て判断でき、数日で終わる大きさが目安です。数か月かかる塊は、まとまりとして置いておき、実際に動かすのは分けたあとの行にします。進捗率で報告したくなったら、その行が大きすぎるサインだと考えてください。

Q4. 続けられているかどうかは、何で判断すればよいですか?

更新回数や達成率ではなく、同じ案件の情報が書かれている場所の数で測ってください。2週間後に数え直して減っていれば設計は効いています。達成率で測ると、数字をよく見せるために小さい行を大量に作る動きが出て、板が読みにくくなります。

ブログ一覧へ

ほかの記事

触ってみるのが、いちばん早い。

5人まで無料で使えます。クレジットカードは不要です。

無料で始める