Noratetsu Lab

　タスク管理は何のためにやるのか、というお話がうちあわせCastであった。

• 第百六十八回：Tak.さんと何のためのタスク管理か - 知的生産の技術

　少し考えてみたが、個人的には「養うため」というのが一番収まりがよいかもしれない。（今自分で考えて書いているけれど、他に誰かは言ってそう。）
　「養う」にも色々あるが例えばこういうこと。

• 自分および家族のいのち
• 人生の納得感、コントロール感
• 自身の有能感、自己肯定感
• 自分の能力

　まず第一に、自分や家族が生きられるように養っていかなくてはならない。仕事がうまくできないということは、昇進できないかもしれないしクビになるかもしれないし仕事が取れないかもしれないし会社が潰れるかもしれないということだ。そうすると文化的な暮らしはできなくなっていくし、いのちすら危うくなる。収入が減らないようにするために仕事をうまくやらねばならない、というのがタスク管理の大前提だろう。
　働き続けるためには働けるような精神状態を保っておかなくてはならないので、その意味では「怒られないようにする」といったことも重要な要素である。（怒られたくなさで倫理を無視してはまずいけれども。）
　切羽詰まっているとか生存以外の欲がないとかであれば、自分や家族を養えれば達成ということになり、それ以外の意味合いはタスク管理に伴わないかもしれない。そして別に管理しなくても養えるなら（あるいは自分が養わなくてもいいのなら）そもそもタスク管理は不要だろうと思う。

　生き物としていのちが続くことを確実にできたなら、次は精神面の健康を養う必要がある。
　不満があったり不幸を感じていたりすれば、寿命まで生きるには生きたが生きた甲斐がなかった、ということになりかねない。それを回避するためには、自分の生活に納得すること、社会を構成する一個体として十分な存在であると思えることが必要だろう。
　つまり、自分の生活がどういうものであり、自分は何を選択しているのか、そして実際に何を成してそれが社会でどういう意味を持っているのか、ということを把握し管理することで不満から脱出するよう試みるわけである。この意味では、誰かを養う身分でなくともタスク管理というものは有用ということになる。
　ただしこれらは、例えば「どう生きたって人はどうせ死ぬのだ」的な考えに納得しているならば必要ない要素であろうと思う。幸福感の欠如に悩まされていないのならわざわざ自分の選択や存在意義に思い巡らさなくても構わないだろう。

　更に、生存を確かにするためにしろ幸福感を確かにするためにしろ、ただ現状をどうにかしているだけでは足りなそうならば、環境を変えるためにまだ自分にない能力を新たに養う努力をしなくてはならない。そのためにはその努力をするのに必要な時間や資金を捻出する必要がある。（ここでの「能力」というのは、いわゆる「スキル」だけでなく「思考回路」も含む。新たな考え方も新たな能力ということである。）
　となると、既にあるタスクと開拓のためのタスクを合わせて管理して日々を設計することになる。これは頭の中だけでやるのはかなり難しいので、実際的なタスク管理の必要に迫られる。必要な行動は何で、それをいつまでにどのようにどの順番でやっていかなくてはならないのか、そういったことをどこかに書き出して検討して決めていく工程は必須だろう。

　まずいのちを養う。現状で頑張っても駄目そうなら新たな能力を養う。いのちが安泰なら精神を養う。現状でやっていっても幸福感が足らなそうなら新たな能力を養う。それを着実に実行していくために、自分の頭の中だけでは足りないようならタスク管理ということをする。
　いずれの意味でも養う必要がない、または養うにあたり改めて把握と管理をする必要に迫られていない、という状態ならタスク管理は多分要らない。

　タスク管理は、タスクの実行を最適化する手段であると同時に、それらのタスクを検討・実行している自分自身の姿が可視化されるという副産物をもたらすものである。
　タスクの選択や可視化された自己の解釈には、タスク管理そのものとは別の営為が必要であり、それが例えばミッション・ステートメントやTak.さんのライフ・アウトラインの「LIFE-BE」「LIFE-AS」といったものということになるだろう。どう実践していけば本当に自分に有用かというのはよくよく勉強と検討を重ねていく必要がある。
　ということを考えた。

　うちあわせCastのこの回を聴きました（結構前に聴いていました）。

• 第百六十回：Tak.さんと生活におけるプロジェクト管理について - うちあわせCast - LISTEN

　この中でCapacitiesでプロジェクトを扱うことについて語られていましたが、自分の感覚とかなり違う気がしたので、どこが違ってそれがどこから生まれる違いなのか考えてみたいと思います。（批判や正解探しということではなく単純に「何が異なっているのか」の分析を試みるということです。）

オブジェクトを全て「～についてのノート」と思っている

　倉下さんのお話の中で「プロジェクトについて書いたノートオブジェクトがある」という話がありました。ここにまず捉え方の違いがあるようです。
　Capacitiesのオブジェクトタイプは、TagやWeblink、PDFなどのベーシックなオブジェクトを除いて全て「Pageオブジェクトの派生」と解釈しているので、私の中で「○○オブジェクト」は「○○についてのPageオブジェクト」ということになります。
　ベーシックオブジェクトは、例えばPDFオブジェクトがPDFそのものを扱うもの、imageオブジェクトが画像そのものを扱うものであるように、オブジェクトが実物です。そこにノートを添えることもできる、という形です。しかしカスタムオブジェクトでは実物を扱うということは基本的にあり得ません。Bookオブジェクトはあくまで本についてのノートであって、Capacitiesの中に本そのものは存在しないわけです。
　プロジェクトももちろんそうです。本そのものや人物そのものがCapacitiesの中に収まっているわけではないように、プロジェクトそのものがCapacitiesの中に存在するということはあり得ません。常に「それについてのノート」の形になります。
　個人的にはそのように認識しているので、「ノート用のオブジェクト」というものは生まれず、Projectオブジェクトは「プロジェクトについてのノートというオブジェクト」ということになります。

プロジェクトを単に「ノートが必要な『やること』」と思っている

　プロジェクトという言葉をどう定義するかというのは、生活・仕事の前提によって大きく変わってしまうところだと思うのでなんとも言えませんが、私がCapacitiesでProjectオブジェクトを使う時というのは、単純に「ノート部分を必要としている『やること』」を扱う時と言えます。
　そして基本的には「完了できるもの」です。ただし断続的にやるものについても、場所を分けることにメリットがないという意味でProjectオブジェクトで扱っています。しかし「完了がないもの」の取り扱いは割合としてごく一部です。なお、例えば「本を読む」「掃除する」「語学を習得する」のような基本的な動詞で表される習慣的なもの、スキルアップを目指すものはProjectオブジェクトではなくDoingオブジェクトというものを作って扱っています（Capacitiesのマイオブジェクト⑥ セルフマネジメント系）。
　また、ルーティン以外のほぼ全ての「やること」が、Projectオブジェクトになっているか、またはいずれかのProjectオブジェクトの中に含まれる要素かになっています。よってデイリーノートのToDoリストにはProjectオブジェクトのリンクが並んでいるということになります。ToDoリストはアウトラインになっていますが、①リンクのノードそのものにチェックボックスがついているパターン、②リンクノードの子項目にチェックボックス付きの小タスクが並んでいるパターン、③リンクノードを子項目としたチェックボックス付き親項目があるパターンがあります。

