準備を進める月曜日

7:00

おはようございます。本日はもろもろの準備と、昨日やっていたTextbox周りの作業を続けましょう。

Textbox:

昨日、一行日記をカレンダーに表示することを検討していましたが、そもそも日記をカレンダーないで書いてはどうか、ということを以前考えていたのでした。

そこらへんから抜本的に考え直す必要がありそう。

publish:CT連載01:さあ、タスクリストをつくろう / 「つくる」ことと生成AI / ジオマッピング法の開発 / ノウハウ本のかたり方|倉下忠憲

* * *

「履歴」をどう扱うか。たとえば、現状のboardでは、メルマガの項目はない。プロジェクトといっても、定形のものを扱うだけだから。そして、終わりがないから。

終わりがないものをプロジェクトノートとしてしまうと、永遠に記述が続いていく。

とは言え、2024年メルマガ運営、というプロジェクトにするならば有限にはなる。時限式。

仮にそういう方式にするとしたら、どうなる?

* * *

一週間のメルマガ作業は定形で、書く内容だけが異なっている。で、毎日一応進捗が出てくる。

仮にプロジェクト用のブロックがあれば、その欄が毎日更新されることになる。逆にそういう欄を設けずにメルマガの進捗を扱うならば総合的な欄が必要だろう。昨日何をやったのかが随時トラッキングされていく場所。done-line。

そういう場所に、雑多な作業ログが残されていくイメージ。これはこれで悪くない。

メルマガの用な定常的なプロジェクトに枠を設けてしまうと、数がいっぱいになってしまう可能性がある。でも、それも合わせて意識するといいのかもしれない。

たとえば、タスクが記載されていても、そのファイルのtypeがdone-projectや待機プロジェクトであれば表示しない、という切り分けはできるだろう。そのような操作で、目下管理したいものだけを表示させるというやり方はできる。

* * *

とりあえず、WRMにタスクを設定してみた。

Image from Gyazo

これだけみれば悪くない感じ。問題はこれがずっと続いていく、ということ。来週も同じようなタスクが生産される。

そのとき「ログ」はどうなっていくか。区別の付かない似たタスクが増えていく。

タスクの名前を、WRM734+ファイル準備、とかにすれば区別はつく。しかし、入力が面倒だし、デイリーのタスクリストとの整合性も取れない。タスク名が同じであれば、こちらで終了済みにしたものを自動的にdoneにする、といったことも可能なので、タスク名を揃えておくと嬉しいことは多そう。

では、タスク名を同じにして、一週間に一度タスクをリセットするのはどうか。つまり、チェック済みのタスクをチェックなしに戻す。手作業では面倒だが、スクリプトを使うことはできるだろう。範囲をして、正規表現で置換すればいいだけ。不可能ではない。

* * *

で、この画面の下の方に以前使っていたタスク管理機能がある。

Image from Gyazo

こちらはメルマガなどの作業を毎週追いかけるもの。週ごとのタスクの記録が残しやすい形になっている。定常プロジェクトと通常プロジェクトの扱いは違いがあった方がいい?

それか、プロジェクトでは指針だけ「WRM734の更新」や「第一章の執筆」などを掲げておいて、具体的なタスクについては、下で管理する?

* * *

WRMもそうだが、ブックカタリスト系のタスクも扱いが難しい。収録は二週間に一回で、しかもどちらがメインスピーカーかによって必要なタスクが変わってくる。たまにゲスト回もある。

自分の脳内には、それぞれの状況に合わせたタスク・スキーマというのがあるが、それをアルゴリズムで表現しきるのは難しい。

あとで読む:GitHub - dvanoni/notero: A Zotero plugin for syncing items and notes into Notion

あとで読む:Google検索を殺した男――Googleはいつ、どこでメタクソ化に舵を切ったのか | p2ptk[.]org

* * *

あと、ブックカタリストのイベントがあるが、その準備はどうか。一つのプロジェクトとして扱うのは、やや大きめのタスクとして扱うのか。

9:00

論文読み:

https://www.nii.ac.jp/TechReports/public_html/02-001J.pdf

を読みます。

あとで読む:創造性の研究領域|日本創造学会

Textbox:

プロジェクト管理の続き。

表示されるタスクは、すべてのページに含まれるタスクという形にしていましたが、type: projectを持っているページだけに限定するとしましょう。

* * *

その上で「ブックカタリストのセミナー準備」のようなそこまで大きくなく、一回きりのタスク・プロジェクトなもの(ミディアム)をどう扱うか。

逆に、今そのミディアムなものはどういう状態にあるのか。とりあえずもう少し後で着手する必要があるので、軽めに覚えておくだけでいい? それともファイルの作成含めて着手し始める?

そこを踏まえないと適切な管理はできない。

* * *

ブックカタリストのイベントの場合、ブックカタリストというプロジェクトに紐付けておくことはできる。しかし、単発の寄稿記事などはどうか。それもなにか大きなセクションを割り当てて管理するのがよいか。

11:00

メルマガ:

とりあえず、もろもろの準備作業を進めましょう。

* * *

ファイルを準備し、三つほど書くことを決めておきました。

12:00

一日一英文:

Take some aspirin. It will cure you of your headache in no time.

環読プロジェクト:

第一章の続きを読みます。

* * *

OKです。

13:00

ニュースレター:

書きます。

* * *

デジタルノート研究会の記事を一つ予約しておきました。メンバー限定記事です。

火曜日は本連載の方がある予定ですが、まあ細かいことは気にしないでおきましょう。

17:00

KW:

本日のエッセイを書きましょう。

* * *

書けました。