多動症的な自分の律し方のまとめ

特別解決ができる訳もなく、この特性とは付き合わなければいけないのだけれど、少しでも言語化してマシにしていきたいな、という記録。

TODO

TODOは棚卸し&ソートする

これだけでも作業になっちゃうんですけど、とりあえず週1でも2どこかで時間をスケジュールしておいて、棚卸しとソートしましょう。 要らないと思ったTODOは消しちゃう、また思い立ったら追加しちゃう。

TODOは本当に悪か

TODOリストはADHD的な、多動症的な人間には良くない、とっとと消費した方が良いっていうのが言われたりしますが、 「とりあえずリストに入れておくだけ」でその場を収めたり、真に必要なTODOを見失わないようにするのはいいと思うんですよね。

TODOに期限をつけない

TODOリストには期限付けない方が良い気がします。とりあえず投げられるだけ投げておく。いったん保留のステップを作れるようにする。

行動

効率は考えないで実行する

買い出しのついでにゴミ出しとか、~をしてから洗濯とか、実行効率を考えず、とりあえず実行した方が選択肢が減って思考はクリアになる傾向にあります。

実際にタスクを実行できて減るわけですし。行動が止まりがちで何もできない感覚を覚えるときは何よりこれが重要で、鬱の時はこれをしてから回復にあった気がします。

問題は優先順位を見失う点です。本当に重要なことは何か、をTODOなりで管理し、確認する必要性は生じてきます。ところがそれが面倒だったりするんですよね。

だものでいつでも当てはまるものではないですが、足が止まる手が止まるときに、とりあえず実行すること、は大事だと思います。

整理

目に見える情報が多いと、思考が散ります。興味関心が広いこと自体は悪いことではないと思うんですが、とはいえそれが自分にとってプラスの結果をもたらすかは別です。

もっと具体的には、利益をもたらしてくれる関心や興味かは別の話というわけです。往々にして放置したものは物理的にも情報的にも、その価値が低下するものが多く、 そこに関心を割いても利益にならなかったりします。

定期的な片付け

単に片付けるではなく、(1)平時使わないものは目に見えないように収納する (2)動かさなかったものは処分を検討する、の2アクションがあると思っていて、これらが常に同時に実行される必要はないです。

(1)が整理で(2)が処分みたいなイメージですかね。(1)には副次的な効果があって、新しく仕入れた感心や物を整理する場所や方法がある程度決まってると、2回目以降は早くなるんですよね。

(2)のアクションも実は重要で、広いスペースがあって片付けが出来る方が、そもそも片付け効率が高いので、定期的にスペースは確保しましょう。

ここで確保されるスペースとは、物理的なスペースにもなるし、思考的なスペースにもなってくれます。きっと。

ブックマークを整理しよう

片づけは物理的な物だけではなく情報にも重要だと考えています。

特にブックマークのように、すぐさまアクセスできるようにするのは、平時よくアクセスするものだけにしましょう。それ以外は片付けが必要です。

Googleのスプレッドシートでも、エクセルでもなんでもいいですけど、少ないアクションでアクセスできる場所に情報があると、思考がそこに引っ張ら裸れます。

スマホのアプリとかもそうですね。情報はできるだけホームに表示されていない方が良いです。決済アプリとか、 時刻表とかTODOとか、素早くアクセスできる必要性がある物だけホームに表示して、それ以外はホームでは非表示が良いです。

スケジューリング

やりたいことはスケジュールに入れる

今の時代に急に休みたくなった、急に休みになったでできることって多くないです。誰かとどこかにでかけるにせ、病院だ、習い事だ、観劇だと。 とりいあえず先に予定入れちゃうのが良い気がします。

スケジュールを入れたら、その時間はそれだけする

どんなに小さいことでもやらなければならないなら、とりあえずカレンダーに「この日のこの時間はこれをする」 を入れて、その時間はそれ以外にしない。終わらなかったらまたスケジュールを入れる。 ルールベースにした方が作業は片付きそう。

消費行動

実物を見ないでまで買う理由はあるか

どんなものでも実物を見てから買った方が失敗が少ないに決まっている。ところが今の時代は店舗が無かったりもするし、欲しい物が見つかると気になってしまう。 そんなときに「実物を見ないリスクを負ってまで買う理由があるか」を考える。どうせそれ以外の理由はたくさん出てくる。

長期的なリソースになりうるか

物を買ったり勉強したり、そのお金の使い方は、長期的に自分の財産になり得るかを考える。もし短期的なら、そこにどれだけの理由があるかを考える。

もし失敗しても失敗理由さえ明確にできれば、それは同じ失敗をしないための長期的なリソースとして見れるから、そのときはきちんと言語化する。