　Capacitiesは現状全文検索が役に立たないという実用上の問題もあって^[1]、情報をオブジェクトから辿れるようにしておく必要を感じており、基本的に全ての「やること」がProjectオブジェクトのタイトル、本文、バックリンクのいずれかで把握できるようになっています。
　あるProjectオブジェクトが、他のProjectオブジェクトのサブタスクになっていることも偶にあります。プロジェクトは入れ子になり得るというのは前にも考えたことがありました（タスクとプロジェクトを考える）。ただ、今のところは「偶に」で、基本的にはフラットになっています。タスク群を一通り完了することで意味をなす、その「一通り」を粒度としてProjectオブジェクトのページを作っている形です。なのでページ本文の文量はプロジェクトごとにかなり幅があります。本文が一行で終わることもあれば、トグルを多用して長文を畳んだり規模の大きいアウトラインを作っていたりのこともあります。

サブジェクト基準でプロジェクトにしていない

　ここまで考えて思ったのは、多分ですが私はCapacitiesに於いてはサブジェクトをProjectオブジェクトとして扱ってはいないのだろうということです。（「サブジェクト」の理解に自信がありませんが、多分。）
　何をどうしていきたいか、ということはライフ・アウトラインの中に含まれるものと見なしています。実際にライフ・アウトラインの場に書いていることもあれば「本来あるべきはライフ・アウトラインの中なんだよな」と思いながらデイリーノートやフリーライティングの場に書いたきりになっていることもありますが、ともかく思いやテーマについては「最終的に存在すべき場所はライフ・アウトライン」ということを前提とし、そこから生まれた具体的な「やること」がProjectオブジェクトになります。何をもって完了とするのかが見えた時点でProjectオブジェクトとして形を持ちます。

　認識の個性の違いが明瞭になったかどうかはわかりませんが、そんな感じで私はCapacitiesのProjectオブジェクトでプロジェクト（と私が認識している塊）を扱っています。

---

1. その後だいたい解消しました。
   Capacitiesで日本語での全文検索が機能するようになりました（多分） ↩︎

理想のタスク管理ツールは何か、私も想像を膨らませてみました。

自分が欲しい要素をまず列挙してみます。

• マルチデバイス
• シンプルモードと全体俯瞰モードの（少なくとも）二つのビュー
• 各タスクには自由かつ簡単にメタデータを付けられる
• タスクの目的や経緯を記すメモ欄がある

マルチデバイス

まずマルチデバイスなものが良いです。スマートフォンアプリでどこでも見られて情報を更新でき、かつパソコンの広い画面で俯瞰できるのが重要です。

二つのビュー

表示はシンプルモードと全体俯瞰モードがあると良いです。タスクを実行する時とタスクを管理する時とでは必要な情報が全然違っているからです。
いつでも全体を確認できるようでないとなんとなく不安なので、スマホからでも全体を見られると良いです。ただしスマホから編集できる必要はなく、お店アプリでチラシを見るのと同じ感じで画像として見られれば良いと思います。
逆に常に全体が見えてしまうと今何をしたらいいのかに集中できないので、実際に行動している間はごくシンプルなビューがあると良いです。一週間分くらい縦に並んでいて明日以降の具合も見ながら動けると良いです。また、その日その日がどういう日なのかを書いておける欄も欲しいです。そこに他の関係者の状態や注意事項などの情報を書き込んでおきます。
イメージとしてはこんな感じです。

これそのままだと翌日以降も視界に入ってしまって今日に集中できないので、日と日の間は広く余白を取った方がいいかもしれません。

全体俯瞰ビューについては前に考えたことがあります。

• タスク管理の変遷語り
• Topic Manager

このツールは今は使っていないのですが（プログラミング能力の不足により）、このビューは今考え直してみてもおおよそのところはこれでいいような感じがします。
トピック（＝プロジェクト＋自分の願望）と具体的なToDoを「面」で一望できるのが重要です。

メタデータの入力

全体俯瞰ビューでいい感じにタスクが並ぶように、各タスクにはメタデータを色々付けられるようになっていて欲しいです。しかし複雑そうに見えないのが理想です。
入力欄の設計は難問です。メタデータが複雑になると入力欄も複雑になってしまいます。チェックボックスにしろリスト選択にしろ、ひとつひとつは簡単に選択できてもそれがいくつもあると嫌になってしまうでしょう。
タスク管理アプリが続いたためしがありませんが、それも入力欄の見た目の問題が少なからずあったように思います。しかしタイトルしか入力できないのではそれもそれで困るのです。わがままな話です。
今思うのは、もしかするとアウトライナーが良いのではないか、ということです。Dynalistの応用をあれこれ試みている今だから思うことですが、ノードのノート欄の書き方を決めておいてそれをプログラムがうまいことデータ化してくれれば良いような気がします。タグ欄、日付欄、メモ欄……とそれぞれ欄を設けると息が詰まってしまいますが、書いても書かなくてもいいノート欄がひとつあるだけなら息苦しくなりません。

メモ欄

タスクの目的や経緯を記すメモ欄も必要です。
ただし各タスクにそれらを書くのはうまくいかない感じがします。タスクは高速で流れて次々消費されていきますが、それと一緒にメモがどこかに行ってしまったら困ります。なので個々のタスクの下に位置するのはよろしくありません。（やり方の補足のようなメモならそれでもいいのですが。）
加えて、一つのメモから三つのタスクが生まれたり、二つのメモから一つのタスクが生まれたりということが普通にあり得ます。そうなると、メモとタスクは別に存在し、多対多のリンクがあると良い気がします。
ですがあまりかっちり親子関係・リンク関係を管理せず、柔軟に扱えたほうがいいだろうと思います。あくまで「メモ」です。タスクに埋もれて自分の頭が混乱しないようにするためのものであって、そんなにきちんとしている必要はありません。

今のところ思いつくのはこんな感じです。これを実際に実装するにはどうしたらいいか。もしかしたらDynalist APIを駆使すればいい線までいくかもしれません。
ちょっとだけ理想像から後退させて考えれば、普段のタスク管理はDynalistでやって、全体俯瞰ビューをDynalist APIで構築するようにするだけでも割と良い感じになりそうです。htmlを用意すればいいのでスマホ用アプリ開発までしなくてもスマホ・PC両用のツールは作れることになりますね。
書き始めた時点では全然実現可能性は考えていませんでしたが、こうしてみると「意外とやりようがあるかも？」という気になってきました。実際にその通りにやるとDynalist依存の高まりがちょっと不安要素になってしまいますが。

