まただいぶ間をあけてしまった一日一文だが，少しゆとりも出来てきたのでぼちぼち再開したい。継続性について考えてしまうといつまでも再開出来ないので，停止したり再開したりは今後も繰り返しながら，あまり気負わずやっていく。

半年ほど前から，デライト市場戦略にも大きな変化が生じている。個人知識管理サービス市場での競争よりも SNS 市場での競争という意識の変化だ。

当初から次世代の個人知識管理サービス（高機能メモサービス）としての売り込みを考えてきたデライトだが，2年以上の市場活動を通して，“時期尚早”の感が拭えなくなってきていた。

「デライトは従来の個人知識管理サービスとは桁違いの情報を扱える」という趣旨の発言をしたところ，その意図を全く理解出来なかった一部界隈から怒られるという，今となっては笑い話のような出来事（N10K 騒動）もあったが，最近，Notion の小さな流行にも考えさせられることが多かった。

綺麗で仕組み作りが楽しいと評判の Notion は，個人知識管理においてはどちらかというと初心者向けのツールだ。

よく，「勉強が出来る人のノートは意外と汚い」などと言われるが，個人差はあれど，その傾向があることに不思議はない。優れた記録術というのは，自分にとって必要な情報を的確かつ効率的に記録して取り出せる技術であって，それは他人から見て綺麗なものではないことが多い。それどころか，自分の理性に反するものであったりもする。

知識管理に限らず，経験を重ねるということは，事前の想定や計画が通用しないことの多さを学ぶということでもある。美しい理想を掲げる独裁政治や計画経済が破綻し，無秩序に見える民主主義や市場経済が繁栄してきたのは，人間が思い描く理想や計画がしばしば現実の複雑性に対応出来ないからだが，知識管理にも同じことが言える。だから，熟練者ほど無秩序に耐えうる単純で柔軟な仕組みを好む。一方，初心者ほど見栄えや「型」にこだわってしまう。

個人知識管理という一点においては厳しい言い方になってしまうが，そういう意味で Notion は，「必要以上に綺麗にノートを取ろうとする勉強が出来ない人」のためのツールと私の目には映っている。Notion 人気が今の市場の成熟度を表しているのだろうとも思う。もちろん，入門者向けツールとしての意義を否定しているわけではない。それはそれで役割がある。

デライトには「使い方」というページがあるのだが，これは最初の頃からまともに更新出来ていない。デライト開発もありがたいことに快調で，いちいち更新していられないほど変化が激しかった。このあたりも近日中に刷新するので，もうしばらくお待ち頂きたい。

もっとも，多くのデライト初心者が躓いているのは，細かい操作方法というより，どういう考え方で使っていくものなのか，という所なのではないかと思う。デライトで躓きやすい「使い方の考え方」について，このあたりで少し補足しておきたい。

デライトは風変わりで慣れが必要なものではあるが，特に難解なものではない。開発者の力不足による不親切さは多々あるものの，あくまで誰でも使えるものを目指している。まずは，ちょっとしたゲームのルールを覚えるつもりで読んでもらいたい。

なぜ「輪郭」なのか

デライトは，個人の知識をよりよく育て，生活の様々な場面で役立ててもらうためのサービスだ。それを突き詰めた結果として，互いに入れ子に出来る「輪郭」という単位で情報を扱う仕組みを持っている。

ここでいう「輪郭」というのも，まずはごく普通の言語感覚で理解してもらえればいい。ある物事の全体を取り囲むもの，という意味だ。もっと具体的にイメージしたければ，手で輪っかを作り，目に見える風景の一部分を切り取って見てほしい。写真の構図を考える時などに似たことをよくやるが，その時に手で作っている輪っかは，世界のある部分の輪郭だ。

その輪郭を，自由に“保存”出来たらどうだろうか。輪郭の中にまた輪郭を作ることも出来る。一つの輪郭は，他の無数の輪郭を含むものであると同時に，他の無数の輪郭に含まれるものになる。そのようにして，“世界を捉える”ことは出来ないだろうか。さらに，この考え方をコンピューティングに応用することで，従来の情報管理が抱えていた問題を解決出来るのではないか。ここからデライトの輪郭という仕組みが生まれた。

例えば，ファイルをフォルダ（ディレクトリ）という入れ物で分類管理する仕組みは広く使われているものの，人間が頭の中で扱っているようには情報を扱えない。一つの物事をどこに分類するかは，見方によっていかようにも変わりうるからだ。これは，一つの情報を一つの入れ物に所属させるような「階層構造」一般の問題（こうもり問題）としてよく知られている。

他方，こうした問題を解決するため，より柔軟な「ネットワーク構造」（グラフ構造とも）を利用した仕組みも広く使われている。Wikipedia などで利用されているウィキはその代表例だ。ウィキは，ウェブのハイパーリンクという仕組みを最大限に活かし，縦横無尽にリンクを張り巡らしながら情報を整理出来るように設計されている。しかし，こうした技術も万能ではない。柔軟な分，散漫・乱雑になりがちで，焦点を絞って情報をまとめることには向いていない。

デライトの現状に対する評価が難しいと私がしばしば言っているのも，本質的な難解さや新規性を考えると，現状の用者数・認知度でも大成功していると言えなくもないから。

