Noratetsu Lab

　1月の振り返りをやったばかりだが今月ももう終わりなのでまた振り返り。

　メールを読む時、メール画面の横でテキストエディタを開いて要点を書き出しながら返信を書くという形をとっていた。そう長くなければ返信画面に直接書いていた。

　Dynalistはアウトライナーだが、私にとってはデータベースである。アウトライナーとして使えるデータベース、くらいの言い方をしてもいいかもしれない。

　もちろん普通にWebブラウザやスマホアプリで操作する分にはただの（と言うのもおかしいが）アウトライナーである。Dynalistがデータベースであるというのは、アウトラインの形をトップダウンできちっと整備してデータベースとして使うというような意味ではない。発想としてはむしろ全く逆である。

APIで取得できるデータはアウトライン構造に縛られない

　DynalistはAPIを提供しており、プログラムを通じて自分のデータを参照したり編集したりすることができる。あるファイルのノード情報を取得する場合、そのファイルに含まれるノードがフラットな配列として取り出される。以下の型のオブジェクトがひとつの容れ物にわっと入っている状態である。

{  
    id: string,  
    content: string, // 本文  
    note: string, // ノート欄  
    checked?: boolean,  
    checkbox?: boolean,  
    color?: number, // 0~6  
    heading?: number, // 0~3  
    created: number,  
    modified: number,  
    collapsed?: boolean,  
    children: string[], // idの配列  
}  

　アウトライン構造はchildrenプロパティに子ノードのidが列挙されることで表現されている。なのでこのidに一致するデータを探せばそれが子ノードだと分かる。しかしデータ自体はアウトライン構造にはなっていないわけである。ルート直下のノードも10層インデントしているノードもデータ上は隣に並ぶ。
　つまり、そのノードがどこにあろうが関係なく扱えるということになる。例えば色を赤に設定したものに何らかの意味付けをするとしたら、それぞれてんでばらばらな深さに存在していてもcolorプロパティによって同じ種類のデータとしてまとめて取り出せる。色なり見出しなりノート欄なりを使ってそのノードの種類を自分で定義すれば、ノードの種類を示すためにアウトライン構造を使う必要はなくなる。
　アプリケーション上のビューでは全てのノードがアウトライン構造のどこかに位置づけられる必要があっても、それぞれのノードのデータはアウトライン構造とは無関係に活用することが可能なわけである。
　このことにより私の中でDynalistの使用感は大きく変化した。APIが使えなかった頃は分類的な視点でアウトライン構造を用いていたが、そのように形式的なアウトラインを作る必要がないとなれば、完全に「気分」で自由にノードを配置できる。これとこれが近い方が便利だ、その方が気分が良い、そういう理由で配置することに違和感を覚えなくなった。
　もちろんカオスな方が良いということではない。自分が納得する基準で適切に配置させられるのがアウトライナーを使う理由なのだから、自分なりに整えていくことにはなる。そこに自分の気持ちとは無関係な形式的構造を混入させずに済むというのがAPI活用のポイントである。

活用例①　サイト記事のデータベース

　ここまでの話だと「データベース」感は薄い気がするので、データベースとしての活用の話をもう少し具体的にする必要があるだろう。単に特定の条件で一度にピックアップできるというだけなら検索機能を使えば済んでしまう。
　このサイトの記事はDynalistに書いてAPIを通じてサイト用のデータを生成している、という話は既に何度か書いている。それはつまり、Dynalistのひとつのファイルが記事のデータベースになっているということだ。
　特定の書式（例えば色が赤でノート欄に日時が書いてあるなど）に従って書いているノードをタイトル行、その子項目を本文と解釈することで、それをひとまとまりの記事データとみなす。

　判定にはアウトライン上の位置は全く関係ないので、書式に従ってさえいればどこにあってもいい。データの並び替えは後で日付順にすればいいのだから、アウトラインの中では時系列がめちゃくちゃでも別に構わない（もちろん敢えて乱す必要はない）。
　その記事が、サイトの中で、あるいは私の考えの中でどういう位置づけにあるのか、アウトライン操作によって整理していきたいこともある。そんな時は並べ替えたり階層を上げ下げしたり自由にぐりぐり動かせばよい。どう動かしたって記事のデータベースとしては何も影響を受けない。

活用例②　ブックマークのデータベース