今月のテーマである「今日（こんにち/きょう）のタスク管理」について。自分のこんにちの形式に至るまでの経緯を振り返ってみたいと思います。フローの説明というより認識の変化の話になるのでちょっと長くなります。

　4ヶ月ほど前に、GTD的な「プロジェクト」の名称はどうあるべきかという話題から（それには答えが出ていない）、そもそもタスクといわゆるプロジェクトはどういう関係にあり、どう管理したら良さそうかということを考えた。

• タスクとプロジェクトを考える

　その後、自分なりにそれを体現したツールを作ってみた。例によって他の人が使えるように公開しているわけではないのだが、ツールの話を通してコンセプトを言葉にして書いておけたらと思う。

　さてツールの外観はこんな感じ。（例として書いてある項目は完全に適当に作ったものなので深く考えないでいただきたく。）

　各エリアの意味は以下の通り。なお全てのToDoが「コンテクストごとのToDoリスト」のいずれかに配置される。そこに無ければ無いですね、ということである。

　レイアウトは前に紹介した自作のタスク管理ツールと似ているが（ツール製作日誌：タスク＆スケジュール把握ツール）、プロジェクトの考え方などは大きく違っている。
　今回のツールは「Topic Manager」と名付けた通り、「トピック」をメインの単位としており、その下にまた「トピック」あるいは「ToDo」が属しているのが基本の形になっている。すなわちトピックとToDoの二種類のデータによって構成されているのだが、一方でトピックとToDoはプログラム上は同じ形のデータとして扱われており、ボタンひとつで切り替えることができる。今はこっちとして解釈する、という選択によって分けられているだけである。
　トピックには「企画」「日程」「目標」の三種類があり、それぞれ次のような意味合いを持たせている。

• 企画：実行して成し遂げる必要のある、いわゆるプロジェクト
• 日程：イベント・会合等の日にちをメモするもの（「締切日」は含まない）
• 目標：こうしたい、こうなりたいという類の個人的かつ気分的な思い

　日程トピックに締切日は含まないというのは、締切を扱えないということではなく、個々のToDoに設定することができるので日程として用意する必要がないという意味である。またToDoには締切とは別に目標日を設定することもできる。
　以上を踏まえて、画面上の文字色や背景色による意味付けを説明すると以下の通り。なお右上のスケジュール欄の項目はマウスオーバーで日にちを確認できるようにしてある。

　具体的にやるべきことを生み出す大本になっているのがトピックであり、ほとんどのToDoはいずれかのトピックに属し、また必要に応じてトピックの下にトピックが入れ子に作られる。トピックの粒度には決まりはなく、自分が思った大きさで自由に作る。形式的な整理のためにトピックを利用しても問題はない。
　親とするトピックはいつでも変更できるので、例えば「あ、こうしたいと私は思っているな」と思ったら目標トピックをとりあえず一番上の層（＝親トピック無し）にパッと作ってしまう。
　他方、親トピックが存在しないToDoを作ることもできる。プロジェクトも目標も特にない、例で言えば「Yシャツのボタンつけ」のようなToDoだ。それは左のトピックリストの中には表示されず、右のToDo欄の中では背景色が灰色であることによって視覚的に区別される。やる必要はあることだが、何かを構築するピースにはなっていないToDoと言えるだろう。

　ところでトピックやToDoというのは具体的にどういうデータを持つものとして扱われているのか。それを伝えるために編集画面を載せることにする。（スクリーンショット内で編集画面の外が暗くなっているのは、そういうオシャレなプログラムとかではなく単に後から加工しただけ。）
　まずトピック。上から順に、トピックの名前、目的の記入欄、親トピック/ToDo指定（複数可）、種類等の選択欄、下位トピック/ToDoの一覧と作成、メモ欄（アウトライナー）となっている。

　次にToDo。目的欄の下のあたりがトピックとは異なっている。各種の日付指定とコンテクストの選択ができる。

　なんだかごちゃごちゃと欄があるが、別に必ず全部を使わなければならないわけではないし、実際半分以上はタイトルと親トピック、コンテクストの指定のみで済ませており、目的やメモを細かく書いてはいない（ToDoの例のようなスカスカの場合が多々ある）。必要な時に書けるためにあるのであって、書かなければならない欄ではない。書きたい時には書く欄があるというのが重要である。
　ただしあまりに自明な場合を除いて、何のためにやるのかを1行でいいから言葉にして書いておいた方が、迷走を回避できるし動機づけの強化にもなるのは確かである。欄があれば書きたくなるので、メモ欄とは区別してわざわざ目的欄を設置し、なるべく書くようにと自分を仕向けている。
　目的欄の下の日にち指定やチェックボックス、ラジオボタンの類は、項目数は一見すると多いが、要するに一覧画面でどこに表示されたら嬉しいかということなので、見た目ほど複雑ではないし億劫でもない。一覧画面の各分類の右上の＋ボタンをクリックすればその欄が選択されている状態（コンテクストならコンテクスト欄にその項目が記入された状態）でToDoを作れるようにしてあるので、手間は感じていない。

　トピックとToDoの設定切り替えも自由にできるようになっている（前に作ったタスク管理ツールではそうできなかった）。一度ToDoとして色々設定したけどこれToDoじゃなくてトピックとして考えるべきだったわ、となったら右上のラジオボタンで切り替えればいいし、逆も同様にできる。切り替えても締切日等のデータは消えてしまわないようにしてあるので、元に戻すのにも不自由しない。
　左上、タイトル横の四角はチェックボックスで、チェックしてデータを保存するとアーカイブ送りになる。データは残るが、画面から表示は消えて見えなくなる。左下の削除ボタンも同様で、画面から消えるが一応データは残る。データベースになっているJSONの中に「アクティブ」「アーカイブ」「トラッシュ」の三つの箱がある状態である。

　ついでに自慢（？）すると、現時点で存在しているアクティブなトピックやToDoはうまいこと見出しをつけて加工し、mdファイルとしてLogseq用のフォルダ内に出力するようにしてあるので、（mdファイルを編集してもこのツールに反映されることはないが）他ツールとの間で横断的に情報を利用できるようになっている。
　アーカイブしたデータはTopic Manager内では表示されなくなるが、これも別途mdファイルに出力してあるので、これまでやり終えたToDoを確認するのは簡単だ。Topic Managerでは常に今とこれからに意識を向けられるようにし、なんとなくログを眺めるみたいなことにはならないようになっている。（なおconsole.logでデータベースの内容はコンソールに出力しているので、デベロッパーツール上でデータの確認自体はすぐできる。）

