Noratetsu Lab

動じないために。

2025/06/03

ブクログを「読むかもしれない本」の一覧として使う

 ブクログという読書状況管理サービスがかなり昔からある。私も十年以上前に使っていたが、環境の変化をきっかけに遠のいてしまっていた。
 そのブクログを、最近またアカウントを作り直して使い始めた。


 読んだ本を記録するため、ではなく、読むかもしれないし読まないかもしれない本をブックマークするためである。他にも同じ種のサービスはいろいろあるが、データをエクスポートできるという理由でブクログを選んだ。
 SNSを見たり新聞を眺めたりしていると本の情報が目に入る。そうしたらブクログに登録し、タグを使って何経由で知ったかを記録する。誰かがシェアしていたなら「by誰それ」というタグを作ってつける。ブックカタリストでやっていたなら「ブックカタリスト」というタグをつける。
 そうすると、誰かが良いと思った本が本棚にずらっと並ぶ。見ていると読んでみたいという気持ちも高まってくる。

 ここに「今まで読んだ本」を混ぜてはいけない。いや、混ぜたい人は混ぜていいが、私は混ざると嬉しくないので混ぜない。既に登録してある本を実際に読んだ時にわざわざ消すことはしないけれども、自分の読書ログのために使うのではないので、あくまで「これから読むかもしれない」ということに集中する。
 つまり未来に対してわくわくできる空間を作っていくのである。

 読んだ記録として使わないので、ブクログの機能は殆ど活用しないということになる。カテゴリも使わない。単に本を登録するという作業が簡単で、そして書影が綺麗に並ぶところがありがたいのでこの種のサービスを使っている。
 NotionやCosenseをブックマークレットと併せて使ってもいいのだが、どちらかというとそれらは実際に読んだ本、つまり自分の歴史の一部になっているもののために使うのが私はしっくり来るので、自分の人生と交わったかどうかを基準に汎用ツールとブクログとを使い分けている。
 

2025/06/02

【Dynalist】考え事を進める時に私が使っている記号

2025/05/31

2025年5月の振り返り

 今月の振り返り。

2025/05/30

階層付きマークダウンアウトライナーを作ろうとした

 一ヶ月以上前のことだが、新しい規格のアウトライナーを自分用に作ろうとしていた。結局没にしたが、最初はいいことを思いついたと思ったのでここに書いて供養する。

2025/05/29

