t_wの輪郭

https://cloud.google.com/architecture/architecture-decision-records?hl=ja

フワちゃんの例えと、Word VS Markdown で死ぬほど散らかっててウケる。

Wordの話がブラックホールすぎる。

https://github.blog/changelog/2022-03-17-mermaid-topojson-geojson-and-ascii-stl-diagrams-are-now-supported-in-markdown-and-as-files/

pulldown-cmarkはRustで書かれたCommonMarkのパーサー。

https://github.com/raphlinus/pulldown-cmark

https://marp.app/

https://mdxjs.com/

MarkdownとJSXの合いの子みたいなやつ

接触元

https://misskey.io/notes/9bm3nhvs91

https://misskey.io/notes/9bm3mid14n

https://future-architect.github.io/articles/20220816a/

https://portalshit.net/2019/11/17/the-end-of-the-plain-text-markdown-era

Tak.「ノートツールなんてそれこそ使い込まないと、ある程度の期間使わないと分からない」
…………
Tak.「Logseqって言ってる人、多分多くは去年はObsidianってきっと言ってたよな。そのうちの何割はその前の年はRoam Researchって言ってたよな。でもいいんですけど、ただやっぱり3年4年使わないと分からないことがある。」
倉下 忠憲「でもそれってある種の賭けじゃないですか。このツールで行く。それ以外は使わへん。みたいな。」

　次々に新しいメモアプリ（個人知識管理サービス）が生まれてきている。それらが出る度にどんどんに乗り換えていく、といった状況を見ていると、個人知識管理サービスの相互運用性が問題になるんじゃないかと思う。

　流行りのメタバースではメタバースの相互運用性が議論に上がるが、個人知識管理サービスの方がよほど影響が大きい。メタバースはあくまでエンターテイメントで、そこでできた友達は可搬（ほんまか？）だが、膨大な記述を伴う知識を別サービスに人力で書き写すのは並大抵の労力ではない。

　もし記述した知識を個人知識管理サービス間で相互に取り込みができないならば、知識が人質になる。サービスの過剰な値上げに対して対抗できないし、サービス終了に対しても脆弱だ。アカウント凍結に対しても不安がある。
　前例を上げれば、Twitterアカウント凍結解除のために弁護士費用121,000円をかけた事例すらある。それだけ、長期間にわたって書いてきた文章は、書いた本人にとって価値を持つと言えるし、人質としての適性が高いともいえる。

　また、記述した知識を個人知識管理サービス間で取り込むことができれば、「個人知識管理サービスは長時間使わないと真価が分からない」という問題も解決できるかもしれない。他の個人知識管理サービスを使い込んだ後に、新しい個人知識管理サービスに知識を取り込めば、あたかも使い込んだかのような環境が構築される。

　
　しかし、上で上げた話は自分の肩の上に立つようなものだ。
　ある個人知識管理サービスで記述した知識を、ほかの個人知識管理サービスに取り込んだ場合に、それが適合することは少ないと感じる。
　例えば、Workflowyで書いた文章をScrapboxに一切の加工なしに取り込んだとしても、何ら機能するものではない。お互いの良さをつぶし合うだけの結果になる。Workflowyで書いた文章の量にもよるだろうが、なじませるには書き換えが必要になり、相応の労力を要するだろう。
　これについてもうちあわせCastにて議論されている。アウトライナーを使って書かれたと思われるTak.氏のブログをScrapboxに取り込んだ結果、何か違和感のあるものになったという話がされていた。

Tak.「アウトライナー系のコンテンツを全部Scrapboxに退避させた。退避というのはScrapboxに移した」
……
Tak.「ある程度構造を持った状態のものをScrapboxに入れた時に、入れる前よりも辿っていくのが難しくなった」
……
Tak.「もともとのコンテンツのつくりがScrapboxっぽくない。それを無理矢理分割してScrapboxに入れているところがそもそも読みやすく感じない理由」
……
倉下 忠憲「このHappy OutliningとTak.さんの本館、どっちが魅力的かというと本館の方なんですけど、最初にあのページを見た時のワクワク感はあんまりこのプロジェクトには感じないですよね」
Tak.「Scrapboxって育てていくものだと思うんですよね。ここにはScrapboxの中で育ったコンテンツじゃないんですよ。違う所で育ったコンテンツを小分けにして入れているだけ。そういうものってScrapboxの魅力が感じられないというか」