　このツールの一番の肝は、「目標トピック」という分類を作ったことにあるかもしれない。このツールには「やる必要のあること」だけでなく、「○○したいなあ」「～～な人間になりたいなあ」といった願望も書き込むことができる。背景色で視覚的に区別されているので、実際に遂行しなければならないものとの混在が気になることもない。（並び順も各階層で一番下になるようになっている。）
　トピックの下位にはToDoがあってもなくてもいい。つまり、トピックは「ToDoが発生しそうなトピック」でなくてよい。日程トピックについても、「とりあえず把握しておきたいけど実際には行かないかもしれない企画展」のスケジュールを書いておいてもいいのである。
　自分の行動を決定するために必要な内容がトピックとして並ぶのが大事なことで、「リストを空にしなきゃ」とか思う必要はない。むしろ、自分の願望を書いておく場でもあることから、空っぽになったら困るのである。トピックリストはタスクリストではないのでたくさん書いてあっていいのだ。
　感覚に従ってトピックを作っていくと、しばしば階層は複雑化する。そのせいでToDoが把握できなくなったら困るので、右側の欄でToDoはコンテクストのみに従ってフラットに並ぶようにしてある。こうすることで、自分の中の気持ちや問題意識に沿ってトピックが構造化されることがToDo管理の邪魔になってしまうことのないようにしている。今のところうまく働いている。

　あとは緊急・重要・要連絡・連絡待ちのToDoリストと、コンテクストごとのリストを「面」で一覧できるようにしているのも自分の中では重要なポイントだ。
　前に作ったタスク管理ツールについての記事（ツール製作日誌：タスク＆スケジュール把握ツール）内でも、自分に必要なのは「細かくなくていいから全体がわかる形」かつ「一枚の面に整然と配置された状態」だということを書いたが、それを達成しているかどうかが私にとってはタスク管理ツールの価値の有無に直結している。そして世の中のタスク管理ツールはいまいちそうなっていなくて、カンバンツールもちょっと違う。列にはなっているが面にはなっていないからだろう。

　私自身はこれを自作したことで色々と楽になっているが、しかしこのツールはプロジェクトの全体像や自分の内面を俯瞰することを大きな目的としているので、仕事に追われに追われている人を救うための一助になるとは言い難い。「捌く」「こなす」ことを助けられるようには恐らくなっていないのである。
　そもそも全体像なんか関係なく目の前に発生するものを次々片付けないといけないような仕事では、トピックを立てるということに意味がないかもしれない。しかし逆に、そういう仕事の助けになるタスク管理ツールなら既に巷に溢れているような気がする。
　そして既存のタスク管理ツールがいずれも役に立たないほど多忙ならば、おそらくそれは多忙の度合いが激しすぎるので「ツールに入力する」ということがもうネックになってしまうだろうし、そうなると如何なるツールも力不足になるのではないかと思う。強いて言えば、音声入力で項目をスイスイ作って操作できるタスク管理ツールが存在したら少しは助かるだろうか。つまりは秘書であろう。

　多忙過ぎる人を救う手立ては私にはわからないのだが、とりあえず、タスク管理ツールが抱えている「タスクそのもの以外の情報を扱いにくい」という欠点を自分なりに解消し、自分の中にある情報を実現可能性・実現必要性に関係なく書き出せるようになり、そしてそれが「遂行しなければならないこと（いわゆるタスク）」の邪魔にならないように視覚的・位置的に区別されていることで、ごちゃごちゃあるのにごちゃごちゃしていないという形を作ることはできた。
　作って使い始めてから一ヶ月以上経っているが、今のところは「ここがネックなんだよなあ」といったことは感じていない。唯一スマホから編集できないのが玉に瑕だが（内容の確認だけなら上述したようにmdファイルを通じて可能）、スマホアプリを作れれば解決するよな～ということを考え始めているので、将来的には解消させられる可能性はある。が、そもそもそんなに欲していないので別にスマホからの編集機能は要らないかもしれない。

　ただ気をつけるべきは、全てのToDoがきちんとログとして残ることを期待してしまうことだろう。
　Topic Managerに書かずに片付けてしまったことを後から書くのかどうか。アーカイブのチェックを入れるのが遅くなった時に、厳密にいつやったことなのか確かにしようとするのかどうか。
　そういうものを必ず正しく書くと決めてしまうと、恐らく「後で書かなきゃ」が溜まり始めてしんどくなって続かなくなる。「Topic Managerのログは別に完璧なものではないが、おおよそこんな感じであったということがわかれば十分だ」というスタンスを守ることが大事だろうと考えている。
　

昨日私が書いた記事と、その後倉下さんがお書きになった記事について、以下のように言及いただきました。
雨昇千晴さん: 「Evernoteさん、雑に使ってごめんなさい https://t.co/oq2FJyKapS 何の気なしのリストインとインボックス https://t.co/46NsDbo0vA 違う話のようで、根のところが似ている話のような。「我思う故に我あり」というのならば、「思う」＝思考することは、「我」を立ち上げる行為なのかもしれない。」 / Twitter
その通りだな！と私は思いました。

　前回（タスクとプロジェクトを考える）の最後で「どういうタスク管理ツールがあったら（私個人が）嬉しいだろうか、ということも考えていきたい」と書いた。今考えて設計しているところなのだが、その前に、この話題が出る以前に考えて作ったツールについてちょっと書いておきたい。

　例によって自分用のツールなので公開はしておらず、提供していないツールについてこまごま語るのもどうかといつも思っているのだが、私と同じように「自分で作ってみたい人」の役にはいくらか立つだろうかとも思うので、（ここは私が好きに書いていい場所なのだし）細かく書いていこうと思う。
　全体像としてはこんな感じ。実際に使っているところなので全面モザイクにせざるを得ず、イメージが湧きづらくなってしまったかもしれないがご容赦いただきたい。（加えて、ちょっと間違えて異様に劣化した状態になってしまった…）

　左のDetail欄で「タスク」「日程」「プロジェクト」の三種類の項目を作成することができる。それぞれを作ると右のビューが構築されていく。そして右のビューに表示されたアイテムをクリックすれば内容が左のDetail欄に表示され、編集することができる。
　なお、右のビューの上段はスケジュール欄として「日程」の項目が並び、中段・下段には「タスク」が並ぶが、中段と下段は同じ内容がそれぞれ別の基準で各リストに振り分けられている状態である。プロジェクト単位で見たければ中段を、現在の取り組みの状態を俯瞰したければ下段を見ればいいということになる。

　Detail欄は項目の種類によって少し違っているので、ひとつひとつ触れていこうと思う。まずはタスク項目。