内部処理の変更に伴うお知らせ/文章エディタとしてのDynalist

 基本的には見た目に変化はないことですが、サイトのデータの管理方法を大きく変えました。


 これまではDynalist上で書いてDynalistからAPIでデータを取得してサーバーサイドでサイト用データに変換していましたが、全てmdファイルにしてローカルに置き、そこからサイト用データを生成する形にしました。
 Dynalistの構造を利用して表現していた記法を機械的にMarkdownとHTMLに置き換えてmdファイルを生成しているため、一部表示が変化したり乱れたりしている箇所があり得ます。軽くチェックした限りでは概ね大丈夫だとは思いますが、リンクの置換ミスが稀にあったりするので、しばらく「あれ?」と思うような部分が残るかもしれません。
 お知らせは以上です。


 ここからは変更の経緯などを記録として書いていく。
 当初、自分の文章の公開方法はBloggerというサービスを利用してのブログだった。Bloggerはブログサービスとしては編集もしやすく昔から使っていたもので馴染みもあって気に入っていたが、やはりデータが自分の手元にないということが不便だった。記事を編集するとなればいちいちその記事の編集画面を開いて編集して保存してということをやらなければならないし、複数の記事について一括で置換する的な処理はできない。何もかも手動でやらなくてはならない。
 そこで全て自分の裁量でデータを扱えるように自分でサイトを作ることにして、現在はDeno Deployというサービスを使って公開している。記事データについては最終的にサイトを開いた時に読み込まれるJSONができていればいいので、どういう経路でそのJSONに至るかはなんでも構わない。今回の変更もJSONを生成する手前の話なので、サイト自体のコードはなんにも変わっていない。
 今の形式でエディタとして利用できる手段は「APIで自分のデータを自由に取得・編集できるアプリケーション」または「ローカルファイルを編集できるアプリケーション」ということになる。前者の例がDynalistやNotionで、後者の例がObsidianや一般的なテキストエディタである。

 Dynalistは文章エディタとして非常に優秀だ。それは「文章のアウトラインが作れるから」という意味ではない(それも重要な要素ではあるが、私にとってはさほど大事なことではない)。それ以上に、行単位で子要素を持てたりノート欄を持てたりすることによって、自分向けの情報も機械用の処理の指示も自由自在に文に付属させられることが大きなメリットである。
 たとえばMarkdownに専用の記法がない折りたたみなども、「この記号で始めたノードは子要素を中身としたdetails要素にせよ」ということを(コーディングの知識があれば)柔軟に定義できて、detailsタグなどを文中に記述する必要はない。自分が文章を書く上でそのような異物が混じらないことは重要だ。
 最終的に文章に反映させない、いわゆるコメントなどもノート欄や子要素で表現できる。加えて、没にする部分についてはプログラミングと同様の形でコメントアウトの記法も定義している。
 行単位でメタデータや構造を持てることによって、アイデアを思いつきさえすればなんでもできるのだ。

 ただしDynalistでは不自由な面もある。それがネットワークの作りにくさだ。
 Dynalistにもノードリンクという機能があるのでそれを使えば「この記事へのリンク」ということは表現できるが、サジェストを使おうとすると全てのノードが対象になってしまうがゆえにノイズだらけでまともに機能しない。ノードリンクについては以前書いたがノードリンクを活用し全てのノードに意味のあるアウトラインを作っていく、ノードリンクを機能させるには使い方に注意を払う必要がある。
 全てのデータが上から下に並んでいなければならないというのもネックだ。データが全て時系列のブログ的記事なら公開日順に並んでいればそれでいいのだが、例えばキーワード単位で作るデータ(当サイトでは「用語集」としている)については、順番に並ぶことに必然性がないので、自分の認識とDynalist上で表現されているデータの並びとが一致しない。
 それゆえに用語集部分だけ先にネットワーク型の管理方法に移転していたのだが、そうするとツールが別になるので記事とリンクが直接繋がらない。これまでどうしていたかというと、Dynalistのタグを用語集に含むキーワードと一致させることで、JSON生成時にサイト上でリンクになるよう処理を可能にしていた。サイトのデータを作るという意味ではそれでも良いのだが、自分の手元でリンクになっていないので作業が直感的にならないという問題があった。

 また、Dynalist(というかアウトライナー)に情報を蓄積させ続けるのが果たして妥当かということもある。Dynalistは仕組み上データベースであるし、検索機能が充実していることもあって主観的にもデータベースらしく使うことは不可能ではないが、しかしデータベースとしての活用が向いているかというととてもそうは言えない。無限に増え続けるタイプの情報を扱うなら他に相応しいものがある。