　インターネットを使っていると、日々数多のページにアクセスすることになる。有用なものがあればリンクを保存しておきたいと思う。便利なツールのURL、興味深い記事のURL、誰かのサイトのURL、後でチェックしたいもののURL、等々、さまざまな種類や状態の情報を保存しておくことになる。
　全てをブラウザのブックマークに入れるとごちゃつきに耐えられなくなるのだが、これらを如何にもなデータベースで管理するとなると、保存の気軽さや頻度の多さとデータベースというものの仰々しさが大抵見合わない。とても手入れはしていられないし、テーブル形式のぴしっとした感じの割にそれほど見やすいわけでもなかったりする。
　とりあえずDynalistにファイルをひとつ作り、そこに全部突っ込んでしまうことにした。最初は「検索すればいい」というつもりでDynalistを選んだのだが、ある時「ほかにビューワを作ってDynalistをデータベースとして使えばいいのではないか」と思いついた。作ったブックマークのビューワがこれ。（画像の内容はもちろんごく一部。）

　ブックマーク用のファイル内にある色付きのノードをブックマークとして解釈し、その色をそのまま背景色にしている。色は「サイト」「ツール」「記事」のような意味合いを表している。分類はノードのノート欄につけたタグで判別していて、アウトライン上の位置とは関係がない^[1]。タグがないものが「未分類」になっている。
　大量に保存したリンクの中でビューワに表示したいノードにちょちょっと色をつけるだけで、あとはプログラムがいい感じにやってくれる。アウトライン上は汚部屋みたいにとっ散らかっていたとしても、ビューワはさも手入れの行き届いたデータベースがあるかのように美しく表示してくれるわけである。
　アウトラインも汚くはない方がいいが、そっちはそっちで別の基準で操作して整えていけばいい。

外からデータを編集する

　ここまではDynalist上で書き込んだ情報を取得・解釈して活用することについて記してきた。しかしDynalist APIでできることは情報の取得だけではない。データの編集も可能である。
　不可逆的な操作になるのであまり軽率に試していいものではないが、APIを使えばファイルやフォルダ、ノードの作成・編集・削除ができる。Dynalistを開いていなくてもDynalistのデータにアクセスして弄れるのだ。
　例えば、あるファイルの中のノードについて一括で置換したい何かがあるという時に、普通はひとつひとつ手作業でやるしかない気がするが、APIを使えばプログラムで処理できる。ルールを前もってきっちり決めなくても後で軌道修正できることになり、大規模な何かをやるにしてもあまり構えずにやれるようになる。
　あるいは、何かのページを見ていてリンクを保存したいとなった時に、自作のChrome拡張機能にDynalist APIを使った処理を実装しておけば右クリックメニューから直接Dynalistの特定の場所に送信するみたいなこともできる。私はブックマーク、記事の本文、Twitter（X）のポスト、YouTubeの情報などをそれぞれ然るべき場所に送れるようにしている。
　こうするといよいよDynalistがデータベースらしくなってくる。Dynalist上での操作より外から操作する方が多いファイルというのもあり得るし、アウトラインの形で見たい時だけDynalistを開くという使い方も考えられる。アウトラインの表示を自分で作るのは割と面倒くさいので、データのアウトライン化を簡単に実現してくれる手段としてDynalistを利用するわけである。

見出し、色、ノート欄の存在意義

　このようにしばしばアウトライナーとしての在り方から逸脱した使い方をしているが、もちろんDynalistのファイルおよびノードを全てデータベースとみなして使っているというわけではない。普通のアウトライナーとしてアウトラインを考えることにも使っているし、その方が当たり前に多い。しかしそれらはいつでもデータベースとして解釈して活用することが可能である。
　Dynalistの見出し、色、ノート欄は最初の頃はさっぱり上手く使えなかった。検索での絞り込みにそれらを使うことはできるが、結局のところ当時の自分にとっては見た目の問題でしかなかったからだ。何色をどういう意味で使うかに必然性はないし、6色もあるが6色しかないということも活用を難しくしている。
　しかしながら、プログラムでの判定にそれらを活用できるとなると、急にそれらが便利なものに変身した。全てをノードの本文部分に書かなくてはならないとなれば、私自身には必要のない機械用のデータが場所を取って見ていて嫌になってくる。なのでメタデータを付与できる手段がほかに色々あるのはとてもありがたいことなのだ。
　今となっては色設定とノート欄は必要不可欠である。色付けに必然性が生まれたことによって使うタイミングに迷うことはなくなり、また「使いこなせてない」という気分もなくなった。