　開始日・終了日の記録というのはタスク管理の中で普通にやることだと思うが、バシッと正確に書けないこともあって（几帳面でないため）、一般的なタスク管理ツールだとちょっと記録にもやもやすることがある。そのストレスを和らげるため、日付専用のメモ欄を設けてその日付はどういうつもりで書かれたものなのかを記録できるようにしている。
　結局のところ、書き込む時に不正確さにもやもやするだけで、日が経ってしまえば厳密に何月何日のことかはどうでもよくなってくるのだが、少しでも書き込みやすくするためにズボラ仕様にしているわけである。

　次に日程項目。

　日程（＝特定の日付についての備忘録）というのは、実のところ様々な意味合いがあるため、区分が一種類や二種類では少し困る。と言ってあまりに細かく仕分けしても、その労力の割に意味をなさない。私にとってはこのくらいの分類が必要かつ十分かなというところだ。
　なお、ひとつのことに対して、「開催日はこの日」「関係することの締切はこの日」「そのための目標はこの日以前の完了」といったことをそれぞれ別項目として書いておくことも当然可能で、ステータスによって色分けされるのでごちゃごちゃあってもそんなに混乱しないで使えている。
　繰り返し機能はまだ作っていないが、作ろうと思えば作れるし、そのうち作るつもりでいる。

　最後にプロジェクト項目。

　実装が面倒くさいから入力欄を増やしたくないという理由で全部の種類の編集を同じ場所で兼ねているのだが、案外悪くないという感じがしている。なおプロジェクト項目にはプロジェクト選択が要らないので非表示になる。

　ちなみに、一度生成した項目を編集する時には、項目の種類が変わってしまうと困るので項目選択ができないようになっている。（↓表示が薄くなっている部分。）

　これを作る前までは実装を考えたことがない挙動だったが、自分が余計なことをしないために先に回って自分の行動を封じるというのもツールを作る上では重要と感じる。他にもいくつか「ユーザーとしては当たり前の挙動だが、作る側としては目立たない要素なのであまり着目しないこと」という感じのものを実装して、少しばかりコーディング能力のレベルアップを感じている。

　なお、このツールは今のところ特定のパソコンからしか使えない（データの保存にブラウザのlocalStorageを使っているため）。しかしタスクをパソコンの前以外で確認できないのは困る。ということで、手動の原始的な方法だが、スクリーンショットを撮ってScrapboxに貼っておくことでスマホでも見られるようにすることを思いついた。せめてスクリーンショットを貼りつけるページはクリックひとつで用意できるように、と思って上部にボタンを作ってある。
　テキスト情報で出力してもいいのだが、見た目が変わると逆によくわからなくなるので、画像としてそのままの見た目で保存した方が良いと考えた。適宜出力しておけばログにもなるし、テキストではなく絵的に残しておけば、後から見ても意味を解釈し直す必要があまりないのでわかりやすいだろうと思う。
（検索、OPMLダウンロード、Markdownダウンロードのボタンが右上にあるが、これらは「実装しようと思えばできるが面倒なのでとりあえずまあいいか」という感じの未実装要素。）

　タスク管理ツールは世の中に数多存在しているし、アウトライナーなどでもタスク管理はできるし、それなのにどうしてわざわざ自分でツールを作ったのか。
　一言で言うと「どれも自分に合わないから」なのだが、それならば何がどうなっていれば自分に合うのかというのを見出すのは容易でない。抱えているタスク自体、どういう規模でどういう粒度でどういう頻度でどういう種類のものになるか人それぞれだし、更に物事を頭の中でどう認識してどう把握してどう処理しているのかも人それぞれである。ある程度はパターン化される、ということさえも言ってしまえるものかどうか怪しいところだ。仕事の種類だけならばいくらかパターン化できても、そこに個人の特性を加えると急激に傾向の分類は困難になる気がしている。
　ということで、自分は何を求めているのかを自分で知るためにも、自分にとってスムーズな使用感のツールを作るということに取り組もうと考えた。少しずつコーディング能力が上がってきて再現できる挙動が増えた分、「面白そうなことを思いついたから試したい」という娯楽感覚も動機づけとしては大きいが、前々からいずれは「思い通りにタスクを管理するツールの形」を見出したいと思っていた。

　そうして作ってみて、今自分に必要なのは「細かくなくていいから全体がわかる形」かつ「一枚の面に整然と配置された状態」だということがわかった。
　縦に並べていくだけだと、的確に構造を作れていたとしてもなんとなく「把握できていない」という不安を覚えてどうも駄目らしい（大丈夫な人は普通に大丈夫だと思うのだが）。また、例えばマインドマップや付箋ツールのように自由に配置できる形式、あるいは一枚の紙のあちこちに書いていくという形式は、書き込むには良いが結局何がどの程度あるのかよくわからず、それも結局「把握できていない」ということになってしまう。つまり、リニアではなく、しかし秩序はある状態というのを欲しているようだ。
　その結果、目的の異なる三種類の表を上段・中段・下段と配置する形に至った。今のところは納得しているし、現在のライフスタイルではこの配置が最適なのではと思っているのだが、処理しなければならないタスクの質が変わってしまえば使いにくくなるだろうとも推測している。「面」で認識したいという自分の性質は不変でも、対象が変わると形式は変わらざるを得ない。
　そういったシステムの柔軟性という意味でも、紙のノートやExcelなど汎用性の高いものを工夫することによって満足できたらよかったのだが、どうも「ぴったりハマっている専用ツール」でないと続かない。なんとなく見たくなくなって、「なんか別のやり方でやりたい」などという気持ちを生じて情報がばらばらになっていく。微妙な我慢に対して飽きるということなのだろうか。ともかく、そうなると自分で自分に発注してオーダーメイドのツールを作るしかないようである。
　そういう変に神経質な人間なのに、プログラミングを全くわからなかった状態では「与えられたツールの使い方の工夫」という形でしか努力できず、したがって常に「なんか違う」という不満に悩まされていた。しかしプログラミング（JavaScript）を覚えたことでダイレクトに「自分のためのツール」を作れるようになり、初めてサイズの合った服を着れるようになったような気持ちでいる。作るのは大変だが、それでしか自分を助けられないとなれば頑張れる。

　ここまでが前回の記事（タスクとプロジェクトを考える）以前のタスク管理観で考え出したことだが、前回の思索を通して、もう少し違う形のツールを作ってみたいと思い始めたところである。
　今回のツールは「プロジェクト」の扱いが緩く、単に大まかな分類として使われている面がある。タスクの質が変わった時に最も影響が出る箇所がおそらくその点で、現状では処理が簡単な分伸縮性がない形になってしまっている。その部分を解消した形式をこれから模索していきたいと思う。
　

