の作業記録
原稿を書く金曜日
- 作業記録の共有
- タスクについて
- メルマガ+原稿3(2300文字)
- メルマガ+原稿4
- ブックカタリスト+087アフター用記事
- 新刊チェック→書店
- Kindleセールスタート
- KW+ミニエッセイ
- 環読プロジェクト+第四章
- 『群論への第一歩』+第八章
7:00
おはようございます。本日は引き続き、タスク・プロジェクトの管理を検討します。でもって原稿です。
タスクについて:
JSONでリストを扱うとして、次なる問題はそのJSONファイルをどう切り分けるか。
現状の選択肢として、history.jsonかdo.jsonか、あるいは新しいファイルを作るかの三択。
現状のプロジェクト・タスクは、do.jsonに置いてあるので、そのままそこに置くのが自然な流れではある。
実行済みとそうでないものを、stateで管理して、表示の切り替えもそのpropertyを使っている。よって、「やること」というコンテキストでデータが統一され、実行済みという過去と、未実行という未来が一つのファイルの中で切り分けられている。
では、これをhistory.jsonに入れるとどうなるか。すでに名前エラーがおきつつある。なにせヒストリーは明らかに過去に属しているわけで、「これからやること」は未来方向舵から。ただ、これを「〜〜をプロジェクトだと認定した」というログだと捉えるならば、一応整合性はとれる。
で、その場合、「執筆プロジェクトリスト」のようなものを作ったら、基本的にそれを更新して使うことになるだろうか。それとも「2024年3月第三週のプロジェクトリスト」のようにアップデートして使うことになるだろうか。同じ項目のタイトルを変えることもできるし、新しい項目として作り、過去分はアーカイブ的な項目にすることもできる。
決めなければならないことが山ほどあるな。
＊ ＊ ＊
「週報」は現状historyに保存している。これは過去方向の記録だから問題ない。で、現状「予定」→「日記」の同一化がうまくいっているので、週報にもこれを適用できたらいいとは思う。
つまり「この週のやること」→「週報」という流れ。
これも実際は、週の項目がdiary.jsonにあるので、そこに書くのがいいのかもしれない。また混乱の度合いが増えた。
＊ ＊ ＊
「これからすること」は扱いによって、未来方向とも言え、過去方向とも言える（決定したと捉えるならば）。
よって、単に情報の性質だけをみると決定できない。たとえば「済」の扱いにしたいならば、「やること」というコンテキストで統一して、その中で分けたほうがいいだろう。
＊ ＊ ＊
pin機能を使って、プロジェクトリストなどは先頭に表示させる？
＊ ＊ ＊
週報や読書日記などは、明らかに過去方向の情報で、タスクリストは明らかに未来方向の情報で、各種チェックリストは中立的（非時間的）な情報と言えそう。
それぞれは実は分けた方がいい？
- history
- do
- list
- diary
こういうもの？ たぶんネーミングが違うが、それは置いておく。
とりあえず、listは、lineでもcardでもnoteでもない第四のタイプなのかもしれない。種別で言えば、cardに属するがしかし、微妙に異なる気もする。
行動に関すること、で集合を作れば、やることリスト、プロジェクトリスト、やったこと、などが集まるだろう。各種チェックリストも、行動において使われるのでそこに入るはず。
＊ ＊ ＊
着想を書きとめるときは、上記のような種別の判定は働いていない。で、それを整理したり、後から使うときにそういう種別が要請される。これをどう処理するか。
＊ ＊ ＊
ファイルをわけて管理するのはよいとして、そのビューをどうするか。
現状のmemo.jsで読み込むfileを切り替えるボタンを付ける？
とりあえず、問題はファイルを切り分けると、目に入るものとそうでないものの格差が大きくなる、という点。未来方向の情報ばかり見て、過去方向の情報が見られなくなるとか、その逆とか、そういう事態が起こる。だからこそ、単一のファイルにまとめておくことに利点がある。
＊ ＊ ＊
とりあえず、history.jsonにまとめてみることに。
＊ ＊ ＊
表示順を、更新日順にしたい。
まず、項目の更新時にupdatedも更新するようにする。
で、表示するときに、updatedでソートするようにする。
その辺はgeminiに聞く。
＊ ＊ ＊
できました。かなりいい感じになったと思います。プロジェクトリストについては、このやり方での管理を試してみましょう。
しかしよくよく考えてみると、これは「プロジェクト」であって、「タスク」ではありませんね。まあいいでしょう。
10:00
ブックカタリスト:
087のアフター用の記事を書いておきます。
メルマガ:
二つ目の原稿を書きましょう。
＊ ＊ ＊
2300文字ほどの原稿が書けました。
12:00
メルマガ:
三つ目の原稿を書きましょう。
＊ ＊ ＊
3800文字の原稿を書きました。分量で言えば二つ分くらいですね。
13:00
note:
セールの記事を書きます。
＊ ＊ ＊
表紙画像を拾ってくれなくなったので、かなりテンション下がります。
14:00
メルマガ:
あと一つ分くらいの原稿の空きがあります。書くこと自体は山ほどあるわけですが、同じ号に似たテーマの話が並ばないように散らばせたいところ。で、そういうときにどのようにして「書くこと」を見つけるか。これ自体が一つのテーマになりえます。
17:00
KW:
今日のエッセイを書きましょう。
＊ ＊ ＊
書きました。
メルマガ:
あと一つのネタをどう見つけるか問題。
＊ ＊ ＊
現状、WorkflowyのWRMという項目に書こうとしていることのネタがいくつかピックアップされている。あとは、ideaScapeのメモ、としてTweetをcard化したTweetlst.mdのページ。これらからどうやって記事のテーマを見つけるかを考えたいところだが、まさにこれがこうしたメモたちの「用途」でもあるのだろう。
理念的ではなく、実際的な「用途」をベースに考えること。
今こうしたタイミングでならば、過去の記録を読み返す動機が生まれる。それを使っていきたい。
＊ ＊ ＊
そうしたものが分割された状態にあるのはどう捉えるべきか。統合した方が見返しのときには楽でいいが、そうなるとフォーマットも統一されてしまう。ただ実際、「これはカード化されていた方がいい」「これはラインにあった方がいい」と感じるものもある。統一しておけば、そうしたややこしさからは解放される。
二つの情報の「行き来」が簡単にできればいい？ それともカードとして統一して、そこからライン風に表示できるようにする？
おそらくこの難しさが情報整理ツールを使う上での難しさにつながっている。
＊ ＊ ＊
仮に「行き来」がやりやすくなる形を考えるとしたらどうか。一つの画面に左側にideascapeのライン、右側にtweetlistを表示させればいい。
たとえば以下は、ideaScapeの画面。
右側は「ノート」を開くようにデザインしたが、その領域にcardを表示させてもいい。cardを表示させる機能は、twetlist.mdから持ってくればいい。
というか。
というか、今こそ二つのページを並べて表示する機能の出番ではないか。
一つのぺーじで二つのカードを並べる機能を付けること自体は容易い。
現状、複数の情報を単一のページでまとめているが、一つのjsonを呼びだすためのmdを一つ定義して、それを複数並べる形で使うことはできないか。それとも、それが使い勝手がよさそうに感じるのは妄想だろうか。