　私個人の実体験としても、デライトで書いた文章をScrapboxにコピーしておくようなことを試したこともあったが、どうにも違和感が出てしまってやめてしまった。デライトでリンクしている部分も再現してコピーしたため、機能面では適合しやすく思われたのだが、それでもだめだった。

　まずもって文章というのは妙にセンシティブというか、些細なことによって印象が左右される。フォント、上下左右の文字の空間の取り方、それを取り囲む装飾などなどによって微妙に、場合によっては劇的に印象が変わってしまう。機能の些細な違いによっても適合しないのは当然のように思える。よしんば、データの構造すら違うものをほかのサービスに移植するのは、他の動物の臓器を人間に移植しようとするようなものなのかもしれない。

　『書くための名前のない技術 case 3 千葉雅也さん』にて千葉雅也氏は、文章のレイアウトが決まってやっと文章の結論が出ると言う。見た目や機能性だけの問題ではなく、そこから得られる結論すら、ツールによって変わってもおかしなことではない。

アウトライナー・Markdown・Fediverseに見る相互運用という理想論の実現例。

　個人知識管理サービス間で違うからこそ良いという見方もできる。
　再びTak.氏の事例になるが、氏が書籍を書く際、アウトライナー（おそらくDynalist？）からMicrosoftのWordへ文章を移植する工程があるらしい。Tak.氏の定義によればDynalistはプロセス型のアウトライナーであり、Wordはプロダクト型のアウトライナーとなる。つまりお互いに異なる性質を持っている。プロセス型のアウトライナーからプロダクト型のアウトライナーへ、書籍を書く途中でバトンタッチする工程を踏むことで、両者の良いところを発揮させている。しかし、そのバトンタッチの工程においてはかなりの労力が必要になる。なぜなら、両者の間でデータの構造が異なるため、単純なコピペでは構造が引き継がれないためだ。
　この事例から分かることは、個人知識管理サービス間の相性によって、その機能が異なっていたとしても良さを発揮できる可能性があるということだ。

　また、不完全ながら、Markdown形式による個人知識管理サービスの相互運用が可能な事例も存在する。LogseqとObsidianは互いにMarkdownを採用しており、さらに手元のPC内でファイルを残す形となっている。特殊な条件が整っていれば、個人知識管理サービスの滑らかな相互運用が可能となる可能性がある。

　相互運用の事例としてFediverseも紹介したい。Fediverseでは、異なる種類のマイクロブログサービスが相互に通信しあい、異なるサーバーで異なるソフトウェアが動く状況下であるにもかかわらず、その間でコミュニケーションが実現されている。サーバーの間では、ActivityPubを始めとした特定のプロトコルによって通信されている。
　
　上記3つの事例からは、データや通信の規格化が相互運用の実現に必要であることが示される。

　しかし、個人知識管理サービスというものがまだ一般に認知されておらず、どういったものだという認識も各々で異なっている。また、個人的に個人知識管理サービスというものはまだ、機能面において成長段階だと感じる。今この段階で規格化してしまう事は、その成長の重しとなりえるのではないかと危惧する。ただ、遠い未来のこととして規格化について議論を進め、共通認識を育むことは、個人知識管理サービスの相互の成長にとって有益となるはずだ。

ウェブブラウザという事例を見れば完全な（理想的な）相互運用は難しい。遠い桃源郷。ガンダーラ ガンダーラ。

　「IE！！！奴は死んだ！！！ウェブブラウザ相互運用黄金時代！！！」とはならなかった。新たな爪弾き者が見出されてしまっている。1990年にウェブブラウザというものができて長い時間がたっているにもかかわらず、完全な（理想的な）相互運用というものは実現されていない。
　これ理由として考えられるのは、企業がソフトウェアを開発している以上、同質化する動きがあるのと同様に、差別化する動きがあるためだ。
　つまり、文書を扱うソフトウェア同士の完全な（理想的な）相互運用というものが、性質としては実現困難であることが示されている。