補足(クリックで開く)  以前Dynalistのデータベース化について書いたが(アウトライン型データベースとしてのDynalist)、それは今話していることと少しレイヤーの異なる話である。というのは、データベースと言ってもひたすらに情報を蓄積していく種のデータベースと、何かを表現するにあたってそれを構成するデータの集まりとして必要なデータベースとがあって(データベースというものに詳しい訳ではないのでふわっとした言い方になってしまうがご容赦願いたい)、前回は後者のためにデータベース然とした形式から解放され自由に文脈を添えられる有機的なデータベースを考えることが有効だという話をした。  サイトの記事データというのもある程度までの規模は「サイトを構成するためのデータの集まり」という性格が強かったが、やはり何百件も蓄積して更に今後も増え続けるとなると(既に800件近くある)、これらは単にサイトの構成のためのデータではなく自分の歴史と一体になった情報であり、データベースとしての性格も変わったと言える。  最初から増え続けるタイプのものだというのはわかっていたわけだから限界は予見できたはずのものだが、やってみなくては「向いてなさ」の形が見えてこなかった。  実際、今後もDynalistに蓄積させ続けるのも無理なことではない。もしデイブ・ワイナー氏のようにアプリケーション自体を自分で作っていてDynalistに不足している要素を自力で完全にカバーできるのであれば、アウトライナーという形態自体が欠点になることもない。アウトライナーであるというのは単にデータの表現形態のひとつに過ぎないからだ。  ただ現状、Dynalistのシステムでは何千件のような単位の膨大な件数を管理することに特段のアドバンテージはない。データの読み込みのタイミングからしても、何千ノード程度ならいいとしても一件が何十から何百のノードで構成され得るデータが何千件となるとかなり厳しい。画像を多く含めば通信量が嵩むし、ノード数が増えすぎると差が認識できる程度に挙動も重くなる。
 Dynalistのノードはどうとでも解釈して使えるという利点があると同時に、自力で解釈を加えないと特定の範囲を一件のデータとして扱えないという難点がある。個別のデータとして形が定まったならば、それはNotionやObsidianのようなデータベースらしく使えるツールの方が扱いやすいし、年月が経った後でも未来の自分が認識しやすい。  アウトライナーは情報を流動的に扱えるのが武器であり、基本的には「今ホットなもの」のための場であった方がよいと思う。過去のものになった情報、つまり情報として固定的になったものは、流動性の乏しさの代わりにデータとしての扱いに長けている種のツールを使った方が後々便利だろう。

 そのようなわけで、サイトのデータはmdファイル化し、Obsidianを用いて管理することにした。
 ただしDynalistで書くのが楽なので、Dynalistで初稿を書くというのは継続する。一通り書いたらプログラムでmdファイルに変換し、以降はmdファイルを編集する。
 書き終わったものの管理はObsidianを使えるmdファイルの方が楽だが、これから書くものはアウトライナーの方が良い。形が定まっていない曖昧な状態で置いておけるからだ。
 

2025/05/27

