タスク管理が続かない本当の理由｜二重管理をやめる設計
「先週更新したはずの管理表が、もう実態と合っていない」「同じ案件のステータスが、スプレッドシートとチャットで食い違っている」「結局どれが最新なのか、毎回確認しないと分からない」——タスク管理や案件管理を続けようとすると、誰もが必ずこの壁にぶつかります。
結論から言うと、管理が続かないのは意志の問題ではなく、状態を「手で書き写している」という構造の問題です。書き写す作業がある限り、更新漏れは「たまに起きる事故」ではなく「いつか必ず起きる仕様」になります。直すべきは自分の心がけではなく、管理表の作りのほうです。
株式会社Fyveの田嶋です。私は1人で複数の事業とAIによる自動化を回しているので、管理を「頑張って続ける」方式は早い段階で破綻しました。この記事では、状態をどこにも持たずに元データから毎回「導出」する設計に切り替えた実体験をもとに、Notion・スプレッドシート・メモアプリのどれでも再現できる形で、その考え方をお伝えします。
管理表が実態とズレるのは、意志ではなく構造の問題
まず、よくある症状から整理します。ツールが何であっても、起きることはほとんど同じです。
誰もが経験する3つの症状
- ステータス列だけが古い：作業はとっくに終わっているのに、一覧上は「対応中」のまま止まっている。
- 同じ情報が2箇所以上にある：メールやチャットのやりとりが実態で、管理表はその要約。どちらが正しいのかが人によって違う。
- 定期的な「棚卸し」が必要になる：月末や週明けに、一覧と実態を突き合わせて直す時間が発生している。
この3つが出ている時点で、その管理表は「情報を管理する道具」ではなく「管理される対象」に変わっています。本来は仕事を軽くするために作ったはずのものが、それ自体をメンテナンスする仕事を生んでいる状態です。
「次から気をつける」では直らない
ズレに気づいたとき、多くの人はまず自分の運用を疑います。更新のタイミングを決める、リマインダーを set する、チェックリストを作る。私も同じことを一通りやりました。
ですが、こうした対策はどれも「人間が忘れない」ことを前提にしています。そして人間は、余裕のある日は忘れず、忙しい日に忘れます。忙しい日というのは、案件が動いてステータスが変わる日そのものです。つまり更新が必要な日ほど、更新されない確率が上がるという構造になっている。ここが厄介なところです。
だから私は、「気をつける」の側で解くのをやめました。気をつけなくても壊れない形に、管理表の作りごと組み替えるほうが早いと判断したからです。
ズレの原因は、状態を「手で書き写している」こと
なぜ更新漏れが起きるのか。原因を一段掘り下げると、ほぼすべてのケースで同じ構造に行き着きます。
一次データと状態のあいだに「転記」が挟まっている
たとえば案件管理なら、実際に起きていることの一次情報は、見積書のファイル・納品したデータ・請求の記録・相手とのやりとりのほうにあります。管理表の「ステータス」列は、それを見た人が要約して書き写した結果にすぎません。
タスク管理でも同じです。実際にやったかどうかの事実はコミット履歴やファイルの更新日時、送信済みメールに残っていて、ToDoアプリのチェックボックスはその写しです。ネタ帳や在庫の一覧も、原理は変わりません。
つまり管理表の状態は、ほとんどの場合「一次情報のコピー」です。そしてコピーである以上、元が動いたときに追随しなければズレます。この追随を人間の手作業に任せているのが、二重管理の正体です。
転記は、忙しい日に必ず飛ぶ
転記という作業には、厄介な性質があります。やらなくてもその瞬間は何も困らないという点です。
納品自体は終わっている。相手にも伝わっている。困るのは「あとで一覧を見たとき」だけです。目の前の仕事は前に進んでいるので、転記は後回しにされ、そして後回しにされたものは高い確率で戻ってきません。
この「サボっても即座には痛くない作業」は、あらゆる運用で真っ先に崩れます。逆に言えば、そういう作業を仕組みの中に残していること自体が設計ミスだと考えたほうが健全です。
二重管理が生む3つのコスト
- 棚卸しの工数：ズレを直すための定期作業が発生する。これは本来ゼロにできる仕事です。
- 判断のミス：古い一覧を見て「まだ着手していない」と思い込み、二重に連絡する・優先順位を間違える。管理表を信じるほど被害が大きくなります。
- 管理そのものをやめてしまう：一番深刻なのがこれです。何度もズレを経験すると、人は一覧を見なくなります。そして「頭の中で覚えておく」に戻り、今度は取りこぼしが起きます。
私が最も避けたかったのは3つ目でした。取りこぼしを防ぐために作った仕組みが、信用を失って使われなくなる。これでは仕組みを作った意味がありません。
解決の原則——状態は持たず、毎回「導出」する
ここからが本題です。私が採った解決策は、更新を頑張ることでも、更新を強制することでもありませんでした。状態というものを、そもそもどこにも持たないという方向です。
「導出」とは何か
導出とは、今どうなっているかを、別の場所に書き写さず、元のデータから毎回その場で計算して表示することです。
身近な例で言えば、銀行口座の残高がこれにあたります。残高という数字をどこかに手で書いて管理している人はいません。入出金の記録があり、残高はそこから計算されて表示されているだけです。だから「残高の更新を忘れる」という事故は起きません。更新すべき対象が存在しないからです。
同じことを、自分の管理表でもやります。「対応中」「完了」「保留」といった状態を列として持つのをやめ、元になるデータから毎回組み立て直して一覧を出す。すると「更新漏れ」という失敗の種類が、運用の努力ではなく構造として消えます。
「正しいのはここだけ」を1つ決める
導出を成立させるために必要な準備は、実質1つだけです。元になるデータ（一次データ）を1〜2箇所に決め、そこ以外に情報を置かないこと。
ここが曖昧なままだと、導出しようにも「どれを元にすればいいのか」が決まりません。逆に言えば、この1点さえ決まれば、あとは表示のしかたの問題になります。
私の場合は、扱いたい情報ごとに「正しいのはこのファイルだけ」というルールを先に決めました。一覧・ダッシュボード・レポートの類はすべてその一次データからの派生物と位置づけ、派生物を直接編集することは禁止にしました。派生物を直接いじれるようにしておくと、そこに書いた内容が一次データに戻らず、結局また二重管理が始まるからです。
人が手で書くのは「イベント1行」だけにする
とはいえ、すべてを完全に自動で判定できるわけではありません。「この案件はもう終わった」「このネタはもう使った」といった事実は、機械には分からないことがあります。
そこで私が引いた線が、人間が手で書くのは「出来事の記録」を1行だけ、残りはすべて導出というルールです。
状態ではなく、出来事を記録する
違いはささやかに見えて、性質が正反対です。
- 状態を書く：「この項目のステータスを『完了』に変更する」——既存の記述を書き換える操作。
- 出来事を書く：「この項目を、この日に消費した」と1行追加する操作。過去の記述には触らない。
状態を書く方式では、書き換えを忘れた瞬間に嘘が残ります。しかも「古い情報が表示されている」ことに気づく手がかりが画面上にありません。堂々と間違った顔をして居座ります。
一方、出来事を追記する方式では、記録が無ければ「まだ何も起きていない」と正しく解釈されます。忘れた場合の挙動が、嘘ではなく「未記録」になる——これが決定的な差です。
なぜイベントなら壊れないのか
理由は3つあります。
- 過去を書き換えないので、矛盾が蓄積しない：追記しかしないため、以前の記録が壊れることがありません。
- 「いつ起きたか」が自動的に残る：状態列は現在の値しか持てませんが、イベントは時系列がそのまま履歴になります。あとから振り返れる情報が増えます。
- 操作が1つに減る：どのフィールドをどう変えるか迷う余地がなく、「起きたら1行足す」だけ。迷いが無い操作は続きます。
記録するイベントの選び方
何でもイベントにすればよいわけではありません。私が使っている基準は次の3つです。
- 機械に判定できないものだけ：ファイルの有無や日付で分かることは、わざわざ人が記録しません。それは導出できます。
- 取り消しがきくものだけ：誤って記録しても、行を消せば元に戻る状態にしておきます。
- 1つの出来事につき1行だけ：関連情報を同じ行に詰め込みたくなりますが、増やすほど記入の手間が上がり、続かなくなります。
私が実際にこの設計へ切り替えたときの手順
ここからは、私が自分の管理の仕組みを組み替えたときに実際にやったことを、順番どおりに書きます。特別な道具は使っていません。
ステップ1：一次データを1〜2ファイルに決めた
まず「この情報の正しい姿はここにある」というファイルを決めました。複数の候補があったので、いちばん現場に近いもの——つまり作業の過程で自然に更新されるほうを選びました。
ここでのコツは、「きれいに整理されているほう」ではなく「実際に毎日触っているほう」を正にすることです。整った台帳は見た目こそ良いものの、日々の作業と切り離されているため、放っておくと必ず古くなります。
ステップ2：状態を表す列・印をすべて消した
次に、一覧側から「済」「対応中」「保留」といった状態を表す列や印を、思い切って全部削除しました。ここは少し怖いところですが、消さない限り誰か（自分）がまた手で書き始めます。選択肢として残っていることが、そのまま二重管理の再発源になります。
削除にあたっては、その状態が本当に元データから復元できるかを1つずつ確認しました。復元できないものだけを、次のステップの「イベント」に回しています。
ステップ3：一覧は毎回作り直す形にした
最後に、一覧を「保存しておくもの」から「見るたびに作られるもの」に変えました。開いたときに元データを読み、そのときの状態を計算して並べる。前回の表示結果は保持しません。
これで、一覧が古くなるという事象そのものが起こらなくなりました。古くなる余地は、保存された結果の中にしか存在しないからです。
切り替えて変わったこと・変わらなかったこと
正直に書きます。変わったのは「棚卸しが要らなくなったこと」です。一覧と実態を突き合わせて直す時間が消えました。加えて、一覧を信用できるようになったので、判断のたびに元データを見直す確認作業も減りました。
一方で、変わらなかったこともあります。元データの入力そのものは相変わらず自分の仕事です。導出は「書き写しをなくす」技術であって、「入力をなくす」技術ではありません。ここを取り違えると、期待外れに感じるはずです。
また、切り替えの作業自体には時間がかかりました。既存の状態列を1つずつ「これは導出できるか、イベントにすべきか」と判定していく作業は、それなりに地味です。ただし、これは一度きりの支出で、放置した場合の棚卸しは毎週・毎月かかり続けます。私はここを一度で払うほうを選びました。
以前の私は「更新を強制する」方向で解こうとしていた
実はこの設計にたどり着く前、私は逆のアプローチを取っていました。更新を忘れないように、仕組みで強制するという方向です。ルールとして明文化し、作業の終了時に自動でチェックが走るようにし、更新されていなければ止まるようにしました。
これはこれで効果がありました。実際、強制の層を入れてから更新漏れは目に見えて減っています。その具体的な作り方は、別の記事でまとめています。
ただ、しばらく運用して見えてきたことがあります。強制は「更新すべき対象がある」ことを前提にした対症療法だということです。守らせる仕組みを足すほど、守らせる対象も管理対象として増えていきます。
だから今の私は、順番をこう考えています。まず「持たなくて済む状態」を全部なくす。それでも人の手が要る最小限の部分にだけ、強制の層をかける。強制は最後の手段であって、最初の手段ではありません。この2つは対立するものではなく、適用する順番の問題です。
Notion・スプレッドシート・メモアプリでの落とし込み
この考え方は特定のツールに依存しません。普段お使いのツールでどう実装するかを、それぞれ挙げます。
スプレッドシートの場合
もっとも簡単で効果が大きいのが、入力用のシートと表示用のシートを分けることです。
- 入力シート：出来事を1行ずつ追記していく。日付と対象と種別だけの、素っ気ない表で構いません。
- 表示シート：入力シートを参照する数式だけで構成し、手入力のセルを1つも置かない。
ポイントは、表示シート側に手で書ける余地を残さないことです。1つでも手入力セルがあると、そこから二重管理が再発します。「関数で出せないから、ここだけ手で」が最初の一歩になります。
Notionの場合
Notionはリレーションとロールアップ、数式プロパティが使えるので、導出との相性が良いツールです。
ステータスをセレクトプロパティで持つのをやめ、「完了日が入っているか」「関連する記録が存在するか」から数式で状態を出す形に変えます。人が触るのはチェックボックス1つか、関連レコードを1件足す操作だけにします。
ビューのフィルタも、状態プロパティではなく数式の結果で切ります。こうしておくと、状態の定義を変えたくなったときに数式を1箇所直すだけで全ビューに反映され、既存レコードを手で直す作業が発生しません。
メモアプリ＋AIの場合
ツールを増やしたくない場合、テキストのメモをそのまま一次データにして、一覧はAIに毎回作らせるという手もあります。私がいちばん手軽だと感じているのはこの形です。
やることはシンプルで、思いついたことや起きたことを1つのメモに素の文章で書き足していき、必要なときに「この内容を種類ごとに分けて、まだ手をつけていないものだけ並べて」と頼むだけです。整形された一覧は毎回その場で作られるので、保存されず、古くなりません。
この「入り口を1つに固定して、整理は機械に回す」考え方は、発信ネタの管理でも同じように効きます。私自身の運用は次の記事で書いています。
AIに任せる業務ほど、この設計が効く
ここ最近、AIに定型業務を任せる方が急速に増えています。その文脈でも、状態を持たない設計は効きます。むしろAIを使う場合のほうが、効き方が大きいと感じています。
AIは「今どうなっているか」を毎回作り直すのが得意
AIに一覧やレポートを作らせるとき、元データを渡して「今の状況をまとめて」と頼めば、その場で読んで組み立ててくれます。これはまさに導出そのものです。
逆に、あらかじめ人が要約した状態表をAIに渡すと、AIはその要約が古いかどうかを判断できません。古い前提のまま、もっともらしい報告を返してきます。人間なら「あれ、これ先週の話では」と引っかかるところを、AIは疑わずに通してしまいます。
AIに状態を持たせると、AIも更新を忘れる
もう1つ、実際に運用して分かったことがあります。AIに「作業したらこの一覧も更新しておいて」と頼む方式は、人間と同じ理由で破綻します。
指示が長くなるほど、末尾の付随的な作業は抜けやすくなります。本来の作業が終わった時点で目的は達成されているので、一覧の更新は「やらなくてもその場は困らない作業」に分類されてしまう。人間で起きたことが、そのまま起きます。
だからAIに任せる範囲でも、原則は変わりません。AIに書かせるのは出来事の記録だけにして、一覧は読ませて作らせる。この分担にしてから、報告の中身が実態と食い違うことがほとんどなくなりました。
AIを業務に組み込むときの全体像や、タスク・スケジュール管理の実践的な進め方は、次の記事でも扱っています。
何でも導出すればいいわけではない——3つの例外
ここまで導出を推してきましたが、万能ではありません。むしろ状態として持つべきものもあります。線引きを間違えると、今度は別の形で壊れます。
例外1：人の判断そのもの
「この案件は優先度が高い」「この相手には今は連絡しない」といった判断は、データから計算で出てきません。これは人が決めて、明示的に持つべき情報です。
ただし持ち方には注意が必要で、判断は判断として、事実とは別の場所に置きます。事実（何が起きたか）と判断（どう扱うか）を同じ列に混ぜると、どちらが古いのか分からなくなります。
例外2：履歴として凍結すべき事実
請求済みの金額、締結した契約の条件、送付済みの書類の内容——これらは「その時点でそうだった」ことに意味がある情報です。元データが変わったからといって、後から計算し直されては困ります。
この種の情報は、導出せずにその時点の値をそのまま保存します。会計や契約まわりで導出を適用すると、過去の数字が勝手に動く事故につながるので、ここは明確に分けてください。
例外3：導出コストが高すぎる場合
元データが膨大で、毎回計算すると表示に時間がかかりすぎる場合は、結果を保存しておく判断もあり得ます。
ただし個人や小規模チームの管理表で、この問題に当たることはまずありません。「重くなりそうだから」と先回りして状態を持つのは、たいていの場合は取り越し苦労で、二重管理のコストのほうが先に効いてきます。実際に重くなってから考えれば十分です。
今日から始める3ステップ
大がかりな作り直しは要りません。手元の管理表1つから始められます。
- ステップ1：一覧の中で「手で書き換えている項目」に印を付ける。ステータス列、進捗率、最終更新日など。これが二重管理の候補です。
- ステップ2：それぞれについて「元データから分かるか」を判定する。分かるものは列ごと削除し、元データを参照する形に変えます。分からないものだけ残します。
- ステップ3：残ったものを「出来事の追記」に置き換える。状態を書き換える操作をやめ、1行足すだけの操作に変えます。
この3ステップを1つの管理表で通すと、だいたい30分から1時間で終わります。そして一度やると、他の管理表を見たときにも「これは導出できるな」という目線が入るようになります。
まとめ
タスク管理や案件管理が続かない原因は、多くの場合、自分の意志ではなく管理表の構造にあります。要点を整理します。
- ズレの原因は転記：管理表の状態は一次情報のコピー。コピーがある限り、更新漏れは構造的に必ず起きる。
- 解決は「持たない」こと：状態をどこにも保存せず、元データから毎回導出する。更新すべき対象が無ければ、更新漏れも起きない。
- 人が書くのはイベント1行：状態を書き換えるのではなく、起きたことを追記する。忘れた場合の挙動が「嘘」ではなく「未記録」になる。
- 強制は最後の手段：まず持たなくて済む状態をなくし、残った最小限にだけ強制の層をかける。
- 例外は3つ：人の判断・凍結すべき履歴・導出コストが高すぎる場合は、状態として持つ。
管理をきちんと続けられる人とそうでない人の差は、多くの場合、まじめさではなく「間違えようがない形に組み替えたかどうか」にあります。頑張って維持しなければならない仕組みは、忙しくなった瞬間に壊れます。忙しくても壊れない仕組みだけが、結果的に長く残ります。
とはいえ、自分の業務のどこが二重管理になっているのかを一人で見つけ出すのは、最初の一歩がいちばん難しいところです。私たちは、業務を工程に分解して、どこを機械に任せ、どこを人が持つべきかを整理するところから伴走しています。自社の管理の仕組みを見直したい方は、専属AI活用顧問サービスをご覧ください。
AIを使う会社と、使わない会社。
その差は、開き始めています。
ここ数年でAIは急速に進化し、正しく導入できている企業とそうでない企業とでは、業務効率や人件費に大きな差が生まれ始めています。「AI導入に興味はあるが、実際に何ができて、どこから手をつければいいか分からない」——そんな方は、まずこの無料プレゼントに目を通してみてください。