手元のPCや、自分が管理するサーバで、個人知識管理サービスを運用したい。OSSとして。

　ここで視点を変えて、知識の存続を保証するにあたって、個人知識管理サービスの相互運用性を諦め、一つの個人知識管理サービスでやっていく方法を模索したい。
　もし、個人知識管理サービス（もといツール）が手元のPCで動いて、それがOSSだとどうだろう。サービスの値上げやサービスの終了におびえる必要は一旦なくなる。もしソフトウェアが古くなってきたとしても、自分で改修していくことができる。
　Logseqは上記の条件を満たす稀有な事例だ。

　ひとまず自分が生きている間の知識の保証は実現されたと言える。では、自分が死んだ後はどうだろうか？

アナログへの回帰・アナログへの蓄積

　個人知識管理ツールが手元のPCで動くことによって、生きているうちは知識が保証されることを上述した。しかし、次に、そこで記述した文章がそのままではどこにも行きつかないという問題が生じる。特に記述した人が死んだ後に文章が消え去っていくのは、記述者にとっても、ほかの人にとっても、余りに惜しい。どうにかして、死ぬ前に個人知識管理ツールで書いた文章を他の人に届け、遺せないだろうか。
　個人知識管理ツールを個人のPCで動かす以上、もはや機能の問題ではなくなってしまう。もしかしたら将来的に、文章を共有可能なdApps（分散型アプリ）が出現するかもしれないが、現時点では、私の観測範囲では、そのようなものは開発されていない（事例があれば知りたい）。
　個人知識管理サービスで書いた内容を書籍化するのが現実的な解なのかもしれない。
　文章を書籍化し、一般に流通することで、多くの人に知識が届けられるうえに、国立国会図書館に所蔵されることによって長期にわたって保存される。

個人知識管理サービスでメモを貯めていって、書籍にまで成長するのか

　ただメモを貯めてもどこにも行き着かない（書籍にまで育たない）という仮説が『第百十五回：Tak.さんとノート術と執筆術の違いについて』でTak.氏・倉下 忠憲氏の両者の対話によって示された。
　ただ漠然と、メモを書き溜めさえすれば書籍になるかというとそうはいかないだろうという感触が私もある。ではどうすればメモを書籍化できるだろうか。

　メモを書籍化するにあたって、ある種の題目に沿ったメモを一か所に集める必要がある。つまり、特定の属性を持ったメモの集合を作る必要がある。
　検索は、簡単に「特定の属性を持ったメモの集合」を作る手段の一つである。

　メモを書籍化することを目的としてメモを検索することを考えると、メモを検索結果から操作できると、書籍化のための操作がしやすい。
　検索結果からメモを、編集し、並び替え、検索結果から削除する。そういったことができれば、検索によって作られたメモの集合を書籍に近づけることが可能だ。

　検索結果からの操作についても、うちあわせCastでは言及されている。

　タグで検索して見つかりましたで終わりって感じがするんですよね。検索結果って、見つけられますけど、検索結果から操作できないじゃないですか。だから、案外意味ないんですよね。
　知的操作ってことを考えた時に#ほげほげがついているものを、集めて、この項目化に再配置するってことができるのであればまたちょっと違うかもしれない

　検索結果を操作することを考えた時、デライトの検索機能である全知検索は特異だ。
　輪郭（メモ）の表題（知名）と、検索語の完全一致により、輪郭を探し出す全知検索において、輪郭の作成は検索結果の事前作成に他ならない。「この検索語で検索されたら、この輪郭の集合を表示してほしい」ということを事前に作りこむことになる。
　また、デライトでは、検索画面から輪郭を編集し、引き入れ・引き入れられを変更できるため、検索結果を検索された後に編集することができる。

　検索は集合を作る。輪郭も集合を作る。この類似性と相性の良さは決して偶然ではなく設計された物だろう。よく考えられている。