　アウトライナーは全ての情報をアウトライン上に位置づける。その特徴は私たちの理解を助けてくれる一方で、情報が位置に縛られるという欠点にもなる。しかしDynalistには別の切り口で情報を扱う手立てがあり、工夫次第でデータを如何ようにも活用することができる。
　その意味で、私はDynalistを単なるアウトライナーではなく「アウトライン型データベース」だなと思って使っている。

---

1. プログラミングを始めた頃はアウトラインの位置を基準にしたブックマークビューワを作っていたが、手入れが面倒になってしまった。 ↩︎

　ここのところデジタルのメモの整理を大規模に進めている。

　　

これまでの様子

　なかなかアプリケーションに納得できずあっちこっちを渡り歩いてきたので、色々なところに色々な形式で散らばっていた。少し前にエクスポートデータの整頓は済ませていたので一応おおよそ一箇所に集まってはいたが、ほとんどがそれぞれの形式でエクスポートしたままになっているのでひとまとめに扱える状態ではなかった。
　大体はテキストエディタで開けば見れなくはないものだが、やはり専用のビューがないと見づらいし、結局は死蔵になってしまっていた。見づらいというだけで見なくなってそれで大して不都合を感じないのだから、その程度のものと言えばそれまでだが、やはりその時その時は一生懸命考えたようなことがたくさんあるし、日記の類を確認できなくなるとその期間が空白だったかのような気持ちにもなってしまうので、いつでも確認できる状態にして安心したいと前から思っていた。
　一応ある程度のコーディング能力は獲得しているのでデータの加工はもう少し前から可能だったわけだが、問題は「どこに集めるか」だ。これだと思うものがなかなかなく、それまでの放浪の経験から「このアプリケーションも結局途中で嫌になっちゃうんじゃないか」という予感があってどこにも集められずにいた。

Dynalistへの認識の変化

　これまでに何度も書いているけれど、最近はデジタルノートツールについてはCapacities＋Dynalistという形で安定している。自分が混乱しない枠組み作りもできて、どの情報についても「これはここだな」とあるべき場所を迷いなく判定できるようになった。
　特にDynalistの位置づけが定まったのが大きいが、実のところ最も重要なのはCapacitiesとの棲み分け方やアウトライナーというものの理解の進み方ではない。やや大きいテーマなので別途記事を書くけれども、Dynalistが私にとってこれほど必要不可欠になったのは以下の理由がある。

• APIがあること
• ノート欄があること
• WebアプリなのでChrome拡張機能で干渉できること

　これらは「アウトライナーの特徴」ではない。Dynalistがたまたま備えている仕組み・特徴であって、私がDynalistを使ってやっていることをアウトライナーの良さとして語ることはできない。
　Dynalistを使い始めたのはそれなりに昔のことだが、その当時はプログラミングのプの字もわからずAPIだの拡張機能開発だのはすごいプログラマのためのものと思っていて、ノート欄については存在意義がわからなかった。ノート欄にごてごてと書いたらそのノードを操作しづらくなるからだ。なので今感じているような自由というのは昔は想像もできなかったし、そのために一時はDynalistから離れることにもなった。
　かつては「紙に書いたら動かせないが、デジタルなら動かせる」程度にしかDynalistの良さをわかっていなかったのが、今は「各ノードのデータは自由自在に利用できる」という認識を強く持ち、その変化によって、Dynalistを情報の置き場として捉えることに納得できるようになった。

実行

　そのような前提のもと、これまでに発生した文字情報を全てまとめてしまう場としてDynalistを使ってもいいんじゃないかと思えるようになり、ここ半月ばかりでそれを実行に移した。
　各ツールのエクスポートデータの形式に合わせてそれぞれOPMLファイルを生成するコードを書き、そのOPMLをDynalist上でインポートして取り込んでいった。XMLの知識がまだあまりないために謎のエラーに苦しめられたが、どのデータについてもどうにかOPMLに変換できた。
　インポートしたツール類は以下のものたちだ。