（進捗時限記録中略）

不意に閃いた「階層区切り線」についての方針をまとめて終了。

従来の見出し未満の区切り線記法に，見出し階層を越えられる「階層区切り線」を加える。以下のように，唯一通常の区切り線と区別出来る見出し記号 #（全角 ＃ も可）を使う。

* 第1階層
** 第2階層

#========================#

第1階層段落。

#------------------------#

第2階層段落。

#- - - - - - - - - - - - #

第3階層段落。

#. . . . . . . . . . . . #

第4階層段落。

##

第1階層段落（# の数でも調整出来る）。

デラング全体の方針検討で終了。

デラングでは，文書構造と装体の記法をあえて混在させることにした。これまでも混在はしていたが，考え方として整理出来ていなかった。

HTML と CSS 的な「文書構造と装体の分離」に従って文書構造の方に徹するという考え方は，実はあまり軽標記言語には向いていない。

記法に厳密な意味を持たせ過ぎると気軽に使いにくくなるし，装体に関する記法が無いと結局誤用される。「文書構造と装体の分離」とデラングが最も重視している「直感性」はしばしば相反する。直感に従って書けば上手く文書構造と装体の分離をした変換がされる，というのが理想と言えるだろう。

例えば強調記法と太字記法のように，デラング内である程度の使い分けが出来るように設計していくべきだろう。これは実装経験を積みながら感じていたことだった。

箇条書き記法の使い方について少し整理して終了。

昨年6月に箇条書き記法（リスト記法）を実装するまで長いことデルン上で箇条書きを使うことが無かったこともあり，私自身が箇条書きに不慣れで，順序無し・順序付きの使い分けに迷うことがしばしばあった。

その原因は，いちいち「記述対象の順序性」を考えてしまっていたことだった。順序付き箇条書きは，単純に順序を強調したい時に使えばいい，ということに気付いてから気軽に使えるようになった。順序があるものだから使わなければいけないということはない。

些細なことのようだが，デラング文書で説明する時にも重要になりそうだ。

（進捗時限記録中略）

ひょんなことから，予てからの課題だった折り畳み記法が急速にまとまった。

折り畳み記法は，他の部区記法と組み合わせて使える汎用的な記法として実装していくことにした。以下のように，部区の開始行末に ^ を加えることで，その部区（見出しなら階層下の内容）が折り畳まれるようにする。厳密に言えば見出しは階層下の内容を含む部区ではないが，例外的に扱う。

・リストの折り畳み ^
  ・折り畳まれる項目

* 折り畳む見出し ^
折り畳まれる内容

+{埋め込みの折り畳み K#XXXX} ^

検討中，これがネタバレや NSFW のような閲覧注意の内容に使えそうなことにも気付いた。

きっかけからまとまるまで

デライト装体調整，URL 装体調整で終了。

直書き URL（<a.URI>）を font-size: 0.9em の等幅フォントにした（URL 装体調整前後）。字間無しは昨年6月30日の開発からだが維持する。

直書き URL のある描写が読みにくい問題はずっと以前から感じていて，何度か調整しているが，一昨日の開発中にふと，「文字サイズを小さくしていない」ことに気付いた。

昨年6月30日の開発で字間無しにしているが，等幅フォントにして変に目立ち過ぎるという理由で戻したりもしている。この時になぜ文字サイズを小さくするという発想がなかったのか不思議だ。他にも問題が山積していて思考時間が割けず，灯台の下まで目が行かなかったか。

今回は <kbd> や <code> の装体について考えていたところだったので，その関連で気付けたのだろう。

文字サイズはやはり0.9emが丁度良い。0.8emにすると長い URL はともかく短い URL を提示する時に今度は目立たな過ぎる。

これにより，十分凝縮されメリハリが付いたので，予てから検討していた長い URL の省略については保留とすることにした。

長い URL の省略は，簡単なようでいざ導入しようとすると意外と難しい問題がある。

まず，デライト上の文書の傾向からいっても，「ちょっと長い」程度の URL は省略したくない。URL の全体が情報として有用な場合がしばしばある。このあたりはマイクロブログなどとは事情が異なる。

では，どこで省略すべきかという問題になるが，長い URL を許容すればするほど比較的短い URL の読みにくさが解消されないというジレンマがあった。これは装体の調整で解決した。

そもそも輪結記法（[ ... ]）もあるので，現状維持で特に困ることはないだろう。そのうち https://example.com/abc ... xyx のような省略記法を導入してもいい。

ただ，パーセント符号化の復号はしたい。これは昨年3月22日2歩で決めていたことだが，少し面倒臭い部分がありいまだに実現していない。

一日，思考が散漫でとりとめのない考え事が多く，開発作業には集中出来なかった。しばしばあることなので，脳が最適化作業をする時間なのだと思えるようになっている。

特に，“時間”についてよく考えた。

思えば海のような時間を使ってここまで来れたが，さらに希哲館事業のために十分な時間を生み出せるかどうかは，やはりここ2ヶ月にかかっている。そしてそれは，焦らず弛まず，毎日着実に歩を進めていれば十分可能なことだ。

そんなことを考えているうちに，緩みつつあった気持ちも丁度良く引き締まった。