の作業記録
準備を進める月曜日
- 作業記録の共有
- メルマガ+ツイート
- メルマガ+ファイル準備
- メルマガ+お題設定
- TH+第三章のアウトライン立案
- Obsidian+テーマボード作成
- Obsidian+テーマボード拡充
- Textbox+プロジェクト情報の管理
- 環読プロジェクト+第三章レジュメ
- KW+ミニエッセイ
- 群論への第一歩+第八章続き
9:00
おはようございます。本日はもろもろの準備デーです。
publish:メモの随伴性２ / 情報カード、縦から書くか？横から書くか？ / 一週間に見出しをつける / Excelとデジタルツール的思考｜倉下忠憲
Obsidian:
テーマノートを作ります。
＊ ＊ ＊
通常はテーマに合わせて黒背景なのですが、CSSを上書きして白にしました。
あとはここに自分がテーマ群について考えていることをつけていきましょう。
一旦書き終わったらスナップショットを残しておくのもよさそうですね。
メルマガ:
ファイルの準備です。
＊ ＊ ＊
ファイルの準備はOKです。
＊ ＊ ＊
今週書くことも暫定的に決めておきました。
あとで読む:Make.md
13:00
プロジェクトの管理について:
プロジェクト的な情報をどう扱うのかを検討しましょう。
＊ ＊ ＊
たとえば、こういうのがよくあるパターンでしょう。
これ以外にどんな形があるのか。
カードスタイル。
https://gyazo.com/42c4441efd0085f15e95818f09da60c0
カードの構成方法を変更。これはこれであり、もっとmemo.mdページに寄せて、プロジェクトやタスクをそれぞれ一枚のカードやラインとして表示する手はある。あるいは、いっそのことmemo.mdに書き込んでも言い。
＊ ＊ ＊
projectを特別なページとして作り込んでもいいし、テキスト+箇条書きでいい感じに見せるだけに留めておいてもいい。あるいはmemo.mdと統合して、閲覧頻度をあげてもいい。
ビューの設計に加えて、いつ入力し、いつ閲覧し、いつ修正するのか、という観点も必要。
＊ ＊ ＊
memo.mdに入れる場合、addressのつけ方をどうするのかという問題がある。プロジェクトの情報はprojectとつけるか、あるいは「執筆仕事」というaddressでより個別に振り分けるか。
タグの二重の絞り込みができるようにするか、そもそもこうした情報は、do.jsonの担当にするか。
do.jsonに入れれば、最初の絞り込みが行われた状態で、そこから種目別の分別（執筆仕事、事務作業、シングルタスク）などなどが可能になる。ただし、ビューが分かれることで、閲覧頻度が下がる問題はある。
さて、どうするか。
この情報は、頻繁にアクセスするようなものだろうか、それとも週一度くらいのチェックで十分だろうか。あるいは、その観点そのものが間違っている？
＊ ＊ ＊
大きな観点として、project.mdというページを作り、そこでプロジェクトの包括的な視点で情報を整理することをするか、それともmemo.mdの一つの情報として「project」を持つかどうか。それが現状の大きな課題。
15:00
KW:
本日のエッセイを書きましょう。
環読プロジェクト:
第三章のまとめを書きましょう。
Textbox:
引き続き、プロジェクト管理について。
たぶん、どちらのバージョンを選ぶにしても実現したいのは「プロジェクト名と直近の雑感」を一覧したいこと。
Workflowyだと、下位に項目を作ってしまうと、すべてを閉じるか開くの選択になってしまって、一部だけを表示ができない。これが全体の一覧を難しくしている。だから、他のツールでビューを作るなら、そこをフォローするものにしたい。
あとは、個別ページかmemo.mdかの選択と、個別ページの場合、テキストなのか、do.jsonなのかの選択。
19:00
Textbox:
project.mdにテキストで書いて、CSSでカードっぽく見せるのが一番簡単ではある。レイアウトの自由度も高い。
一方で、ログをどうするのか、という問題がある。
カード形式の場合、カードを長く書き足していくか、新しいカードを作ることによって、履歴が残る。一方で、テキストで直近の動向だけを書くのでは、履歴が残らない。一つのリストに長く書き続けてもいいが、そうなるとそれぞれのprojectノートとの中身との整合性もある。
いっそ、それぞれのprojectノートの中身から抽出すれば話は早いし、deepfileのリストを作るとき、一番上のテキストを抜き書きする、というやり方をすれば、JSONだけからそうした表示は可能になる。
が、そこまでする意義はあるだろうか。あと、ここにさらに、テーマを育てるという課題も加味する必要がある。それが問題。
＊ ＊ ＊
いろいろ加味すると、とりあえずproject.mdに手書きで情報をまとめていくだけ、ということにしておくのが無難そう。ログとかも、しばらく使ってみて感触を確かめてから検討しよう。
historyが、どちらかと言えば過去方向の情報に対して、こちらは未来方向の情報になる。そこが差異になるかもしれない。
ただ、do.jsonとの関係は頭の片隅においておきたい。
GTDとプロジェクト:
GTDにおいて、プロジェクトリストは、自分が抱えているプロジェクトを一望するためのもの。
それらは日々細かく目にすることはなく、目にするのは「次の行動」になる。
この関係をどう扱うか。
つまり、作ったプロジェクトのビューと、「次の行動」をどのようにリンクさせるのか、あるいはさせないのか。
プロジェクトのビューを整理したら、そこから必要に応じてタスクを起こす。そのタスクを日常的には実践していく。そのタスクは、現状はdo.jsonに記録されている。
つまり、このprojectビューから、新しいタスクが作成できればいい？
タスクは、チェックボックスの記法をつけて記述すればいいし、その部分だけを抜粋することも不可能ではない。たとえば、deepfileのdescriptionには、未終了のタスクだけを抜き出しておく、というようなことができる。
ただ、もっと原始的にできないだろうか。
＊ ＊ ＊
最終的にレビューのやり方によっては、テキストではなくJSONを選択することになるかもしれない。が、とりあえずはテキストでやってみて、どういう機能を自分が欲しているのかを確かめてみることにする。