• Diaro
• UniversalDiary
• POPdiary
• Clipto
• ミミノート
• XTMemo
• CatMemoNote
• ハルナアウトライン 18ファイル
• Transno
• Logseq
• Obsidian 4Vault
• Cosense（Scrapbox）9プロジェクト
• 階層付きテキストファイル 2ファイル
• 自作ツール 4種

　一部は既に自作ツールに取り込んであったものなので、これら全種類のコードを書いたわけではない。データの出自を辿るとこれらのものが集約されたことになる（厳密にはもっと多い気がする）。
　これだけの散らかり具合ではデータの活用も何もあったもんじゃないが、ようやくひとつの規格で統一することができ、探し出すのも極めて容易になった。JSONなどに対してただテキスト検索しても結果は見づらいが、Dynalistのノード検索ならとても視認性が良い。
　一番スッキリしたのは日記類の集約だ。ツールを乗り換える度に日記の場が移ってしまい、データの加工技術もなかった時は引っ越しは容易でなく（そもそも不可能なこともある）、散らばるだけ散らばった状態になっていた。今回の整理で2014年頃から2024年8月までのほとんどがひとつのアウトラインに集まった。（2024年8月以降はCapacitiesにある。）

　デジタルツールに書き留めた日記やメモの類がこのように一箇所に集まったことは未だ嘗てない。なので私の中では人生史上で割とすごい出来事である。

• 記録のジレンマをどのように乗り越えるか？ - by tks - トンネルChannel
• じんわりと温かい嬉しさ - by 倉下忠憲@rashita2 - トンネルChannel
• ツールのスナップショットを残す - by 倉下忠憲@rashita2 - トンネルChannel

tksさんと倉下さんのこちらの投稿を読んでいてひとつ思ったのが、「写真とスクリーンショットはなんぼあってもいいですからね」ということです。

普段写真をたくさん撮る人というのは少なくないと思います。しかしそのような人でも、「ありとあらゆるもの」を撮っているかというと、おそらくそうでもないでしょう。風景や植物、食べたものなど「心が動いたもの」については、写真に撮っておこう！という気持ちが生まれてうきうきとシャッターを押すものですが、淡々と記録するための写真は前もってこのタイミングで撮ると決めておかないとなかなか撮らないように思います。

何事も無目的に機械的にやると後でノイズになり、もちろん写真やスクリーンショットも例外ではありません。誰かと会ったり旅行に行ったりイベントに参加したりするたびに写真を大量に撮るけれど…というケースはよく耳にします。実際の光景を自分の目でまともに見ないで終わったという反省が生まれることもあるでしょう。
ですが、「記録」のための写真やスクリーンショットを「多すぎて雑然として困る」というほど残すことはまずない気がします。撮っておけばよかったと思うことはあっても、こんなに撮るんじゃなかったと思ったことは今のところありません。
撮り過ぎよりも「何の記録か」がわからなくなることが問題で、それは数の多さによるものではないでしょう。「撮影する」という動作が完了した時点で用が済んだ気になって放置しがちですが、写真が記録として成り立つための手入れはどうしても必要です。

基本はやはり文字情報として日記や日誌に残し、プラスアルファとして写真やスクリーンショットを撮っておくというのがよいでしょう。写真を撮ったからいいや、という判断は後から困る可能性があります。
しかし写真もスクリーンショットも極めて簡単に撮れる時代になっているのですから、全てをどうにか言語化して文字で記録しようと頑張らなくてもいいわけです。そういう時代になってから既にかなりの年月が経っており、画像での記録がとっくに当たり前になっている人は普通にいると思いますが、私は今のところそこまで記録としての撮影が日常のものにはなっていません。「あ、撮っておけば楽か」とたまたま思い至ったら撮る、という状態です。
なので、記録のジレンマを乗り越えるためにしろ、嬉しさを増やすためにしろ、ツールの様子の変遷を歴史化するためにしろ、その前提として写真やスクリーンショットを頻繁に撮ることを習慣にしたいなと思いました。

　用語集の更新をしようと思って自分の記事を遡って読み返していて、昨年末に「今年のはじめにやっていた月間振り返りを来年もやっていこう」という旨を書いていたのを見つけ、見事に忘却していたことに気づいた。

　忘れることはないと思っていたことだったので、すっかり忘れ去っていたことにちょっとした衝撃を受けた。月が替わる時に思い出さなかったことにびっくり。