かつて一冊にまとめようとしたノートを反省する

 ノートは分けないで一冊にまとめよう、という話が流行った時期があった。


 その種の話は色々あったと思うが、私が影響を受けたのは以下の本だった気がする。

  • 中公竹義『100円ノート「超」メモ術』
  • 奥野宣之『情報は1冊のノートにまとめなさい』
  • 樋口健夫『図解 仕事ができる人のノート術』

 十数年前に書いていた大学ノートを読み返すと、これらの本から受け取ったメッセージを忠実に実行していたのがよくわかる。それ以前の私は無意味にノートを使い分けようとして失敗していたから、一続きの大学ノート群にどんどん書いていくというのは当時の私にとって画期的なことだった。
 書くことが楽になったから、当時は猛然とノートを消費していた。なんでも書いていたし、一冊終わるごとに振り返って書き方の改善点を考え次のノートをバージョンアップさせるというサイクルが気持ち良くて、ノートを埋められるものを探していたふしもある。
 読書メモも自分にしてはたくさん取っていた。数えてみたら、三ヶ月ほどで計120頁超の読書ノートを作っていた。その中に例えば梅棹忠夫の『知的生産の技術』の読書メモも含まれている。

 しかしである。書くにはよかったが、後年読み返してみて、このノートは残しておきたくないなと思った。
 その原因は「情報を一冊にまとめよう」という発想そのものにあったわけではない。なので例えば冒頭に紹介したような本のメッセージが誤っていたとかいうことではない。個々人の相性はあるにしても、これらはノート術として有効であると今でも言える。
 情報の混在でカオスになっているとかいうことが問題なのではなく――混沌への対応策はそれぞれのメソッドに含まれている――自分個人の話として、そもそも同居させてはならない情報があったことに問題がある。

 私が書き留めていた情報には、私の中で以下の種類があった(ということを今なら指摘できる)

  • 事実
  • 思い(気持ち、自己分析、仮説)=文脈に依存
  • アイデア(具体的なひらめき、案)=文脈に依存

 一冊にまとめようということをしたとき、それらを構成するのが全て「事実」なら、どれだけ混在していてもおそらく嫌な感じはなかった。いずれも情報として価値があり、それが散逸の可能性なく一箇所にまとまっているならありがたいことだ。
 しかし「思い」とか「アイデア」がその合間にごちゃごちゃと混ざっているとかなり雑然とした感じになる。反省の弁などが混ざっていようものなら、もはやそのノートは丸ごと捨ててしまいたい。
 自罰性のある記述や嫌なことを思い出す記述はそもそも残さない方がいいとして、ポジティブな内容であったとしても「思い」や「アイデア」はノイズに感じる。その理由は、その記述単体で見ても何の話をしているのか明瞭ではないというところにある。文脈に依存しているのである。そして全てを一冊にまとめていると、複数の文脈が入り乱れている状態なので、特定の文脈に基づいた記述を拾っていくというのがかなり難しい。ノートを一から全部読んで当時の自分の文脈を全て把握して辿っていくとかしないと記述の意味がわからない。
 もちろん後からそのように困ることのないように文脈自体を整理しつつ書くという工夫はあり得る。今ならそうする(例えばその工夫のひとつとして「あらすじノート」を先日紹介した)。しかし当時はやらなかったので、過去のノートに文脈を把握しやすくする仕組みはない。苦労して辿ってまで当時の記述の意味を蘇らせたいとは思わないので、ほとんどが今の自分に役立たない無駄な記録になってしまっている。
 ちなみにSNSに投稿したポストが後から読んでも概ね生きているのは、他の人にわかるように心がけて書いていることや、その時点の話題がリツイートなどによって自然と記録されていることによって、文脈を辿ることが容易だからであろう。

 文脈依存の情報がその後も生きるようにするには、とりあえず二つの工夫があり得ると思う。

  • 一冊にまとめるが、文脈を明示するタイミングを作る
  • 文脈に応じてノートを分ける

 文脈をその都度言葉にするのはかなり大変なので、「一冊にまとめる」ことの楽さがそれを上回るかどうかは微妙なところだ。
 文脈に応じてノート自体を分ければ、思いやアイデア自体が文脈を示すものになるので、わざわざ文脈を書き残そうとする必要はなくなる。ただし、自分はどういう文脈で考えているのかというのは自明のことではないし、どういう切り分け方でノートを分ければいいかを見極めることに苦労する可能性はある。
 とりあえず「事実」「思い」「アイデア」の三つのノートを作っていれば、それだけでもかなり整理されていたと思う。「思い」には常に複数の文脈があるが、それ以上は細かく分けなくてもいいかもしれない。
 最初に取り上げた本たちの中で、「事実」「アイデア」はいいとして「思い」をどう扱うよう書いていたか覚えていない。もしかしたら何か工夫について書いていたのかもしれない(書いていないかもしれない)。そもそもそういうのは想定していなかったかもしれない。
 私は日記を日記らしくつけることがないので、自分の思いというのはこのようなノートに書くことになる。しかし日記を別に用意するなら、思いは事実やアイデアから自然と切り離された状態で扱うことになったのだろうと思う。

 ここまでは「文脈がわからないから記録として意味をなさない」という問題の話だが、そのほかに、そもそも「思い」を物理的に残しておきたくないということがある。
 これは五年後楽しくなっているように記録をつけるで書いたことと重なるが、「思い」を後年振り返って読みたいかというと、私の場合はそのようには思わない。きちんと整えた文章は自分なりの作品であるから残したいが、メモとして書き留めただけのものは残っている必要がない。そして人に読まれる可能性が僅かにでもあることはかなり嫌な感じがする。なので書くならデジタルツールの方が良い。
 最近はそもそも紙に書くことが減ったのでこの点では当時のような問題は発生していない。

 紙のノートに書き残すという時、何が残っていてほしいかは人それぞれだろう。自分の思いこそモノとしてはっきり残しておきたいという人ももちろんいると思う。私はそうではなかったので、それが混じっていることがノート全体の価値を損なってしまった。
 とはいえ、当時のノートが無駄だったかというとそんなことはない。とにかく書きまくるということはある種セラピーとして働いて当時の私を救った。後先考えずに書いていったのも悪いことではない。
 残っていてほしいノートはどんなものかを考えた時にそれがマッチしなかったということは不幸だが、何もかも未熟で不安定だった時点で何十年も先に残しておきたいようなものを残せることを期待するほうがどうかとも思う。当時と比べて精神状態が比較的健康で人格的にも多少成長し、情報の扱いについても知見や経験を得た今だからこそ、将来残すものについてまともに考えられるようになったのだろう。
 過去に既に失敗していることを今になって繰り返すのはつまらないので反省はするとして、当時の自分を責めるつもりはない。

 ちなみに、昔のノートはスキャンしたり写真を撮ったりしてデジタル化した上で、特別残したい部分を除いて処分している。
 

