CT連載07：やることの先送り / アナログのノートをいま使うこと / 一歩引いて考える

はじめに

ポッドキャスト、配信されております。

◇BC103 『肥満の科学』 | by goryugo | ブックカタリスト

◇第百六十三回:Tak.さんとカード法について 作成者：うちあわせCast

ブックカタリストでは、ごりゅごさんが『肥満の科学』をご紹介くださりました。サバイバルスイッチの話も面白かったですが、「純粋すぎるものの摂取は体によくないかもしれない」というのは、情報摂取論の視点からも参照できそうな話です。

うちあわせCastでは、最近倉下が理解した（あるいは発見した）情報カードの使い方の話を語りました。個人的には、この理解からどう展開していくのかが鍵だと思っております。

よろしければお聴きください。

〜〜〜オーディオブックに向いた本〜〜〜

特に根拠がない直感ですが、「オーディオブックに向いた本」というのがありそうです。

ごく素朴に言えば、「図解でわかる」的な本は図解が前提で話が組み立てられるので、それを聴いてしまえば魅力は半減するでしょう。オーディオブックには向いていない本というわけです。だったら、その逆もあり得るのではないか。

で、最近私は哲学系の本を聴いているわけなのですが、少なくとも私が聴いた本はどれも読み手に「語りかけて」います。哲学という営み自体が、どこかしらに対話性を帯びているからある意味必然なのかもしれませんが、「ある人が語っていることを、対面して聴いている」という感じになるのです。そうなると「聴く」というモードになりやすい。

一方で、いくつかの小説では、主人公の独白のような形で著述が進んでいきます。そのようなものが「読める」というのが小説の効能（他者の内面にも心があるということが文字を通して理解できるということ）なわけですが、そうなると「聴く」よりも「読む」感じが強まってしまう。

というのは、もちろん勝手な推測なわけですが、とはいえ目の前の人に語りかけるように書かれている本は聴きやすいのではないかなとちょっと予想します。しばらくいろいろな本を聴いてその推測をたしかめてみるとしましょう。

〜〜〜知識はつながっている〜〜〜

ObsidianにWeb Clipper機能が追加されたので、カスタマイズして遊んでいたのですが、これは知識がないと他の人はちょっと厳しいかな、という感じがありました。

逆に言うと、ちょっと知識があればカスタマイズが可能ということでもあります。そこで、解説記事を書きました。

◇Obsidian Web Clipper | Knowledge Walkers
https://knowledgewalkers.com/?Obsidian Web Clipper

で、書いているうちに気がついたのですが、このClipperのカスタマイズ性をフルで発揮させるためには、HTML+CSSの知識が欠かせません。もちろん、すべての領域をカバーする必要はなく、せいぜいセレクターのコンセプトが理解できていればいいのですが、それでもそうした知識がゼロだと、どこから手をつけていいのかわからないでしょう。

しかしながら、CSSのセレクターはそれ自体が一つの解説ページを必要とする知識です。言い換えれば、別領域の知識。

こんな感じである知識の系を説明しようとすると、別の系の説明が要請されるということはしょっちゅうあります。

最近『ライフハックの道具箱』を編集していても似たようなことを思います。あるツールの説明を書いていると、他のツールとの類似性や相違点などを記述したくなる場面が少なからず出てくるのです。しかしその記述では、他のツールの知識が前提となります。言い換えれば、その「他のツール」についても説明が必要となる。

幸いなことに『ライフハックの道具箱』ではさまざまなツールの説明が一つのパッケージとしてまとめられてるので、Evernoteの説明にCosenseの名前を出してもへっちゃらです。なにせCosenseの説明が別途あるからです。

ようするにwikiって便利だよね、という話なのですが、知識を総合的にまとめていくことの利便性と苦労については意識しておきたいところです。

〜〜〜実行せよ、さもなくば書き留めよ〜〜〜

具体的な内容は覚えていないのですが、何かしらの作業をしているときに「あっ、あれもやらないと」という思いつきがありました。その思いつきが脳内に留まっているとモヤモヤしてくるので、そのときやっていた作業を中断し、その思いついた作業に取り掛かりました。3分ほどで終わったので、元の作業に戻ります。

そのとき「これが15分くらいかかる作業だったら、とりあえずメモしておくだろうな」とふと着想しました。実行するか、そうしないならメモすること。そうすることでモヤモヤ感が扱えるようになります。

ここで、先日読んでいた本に出てきた、「Publish or Perish」というキーワードが閃きました。そのフレーズと似たような感じで先ほどの着想を表現できないか？

ということで、英語表現の探索が始まったのですが、もちろん私の語彙ではまったく太刀打ちできません。なにせ、英語での表現を調べるだけでなく、並べる二つの言葉が「いい感じ」に揃っていることが大切なのです。

そこでGeminiに相談したのですが、最初は「down」という表現で揃えようとそのイディオムを聴いたり、「取り掛かる」を英語で言うバリエーションとかを聴いていたのですが、なかなか埒があきません。

しかし、ある瞬間に閃きました。まるっと聴けばいいんじゃね？

自分がやろうとしていることを文脈含めて説明したところ、一気に話が進みました。いくつかの案を挙げてくれたのでその中から「Do or Document」を採用。やはり生成AIは優秀です。

今回の試行錯誤を振り返ってみても感じますが、生成AIはググると同じように断片的なキーワードから解答を引き出すのではなく、文脈全体で問うことがその有用性を引き出す鍵だと思います。

その意味で、「文章で書き表す力」がすごく大切になりそうです。

皆さんはいかがでしょうか。日常的に生成AIをどのような目的で利用されていますか。その際には、どんな風に入力を行っているでしょうか。よろしければ倉下までお便りください。

では、メルマガ本編を始めましょう。今週は、タスクリスト連載の続き、アナログノート話、自分の頭で考えることについて考える、の三編をお送りします。

CT連載07：やることの先送り

すべての「やること」を集める総合的なリストを作るのではなく、一日やそれに類する単位で区切った時限式のリストを作る。

そのようにして記述の賞味期限を設定し、一定の頻度で新しく作り直していくことで、Todoリストを「腐らせる」ことが避けられます。

じゃあそれでまるっと問題解決かというとそういうわけではありません。やることの発生量と、消化量がバランスしていないと、「やりのこし」が生まれ続ける状況は依然として残ります。

では、それにどう対応するのか。今回はそれについて考えてみます。

■積み増されるやり残し

たとえば一日に10個タスクが発生し、そのうち9個処理できるとしましょう。その日は一個のタスクが残り、次の日にタスクリストを作るときに、その残ったタスクを実行するかどうかを判断するとします。

その判断が「やる or 捨てる」という単純なものならば話は簡単です。やるならやるで、そうでないなら捨てるのですから、リスト内の数量的秩序が破綻することはありません。

しかし人間の判断とは微妙なものです。上記のような鋭いカミソリ的判断を下せるとは限りません。「今日や明日には手をつけないけども、かといってまったくやらないわけにはいかない。どこかの時点では手をつけたい」という曖昧な（あるいは中途半端な）思いを抱えることも起こりがちです。

そうしたとき、どうするのか？