　もう二月も下旬なので二ヶ月分まとめてやるかと思ったけれど、せっかく細かく記録もつけているし一月分は一月分でやろうと思う。以下「今月」は一月のことを指す。
　今年は振り返るポイントをわかりやすくして定点観測として意味のある形式でやっていこうと思う。

今月の投稿

1. 2025年
2. 自分に定着させるために記事にする
3. Capacitiesでのプロジェクトの扱いを考える
4. 忘却に伴う恐怖／私が欲しい第二の脳
5. 苦手なことはどこに整理したらいい？（トンネルChannel）
6. DoMA式とCapacities
7. タイプライターとワープロの思い出
8. 苦手要素への対処自体をプロジェクト化しない／ライフ・アウトラインの拡張（トンネルChannel）
9. ライフ・アウトライン日記: 動かない事実を扱う領域の追加
10. Capacitiesで日本語での全文検索が機能するようになりました（多分）
11. ライフ・アウトライン日記: あり得る未来を考える領域の追加

　Capacitiesとライフ・アウトラインの話がほとんどだったが、その他のものも含めて全体的にいずれも自分にとって重要な点を含んだ内容になったように思う。

今月の情報整理

　今月の大きい変化は、ライフ・アウトラインの改革、四つのエッセンシャル・アウトラインの整頓と整備を進めたことだ。これによって日々発生する情報の居場所がより明確になり、どこに記録するのだったかを自分の記憶力に頼って探すみたいなこともほぼなくなった。
　その他にも細かい整理をあれこれ進めた。後回しになっていたGmailのアーカイブ整理をしたり、ブラウザのブックマーク類の整理方法を変えて簡単にしたり、久々にFeedlyを整えたり、このサイトの用語集のデータ管理をCosenseからObsidianに変えたり。
　ずっとちょっともやもやしていたもの、の類をガンガン整理整頓し、それも表面上スッキリするためにとりあえず片付けるという形ではなく、多分この先もこれで納得していられるだろうと思える形に収めていっている。その場しのぎでやるとその場しのぎであることを自分でわかっているから後で結局もやもやするのだが、今の感じだとおそらくそうならずに済むだろうと思う。

今月のプログラミング

　今月はDynalist APIの活用の幅を広げるようなアイデアをいくつか思いついた月だった。
　半端に言及するのも微妙なのでそのうち記事を書くが、まずブックマーク管理に使うようになった。Dynalistにぺたぺたリンクを貼り、そのデータをAPIで取得して必要な分を加工してDeno DeployでデプロイしたHTMLで表示するようにした。Dynalist上ではそんなに綺麗にわかりやすく整える必要がなく、大量のブックマークを雑に収集・管理できるようになった。
　また、DynalistのChrome拡張機能として公開されているもののように、開いているページの情報をDynalistに送信する機能を自作のChrome拡張機能に組み込んだ。Markdown形式のリンクを送信できるほか、記事の本文部分をMarkdown書式で取得してノート欄に貼りつける形で送信可能にした。記事のクリップはこれで済むようになった。（つい先日感動したObsidian Web Clipperは早くもお役御免になってしまった。）
　あとは用語集のデータの拠点をCosenseからObsidianに移すにあたり、CosenseのJSONからmdファイルに変換するコード、mdファイルからサイト用のJSONに変換するコードがそれぞれ必要になったのでそれを書いた。その程度のコードはあまり苦労なく書けるようになったので移転は簡単に済んだ。

今月のノートフロー

　情報の居場所のイメージは四つのエッセンシャル・アウトラインと四つのエリアにまとめられるが、具体的なツールを基準に整理するとこんな感じ。

• Capacities
  • タスク、プロジェクト、日誌
  • 好きなもの、思い出
  • 知識類全般
• Dynalist
  • 執筆拠点
  • 人間・社会についての考え事
  • Webクリップ
• SoulLinkMap
  • 読書メモ
  • （追加ペースは既に鈍っているがまだ移転はしていない）
• Obsidian
  • Noratetsu Houseの用語集データ管理
  • （✕Webクリップは廃止）
• B5Wリングノート
  • 単発の調べ物類
• A5綴じノート
  • 雑記帳
• バイブルサイズ6穴システム手帳
  • 参照用

今年の目標の進捗と再検討

　今年の目標とそれぞれの状況はこんな感じ。