どれだけのメモを個人知識管理サービスで溜めればよいか

　多くの著作を残したことで有名なニクラス・ルーマンは9万枚のカードを書いたという事例を取れば、多くとも9万のメモがあれば十分だと考えられる。
　この9万という数にたじろぐかも知れないが、9万のメモはデジタルだとうっかり超えてしまえる数だ。ツイートはメモだとするならば、10万ツイートする人は少なくない。Twitterと類似したサービスのマストドンでは、マストドンチュートリアルは10万投稿とか言われている。10万投稿が簡単な数ではないことを使った冗談の類だが、それでも不可能な数ではないことを示している。

　ほかの事例を見れば、メモを書籍化するには数万のメモは不要だ。1万未満のメモでも書籍化が可能である。
　ツイートが書籍化した事例としてTestosterone氏がおり、『超筋トレが最強のソリューションである　筋肉が人生を変える超科学的な理由』は、彼がTwitterで投稿している内容と類似した内容が含まれる。そのTestosterone氏は2022年10月30日時点ではTwitterにて6,300 件の投稿をしている。

どんなメモを個人知識管理サービスで溜めればよいか

ノートはできるだけ抽象的に書く

アトミック・ノートも、自分の知識、アイデア、考えをできるだけ「汎用性が高いノート」としてまとめることを目指します。書いた文章は、できるだけ「普通」の、抽象的で汎用的な文章にする。そうすることで、書いた文章は様々な場面で応用しやすくなります。

　文章を抽象的に書くか、具体的に書くかという切り口は興味深い。

　筆者の五藤隆介氏は「文章を抽象的で汎用的にすると、多くの場面で応用しやすい」主張している（と私は読み取った）。この主張の対偶を取れば「応用しずらい文章は、具体的な文章である」となる。この主張とは異なる、「具体的な文章も、多くの場面で応用しやすい」ということを主張したい。

　具体的な文章、つまり出来事についてかかれた文章は後から意味付けがしやすい。したがって、具体的な文章は応用が利き、使いまわしができる。想像もつかない使われ方ができるため、具体的な文章を書き残すことには大いに効果がある。
　実例を上げれば、『アトミック・シンキング: 書いて考える、ノートと思考の整理術』の中で、携帯キャリアが牛丼が無料になるクーポンを配布していたことについて記載されている。

　実際に、とある携帯電話キャリアを契約していると牛丼が一杯無料になるというキャンペーンがありました。

　この出来事が「ノートと思考の整理術」と結びつくとは、誰も想像できないだろう。

　また、アトミック・シンキングでは「「事実」と「それ以外」を分けて書く」ことを勧めているが、こちらについては同意するところである。
　事実とそれ以外、すなわち具体的なことについて書いた文章と、抽象的なことを書いた文章とを分けることによって、それぞれが書籍の素材として使い回しがしやすくなる。

最後に（まとめ）

　本文章では「個人知識管理サービスが出現しても書籍化が必要である」こと、「個人知識管理サービスに書いたメモから書籍化するにあたって、個人知識管理サービスに検索から編集する機能があれば書籍化の助けになり、具体的なことを書いたメモと抽象的なことを書いたメモを分ければ使い回し（書籍化）が容易になる」ことを示した。

　今後の課題としては、本文章を書いたt_w本人が書籍をまだ書いていないために、上記の機能や手法の有効性が実証されておらず、信用性に欠けることが挙げられる。

Markdown記法などからリッチテキストに変換してしまうと、Markdown記法に戻すには手間が必要になること。

Craftの良いところ① 「最高のUX！画像を美しく配置できる。」
Craftの良いところ② 「ブロックエディタにマークダウン。編集簡単！」
Craftの良いところ③ 「階層に分けて保存可能。整理整頓。」
Craftの良いところ④ 「オフラインで利用可能。デバイス間の同期も優秀。」
Craftの良いところ⑤ 「動作がサックサク。軽さ抜群」
https://note.com/yukkakiyo/n/n56fa031982d4

https://typora.io/

Markdownエディタ

突然楽しげになる