の作業記録
企画案を考える水曜日
- 作業記録の共有
- 次の企画案
- メルマガ+原稿1
- アイデアノート整理
- ツイートノート移動
- R-style+体験から書く
- 各種日課
- 集中的読書
- 復文勉強
- サブ執筆
- KW+ミニエッセイ
7:00
おはようございます。本日は次の企画案を考えましょう。あとは、メモとネタの扱い。
アイデアの扱いについて:
一度それを作っておけば、以降は大きな整理を必要としない何かを求めていた気がしますが、そのニーズそのものが歪んでいるのかもしれません。
＊ ＊ ＊
Textboxにそのままコピーしたツイートピックアップメモ。
ノートの扱いとしては良いが、断片の扱いとしてはどうか。全文検索をすれば、中に含まれているものは取り出せるが、現状Textboxには全文検索の機能がない。作ろうと思えば作れるが、いったんそれがないものとして考える。
だとしたら、それぞれの行をNUKAに入れる？
NUKAに入れると、JSONLに入れることになる。あるいはListのようにJSONに入れてもいい。どちらでも、メモリ上に読み込めば検索などは容易になる。
でもって、それを生成AIに扱わせてもいい。ベクトル化する、あるいはAPIのスクリプトを書く。ここはsqliteでも別に構わない。JSONからsqliteを作るという手もなくはない。
ともあれ、第一の議題はこうした「メモ」をどう扱いたいか。
＊ ＊ ＊
WorkFlowyを検索したらたまたま見つかった項目。日付の項目の内側に格納されていた。
個人的にやろうとしていたのは、この項目を最上位に置き、以降の執筆活動を"統治"すること。しかし、それはどれだけ適切なのだろうか。
あるいはこういうマスターを一つ置いておき、定期的にアイデアだしして、このアウトラインに「反映」させていく？
これが二つ目の議題。
＊ ＊ ＊
二つの議題は別の話題なのかもしれない。今まではそれをあまり意識しておらず、二つをトップ＆ボトムの統合と考えていたが、そうではないのかもしれない。
＊ ＊ ＊
デイリーから近しいものを集めて、グループ（スレッド）を作るイメージ。
＊ ＊ ＊
ちょっと狭いというか、詰まりすぎな気もしますね。ノート感は薄い。
とりあえず、WorkFlowyだけの運用ならこの感じでよさそう。
でもって、WorkFlowy MCPを経由して、自分のターミナルに表示させることは余裕。
＊ ＊ ＊
気がついた。MCPを使えば、自動で手動ができる。
どういうことか。
たとえば、Evernoteで「更新日順」でソートすれば、何か編集すれば自動的に順番が変わる。WorkFlowyではそれができない。「押し出しファイリング」のようなことが常に操作を必要とする。わりと面倒。
MCPを経由すれば、ノートを表示し、編集したらそれを最上位に移動するということが（おそらく）できる。
いや、そもそもそういうものではないな。操作としては可能だが、ターミナル上である項目を「表示する」というのは想像以上にややこしい。
なぜなら、何かの項目を表示したとして、その内容も項目なわけでIDを持っている。それらの編集は再帰的に項目の編集となる。これはノートツール向きではないな。でも、一つの大きなヒントにはなる。
操作のAPIがあるならば、手動操作のUIになっていても半自動が可能になる。
＊ ＊ ＊
ひとまず、WorkFlowyの検討はこれでいいとして、結局Threadも成果物というよりはアイデアのグループを作っているだけ。
「ツイート振り返り」でも似たようなことをすればいいのかはまた別問題。
＊ ＊ ＊
いくつかをNUKAに入れてみた。悪くはない。抽出条件を増やせば実用に耐えうるかもしれない。
たとえば、こうして移したとして、もともとのツイートまとめノートはどうするのか、というのが一つの問題。それはそれで保存しておけばいい？それがある種のバックアップになる、という見方で。
仮にそうするとして置き場所はどうなるか。Textboxのcards/内にそのまま入れておくのか、それとも別のフォルダをつくるのか。
＊ ＊ ＊
バックアップという意味で言えば、データベースに入れておく方がよりアーカイブ感はある。しかし、今バックアップがmdファイルで、操作の為のデータベース（jsonを含む）に入れようとしている。今までの検討概念とのズレを感じる。
操作の為のバックアップではなく、データベースを再構築する為のバックアップというところか。
つまり具体的なデータベースがどういう形で実装されるかはわからないので、ひとまず断片としてテキストファイルで保存しておく、というイメージ。それは悪くない。
＊ ＊ ＊
ただし、この形では、iPhoneから確認することはできない。テキストファイルで直接ひらいてもあまり見栄えはよくない。
抽出などの要件を取り除けば、テキストファイルオンリーでもやっていける。テキストファイルでも、検索の機能をデザインすれば抽出はできる。そちらの方にシフトすれば、多くをテキストファイルベースでやることができる。iPhoneや他のツールでも扱いやすくなる。それをどう考えるか。
UI上で表示するならば、データがjsonでなくてもいい。テキストファイルでもいい。内容をパースすればいいだけだから。ただし、空改行が入るような内容だと話はややこしくなる。
＊ ＊ ＊
ようは断片的なメモをそのまま放置し続けているということに問題がある？
＊ ＊ ＊
新しいメモをNUKAに入力したら、テキストファイルのエクスポートを作り、それをicloud、ないしはサーバーにアップする処置をすればいい？
＊ ＊ ＊
いったん、Textboxからツイートピックアップノートを取り除きました。
もう少し扱い方を決めてから入れた方がよかったかもしれませんね。
たぶん、Textboxの中にいれておくこと自体は問題ではなく、操作の仕方がわかっていないものが混ざっているということが問題なのでしょう。
あと、メモしている数の多さに比べて、実際にメモの処理に使っている時間の少なさがよくない状況を引き起こしている気がします。
もう一つ一つ言えば、私にとって記事を書くことが「メモを処理する」（メモに書いた内容を展開させる）という意義なのだと思います。記事を書く為にメモをとるのではなくて、メモを発展させるために記事を書く、という構図です。
11:00
メルマガ:
まずはメルマガの記事を書いておきます。
＊ ＊ ＊
4200文字の記事を書きました。
13:00
R-style:
記事を書きましょう。
＊ ＊ ＊
publish:体験から書く | R-style
15:00
作業の合間に煮豚を作っております。
Textbox:
Textboxからツイートメモを動かしたわけだが、むしろ個別のツイートメモを「一気に横に並べてひらく」ことができれば、新しい観点が生まれるかもしれない。ようするに、デジタルツールにアナログの「ページ」を導入するには、そういうやり方になるだろう。
そのとき、どういう設計ができるだろうか。
＊ ＊ ＊
もし複数のノートを一気にひらけるなら、それは「ノートブック」に相当する機能になる。問題はそれをどう指定するか。
集中的読書:
GEBを読みます。
＊ ＊ ＊
「構文論と意味論」を読みました。
16:00
Textbox:
function面で言えば、連続的にノートをひらく作業をすればいい。あとは、その「このノートを開く」という指定を以下に行うか。
たとえば、同質のハッシュタグを持っているものを一斉にひらく、というのが一番シンプルだろう。仮に10箇くらいのノートだったらいいが、それが100箇もあったら結構大変なことになりそう。
が、とりあえずこれは気にしないことにする。上限を定めておいてもいい。
＊ ＊ ＊
とりあえず、Claudeと相談しつつ検討しよう。でも、これはあまり筋の良い解決ではない感触もある。
むしろ個別にバックアップのmdファイルがあり、それを任意で「一つの場所」（dbかjson）に入れて操作する、という筋がよい気がする。