• デジタルデータおよび紙類の整理
  • 今月は紙類の整理はやっていないがデジタルデータはかなり整理が進んだ。
  • まだ途中なので引き続きやっていく。
• 二度手間撲滅
  • 本当にその場所でその手順でやることにしていいのか、ということをかなり綿密に考えるようになったと思う。
  • 意識する習慣が付き始めたかなというくらいの段階なので引き続きやっていく。
• 概念やシステムの明確化と各媒体に合った発表
  • ライフ・アウトラインの自分用構造改革およびエッセンシャル・アウトラインの整備は大きな一歩。
  • 他にも明確にしたいものがある。また、発表は翌月以降。
• どうでもよいことはどうでもよいとする
  • ある程度心がけられたような気はする。しかしまだ「重要ではない他者の適当な言葉」を引きずることがなくはないので、これからも念じ続ける必要がある。

　　いずれも前進したと思う。目標に変更はなし。そのまま続けていく。
　

　タスク管理は何のためにやるのか、というお話がうちあわせCastであった。

• 第百六十八回：Tak.さんと何のためのタスク管理か - 知的生産の技術

　少し考えてみたが、個人的には「養うため」というのが一番収まりがよいかもしれない。（今自分で考えて書いているけれど、他に誰かは言ってそう。）
　「養う」にも色々あるが例えばこういうこと。

• 自分および家族のいのち
• 人生の納得感、コントロール感
• 自身の有能感、自己肯定感
• 自分の能力

　まず第一に、自分や家族が生きられるように養っていかなくてはならない。仕事がうまくできないということは、昇進できないかもしれないしクビになるかもしれないし仕事が取れないかもしれないし会社が潰れるかもしれないということだ。そうすると文化的な暮らしはできなくなっていくし、いのちすら危うくなる。収入が減らないようにするために仕事をうまくやらねばならない、というのがタスク管理の大前提だろう。
　働き続けるためには働けるような精神状態を保っておかなくてはならないので、その意味では「怒られないようにする」といったことも重要な要素である。（怒られたくなさで倫理を無視してはまずいけれども。）
　切羽詰まっているとか生存以外の欲がないとかであれば、自分や家族を養えれば達成ということになり、それ以外の意味合いはタスク管理に伴わないかもしれない。そして別に管理しなくても養えるなら（あるいは自分が養わなくてもいいのなら）そもそもタスク管理は不要だろうと思う。

　生き物としていのちが続くことを確実にできたなら、次は精神面の健康を養う必要がある。
　不満があったり不幸を感じていたりすれば、寿命まで生きるには生きたが生きた甲斐がなかった、ということになりかねない。それを回避するためには、自分の生活に納得すること、社会を構成する一個体として十分な存在であると思えることが必要だろう。
　つまり、自分の生活がどういうものであり、自分は何を選択しているのか、そして実際に何を成してそれが社会でどういう意味を持っているのか、ということを把握し管理することで不満から脱出するよう試みるわけである。この意味では、誰かを養う身分でなくともタスク管理というものは有用ということになる。
　ただしこれらは、例えば「どう生きたって人はどうせ死ぬのだ」的な考えに納得しているならば必要ない要素であろうと思う。幸福感の欠如に悩まされていないのならわざわざ自分の選択や存在意義に思い巡らさなくても構わないだろう。

　更に、生存を確かにするためにしろ幸福感を確かにするためにしろ、ただ現状をどうにかしているだけでは足りなそうならば、環境を変えるためにまだ自分にない能力を新たに養う努力をしなくてはならない。そのためにはその努力をするのに必要な時間や資金を捻出する必要がある。（ここでの「能力」というのは、いわゆる「スキル」だけでなく「思考回路」も含む。新たな考え方も新たな能力ということである。）
　となると、既にあるタスクと開拓のためのタスクを合わせて管理して日々を設計することになる。これは頭の中だけでやるのはかなり難しいので、実際的なタスク管理の必要に迫られる。必要な行動は何で、それをいつまでにどのようにどの順番でやっていかなくてはならないのか、そういったことをどこかに書き出して検討して決めていく工程は必須だろう。

　まずいのちを養う。現状で頑張っても駄目そうなら新たな能力を養う。いのちが安泰なら精神を養う。現状でやっていっても幸福感が足らなそうなら新たな能力を養う。それを着実に実行していくために、自分の頭の中だけでは足りないようならタスク管理ということをする。
　いずれの意味でも養う必要がない、または養うにあたり改めて把握と管理をする必要に迫られていない、という状態ならタスク管理は多分要らない。

