読書を「プロジェクト」として管理する

 タスク管理、GTDでいう実行のフェーズになると思いますが、最近なかなか読書がはかどりません。やるべき事が明確になってくると、それをこなすことに注力してしまい、読書は後回しになってしまいます。しかし、インプット不足になってくるとアウトプットにも支障が出てきて、そのバランスを取ることに苦労します。

 その中で気がついたのは、読書は気が向いたら読むというものではなく、期限を設けて進行管理をしていくもの、それはやはり「プロジェクト」なんだと。

 これは考えてみれば当たり前のことですが、これまで意識をしておらず、プロジェクトリストにも登録していませんでした。

 単なる息抜きで読むのであればそれで問題ないのですが、そういう訳にはいかない。読み終わるのが遅くなれば何かしら困るものなのです。

 読書をプロジェクトにする時に気をつけないといけないのが、いつ終わらせるという明確な期限がある訳ではない。しかし、一定の終了見通しをたてながら、読んでいかないといけない種類のものだということです。期限が明確であれば、既存の作業量と比較して優先順位を上下出来ますが、期限があまり明確でないために、優先順位を上手く決められない。読書の優先順位が下がってしまうのです。ならば期限を決めればいいのですが、根拠なく仮で決めた期限は、意識的・無意識問わず、先送りしてしまいがち。機能しないのです。

 そう考えると、仮の期限を設定してそれをむやみに追うより、完了の見通しと期限とを見比べながら進めていく方が、先送りから逃れやすいように感じます。

 佐々木正悟さんの「クラウド時代のタスク管理の技術」では、その事に関してこう書いておられます。

締切がはっきり決まっているプロジェクトはまだいいのですが、「夢を叶えるプロジェクト」などは難物です。「海外で生きていくために毎日英語の勉強を３時間はしよう！」などと意気込むのはいいが、現実には３秒もやらなかったりします。「英語の勉強をするプロジェクト」や「海外移住プロジェクト」などは、ほとんど妄想の産物と言って良く、これをOmniFocusで管理しようとTOOdledoで管理しようと、それだけで目標を達成できる訳ではありません。そこでまず現実をチェックします。（中略）　このようにして、毎日の読書ベースを計測し、将来読もうとしている本についても、大ざっぱな計算をしてもらいます。（中略）　こうした計算をちょっとやってみるだけでも、プロジェクトがイメージしているとおりに進行しているのか、それとも希望的観測にすぎないのかがよくわかるのです。（P73）

 何かしら見通しとイメージをつけて、それを期限に反映させていくということだと思います。

 これまで優先順位を下げてしまっていた読書をプロジェクトとし、見通しをつけて前に進めていこうと思います。