　Twitterの知的好奇心向上委員会コミュニティ内で@rashita2さんが「gtd的な『プロジェクト』を別の名前で呼ぶことにしませんか」という提案をされていた。（コミュニティはオープンであるものの仕様上ツイート埋め込みができないのでリンク先をご参照ください）
　個人的にこの「プロジェクト」なる語に不明瞭さを感じていたこともあり、タスクとプロジェクトについて、語のイメージとそれらに関わって存在する要素を考えながら自分なりに整理を試みたい。

　

　倉下忠憲さんがお書きになっているように、GTDなどで言うような個人のタスク管理上の「プロジェクト」と、一般的に「プロジェクト管理」と言う時のマネジメントの文脈で使われる「プロジェクト」とでは、同じ言葉でも指している層が異なるように感じる。
　もちろん、会社で動いている「プロジェクト」に、その当事者としての自分のタスクの「プロジェクト」が強く紐付いているならば、そこに区別をつける動機が薄くなっていく可能性はある。ただ、個人のタスク管理は100%会社の仕事の話ではないことを前提とするならば、そこに層の違いがあることは考えておく必要がありそうである。その境界が薄い人（薄くて構わない人）と、はっきり境界を感じる人はそれぞれいるだろう。

　さて、ここでは個人的なタスク管理に関して考えたいのでマネジメントとしてのプロジェクト管理の話はもう仕舞いとして、GTD的な意味での「プロジェクト」について考えていきたい。
　GTDそのものについては語れるほど詳しくないので、認識に間違いがあるかもしれないが、とりあえず現時点の認識を元に考えられることを考えてみたいと思う（無責任で心苦しいが個人のブログということで許されたし）。
　GTDで登場する「プロジェクト」は、「2つ以上のステップを必要とするもの」を指しているが（多分）、その実際的意味としては、自分の頭の中から「（近いうちに）やること」を取り出した時に、しかしすぐ着手できない（粒度が大きい、時間がかかる、具体性が足りないなど）状態にあるものを扱うものだ、とひとまず認識している。GTDのその工程については、コンセプトを踏まえて納得しており、GTDに対して何か物申したいことは今のところ何もないのだが、私の中で起きていることとして、この「プロジェクト」というワードの印象と、それがGTDの中で担っている役割がいまいちマッチしていないという問題がある。
　そもそも「プロジェクト」という単語は随分曖昧に思える。国家プロジェクトも、企業でマネジメントするプロジェクトも、GTDのプロジェクトも、更にはScrapboxのプロジェクトも、全部「プロジェクト」だ。辞書を引くと特に動詞の多さにこれまた混乱してくるのだが、とりあえずカタカナ語で「プロジェクト」と表記した時に何を示しているかと考えると、一言でいえば「ある目的を達成するために臨時で計画・構成される組織及び業務」といったところだろうか（参考：ASCII.jpデジタル用語辞典）。
　後で必要になるので要素を分解しておくと、「ある目的がある」「目的は達成される類のものである」「具体的な業務が計画・構成されている」という三点が「プロジェクト」という語に伴っていそうである。敢えて「目的は達成される類のものである」としたのは、「達成されたら終わり」という意味に加えて、例えば「私は犬になりたい」と思っても「犬になる」というプロジェクトは成立しない、つまり「夢」がそのままプロジェクトにはならないということを一応含めておこうと思ったからである（一方で「ここまでやったら実質犬になったとみなす」という条件を作ってしまえばプロジェクトとして成り立つ）。

　GTDの話に戻ると、頭の中を漂っているものを外に出していった時に、「やること」のうち「1ステップで済むこと」は管理が単純なのでそれ単体で扱われてフローの中を動いていき（実行に際してはプロジェクトとは別種のリストが適宜作られる可能性はある）、「2つ以上のステップを必要とすること」はまとめて「プロジェクト」ということになるわけである。
　これは直感的に見れば自然な仕分けに思える。「後はやるだけのもの」と「手順などを色々考える必要があるもの」は同じようには扱えないし、そこに線が引かれるのは体感としては納得感がある。自分が次にやらなければならないこと、考えなければならないことが両者で違うからだ。GTDというメソッドの目的からしても、「次の行動」が違うものを分別して整理していくのは極めて妥当である。
　しかし、「1ステップ」は「プロジェクト」ではなく、「2ステップ以上」は「プロジェクト」というのは、なんだか呼称に飛躍を感じる。実務上、そこで線を引くのが妥当なのはわかるが、「プロジェクトか、そうでないか」がそれで決まるのは（たとえ呼び方の問題に過ぎないとしても）首肯しがたいところがある。
　最近では、ある基準でまとめたタスク群などを「プロジェクト」と呼んで扱うパターンをよく見る気がするし、「2ステップ以上のやることの一連」を指す語として便利で定着しているようであるが、「プロジェクト」という語の語感を踏まえながら少し考え直したい。

　前の段落で、「プロジェクト」の語が伴う要素として「ある目的がある」「目的は達成される類のものである」「具体的な業務が計画・構成されている」という三点を整理した。（これは絶対的なものではなく、あくまで私の中のイメージの言語化である。）
　事の規模の大小を無視すれば、これはあらゆる「タスク」が伴っている要素でもある。何かをやる必要があるという時、それは何か目的があるからであり、やればその目的の一部あるいは全てが達成されるもので、「やる」ということはつまり具体的な業務を実行することを意味している。「タスク」が特に「具体的な業務」の部分を指すならば、「タスク」と、そこにくっついている前提とを合わせたものが、「プロジェクト（という語の語感が引き連れている要素）」ということになる。なお、ここでの「目的」あるいは「前提」というのは、タスクにまつわる「経緯」や「文脈」と言い換えても良いだろうと思う。
　ところで、以前からTak.さんや倉下忠憲さんは「一般的なタスク管理ツールではタスクに関する経緯などを（それこそが本当は大事であるにもかかわらず）書き添えにくい」という趣旨のことをお話しになっている（理解が間違っていたらすみません）。
　その通りだ、と私は深く頷いて拝聴していたのだが、今考えると、この問題は「タスク」が伴う「プロジェクト」的要素（目的があって、それは達成し得る種のもので、具体的な業務がある）の一部しか扱われないことによって発生しているのだと解釈することができそうである。
　また、「プロジェクト」的要素を単純に整理して「目的+具体的業務」という構成であると捉えるならば、具体的業務である「タスク」を主とみなし、その従の要素として経緯（目的を含む）を書こうとするというのは、あまりうまい構成にならないかもしれないという想像が生まれてくる。つまり、タスク管理ツールで個々のタスクに経緯のメモ欄を作れば良いという話にはならなそうな気がしてくるのである。何しろ、一連の経緯から複数のタスクが生じるというのはごく当たり前のことに思える。となれば、個々のタスクの下に経緯をメモするのはどうもうまくなさそうである。