　タスク管理は、タスクの実行を最適化する手段であると同時に、それらのタスクを検討・実行している自分自身の姿が可視化されるという副産物をもたらすものである。
　タスクの選択や可視化された自己の解釈には、タスク管理そのものとは別の営為が必要であり、それが例えばミッション・ステートメントやTak.さんのライフ・アウトラインの「LIFE-BE」「LIFE-AS」といったものということになるだろう。どう実践していけば本当に自分に有用かというのはよくよく勉強と検討を重ねていく必要がある。
　ということを考えた。

2021年から2022年あたりはCosense（Scrapbox）の公開プロジェクトをサイト代わりにしていた。

• Noratetsu's Room（のらてつ研究所）

今読み返してもいろいろ面白いことを書いていると思う。しかしもうこのプロジェクトを更新する気はないし、このままにしても何も生まれない。何かしらの流れの中に過去のノートを組み込みたいけどどうするのがいいか…。

Noratetsu's Roomの気に入らないところは、ネットワーク型に全然向いていない記述が入っていたり、誰に向けて言いたいのかも曖昧だったり、とにかく雑然としているところ。自分の性格に合っていない運用をしてしまった。Scrapboxの懐の深さに甘えてカオスを作り出したことに反省がある。
今何かを公開するとしたら以下のいずれかになる。

• Noratetsu Houseの記事
• Noratetsu Houseの茶の間
• Noratetsu Houseの雑記帳
• note
• トンネルChannel
• Bluesky

軽い記述は茶の間あるいは雑記帳がいいだろう。一部は実際に雑記帳に移した。
そもそも記事として書くには足りないところがあるからScrapboxの曖昧なアウトラインで終わらせていた感があるので、Noratetsu Houseの記事にするのはあまり現実的じゃないかもしれない。
一方で同じ「記事」でもnoteならいけそうな感じがある。読む層が違うから。ライトに書くという選択肢がある。自分のサイトの記事を1000字で終わらすのはものすごく消化不良感があるが、noteだと逆に5000字とか書くと多すぎる。
とりあえずScrapboxのままだと扱いづらいので、機械的にOPMLにしてDynalistに取り込んでしまおう。

　Cosense（Scrapbox）で、倉下忠憲さんのPodcast「うちあわせCast」のノートを取ることにした。

• うちあわせCastノート by Noratetsu | Cosense

　聞きっぱなしでは次の日にはもう半分以上忘れてしまうしそれでは勿体ない。何も残らなければ聞く意味も減ってしまうので、ノートを取らなくてはと前々から思っていた。
　そう思いつつどこにどうやるのがいいかと考えてしばらく迷走していて、最終的にCosenseがよかろうという結論に至って新たにプロジェクトを作り、どうせなら公開するかということになった。
　基本は文字起こしにタイトルを付けてページを作り、テーマ毎のまとめページを用意してページリンクを組み込みながら短文を作って「何の話をしていたか」の概要を作るという形を取っている。

　まずお話の内容を切り出してページ化するフェーズと、それらを見渡して自分なりにリンクしたり解釈を記述したりするフェーズとがあり、今のところ前者に偏っているのでただ引用だけ書いたページが多い状態だが、手入れを繰り返して自分なりの「ノート」として意味あるものにしていくつもりでいる。
　一回分のページを作って整理するのにもかなり時間がかかるので、理想を言えば全部の回作りたいとは思いつつもなかなかできないかもしれない。しかし一部しかできなくても得られるものは十分多いはずなので、やれる範囲でちまちまやっていこうと思う。

Q. 共同編集にしてみんなで作ったほうが早いのでは？
A. とりあえず私は私のノートを作りたくてやっているので、「うちあわせCastWiki」みたいにしたい場合は誰か別に作ってください。
　

NHKのEテレで「NHK短歌」という番組が放送されている。

• NHK短歌 - NHK

この番組の司会の一人がヒコロヒーで、静かに淡々と進みつつ時折的を射たようなコメントがスッと出てくるのを面白く見ている。
あと普段目が取り澄ましたような雰囲気なのが、時々ぱっと目を開いた時にすごく輝いた感じになるのが好き。CMで看護師を演じている時にも思った。