t_wの輪郭

デライトの強みデライト(なんでもメモ)あれ語句駆動入力速度がボトルネックこうもり問題スペクトラム名前を後から付ける似た情報を近接して配置無名の概念

輪郭法による語句駆動からの脱却

2022/10/7 22:12:00

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

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

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

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

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

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

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

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

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

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

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

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

あれあれあれ

こうもり問題ローカルアプリ全公開全非公開 Cotoami Ctrl+Enter 公開設定文輪 Scrapbox アウトライン

文輪の公開設定

2022/4/26 23:41:00

悩んでいる
Scrapboxみたいに書いたものが随時公開される仕組みだと、公開前の確認とかができなくて困る
チャットぽい感じにして、Ctrl+Enterで公開に進むようにしたら良い？
チャットぽくすると、いよいよデライトやcotoamiに近づいてしまう

ページにアウトラインが属するようにして、ページごとに公開・非公開を設定可能にしたら良い？

こうもり問題が起こるので嫌だな

公開/非公開フォルダにする？

アウトラインごとに公開設定/非公開設定にするのと変わらなくなる

アウトラインごとに公開・非公開を設定する？

ネットワーク構造なので、親の輪郭が公開されたら子の輪郭も公開にするといったことがしづらい
再起的に伝搬して、ネットワーク全体が公開になってしまう
行ごとに公開・非公開設定をするのは大変

全非公開・全公開のどちらかだけであれば、トリッキーなことはしなくても済む

いっそのこと有償のローカルアプリにしてしまった方が楽かもしれない
ただ、ローカルアプリ開発を考えた時、iOSアプリとかMacアプリとかを作るにはMacが必要になりそう

輪郭法応用の難しさ

こうもり問題 Scrapbox 提案書 Scrapboxの提案書を作りたい情報の構造が組織の構造を規定している Scrapboxのエレベーターピッチ

Scrapboxの提案書

2022/3/2 4:19:00

一般論的な話
あくまでアウトライン

■ 現状の問題点（検索・分類型ツールの限界による問題点）

チームが小規模に分かれていて、それぞれのチームが何をしているかわからない/知らない/調べたらわかるけど調べるのが大変
ファイル共有で資料がどこに行ったのかわからなくなる。検索しても目的の資料が見つからない
検索結果上で雑音になってしまうようなメモの行き場がない（きっちりした文書しか置き場がない）
フォルダ分けされているが、どのフォルダに情報を置いたらいいのかわからない
上位層に行くほど報告を受ける時間が増える/自分から情報を取りに行かないといけない

■問題の原因

情報が木構造（縦割り）になっている
- 情報の構造が組織の構造を規定している
- フォルダわけでコウモリの分類問題が生じる
- 階層の下にどんな情報があるのかわからない

■解決策
WikiシステムであるScrapboxを導入する

■予想される効果
他のチームが何をしているか、Scrapboxを見ればすぐに知ることができる
上位層が報告を受ける頻度が減り、必要な時に必要な情報へアクセスできる
思考過程のメモを残すことができ、行き詰まればすぐに助けを得ることができる

『Scrapboxでの考え方』やる気出ない Scrapboxの提案書を作りたい