t_wの輪郭

ページ名を[update links]にしました[bsahd.icon]
　　変更により、文章がおかしくなる箇所の確認をしていないの？[suto3.icon]
　　　[update links#669caade71b3c20000c4e460] これは私が「[update links]」と呼ぶくらい →　これは私が「ブルートリンク」と呼ぶくらい
　　　まだ他にあるかも知れません
　　　ごめんなさい[bsahd.icon]
　　　 デライト関係のページは確認しておく

Wikiの大変なところの一端を現してるなって思った。ページ名を変えるたびにリンクに文脈的問題が生じていないかを確認する必要がある。その労力がかかる。

KNSとは何か

　knowledge networking serviceの略であり、個人知識管理サービスとSNSとが融合したサービスとなっている。SNSのように気軽に投稿できつつも、その投稿によって表現された知識が高度に管理可能なサービス。宇田川浩行氏によれば、「SNSの次」に来るサービス形態である。
　この文章では、このKNSについて雑多に書く。

KNSはすでに存在する

　KNSとして作られたデライト、Scrapboxの一部プロジェクト（井戸端・アープラノート）など、すでにKNSは誕生している。

　井戸端やアープラノートに関しては、WikiであるScrapboxをチャット的に用いることで知的交流を成している。

KNSの流行らなさ

　KNSは自己対話による面白さがある。故にKNSは他者を必要としない。必要とする度合いが低い。そのために、他の人を呼び込むことが少なくなり、広まるまでに時間がかかる。

KNSは「まとめ」と「言及」で駆動する

　KNSを通して、各種ウェブページをまとめ、さらにそれらに言及していくような使われ方が進んでいく。はてなブックマークに成り代わり、Togetterに成り代わり、SNSに成り代わる。そうして段階的に社会に浸透していく。
　そうした「外部サービス」としてKNSを見たとき、ウィジェット化が有用な機能として挙げられるだろう。KNSでまとめと言及をし、ウェブページの方でさらにKNS上のそれらが表示されれば、相互の流入が期待できる。
　そうして代替として普及しつつも、KNSの真価に触れた人にとっては、他では代替不可能なものとして確立されていく。

SNSの限界とその拡張、SNSのKNS化

　生物が単純な形態から複雑な形態へと進化したように、SNS上で交わされる話題の複雑化は当然のことながら生じる。
　Twitterではそれに対応するために、140字から280文字に文字数制限を緩和した。ユーザーも自己リプライによって話題の複雑化に対処しようとしている。
　SNSのKNS化が進んでいる。タグや外部サービスによってまとめる機能が付与されていっている。つまり後付のまとめ機能でなんとかやりくりしている状態だ。
　しかし、そのやりくりも限界がある。抜本的な作り直しが必要になるときが来る。その時、既存のKNSが参考にされ、さらにSNSのKNS化が加速する。

インタラクティブなWikiっぽい何か

コグニカルは、足りない知識をツリー構造で掘り下げられる学習サイトです。数学、自然科学、工学の知識を分かりやすく説明しています。

接触元 「離散コサイン変換」のGoogle検索

　「この流れに乗じてデライター増加を狙い、上流のTwitterで宣伝する」とかできたらいいのだが、私のTwitterでの発信力が皆無だ。
　そもそも、Twitterに安住していた人たちにとって、デライトが求めるものだろうかという疑問もある。勝手が違いすぎる。Twitterには合わない人。自分のメモに深く潜るような人が合っている気がする。ある種、自己完結した人ともいえる。
　どうすればそういった人たちに情報が到達するだろうか。

　一見、倉下 忠憲氏のような知的生産を生業や関心とする人々に情報が到達すれば良いと思われるが、実のところそういった人たちはN10K 騒動でもうすでにデライトを知っており、そのうえでデライトを選んでいない。彼・彼女らはすでに自らの個人知識管理の手段（ツール・サービス）を有しており、そこから離れることがない。離れることができない。

　星取表的に機能を比較すればNotionが勝つし、Wiki的なものを求めればScrapboxに行きつく。それらと比較すれば、デライトはあたかも機能的に貧弱・不合理に映る。
　全知検索一つとっても、一見不便な検索機能にしか見えないし、自ら索引を作っていくという行為に対してもただただ面倒なことをしているように見える。その実、輪郭法との組み合わせによって、意図通りの検索結果を返す検索エンジンとなってくれることはまだ多くには知られていない。「メモによって索引を作る」という発想に至っている人間でさえごく限られている。デライト以外でこれに似たことをしている事例は、増井俊之氏のGictionary以外に知らない。しかし、このGictionaryでさえも、IMEのための言葉の置き場という以上の物にはなっていない。

　単純にメモを取ることだけを目的にすれば、Google KeepやMac純正メモアプリに軍配が上がる。理解が容易だ。

まず題目指向と日時指向について、それぞれ定義しよう

事例

題目指向の事例

• 本
• 『t_wの輪郭』で実施した作業

日時指向の事例

• 日記
• 新聞

題目指向と日時指向の混在

• 井戸端（Scrapbox（WiKi））

題目指向・日時指向の利点と欠点

題目指向の利点と欠点

題目指向の利点

• 一覧で表示された時に、文章の表題で何を書いているかを知ることができる
  • SEOに強い
• 再利用が容易
• 並び替えの自由度が高い
  • 優先度順など、任意の並べ替えが可能

題目指向の欠点

• タスクリストとして使う場合、ある日（たとえば今日）何するかを考えづらい
• 分類として見たときに、MECEでない
  • あるいはMECEにしづらい
• 脱線した内容や、些細な事の記述がしづらい
• 新しい題目を立てるのが億劫

日時指向の利点と欠点

日時指向の利点

• タスクリストや作業日誌として見たとき、その日何をやったか、今日何をするのかが一覧になるのでわかりやすい
• タスクリストとして見たとき、タスクが時系列（実行する順）に並ぶため、実行しやすい。
• 分類として見たときにMECE
• 脱線した内容や、些細な事を記述しやすい

日時指向の欠点

• 一覧で表示したときに、本文として何が書かれているか知ることが難しい
  • 検索性が低い
  • SEOに弱い

雑記・思い・雑感

2022年10月27日

　題目指向と日時指向どっちがええんや……どっちも使いたくなる。書くときは日時指向の方が書きやすい感じがする。探すときには題目指向の方が探しやすい感じがする。「書いた文章を読まれたい。そのために検索で一覧表示された時に見いだされたい。」という欲求を答えるのはやはり題目指向になるのだろう。よくある記事のような感じだ。

　どっちも書くというやり方もある。労力二倍拳。嘘。二倍にはならないはず。
　今はどっちも書くという運用をしている。基本的には題目指向で書いておいて、毎日の終わりに、日付志向の日記で題目指向では拾いきれなかったことについて書くみたいな運用。さらに題目指向で書いた文章へのリンクを日時指向の文章の方に貼っておくとより良い感じ。

　井戸端は、題目指向と日時指向が混在する事例として面白い。
　基本的には日時指向で書かれていて、ある日付のページの中でまとまった話題が出たら題目をページの表題にして、その内容を切り出している（っぽい）。もちろん題目が先にあってページが作られることもある（だろう）。

　題目と日付を一致させてしまうということもできる。つまり、1日1題目で、その両方を日付に書くみたいなことをする。
　ただ、両方の悪いところが発揮されるというか、脱線のしづらさが気になるな。
　デジタルだとどんどん追記・更新していくみたいなやり方ができるけど、そういうことをするのが難しくなるみたいなところもある。

　輪郭法ついてはいったん考えないでおこう。というか後で別枠でちゃんと考えよう。そもそも題目を付けないという事すらできてしまう。特別すぎて議論がアレ。というかデライトを使い始めてから、デライトとか輪郭法のことばっかり考えてしまっててアレ。

語彙というものは空間として捉えることができるのではないか？

特に、Wikiのようなページの表題が重複することを許さないシステムを用いると、その空間としての性質を強く感じる

https://tiddlywiki.com/

HTMLファイルの自己書き換えをするWikiシステム。HTMLファイル一つで使うことができる。
個人用の記録を書き残すのに向いている。

利点

• セキュリティが厳しい環境でも利用可能
  • ブラウザでHTMLファイルを開くだけで利用できるため、追加のソフトウェアインストールが不要
  • SaaSではないため、手元のPC内で情報が完結し、外部に情報が出ない

欠点

• 多人数での利用が難しい

　以前、メモそのものが知能増幅という内容の文章を書いた。では、なぜ輪郭法が知能増幅として特筆に値するのだろうか。

　メモそのものが知能増幅であり、単純なメモによる知能増幅には制約があるのであれば、輪郭法はその制約を克服していると言える。では、何が制約になっているのかを考えてみたい。考えられる要素は、読む（探す）速度・書く速度・記録容量の三つだ。この中で制約となっているのは読む速度である。その理由を以下に示す。

　まず、考えたこと・経験したこと・その他なんでもを書くには、殆ど計算機械の容量は無限と言える。『ゼロ秒思考』で書かれている通り、多くの人が1日に書ける文章量は1000文字（20文字5行10枚）程度だ。これ以上のことを思考している人間は希だと言える。この文字数であれば、手書きであっても、情報を書き出すだけなら十分高速だと言える。よって、残りの読む速度が制約となる。

　読む速度を早くすれば良いかというとそうもいかない。人間、読む速度には限界がある。そのために、読むこと探すことを想定して書くわけであるが、これにはかなり労力がかかる。読むこと・探すこと を想定して書く場合、似た情報は近接して配置する必要がある。しかし、情報を1列に並べた場合（情報をリストにした場合）、ある情報を似た情報に近接して配置するには、リストの要素をすべて見る必要がある。

　これを解決する素朴な方法としては分類するという方法が用いられるが、「この情報はどっちに分類すればいいか分からない」といういわゆるこうもり問題が生じる。

　こうもり問題の克服のために、ネットワーク構造を用いた情報管理が考えられる。その一つとして、情報に名前を付け、その名前によってリンクを張る、Wikiのような構造が挙げられる。デライトでは、語句輪結(キーワードリンク)と呼ばれている。この語句輪結を用いることで、ある情報を複数のカテゴリーに属することが可能となる。また、ネットワーク構造は情報を探すのが大いに簡単になる。求める情報と似た情報からさらに似た情報へ移動を繰り返すことで、高速に情報を探すことが可能となる。この情報を探す方法は芋蔓検索と呼ばれている。

　しかし、語句輪結にも課題がある。それは語句輪結は無名の概念を扱えないことだ。

　語句輪結は無名の概念を扱えないという問題について考える。その名の通り、語句輪結は語句（キーワード）によってネットワーク構造を成している。その特性から、あらゆる情報（ページ）には名前を必要とする。名前を付けなければリンクを張ることができず、リンクを張ることができなければネットワーク構造を構成することができない。この特性によって、思考の途中で生じる多くの情報について「予め命名する」という作業を必要とする。命名が必要な場面について列挙すると、「語句の間に概念がスペクトラム状に存在し、その合間に存在する概念について記述したい」、「まだ名前の無い新しい概念について記述したい」、「ある体験について記述したい」などが挙げられる。

　概念に命名するという作業を考えたとき、その概念についてある程度情報が集まってから命名する方が楽である。しかし、語句輪結では命名無しに情報を書くことができない。したがって、語句輪結では命名が先か、情報の記述が先か（鶏が先か、卵が先か）という問題が生じる。そのために、安易な解決方法として「既存の命名された概念に対して追記する」という行動が優位となりやすい。それ故に、語句輪結は「網目が大きくなる（粗くなる）」、「一つのページが大きくなる」という特性を持つ。「語句輪結は網目が大きくなる（粗くなる）」という特性は「大きすぎるリンクの問題」をも引き起こす。客観性を重視するWikipediaではこれらの特性が顕著となる。

　輪郭法では輪郭（情報・概念）同士を直接結びつけることが可能となっている。この特性により、輪郭には名前が不要で、命名することなしに概念について情報を記述していくことができる。つまり、ありとあらゆる概念について、後出しじゃんけんのように、「情報が集まってから命名する（名前を後から付ける）」ことが可能になる。これが輪郭法を応用したメモツールであるデライトが「なんでもメモ」というキャッチコピーを冠している理由だと思われる。

　以上の特性により輪郭法は、ネットワーク構造が持つ情報探査の容易性を有しながら、語句輪結が持つ無名の概念を扱えないという欠点を克服している。

2022年5月2日 初稿
2022年7月3日 微修正
2022年10月8日 表題追加・微修正

　デライトは階層構造が作れる。これもWikiのような語句輪結だけのシステムとの違いの一つだ。

　私個人に帰属する問題かもしれないが、語句輪結だけでは階層を構築・認識できない。

突然「陰謀論をまとめたWikiがあれば面白いかもしれない」という思いが降ってきた

　スライドは発表するためのツールなので、スライドの上で考えをこねくり回すにはどうしても機能の不足がある。スライドが線形に並ぶだけなのは限界がある。
　というか、Google Workspaceにあるアプリケーションだけでは考えるためのツールが足りない。GoogleがWikiを作ってほしい。

• 複数のWikiが乱立するため、情報が分散し、どこに何があるのかわからなくなる
• 社内にWiki運営の知識を持つものがいない
• 社内Wikiを編集する敷居が高い
• 社内で情報を共有する利点がない

自社内でMicrosoft TeamsのWikiがなぜ機能しないのか

ITリテラシーが高めの層にとって、WikiはWikipedia等の著名なサービスの印象を引きずっていて、編集の敷居が高いイメージがあるのではないか。

ITリテラシーが低めの層にとって、Wikiとはそもそも何をするものなのかイメージがつかみにくいのではないか。

Wikiは知識を整理し共有する場というのが自分のイメージに近いが、そもそも共有することに重きを置いていない人が多い(「情報を投稿する利点がない」と感じてしまう)。

スライドのページへのリンクを張りまくると、Google SlideをWikiみたいに使える

https://scrapbox.io/shokai/wikiでページのURLをIDにすると絶対にうまくいかない

うまく理解できていない。もうちょっと読み込みたい。

活字を主に掲載する媒体、メディア
　
新聞
本
ウェブサイト
掲示板
チャット
SNS
Wiki
デライト