2025年3月の振り返り
3月の振り返り。以下「今月」は3月のことを指す。
動じないために。
ナンバリングの数字が巻き戻っていますが、過去記事のタイトルを一部変更したことによるものです。
さて、今回は前の記事(Capacitiesのマイオブジェクト定点観測(2025/03) 生活に関わるもの以外のオブジェクトの除去)で触れたContainerオブジェクトについてです。
情報の扱いを考える上では、情報を置く場所、あるいは容れ物について考えることが不可避でしょう。仮に全ての情報をひとつのツールで扱ったとしても、そのツールの中にフォルダ的なものや内容ごとのトップページにあたるようなものがおそらくあり、それぞれが容れ物の役目を果たしていると思います。
この情報はあれに入れようと考える時、その容れ物に名前がついていると考えやすいです。意識しなくとも大抵識別のために何らかの名前はつけるものと思います。
そういった容れ物は、新たに作ったり解体したり統合したり意味合いを変えたり、様々な操作をして在り方がしばしば変化していきます。こうしようと思いつくとすぐ着手して変更を加えがちですが、その場その場でやっていると後から変遷を追えなくなります。そうすると前にやった失敗を数年後に繰り返すようなことも起こり得ます。
なので、容れ物自体の検討や記録をする場所があると便利です。少し前からContainerオブジェクトとしてCapacitiesに用意することにしました。現在作っているコレクションは以下の通りです。
結局今どこにどんな場所を作っているのかというのがこのオブジェクトの一覧を見れば一目瞭然です。色々なところに情報が分散していたとしても、リストによって把握できるならばそれほど混乱しません。Containerオブジェクトを見ればいいわけなので、情報の所在を思い出すために認知資源を消費するということがなくなります。
また、「こうした方がいいんじゃないか」と思った時に、本当にそれが妥当かを検討することが簡単になります。検討の場がページとして用意されていること、今運用している全ての場を把握できること、リンクによって過去の記述の参照が可能になること、これらによって検討をスムーズに進められます。
このようにContainerオブジェクトを用意したことで、情報の整理方法を考えるのが随分楽になりました。
Capacitiesに自分で定義しているオブジェクトタイプの話。今回は去年12月(Capacitiesのマイオブジェクト定点観測(2024/12))までの定義から変更した点について書きます。
営業妨害という言葉がある。
真面目な文脈では、実際に相手の営業を妨げて損失を与えるような場合に言われる。
人気商売の人々の戯れでは、ワルっぽいキャラで売っている人について「本当はいい子」「実はすごく真面目」みたいな人間性の良さを暴露することを、冗談めかして「営業妨害だ!」と言うことがしばしばある。
基本的に「商売」の文脈で使われる言葉だから、書き物の世界ではあまり聞かない言葉のように思う。営業というのは一応営利目的の事業や売り込みのことだから、商業作家以外の書き物を営業と言うのは馴染まないということはある。しかし最終的にいくらかの利益を得ることに繋がるかもしれないなら書き物も広義の営業と言って良い気がする。そしてそれを邪魔する行為は巷に溢れている。この場合は本当に妨げる方の営業妨害。
誤解した状態で論じることで、元の文を書いた人が恰もそういう文を書いたかのように見せかける、というのは、意図的であれ意図しないものであれ営業妨害だろう。元の文章を読みに行かないで難癖だけ読んで鵜呑みにする人もいるし、読みに行ったとしても「この文はおかしいらしい」という前提を持っていれば伝わるものも伝わらない。
これは「ネガティブな評価は営業妨害である」という話ではない。批判はあって然るべき。でも曲解を吹聴するのは批判とは言えない。建設的な理由が何も無くただ印象を悪くするようなことは単なる営業妨害でしかないように思う。
最近、Dynalistでノードのリンクを活用するようになった。
Dynalistでは全てのノードにURLが存在し、別のノードにそのURLを貼るとノード間で紐づけられバックリンクも表示してくれる。貼り方はURLだけでもいいしMarkdown形式でもいい。URLのみ貼った場合は自動的にリンク先のノードの本文が表示されるようになっている。
また、行頭または半角スペースの後でダブルブラケットを入力するとリンクのサジェストが表示される。文字を打っていくと候補が絞られていく。範囲はアーカイブしていない全ファイルで、編集中のファイル内のノードが優先されるが他のファイルのノードも候補に並ぶ。 候補のノードがどこに存在するものかというのは、パンくずリストも一緒に表示されるので判別できる。
なお、サジェストの絞り込みに反映されるのは本文部分のみで、ノート欄の内容は候補のピックアップに関係しない。
サジェストとバックリンク表示機能があるわけなので、Dynalistをネットワーク型のツールとして扱うことも機能的には可能である。しかしながら、推測するにノードリンクを多用している人はそういないような気がしている。なぜなら、普通に使っていたらノードのリンクをあちこち張り巡らしたくなるような使い方にはおそらくならないからだ。
今Dynalistを使っている人は実際にダブルブラケットと何か文字を入力してみてほしい。そうでない人もちょっと想像しただけでわかると思うが、存在している全てのノードが対象になってしまうとなると、サジェストはおそろしく雑然としたものになるだろう。ノードごとに粒度はばらばらだし、そもそもアウトライナーというのは文脈の可視化やコントロールのためのエディタ、つまり文脈エディタとでも言うべきものであり、周辺のノードがわからなければそのノードの意味は見えてこない場合が多い。
ノードのリンクを貼りたい、つまり「あのノード」と指し示したいと思うようなノードというのはそう多くはない。自分の中でそういう重さのノードかもっと軽いノードかというイメージを持っていても、ツールの側はそれを察してくれはしないので、気を使わなければサジェスト候補は各々の文脈でしか意味を持たない細かいノードで埋め尽くされ、まともに機能しない。
じゃあどうするか。気を使って利用すればいいのである。ノードリンクを活用することを前提としたアウトラインづくりを考えてみる。
まずは普通に自由に書いていく。例えばこんなアウトラインができたとしよう。(例は昔Scrapboxに書いた内容を一部変えたもの。)
ノードリンクのサジェストがどうなってほしいかを念頭にこのように整理する癖をつけると、アウトラインの各ノードはそれ単体で明瞭な意味を示した、謂わばアトミックなものになる。そうすると結局今まで何を考えてどんな結論を出したのかもわかりやすい。ノードひとつひとつが財産になっていく。
考えた結果はちゃんとまとめよう、という心がけを持とうとしても、どういう状態になっていればOKなのかがはっきりしていなければ努め続けるのは難しい。しかし「サジェストに出てきた時に納得できる粒度」という尺度があれば、それを満たしていればまとめは完了したと言えるし、そうなっていないものにはもやもやと不快感を覚えるのでもうちょっとどうにかしようと思うことができる。心がけの力ではなく、収まりの悪さへの苛立ちによって整理を進めていくわけである。
なお、冒頭に書いたようにサジェストの範囲はアーカイブしていないファイルに限られる。アウトライナーを使って扱いたい全ての内容についてこのような整理を目指す必要は全くなく、ノードリンクを使いたい領域以外はアーカイブしてしまえばいい。アーカイブ設定は全体検索にも影響が出ることには注意が必要だが、個人的には全体を横断して検索したいことはほとんどないのでアーカイブ設定で支障を感じたことはない。設定のオンオフは簡単なので必要が生じたら解除すればいいだろう。
リンクの貼り方にはURLそのままとMarkdown形式とがあると最初に書いた。URLだけを貼った場合には、リンク先の内容を変更した場合にそれが常に表示に反映されるという利点がある。そして同じ文面をあちこちに書くことにならないので、検索やサジェストのノイズにもならない。
となれば、Markdown形式は表示を意図的に変更したい場合に使えばよいと言える。リンク元が何十字かの文になっていたとしても、それを数文字で示して文中に組み込むということもできる。その都度エイリアスを生み出せるようなものだ。
ネットワーク型ツールではリンク元のタイトルそのままでしか扱えないことも多く、その場合文中に馴染ませるためにタイトル付けに工夫が必要になったりするが、その都度適当に言い表せばいいとなればタイトル付けに悩むこともない。アウトラインの各ノードにタイトルは不要である。
ただしこの場合、どのノードを指してその表現にしているのかが自分でわからなくなることもある。リンクをクリックすれば確認できるが、いちいち飛ばなくてもわかったほうが便利ではある。この課題について、私はChrome拡張機能を作りスクリプトを走らせてマウスオーバーでリンク元の本文とパンくずリストを表示できるようにしているのだが、その話は別の機会にするかもしれない(しないかもしれない)。
ノードリンクは便利な機能だが、ひとつ問題を挙げるならば、デフォルトの状態だとノードリンクはちょっと見づらいということがある。
.node-inline-item:not(.node-inline-image) {
display: inline;
border: unset;
background-color: unset;
color: #384d98;
font-size: inherit !important;
text-overflow: unset !important;
white-space: normal !important;
text-decoration: underline dotted;
&:before {
display: none;
}
}
こうすると本文中に混ざっていても違和感はない。既出の概念についてはリンクになっていた方が嬉しいという感覚も生まれ、一層リンクを活用したくなる。
CSS書き換えはDynalist自体に備わっている機能ではなく裏技的なものである。Webブラウザでしか実行できないという難点もあるが、見た目を変えるだけで使用感が劇的に向上するということはよくあるので、ツールの機能をフル活用するために試してみる価値はある。(書き方を細かく解説するのはちょっと手間がかかりすぎるので割愛する。)
最後に。重大な注意点として、ノードを別のファイルにMove to...で移動してしまうとそこでリンクが切れるということがある。ファイル一覧にドラッグして移動した場合には更新されるようだが、ありとあらゆるパターンを試して確認してはいない。動かし方によってリンクの追跡がされたりされなかったりということになるので、ファイルの構成に迷っている間はあまり多用しない方がよいかもしれない。
PCの中にはフォルダというものがたくさんある。大抵は多重に階層を作っている。フォルダを作る基準やその粒度に万人共通の規格はなく、フィーリングで多種多様なフォルダが無数に生成されていく。
フォルダを作った時というのは自分なりに根拠があってそうするのだが、使用頻度があまり高くないものだと月日の経過とともに納得感が薄れることもあるし、そもそもどういうつもりでその作り方をしたのかを忘れる場合もある。
ところで、GitHubにリポジトリを作ろうとすると「README.md」の作成を勧められる。そこに書いた記述を元にGitHub上の表示も自動で生成されるし、公開リポジトリなら訪問者に向けた説明が必要なので「README.md」を用意するのは半ば当たり前のことだろう。
あとはアプリケーションをダウンロードするとそのフォルダ内には大抵「readme.txt」が入っている。アプリケーションの情報はそこに書いてあるので、インストール手順などに困ることはほとんどない。
こんな感じでreadmeというのはよく見かけるものである。けれども基本的には自分以外の誰かに何かを説明する時に書くものであって、個人的なファイル管理の中で登場することはなかなかない。
自分の作ったファイルやフォルダについて時間が経った時に曖昧になっていくのは、実質的に過去の自分と未来の自分が他人だからである。なので未来で困りたくなければ未来の自分に向けて説明を残しておく必要がある。
となると、未来の自分への手紙として用意すべきはこのreadmeということになるんじゃあないか。
今までは、例えばアウトライナーなどに、今フォルダはこういう構成にしていてそれぞれこういう意味があって、と書いておくことはあったのだが、そのアウトライナーと現場のフォルダとが直接リンクしていないので、現場の状況が変わった時に記録を更新するということが遵守されなかった。変遷の記録を一段階飛ばしたりするともう面倒くさい。
しかしフォルダに「README.md」が存在していれば、状況が変化した時にもそのファイルが目に入るので、ここに書いておこうという流れが生まれる。
例えばこんな感じ。
もちろん、これはいつまでもフォルダの構成に迷走しているがゆえに生じる必要ということでもあるので、そんなん要らないよ自分で作ったフォルダは意味が明瞭だよという人は多いだろう。PCというものを使い始めていったい何年経っていると思ってるんだ、というのは自分でも思うことだ。
まあでも、そんなことはどうでもよく、とりあえず「メタな情報」の置き場所にシンプルな名前がついて今ハッピーな気分でいる。
前まで「ライフ・アウトライン日記」という題にしていたけれど、構造が変わり「エッセンシャル・アウトライン」と呼ぶことにしたのでタイトルも変更。しかし「エッセンシャル・アウトライン」は長いので、「EO日記」とでもするかと思った。一見して何のことかわからないのが微妙だが、まあ仕方がない。
前々から置き場所が曖昧になっていたものとして、ネットでちょっとやった心理テストや性格診断のスクリーンショットというのがある。正直ぜんぜん重視していないし見返すこともまずないので大事に保管しておかなくてもいいものなのだが、せっかく色々質問に答えてやったものなのでなんとなーく取っておきたい気持ちもあって、適当な場所にフォルダを用意して画像を保存していた。
しかし、位置づけが曖昧なものなのでそこにあることに必然性がなく、常々邪魔に感じていた。それでもばっさり処分してしまうのは気が引けて、納得できる場所があるならそこにきちっと収めたい。
昨日ふと思いついたのが、ローカルファイルとして扱うのをやめてDynalist上のマイライフ・アウトラインに組み込んでしまうことだ。マイライフ・アウトラインとは、ファイル名としては「Life」と名付け、直下に「LIFE-○○」の類を四つ並べたものである。
ただし、「LIFE-○○」のどれかに入れるのではなく、それらとは別に、直下に場所を作ることにした。
今のエッセンシャル・アウトラインの形式にする前は、「LIFE-BE」「LIFE-AS」をそれぞれ個別のファイルにしていたので、「LIFE-○○の隣」という場所は存在していなかった。新たにファイルを作って同じフォルダ内に入れれば隣ではあるが、やはりファイルが別になると別個のものという印象が強くなり、緩くまとめて扱っているような気分にはあまりならない。
Dynalistのようにファイルとフォルダの概念があると、どこまでひとつのファイルにまとめてどこから個別にするかという判断が生じるが、明確な基準がないので迷ってしまうことがある。組み換えは簡単なのでとりあえず試してみるのがいいが、「後から仲間が増えるかも」と思うようなものはひとつのファイルにまとめて大きく扱った方が上手くいきやすいというのはあるのだろう。