　少し脱線するが、タスク管理ツールには「タスク」の下に「サブタスク」を設定できるものが多々ある。この機能は便利だと思いつつ私自身はどうにもうまく使えないのだが、その理由として、あるタスクの中のサブタスクが、それとは関係のない他のタスクより必ず粒度が小さいとは限らない、というところにあるかもしれない。
　関係のないタスクなのだから粒度が揃っている必要はないのだが、軽いタスクが「タスク」として存在しているのに、あるタスクのサブタスクがそれより多少重くとも「サブタスク」として存在する、ということにどうにも馴染めないでいた。おそらく一覧性の問題よりも粒度の問題が気になっていたのだ。これはツールの性質の問題というより、私自身が「タスク」として認識する粒度がツールに対して適切でないことが原因の可能性が高い。

　ここまで考えたことから、現時点のタスクとプロジェクトのイメージを図示するとこんな感じである。ﾄﾃﾓﾀﾞｻｲ感じで悲しいがご勘弁ください。

　「プロジェクト（仮）」は「目的（＝実現されてほしいイメージ）+具体的な一つ以上のタスク」によって構成されている。タスクが一つしかなくとも「プロジェクト（仮）」は構成されることになる。
　ところで、そもそもマネジメント上の「プロジェクト」とGTD的な「プロジェクト」が同じ「プロジェクト」という語で語られるのは望ましくないという話が前提にあるわけで、ここで更に新たな用法を「プロジェクト」に負わせるのはよろしくない。といって今ここで私が特定の語を提案したいわけでもないし、いまいち思いつかないので、「プロジェクト（仮）」ということにしておく。

　ちなみに、何かを実現したいというイメージがある時に、それを「目的」欄に置いた「プロジェクト（仮）」を作ったとする。その場合、そのイメージが高次のもの（極端な例を挙げれば「世界を平和にする」「宇宙に行く」など）だと、目的達成のためのタスクとして思い浮かぶものもまた高次なものとなるだろう（例えば「平和を訴えるデモを成功させる」「宇宙飛行士試験の勉強をする」）。そうすると、そのタスクを「実現したいイメージ」として「目的」欄に置いた「プロジェクト（仮）」が一段階低次の層に作られるのが自然に思われる。そうやってブレイクダウンしていってこれ以上低次にならないというところにあるのが、個人が日常で扱う「プロジェクト（仮）」ということになるのではないか。（要するにアウトライナーなどでどんどん具体化・細分化していった一番末端部分、ということである。）
　つまり、よく「人生の目標」とか「本当にやりたいこと」といったような名称で考えるものは「プロジェクト（仮）」の高次のものであると言い換えられる。国家プロジェクトも企業のプロジェクトもそうだ。ゆえに、ある段階以上の高次のものを「○○プロジェクト」、最も低次で実際に個人が日々取り組むものを「△△プロジェクト」、というような形で呼び分けられれば「あれもこれも『プロジェクト』じゃ困る問題」は解決するように思われるが、おそらくその企みが市民権を得ることはないので、何か別の名付けがどうしても必要になりそうである。ちなみに個人的なことだけでも高次から低次まで幅広くあるので、「個人プロジェクト」と呼ぶのは解決にはならなそうだ。
　じゃあ名付けとして何が良いかということを提案できないと冒頭の倉下さんの問いかけに答えたことにならないのだが、問いかけを見た時点で私は「『タスクグループ』『タスク塊（かい）』的な感じでしょうか」と反応したものの、自分なりのモデルを組み直して考えてみるとなんだか微妙な感じがしてくる。シンプルに「連なったタスク群」を指すのか、その連なりを成り立たせている背景もを含めて考えるのかで、妥当な名称は変わってしまう気がする。GTDに準拠して考えてもなお微妙である。

　ここまで何を語ってきたのかということを整理すると、まず問題意識として、

• 業務のマネジメント上の「プロジェクト」と個人のGTD的「プロジェクト」は呼び分けたい
• 「1ステップはプロジェクトでない」、「2ステップ以上はプロジェクトである」という呼び分け方は飛躍を感じる
• タスクにまつわる前提（経緯、目的、意図、文脈…）はタスクに伴って管理された方が良い
• 「プロジェクト」は多重の入れ子状になっているために、「プロジェクト」という語感によって一意的に特定の範囲を指し示しにくい

ということがあり、それを踏まえて以下のようなモデルを考えた（高次・低次の話を反映）。

　モデルの意味するところは、

• 全ての「タスク」がいずれかの「プロジェクト（仮）」の中にある
• 全ての「タスク」に前提（経緯、目的、意図、文脈…）が存在する
• 「プロジェクト（仮）」が持つ「タスク」がただ一つであることも普通にあり得る（「タスク」がただ一つでも常に「プロジェクト（仮）」は存在する）
• 「プロジェクト（仮）」は入れ子になる場合がある

ということである。

　更にもう一歩進んで、どういうタスク管理ツールがあったら（私個人が）嬉しいだろうか、ということも考えていきたいが、それは次回以降ということにする。
　

　先日、Notionから学んだこととしてデータベースの五形態について書きました。

• Notionから学んだこと――情報管理の五形態

　更に、ここに「まだ変わる可能性がある」のか、「もう変わることはない」のか、という区別をしていますというのが今回の内容です（複雑になるので今回はデータベースの形態と絡めた話はしません）。

　なぜその区別をしなくてはならなかったかというと、書き込むツールとして適切なものが変わってしまうからです。そして以前まではそこの区別が曖昧で、だいたい内容の種類だけでツールを決めようとしたので「なんかしっくりこない」ということを繰り返すことになりました。
　例えばスケジュールにしても、「もう決まっている日程」と「まだ変わるかもしれないorまだ決まってない日程」とは書き方が変わりますよね。アナログだと、決まったことはペンでびしっと書けますが、まだ決まってないとか仮押さえでしかないとかいうときはシャーペンやフリクションボール、あるいは付箋を使ったりすることになります。更に「このあたりでこれをやっておきたいなー」みたいな自分の中での計画は、他の動かないスケジュールに混ぜると全体の視認性が悪くなってしまいます。
　ToDoも、完了するまでは「工程や日程が変わる可能性がある」情報として柔軟性のあるツールなどで管理しますが、完了すれば過去のことになるので「もう変わらない」情報として日誌に記録したりすることになります。タスク管理アプリなどでは済んだToDoをそのまま情報としてアーカイブして必要な時に探すこともできますが、そういう考え方が向かない人や、他の人にログを見せなければならない人は別途記録としてまとめ直すことになりますよね。
　単純な話、書き直せないツールでは「まだ変わる可能性がある情報」は処理しにくいですし、逆に簡単に書き直せてしまうツールで「もう変わることがない情報」をストックするのは人によってはしっくりこないということにもなります。これからのことと済んだことが混在するのも望ましくありません。