2025/05/26

ノート裏表紙にはがせるラベルシールを貼ってインデックスを作る

2025/05/19

【Capacities】「今日以降やること」の扱いに用途を絞って使ってみる

2025/05/17

Capacitiesのマイオブジェクト定点観測(2025/05) 今日以降のやることに関わるものに限る

 Capacitiesに自分で定義しているオブジェクトタイプの話。今回は3月Capacitiesのマイオブジェクト定点観測(2025/03) 生活に関わるもの以外のオブジェクトの除去までの定義から変更した点について書きます。

2025/05/16

Obsidian日記:本腰を入れて整備し始めた

 年単位で昔にしばらく使っていたものの、なんでかプチフリーズが多発して使っていられなくなってやめてしまったObsidianを、また主力として採用することを検討し始めた。


 今までずっと使っていなかったわけではなく、限られた用途では使っていた。しかしそれは単に「mdファイルを扱うなら他を使うよりはObsidianだろう」という程度の位置づけだった。

 プラグインをあれこれ見て、自分に実際に必要な機能を備えていそうなものをインストールした。前から入れていたものも含めて現在インストールしてあるのは以下の26個。

  • 2Hop Links Plus
  • Advanced Tables
  • Big Calender
  • Calender
  • Commander
  • Dashboard navigator
  • Dataview
  • Dialogue
  • Excalidraw
  • Floating Search
  • Front Matter Title
  • Hover Editor
  • Iconize
  • Image Toolkit
  • Link Tree
  • Omnisearch
  • Open In New Tab
  • Outliner
  • Quick Explorer
  • Recent Files
  • Sets
  • Sticky Notes
  • Tag Wrangler
  • Templater
  • Zoom
  • Nest Map(自作プラグイン)

 数えてみたら思いのほか多い。これでも「面白そうなものを片っ端から入れた」というわけではないし、インストールしたものの自分の用途に合わないとか相性が悪かったものは除いてある。
 そしてCSSもあちこち弄った。まず自分の好みとして背景色はほぼ真っ白であってほしいので白くして、フォントサイズを下げて各所の余白を適度に詰めた。現状の見た目はこんな感じ。

画像

 サイドバーの配置も前まで適当だったがちゃんと考えて改めた。なお中央はExcalidraw。
 Capacitiesを気に入っているのでCapacitiesと同じ感じを再現できたらと思ったものの、各ページに設定した日付の扱いを同じようにする手段が今のところない気がするので、再現するには自分でプラグインを作る必要がありそうだ。
 今後どうしていくかはまだ検討中だが、いろいろな可能性は見えてきた感じがする。

管理人

アイコン画像

のらてつ Noratetsu

キーワード

このブログを検索

検索

ブログ アーカイブ

2025
2024
2023
2022
2021