の作業記録
ゆっくりしたい日曜日
- 作業記録の共有
- 朝巡回
- 来週のSTL確認
- 週報作成
- ブックカタリスト+配信予約
- 情報を呼び出すツールについて
- 情報を呼び出すツールについて
- 爪を切る
8:00
おはようございます。本日は来週の予定を確認後、本を読むなどしたいと思います。
朝巡回:
来週のSTL確認:
まずはスケジュールから。
＊ ＊ ＊
Googleカレンダーから、Textboxに一週間分の予定を写しておきました。これはOK。
問題はここからです。
＊ ＊ ＊
状況を整理しておきます。
まず、todo boardがある。これはGTD的には「次にやることリスト」に位置づけられるでしょう。役割としては、日中の行動を支えるもの。
あと日記を書く欄もあり、一週間の振り返りではこのページを参照するのがよさそう。
一方で、少し視点を上げて、「プロジェクト」をビューするときには、「次にやることリスト」とは違ったビューが望ましい。
こちらはそうしたビューとして機能するだろうか。少なくとも、その萌芽は感じる。
今、プロジェクトのタイプで一つのカードを作っているが、これを一プロジェクト一カードにすることもできる。そうすると、それぞれのプロジェクトの概要も（いちいちページを開かずに）確認することができる。
一方で、そのプロジェクトがどういう位置づけを持っているのか、という一つ上からの視点は失われてしまう。
ここでやろうとしているのは、まさにその一つ上の視点でのチェックなわけだから、一プロジェクト一カードはやめておいた方がよさそう。
あと、このビューだと、更新日順でソートされているので、更新する度に順番が動いていく。それがやや煩わしい感じもする。それぞれのカードをチェックしていき、一通り作業が終わったら、全体の順番が再ソートされる、というのならばもう少し落ち着いた感じがするかもしれない。
あるいは順番は固定か。しかし、そうすると後の方のやつを見なくなる可能性はある。
ただ、たとえば「執筆プロジェクト」は先頭に固定表示されていたほうが嬉しい感じはする。
と、ここで何かそういうのを作っていたのを思い出す。
＊ ＊ ＊
これだ。
ふむ。このページは巡回に入っていないので、自分でリンクをクリックしないと出てこない。その問題は後でケアするとして、プロジェクトのレビューにはこれを使った方がいいのかどうか、という問題。
各種リストの表示だと、プロジェクト情報以外のカードも目に入る。たとえば何かしらのチェックリストだとか。それを目にして、「そういえばちょっと書き換えておくか」というアクションが起こるのは悪いことではない。また、「考えたいこと」などのリストもあり、それとの再会とも悪くない。
特定の役割ではないものと、なんとなく再会できるのが各種リストという大ざっぱなカテゴリの良さだろう。そこに「プロジェクト」という見返した方がよいものが混ざっているから、全体としていい感じになる。
現状の上(do processing)のページは、2コラムだが、3コラムにしてもう少し要素を追加することもできる。考えたいことなどを追加して、全体としてもう少し雑多さを増やしてもいいだろう。それでも、各種リストとの使い分けは考える必要がある。
＊ ＊ ＊
たとえば読書メモリストとか読む本リストといったものは、do processing に入れたい感じはない。あるいは、日課リストとかも同様。
各種リストに並んでいるものは、執筆プロジェクトのようにある塊（オブジェクト）をリストにしたものと、行動のチェックリストのように中身がそのまま並んでいるリストがある。
一つ上の視点での振り返りで必要なのは塊をリストにしたもの。コンテナリストと呼ぼう。
その二つを区別するかどうか。
＊ ＊ ＊
ネックになっているのはたぶん「考え事」リストだろう。これは中身がそのまま並んでいるので、コンテナリストではないのだけども、何かしらdo processing に入れたさがある。この中途半端なものをどう位置づけていいのかちょっと悩む。
現状各種リストのprojectの要素には、projectというタグ（アドレス）も与えているので、プロジェクトは各種リストではないようにしてもいい。要するに全体の一覧には出てくるが、各種リストの絞り込みにはプロジェクトの情報は出てこない、という寸法。それで排他性は担保されるが、その担保にどんな意味があるのかはわからない。別に表示されていてもいい気はする。
あと、逆に「今後書いていきたいこと」は、並んでいるのは塊だが、do processing には入れたくない感じがある。
＊ ＊ ＊
リストの統廃合を行いました。で、扱いの課題が残ったのが以下。
- 読書アクションステップリスト
- 書き物をしたくないとき用の作業リスト
- 考え事リスト
- ミニエッセイ mini ネタ帳
まず「ミニエッセイ mini ネタ帳」はネタ帳と名づけているのだから、各種リストではなく、ネタ帳にしておきましょう。
で、「考え事リスト」は、ややこしいのは「考え事」というタグ（アドレス）があること。
どちらかに統一するのか、何か別の方法を考えるのか。
そもそも、これをどう使っているのか、という点から考える必要がありますね。というのも、直近までで「考え事」というタグで絞り込んだ経験がほとんどない、つまり使われていないからです。安易にこちらに統一すればいいというものではなさそうです。
いったん保留して次に。
「書き物をしたくないとき用の作業リスト」は、中身が直接書かれたリストですが、これは週一回の振り返りのときだけに閲覧すればいい、というものではないでしょう。どちらかといえば、日課のように適宜参照された方がよいものです。
まあ、そんなことを実行している時間が日中に本当に存在するのかはなぞですが。
現状、主要プロジェクトと日課と読書だけで一日の作業時間はほとんど使い終えているので、「書き物をしたくないとき用の作業リスト」があったとしても参照されるタイミングは薄そうです。
では、どう考えるか。
作業の手がとまっているときに、手遊び的にこういうリストが開くのが一番だ、というところまでは予想できます。
それについてはまた少し考えましょう。
＊ ＊ ＊
「読書アクションステップリスト」は、具体的な行動というよりも、こういう方向で本の情報をまとめていこう、という指針です。ある意味では、プロジェクトと言えるかもしれません。
というわけで、プロジェクトタグを与えてみましょう。
＊ ＊ ＊
「ちょっとやってみようと思ったことリスト」というのがあったので、「書き物をしたくないとき用の作業リスト」の中身を統合しておきました。
残すは、「考え事リスト」だけ。一考え事一カードにすると、詳細の情報を扱いやすくなりますが、その代わり、一覧性が落ちます。
で、現状「考え事」タグがついているものは、知的好奇心の疑問というよりは、「これからどうしていこうか」といったまさに考え事の割合が多いです。ここも問題をややこしくしますね。
現状「考え事リスト」に書かれているのは以下の話題です。
- 情報を扱う軸にはどのようなものがあるか？
- 個人の技法はなんと呼ばれるか？
- 知のネットワーク作りは、実際は何をしているのか？
- 組成・グループ化の別の呼び方は何か？
- なぜ生きる上で、書くことが大切なのか？
- コンテキストは情報整理でどのような意味を持つのか
もっておきたい疑問、定期的に考えたい疑問という感じでしょうか。ようは「考え事リスト」というよりは「疑問リスト」なわけです。だとすれば、無理に「考え事」タグに統合する必要はないでしょう。いったん「疑問リスト」にリネームしておきます。
でもってタグを各種リストからネタ帳に変えてみます。
でもって、「読書アクションステップリスト」も「研究ステップリスト」にリネームして、ネタ帳に変更しておきます。
これでだいぶ収まりがよくなりました。
＊ ＊ ＊
一つ一つタグを確認していたら、「断片」というタグが、先ほどの考え事（あらため疑問）の置き場所としては最適な気がします。
が、ひとまずは様子見。
＊ ＊ ＊
さらにタグを見ていたら「論文メモ」 もありました。これも、今考えているPDFファイルの扱いに関係しています。
とりあえずは、論文のPDFファイルをTextbox内のフォルダに保存し、そのファイルへのリンクと書誌情報をまとめたJSONを作り、それを表示させるmdページを作ろうかと考えていました。いわば、上記のメモとは別口に新しいJSONを作るという考えです。
一方で、こうしてまとめると、単一のページからいろいろなものをぽちぽちクリックしながら参照することができます。それはそれで魅力的です。
これもどうするか。新しい問題です。
＊ ＊ ＊
上のようなhistory.jsonに統合する形の場合、新しくメモを起こすのが簡単です。ページを移動せずとも、メモローグを立ち上げて、入力するだけで済みます。一方で、別途mdページを作る場合は、そのページに移動して記入するというステップが必要になり、それが若干ネックになるかもしれません。
ただ、「このフォルダに新しいPDFファイルが追加されたら、その中身を確認して、JSONに追記せよ」というような処理を書けるならば、上のようなステップはほぼ必要ではなくなるので、考慮する必要はなくなるでしょう。
全体の運用をどうするのか、どうしたいのかが見えてこないのでなかなか決めがたいところです。
＊ ＊ ＊
いったん、論文メモは論文PDF.mdに移すことにします。
で、最終的にはそれはJSONなりなんなりにします。あるいは同種の管理が可能な形でmdに書き込むことにします。
＊ ＊ ＊
ここで考えるのは、総合ノートというのを作り、それをタグなどで分別するというやり方か、それとも個別のノートを作り、小分けして管理するのか、ということ。また、後者のやり方をした上で、それらを統合するビュアーを作る、という形もありえる。
＊ ＊ ＊
現状、history.jsonは、523KBファイルとしてはとても軽いが、テキストファイルとしてはかなり大きい部類に入るだろう。
すべてを一つのファイルに集めていけばいくほど、ファイル容量の増加速度はあがっていく。それが好ましいのかどうか。
OBTFでは、たとえば年単位で区切るだろうが、history.jsonではすべてが統合されている。当然際限なくファイルは大きくなる。あまり好ましいことではないだろう。
history.jsonを年単位で切り分けるという手はある。で、読み込む差異にはそれらをすべて読み込むというようにする。
＊ ＊ ＊
history.jsonにまとめておくと、処理の書き方がまとめやすい点は大きい。途中までは同じで、タグでの抽出を切り替えれば、さまざまな用途に使える。設計を考えるのは楽ではある。
＊ ＊ ＊
do processingはしばらくこの３カラムでいきましょう。なかなかよい感じだと思います。
13:00
情報を呼び出すツールについて:
保存しておいた情報をシュッととり出せるツールについて考えます。
一応6月いっぱいでObsidianで作業記録をつけるのは止めようかと考えています。
ただ、Obsidianをぜんぜん使わないというのもちょっともったいないなという気分があります。URLスキームを使えば、ページを開けるわけで、それを使えば、以前から考えていた必要な情報をしゅっと表示させるために使えるのではないか、というアイデアがあります。
今でも、作業用のvaultを開いた状態で、別のvaultでノートを表示させることはできますが（そうしないと今開いているノートが変わってしまう）、その場合、必要な情報を保存するvaultと作業記録用のvaultを分ける必要があり、リンクの運用などを考えても面倒になるだけです。
というわけで、作業記録をObsidian以外で書くようにすれば、ただ呼び出すためだけにObsidianが使えるのではないか、という発想です。
もちろん、自分でいちからそういうツールを作ってもいいのですが、ひとまずはObsidianで考えてみましょう。
＊ ＊ ＊
確認しておきたいのは、Obsidianで特定のファイルを呼び出す方法です。URLスキームを使うことになるでしょう（ターミナルでopenを叩いても良さそうですが）。
＊ ＊ ＊
ページ名がアルファベットだけならば単純で、
obsidian://open?vault=writing&file=home
とでもすればhomeが開きます。これをターミナルでやる場合は？
pythonを経由する方法がある。
python3 -m webbrwoser obsidian://open?vault=writing&file=home
あるいは普通にopen を使うか。
open obsidian://open?vault=writing&file=home
pythonだと「webbrwoser」モジュールがないと言われた。
openは普通に開いた。これで一応いける。
開くと、ウィンドウの状況が再現される。
たとえば、今この状況、つまり2枚開いていて、フォーカスが作業記録にある状態でObsidianを閉じ、openで呼び出せば、作業記録がhomeになって呼び出される。
では、開いている状態ならば？ やはりフォーカスを持っているこのウィンドウがhomeになった。ちなみに「戻る」でここに戻れた。
つまり、情報ウィンドウとしてObsidianを開きっぱなしにしておけば、あとはターミナルでさまざまな情報を表示することができる。しかし、複数のウィンドウを表示するのは難しそう。なにせフォーカスのウィンドウを上書きしてしまうから。
たとえば「日課リスト」「取り組んでいるプロジェクト」「注意したいこと」のような三種の情報を同時に表示したい場合は難しい。新しいポップアップウィンドウで表示する、というコマンドが用意されない限りは難しいだろう。
一応３つ順に開けば、「進む」と「戻る」で複数の情報を行き来すること自体は可能ではあるが、やりたいこととは違っている。
とりあえず、単一の情報を示すことだけならばできそう。
＊ ＊ ＊
しかし、不十分であることは間違いない。ようは、ローカルに保存されているファイルの情報を読み込んで、Macのウィンドウを作る、というだけの単純なアプリケーションであればそれいいのだ。
以前、似たものを作っていた気がするが、もうあまり思い出せない。どういうのだったかな。
ウィンドウを生成することだけならば、Pythonでもできるし、調べたらRubyでもできるだろう。Electronだったら、CSSの知識がそのまま使えるという点で便利というだけにすぎない。
＊ ＊ ＊
list luncherという自作アプリだった。
アプリケーションを起動すると、移行は、alt + spaceで検索ボックスを呼び出せるように。
Textboxのlistフォルダに保存しているmdファイルの中身を呼び出せる、というヤツだった。
どうも箇条書き部分しか表示していない気がする。いや、そうではないな。単にこのページは残りの部分をScriptで生成しているだけだった。
Textboxはmdとjsonの二つがあるので、どちらを呼び出すかは考える必要があるのと、この方式だと、複数ウィンドウが開けないのでやっぱり求めているものとは違うという問題がある。
明示的にファイルを開きたい、という場合があるのだ。
上のツールはいちいちTextboxを開かないでファイルを開けるという点では便利だがまだ十分とは言えないな。でもおかげで、方向性が見えてきた。
18:00
情報を呼び出すツールについて:
あるタイミングで、何か情報を欲するということはある。たとえば、CSSを書こうとして名前が思い出せないのでアンチョコが欲しくなる、というとき。
こういうときは、「CSS」のような言葉でその情報が探し出せる環境であればよい。List Luncherがこなせるのはそういう役割。
一方で、今日やることを決めるときに、日課のリストやプロジェクトのリストを表示したくなるのは、少しだけシチュエーションが異なる。
第一に、必要になるタイミングとその情報がある程度予想できること。第二に、「考える」作業をするためにしばらくその情報が表示され続けて欲しいこと。第三に、複数の情報が必要になること。
この違いを踏まえて、情報を呼び出すツールは設計されなければならない。