　具体的に「まだ変わる可能性がある情報」とは何かと言うと、ToDo、未定の日程、ふとした考え、アイデア、といったものです。
　一方で、「もう変わることがない情報」は、やり終えたこと、決定した日程、見聞きしたもの、学んだ教養、などです。
　更に、「更新する可能性がある情報」もあります。これは「対象は決まっている」が、「内容は変わる・増える」かもしれない情報です。つまり二種類が一体になっている形態のもの。調べ物やマニュアル、読書メモ、何かへの感想、分析や考察、などがそういった形です。考え事やアイデアも内容によってはこちら。
　ツールを適切に選択するために、私は情報をこれら2+1種類に分けて捉えることにしました。

　それではそれらをどう使い分けていけばよいでしょう。場所自体を変えたり、ひとつの場所の中で工夫したり、色々と区別の仕方があると思われます。例えば、

方法①　デジタルとアナログ併用
　変わらない→ノートや手帳
　変わりうる→アプリやwebツール

方法②　ノートの使い分け
　変わらない→綴じてあるノート
　変わりうる→メモ紙・ルーズリーフ

方法③　バレットジャーナル式
　変わらない→マンスリーページやFutureLog
　変わりうる→デイリー部分の箇条書き

方法④　付箋の活用
　変わらない→ノートや手帳の紙面に直接記入
　変わりうる→付箋に記入して貼付

方法⑤　webツールの使い分け（一例）
　変わらない→Evernote
　変わりうる→Scrapbox、Dynalist

　といった形。私はこれらの組み合わせと応用で情報を管理しています。
　具体的にどうしているかというのは、やっている分には手間でもなく自然なのですが列挙すると膨大な数で複雑な仕組みであるかのように見えてしまうので、一部だけ触れようと思います。

ToDo

　ToDoについては、やり終える前が「変わる可能性がある情報」、やり終えた後が「もう変わることがない情報」となります。
　タスク管理アプリを色々試しましたが、個人的に紙に書いたほうが良かったのでアナログ管理です。管理の流れはGTDというタスク管理法を元にしています。
　B7サイズのメモ用紙を使っていますが、使い方は複数あります。
　①洗い出し
　②今週やること
　③今日やること
　④○○なときにやること
　まず①の洗い出しは、GTDで言うところのinboxの役割です。いつやるかは置いておいてとにかく「あ、あれやらなきゃ」「これいつかやっとこ」と思ったものを書き出していきます。そして定期的にそれを②以下に振り分けます。
　②の今週やることリストは、メモ用紙に一週間の日付を振ったり枠を作ったりして（形式は気分により）、必ずこの日にやらなきゃいけないということを書いています。最初は手帳に書いていましたが、手帳でタスク管理をするということ自体が合わなかったのでメモ用紙に変えました。
　③の今日やることリストは、①②を踏まえてその日やることをメモ用紙に列挙していくものです。複雑な工程があるものは紙を分けて細かく書き出します。
　④の**○○なときにやることリストは、例えば「5分でやれること」「連絡が来たらやること」「外でもできること」「帰ったら家でやること」「ホームセンターで買うもの」みたいな、場所や時間などの状況ごとに作るリストです。
　②～④に振り分けられない、いつでもいいようなToDoは「いつかやる／いずれやる」というリストをノートに作って溜めておきます。
　そしてやり終えたことは日誌用の大学ノートに1行1件で書き込みます**。バレットジャーナルで言うKeyのような記号を自分で設定し、またキーワードをマーカーや色鉛筆で強調して、どんな種類の記述かひと目でわかるようにしています。時刻や時間帯も記録します。ちなみにこのノートには、完了タスク以外にも食事の記録や目に留まったことなど生活における「もう変わることがない情報」を書き込んでいるので、どんな日だったかひと目でわかるようになっています。
　更に、「いつやったか」を後から知る必要があるものはマンスリーカレンダーに書いておきます。連絡のログや、定期的な実行や交換が必要なものなど。
　用が済んだメモ用紙は一応全部取っておいていますが、見返す必要に迫られたことはないので、そのうちそのまま処分すると思います。マニュアル化すべきものは分けて別のノートに書き写したり貼りつけたりします。

スケジュール

　ウィークリーの欄までは要らないタイプの生活をしているので、大学ノートに月間ページを自作しています。適当に架空の予定で作った例がこちら。

　自分の今後の行動を左右する予定・日程類は全部ここに書いています。まだ決まっていないことは付箋に書いて貼っておきます。
　ToDoの項で書いた通り、毎週「今週やることリスト」を作るので、この日程表では予定が時系列順に並んでいなくても支障ありません（私の生活スタイルでは）。
　そしてここには「やったこと」の類は書きません。これとは別に、上記で触れたマンスリーカレンダーのページを作り、ログの類はそちらに書きます。

読書メモ

　読書まわりは、読了リストが「もう変わらない情報」、読んだ感想や関連する情報のメモが「変わる可能性がある情報（更新する情報）」です。
　読了リストはルーズリーフに書いています。前は読了日に出版社に出版年にと書けるものを全部書こうとしていましたが、ぶっちゃけそんな情報はここには要らなくてただただ面倒くさくなってしまったことが何度もあったので、シンプルに著者と書名だけを並べています。何年のリストかは上部の日付欄に書いています。
　読書メモはA5サイズの無地のノート（場合によってはA4紙を折って真ん中をノート状にホチキスで留めたもの）に書いています。出版社などの細かい内容はこちらに書きます（読書メモを作る時はやる気があるので）。読書メモの内容については昨日投稿した通りです。そして自由に書きたいときに罫線があるのが苦手なので徹底して無地です。基本は見開きを単位として、余白はあまり意識的には取りませんが、途中で記述が終わって紙面が余っても同じページに複数の本の読書メモは取ることはしません。
　「更新する可能性がある情報」の類はだいたいどれもこの形式で、リスト＋ページ/見開き単位の紙面、という形です。PCを用いた作業が関連することはScrapboxかDynalistに書いて管理しています。特にScrapboxはリンク集を作れば簡単にリスト＋それぞれの内容ごとの紙面という形になります。

　私の例については以上ですが、このようにして**「変わる」「変わらない」「更新する」を意識し始めて、書く場所や使うツールに迷うことが減りました**。データとしての情報の扱いはよくわかっていなかったので、それについては冒頭でも触れたようにNotionを通して解決しました。
　使うツールに根拠と必然性がある形になったので、後からもやもやしてくるということがなくなりそうです！

（※この記事は一度noteに投稿したものの下書きに戻したものです。）