Noratetsu Lab

　この頃、ブログ用の文章を書くのが楽になったなと感じている。
　文体や内容の質が変わったわけではないと思うが、なんとなくすらすらと言葉が出てくる。事前にアウトラインを整理することもなく、大体いきなり書いて、自分としては「これでいい」と思える文章になっている。

　今回は日記。

　少し時間ができたので、過去十年分くらいのノートを集めて整理した。

　ちょっと迷いが生まれた時に、自分が前に書いたことを読み返すと、「ああ、そうだよな、そうだった」と迷いを振り払ってくれることがある。
　私はこのブログで自分の問題を解決しようとする記事をよく書いているので、その問題が再発したような時に読むと特効薬を得たような気分になる場合が結構よくある。
　逆に言うと、一度解を得たにもかかわらず、ちょっとすればもう忘れているということでもある。

　何かについて書いている時というのは、その対象についての知見という意味では、人生史上最高に天才的になっている時であると言っても良いかもしれない。もちろん自分比なので、他の人と比べての天才性ではない。あくまで自分の中で一番敏い瞬間だというだけである。
　なぜそうなるかといえば、意識をそれに集中していられるからだ。内容によっては事前に入念な取材すらしている。書き終えてしまえばそんな風には意識を割いていられない。一瞬その対象についてのプロのようになっても、その瞬間が過ぎればもう素人である。研究者にとっての研究対象のように現在進行系であり続けているものなら話は別だが、記事を書いた時点で一区切りということになるとその範囲に於いては急速に素人化していく。

　書いている時の自分は（自分比で）天才なので、それまでの自分は思いついていなかったこともすらすら思いつく。書いてみるとびっくりするほど滑らかに理屈が通ったりする。「そうだったのか」と思いながら書いているということがよくある。
　それが正しいか誤っているかはここでは置いておく。正しいとか正しくないとかいう以前の問題がここにあるのだ。
　当たり前のことだが、自分の信念というようなものは、繰り返し繰り返し同じ結論を導き出すから自分の中に形を持っていくものだろうと思う。事柄Aを見ても事柄Bを見ても同じことを思う時に自分にとってそれが確信になっていく。それが正しいか誤っているかはやはりここでは問わないものとする。とにかく、何度もそれを思うから自分の中に定着する、ということが今大事なことである。
　ところが、天才な自分が何かを思いついた時、それが如何に筋が通ったものであっても、思ったのは「一回」なのである。厳密にはたった一回じゃないにしても、少なくとも繰り返し繰り返しということにはなっていない。今まで思いついていなかったのだから書く以前は零回で、書いた後に同じ結論に至る体験が重ねられなかったとしたら、結局書いた瞬間のたった一回に終わってしまう可能性は普通にある。
　そうなると、その先覚えていられないのも当たり前である。理屈として尤もかどうかは定着とは関係がない。理屈として見事ならいつでも何度でも同じように導き出せるような気分になるが、そんなことはないのである。実際に繰り返し思うことでしか定着はしないと感じている。

　書きながら自分が導き出した結論というのは、所謂偏見の類以外は自分の中に再現性がないと思ったほうがいいくらいかもしれない。偏見は自分の人生経験と密接に結びついているのでそう簡単には消えてくれないが、閃きは一度形にしてさえあっという間にどこかに飛んでいく。メモしただけでは忘れるのと同じで、きちんと手間をかけて文章にしたってそれだけではあっさり忘れてしまうのだ。
　つまり、自分自身が繰り返し読み返すことで自分の書いた文章というのは完成されていくのだと思う。文章そのものは書き直さない限り変わらないが、その文章を書くという行為の周辺にあったことの、自分の人生に於ける意味が、読み返しによって豊かになっていく。

　何かを書こうとしているその一瞬だけ自分は過去にないほど天才的になり、その天才性は書かれた文章によって保存されている。自分自身は瞬く間にポンコツになっていくけれども、文章さえ書けていれば、その時一瞬だけあった己の聡明さに後から頼ることができる。
　それは非常に不思議で面白いことだと思う。たとえ向上心高く常に前進して総体としては賢くなり続けていても、一瞬の天才性がずっと維持されるわけではない。しかし形になっていれば失われっぱなしにならずに済む。
　やはり何より自分のために、自分の思いは形にしておくべきだと思う。それを公開するか否かは別だが、公開しなくともきちんと格闘して言葉にするのが自分のためになるだろう。
　

興味深い投稿が続いてとても楽しいです。使っていて自由を感じるツールだ、と言った場合に関連する要素というのは複雑に絡み合っているなと思いました。

ちなみに私が今最も自由を感じるツールは、自分で作った日記兼ひとりチャット兼ひとりWikiなツールです。自分に必要な機能というのが、シンプルなアプリケーションが提供してくれるものよりも複雑で、且つ既存の「色々できるアプリケーション」でできることとは一致しないからです。個人的には、（褒めておいてなんですが、）世にあるシンプルなアプリケーションはあまり相性がよくありません。（そうでなければわざわざ自分でツールを作ろうなんて思わないのですよね。）
今使っているツールになぜ自由を感じるかと言えば、過去の記述は自動で視界から除かれ、見たい情報を見たい形で見ることができ、情報と情報の繋がりを自分の求めるように作れるようにしているからです。あとはフォントとか色とか余白といった見た目の問題もあります。

さて本題です。
そこかしこで議論されていることだとは思いますが、自分の認識の整理を兼ねて考えていることを書いてみようと思います。
ツールを自由に使えるという時に必要なことは、大きく分けて以下の三つの要素を満たしているものと考えています。（私はこう思いますが、全然それだけではないかもしれません。）

1. 操作に迷わない（UIの問題）
2. 自分に必要なものがある（機能・情報・心地よさ）
3. 自分に不要なものがない（機能・情報・違和感）

私の投稿（解釈の余地がない且つ無限の解釈があり得る）では、WorkFlowyとScrapboxの間に共通しそうなこととして、主に三つ目の「不要なものがない」のうち「不要な機能がない」ということに着目しました。加えてこの二つのアプリケーションの設計思想から複数人で共同で使うことに焦点を当て、「操作に迷わない」点にも少し触れました。
続く倉下さんの投稿（自由に使うというアフォーダンスは可能か）では、個人にとっての話からツール側の視点に移り、アフォーダンスに焦点が当てられました。「操作に迷わない」ということと、「自分に必要なものがある」に含まれる「自分に必要な（自分を導く）情報がある」という要素の話だなと私は解釈しました。
そしてtksさんの投稿（自由に使うためには「定期的なリセット」と「見えなくすること」が大事かもしれない）と倉下さんの投稿（見えなさと随意操作）で、「不要なものがない」のうち「不要な情報がない」ことについて語られたと思います。tksさんの投稿にあった「『自分で』操作しなければいけないところが窮屈さに繋がっている」という感覚には深く共感します。私も同じタイプです。（ついでに言うと「初対面はいいけど…」というのも同じです（！））
いずれの要素でも、核にあるのはやっぱり「見えるか見えないか」です。見えてほしいものが見えて、見えてほしくないものは見えない、というのがツールの使用感を滑らかにするわけですね。

操作に迷わない

優れたUI、そうでないUIというのは、大体誰にとっても同じように感じられるものと思います。良いUIは大抵みんなにとって良いUIでしょう。洗練されたアフォーダンスで、各要素の意味するところが限りなく自明に思えるようなUIが好ましいです。「自分以外の人間によって作られたもの」ならばほぼそうです。
他方、自分が自分のために作ったものなら必ずしもそうではありません。自分の中に迷いが生まれないのなら、UIとしては多少変でも構わないわけです。
誰にとってもわかりやすい美しいUIと、自分にしかわからないけど自分は不自由しないUI、そのいずれかが「自由」には必要なのではないかと思いますが、前者に頼るだけでなく偶には後者について考えてみると色々面白い発見があると感じています。

また、この「操作に迷わない」というのは必ずしも「使い方に迷わない」ということを意味しているわけではないというのも肝心かなと思います。ノートとペンがある時、「ノートにペンで何かを書く」という動作に迷うことはありませんが、「ノートをどう使うか」は全然自明ではありません。同様に、操作に迷うところのない洗練されたアプリケーションだからといって、それをすぐさま自由に使えるわけではないでしょう。汎用性が高ければ尚の事です。
では、アプリケーションに出会ってすぐに水を得た魚のようにすいすい使えている人がいるのはどうしてか。それは前々から水を欲していた魚だからだろうと思います。つまり、自分の中にまず「これをなんとかしたい」という切実で具体的な要求があり、それをツールに当てはめてぴたりと嵌ったと感じた場合に「これはいいぞ！」と感動する。必然的に、要求の解像度が高いほど、ツールとの相性は厳密なものになっていくと思います。

自分に必要なものがある

機能、情報、あるいは使った時の心地よさの面で、自分に必要なものがある（もしくは見えている）、というのは言うまでもなく重要なことと思います。自分がやりたい操作をやれる、自分が見たい情報を見れる、自分の感性に合った見た目をしている、それらが揃った時にツールに対して強い愛着を持つのではないでしょうか。自分をプラスの方向に引っ張ってくれるツールだという感覚です。
これは多分当たり前のことなのですが、しかしその一方で、自分と相性の良いツールを見つけるには自分に何が必要なのか知っていなければならないということでもあり、それは結構一筋縄ではいかない難題のように思えます。
自由に使うというアフォーダンスは可能かで語られていたのは、自由に使うということをツール側が導けるかということだったと思いますが、これはつまり、自分のことがまだ十分にわかっていないユーザーに、ツール側が可能性を提示することで、「あ、こういうことをやってみたいかも」と気づかせるということなのではないかと思いました。欲求の自覚に向けて牽引してくれるということです。
それがひとつのツールで可能かは倉下さんが仰るように未知数です。「自由」という状態自体が人それぞれ千差万別な気がするからです。

「色々なツールを試す」というのはよくあることと思いますが、これは自分が考えていなかった発想にリーチする上で非常に役立ちます。そのツールを継続使用することにはならなくとも、自分をどこかに導く情報をツールが備えていることがしばしばあるからです。ツールの設計者が意図しないものであることも多いでしょう。
何かのツールをうまく使えている人には、数多のツールを渡り歩いてようやくここに辿り着いた、というような表現をする人がとても多い印象があります。それは「自分に合うツールというのはなかなかない」という事実とともに、「これだ！」と感動できるほどその人は自分の要望の解像度を上げてきたということも示しているように思います。
ツールが規定しているもの以外の使い方をしようとするという「自由」の背景には、切迫した自分の要望のほか、他の道具を使うことや他の人のあり方を知ることで思いついた使い方を転用したい、という気持ちがあるのではないかと思っています。

自分に不要なものがない

逆に、自分をマイナスの方向に引っ張らないということも重要と思います。見えてしまったら無視できない（無視できる人もいますが、無視できない人は無視できない）ので、如何に上手に不可視化するかが鍵になるでしょう。
tksさんが書いていらっしゃったような「過去」の影響力というのを私も強く感じています。「過去」つまり「今より前」のことというのは、視界に入ると「今」を「それ以前の延長」にしようとする力をもたらすような感じがするのです。手動でアーカイブ送りにするとなるとその作業をする時点で視界に入れざるを得ないので、影響を受けやすい質だとそれだけで気分が引きずられてしまいます。
なので、過保護な親のごとく、自分が朝起きた時にはその日の自分にとって過去のものをすっかり取り除けておいてくれると気が楽になります。実際の親にはそう甘やかされない方がいいですが、ツールには手厚く先手を打ってもらってもいいだろうと。
ただ、どの程度「見えない」のが良いのかというのは情報の内容次第なところもあります。強制的な不可視化と意志的な不可視化についての話がありましたが、一口に「見えない方が良い」と言っても、「『今』からすっかり切り離したい」なのか「今はちょっとコンパクトになっていてほしい」なのかは感覚としては結構違うと思います。視界の中に存在していて良いのか良くないのかが違っています。tksさんが敢えて二つに分けてお考えになっていたのもそういうことかなと思いました。この二種類の区別をつけるには、強制的な処理と自分の意思での手動の処理の二通りがどうしても必要だと感じます。全自動で全てを片付けられてしまってもそれはそれで困るのです。

あと「自分に不要なものがない」という点では、「見た目に違和感がない」というのも大事だと思います。なので、自分でスタイルを変更できるようになっていれば、機能としては全く変わらなくとも「自由」な感覚はずっと豊かになると思っています。
自分がどの程度「不要なもの」を無視できるタイプか、というのはわかっておいた方が良さそうだという感じがしてきました。「自分に必要なものがある」と「自分に不要なものがない」を天秤にかけた時に、どちらを優先すべきかがそこで変わってくると思うからです。

それぞれが何に「必要」を感じて何を「不要」と思うのか、というのは見聞きしていてとても楽しいポイントと思います。共感できることもあればできないこともあるでしょうが、自分との合致性がどうであれ知った分だけ面白くなる気がしています。

（話の流れを俯瞰したかったので自分の理解を整理しましたが、話をまとめて畳んでしまおう的な意図は全然ありません）

　ブログを無理なく書けるようになろう、という話の第十一回。過去の回の記事はブログの書き方ド下手問題からどうぞ。

　今回は、せっかく書いた自分の文章に「そりゃそうでは？」と批判の目を向けてしまう問題について考える。

　他の書き手がどうかは正直全然わからないのだが、私は記事を書いていて「これは当たり前の話では？」と思って価値を疑うことがかなりよくある。そう自己批判してブラッシュアップするというのは大事なことだけれども、これ以上どうにもしようがないという内容でもそう考えてしまうのはただ自分を辛くするだけという感じがする。
　なんとか投稿の手を止めないでいられるのは、少なくとも自分語りの部分に関して「自己についての発見は自分にとっては当たり前ではない」という保証があるからだろう。しかし自分以外のものについての発見は何を書いても「そりゃそうでは？」という気持ちに苛まれ、自分語りをあまり含まないものは投稿ボタンを押すのにかなりの気力を必要とする。
　例によって、私自身が困っているのでこのことについて考えたいと思う。

本当に「そりゃそう」なのか？

　まず、事実として自分の書く内容が「そりゃそう」なものなのかどうか、ということを考える必要があるだろう。
　といっても、それは自分では判定できない。それこそ「そりゃそう」である。自分以外の人が読んだ時にどう感じるものかというのはどう頑張っても事前に察知しようがない。
　しかし一切判定できないわけでもない。少なくとも、自分自身はそれを書いてみるまでそれは当たり前ではなかったはずである。ということは、それを書く前の自分がよっぽどの無知蒙昧でない限りは、その内容を「そりゃそう」と感じない人がいくらかはいると思ってよいのではないか。「そりゃそう」と思う人が多数派である可能性を排除することはできないが、全ての読み手にとって「そりゃそう」なわけではないということは言えそうである。

「そりゃそう」が生まれる理由

　自分自身は書いてみるまで当たり前じゃなかったはずなのに、書いてみると途端に「当たり前では？」という気分になる。それはそもそもどうしてだろうか。
　当たり前のような気がするというのは、元々知っていたことのような気がしているか、理屈が単純で展開が必然的過ぎるような気がしているか、のどちらかのように感じる。
　この感覚はとても厄介である。自分の中から生まれたことなのだから、言語化以前の状態では既に自分の中に存在していたことだろうし、自分が書いたものであれば自分の理屈に必然のように納得してしまうのも当然のことだ。書きあらわした時点で、その内容は自分にとっての常識としてもう自分に組み込まれてしまっている。
　今まで自分が読んだことがないような話を書いてみたのだとしても、他の人達は既に知っている記述を自分が見ていないだけだとか、当たり前過ぎて今更誰も言わないだけだとかいう可能性は捨てきれない。

　更にそこに「自分ごときがわかるなら他の誰もがわかるはずだ」的な自己評価が加わると当たり前感が跳ね上がる。それを言い出したらおしまいなのだが、そう思い始めると振り払うのは容易でないと感じる。
　書こうとしているのが「新しいものを咀嚼する」という類の内容ならば、自分が咀嚼できたということで多分納得できる。しかし既にあるものを見つめ直して何かを言うというようなことをする時は、それがもし「自分だけが今更気づいた」ということだったなら、それを発表することが自分や他者にとってプラスになるかわからない。その可能性が高いかもしれないと思うと何も言えなくなってしまう。
　これについては、自分の発想の程度について忌憚のない意見を言ってくれる知人がいない、というのが大きな問題かもしれない。（信頼関係を築いていない人の評価は本気の批評なのかそうでないのか判別できない。）
　リアルの友人は文面でググって辿り着かれると私としては困るので見せられない。ネット上の友人は今のところ全然違う趣味での繋がりであり、こういう文章を読んでもらうような相手とは言い難いし、違う名前でやっていることなのでこれもまた文面でググって辿り着かれると困る。
　この「辿り着かれると困る」というのは私の個人的な理由なので、そういうのがない人は普通に親しい友人を付き合わせて批評してもらうのが自信に繋がる有効な手なのではないかと思う。

　あるいは、世にある記述を網羅するくらいに読みまくって、実際にこの世に何が書かれていて何が書かれていないかを知るのが一番早いのかもしれない。途方も無い遠回りに思えても、最も確実で結局近道になりそうである。本を読むのが苦手な人間にはかなりしんどい道だが、避けていてはいつまでも不安から逃れられないとも思う。
　『独学大全』を読むと自分が如何に怠惰かわかるし、自分を不幸にしているのは自分であると感じる。

「そりゃそう」なら駄目なのか？

　ただそもそもの話、「そりゃそう」なものを「今更」書いたら駄目なのだろうか、ということは考える必要がある。博覧強記の人からしてみれば、いま世の中にある文章の大半が「今更」に思えるのではないか。一体何回、この次元の話を繰り返すのか、と思うかもしれない。
　私自身（そしてきっと皆さんも）、おんなじ内容のものを何度も見かけるということは常日頃当たり前に体験している。各々の書き手が「その内容は既に世界に溢れている」ということを知っているのかいないのかわからないが、知っていようがいまいがそれらは発表されたのだろうし、既に世界に溢れているはずのその内容が全ての人に染み渡っているかというと到底そうは思えない。
　例えば「人ってご飯食べないと死ぬんですよ」レベルの「そりゃそう」はさすがに何の価値も生みそうに無いが、「人って寝ないと死ぬんですよ」となると「そりゃそう」度合いはもう半分くらいになりそうである。いや、もちろん概ね「そりゃそう」ではあるのだが、その一方でなんで死に至るのかはそんなに自明ではないし、どのくらいの不足でそうなるのかも明らかではない。死の原因が睡眠不足であったことがわかられていないケースもあるだろう。わかっている人はわかっている話だが、わかっていない人もいるかもしれない、というくらいになってくる。そうなると、それを知らせる記述はなんぼあってもいいですからね、という気もする。

信念はどこにある？

　この「今更」問題については私自身三年以上前に考えたことがある。

誰かにとっての「今更」は誰かにとっての「今」だ、という今更のこと

　一応答えは出ているのだが、それなのに今スッキリしない気持ちが残っている。なぜかと考えてみて、思い至ったのは信念の所在である。
　この三年前の記事内で出た結論では、まさに今その段階にいる人のために書くのだ、ということが自分を納得させうる理屈だった。今もそう思うし、そう思っている限りは無敵のような気がする。
　また、先程取り上げた「人って寝ないと死ぬんですよ」の例を考えれば、とにかく睡眠不足で命を削っている人を救いたいという強い思いがあればいくらでも繰り返し発信できるだろうと思う。他にもそれを言っている人がいるかどうかは全然関係ないし、むしろ同じことを言う人が多ければ多いほどいいくらいである。
　つまり、「○○な人のため」という目的があれば、「○○な人」がこの世に存在する限り立ち止まらずに続けていられることになる。立ち止まっているのは「○○な人のため」という思いがなくなっているからではないか。
　例えば今この記事を書いていられるのは、「自分と同じ悩みを抱えている人のため」ということがあるからだ。全然しょうもない文章かもしれないけれども、それでも自分と同じ悩みを抱えている人の力にちょっとでもなれたらそれでいいと思って書いている。

　ノリノリで投稿している記事と同じテンションで書いているつもりでいるのに投稿に躊躇う時がある。それは多分、「○○な人のため」という意識が欠けている時なのだと思う。じゃあどんな意識でやっているのかと言えば、「自分（の文章）が面白いかどうか」である。自分の存在意義に意識が向いている。だから「もう常識かもしれないことを発信してどうするんだろう」という思いに支配されることになる。みんなが知っていることを書いていたんじゃ自分の文章には価値がないんじゃないか、という発想だ。「みんなが知っていることを書いても意味がない」というルールのゲームを自ら設定しているということである。
　この状態にあるかどうかを判別するのは簡単で、「そんなのもう知ってるよ」と言われた時にダメージを受けるか受けないかを考えればいいだけだ。もしダメージを受ける状態にあるとしたら――オリジナリティによって自分の存在意義を証明しようとする試み自体が悪いわけではなくとも――発信者が過去に星の数ほど存在し、そして今この瞬間にも夥しく発信がなされているこの世界にあって、あまりにも無茶なことを成そうとしていることになるのは確かだろう。
　別に世紀の大発見をしたいわけではないにしても、「そりゃそうって言われるんじゃないか」と恐れるのは、つまるところそういう価値を勘定していることに他ならないのではないかと思う。

　誰かのために動くのなら、「そりゃそうでは？」なんて迷っている暇はきっとない。
　

　WorkFlowyとScrapboxの共通性がどこにあるかという話が話題にのぼっていたので、ちょっと考えてみました。

関連記事・ツイート

• https://gofujita.info/notes_workflowyJesse.html
• WorkFlowyの魅力について｜倉下忠憲
• https://twitter.com/gofujita/status/1690472047066107904
• https://twitter.com/rashita2/status/1690512911402475520

　といっても私はWorkFlowyユーザーではないので（試してみてやめたというのではなく、Dynalistから入ってこれがいいとなりました）、具体的に素晴らしさを語ることはできませんが、WorkFlowyの見た目や他の人の体験談から感じたところを書いてみたいと思います。

「ある」というストレス

　何かが「ある」ということは、なかなか無視できないものと思います。誰かがそこにいる、何かがそこにある、何かの音がしている、何かの匂いがする、個々人で程度の差はあれど常日頃そういったものから影響を受けているはずです。
　ツールでも同じです。自分に合う機能が「ある」ということ、自分に合わない機能が「ある」ということに、やはり影響を受けるものと感じます。
　自分に合わない機能がそこに存在しているというのは、そんなことが些末に思えるほどそのツールを気に入っているか、何かが「ある」ということから元々影響を受けにくい体質か、そのいずれかでない限り、いくらかはネガティブな影響を受ける気がしています。早い話が「邪魔」だとか「余計」に感じるのです。物理的に場所を取っているわけではないとしてもです。視界に入るというのはそのくらいの力があるのでしょう。

　自分の要求の何かに沿った機能があるという場合にも、それが常に良いこととは限らないかもしれません。いくら自分の需要に沿っていると言っても、本当に100%沿っているわけではないかもしれませんし、自分の需要自体が形を変える可能性もあります。そうなると、高いレベルでマッチしているツールに、マッチしきっていない部分に目を瞑って自分が合わせようとしてしまうこともあり得ると感じます。
　それが無意識化で行われている時、うっすらストレスが溜まり始め、ある時ふと「なんかもっとシンプルなツールないかな」という気持ちとなって現れるような気がします（これは推測です）。

　ここで肝心なのは、「合うものがある」にしろ「合わないものがある」にしろ、その影響を「受ける」ことになるということです。否応なしに受けてしまうのです。
　でも逆に「ない」ことに対しては、自分が能動的に考えを巡らせることができるのではないかと感じます。WorkFlowyもScrapboxも「ない」機能があるわけですが、そのことについて私たちは自分で意識的にどうするかを判断することになるでしょう。
　もし余計なものが何もないとすれば、ユーザーはいつも能動的でいられるということなのかもしれません。

解釈の余地がない且つ無限の解釈があり得る

　シンプルシンプルと言いますが、シンプルというのは要するに何なのか。それを考えると、「解釈の余地がない、且つ無限の解釈があり得る」ということだと私は思います。
　WorkFlowyやScrapboxは、パッと見た時に自由過ぎて戸惑うということはあるかもしれません。自分で道を見いださなくてはならない戸惑いです。「例えばどう使うのが効果的なんだろう」とヒントを得たくなる心境です。しかしそれは「正しい使い方は何だろう」という疑問とは異なるものと思います。つまり、「このツールをどう解釈しなければならないのか」という正解探しからは無縁なのではないかと思います。
　もちろん、正解探しの生活に順応しすぎて何にでも正解を探そうとしてしまうというユーザー側の個人的な（あるいは社会的な）問題はあり得ますが、それはツールの設計のせいではないわけです。

　他方、ある目的のための機能が付与されているツールでは、その機能があるということに対して、「目的として設定されていることを正しく解釈する」という必要が生じます。無視してしまってもいいのですが、何らかの目的があることをわかっていながらそれに一切興味を向けないというのは誰にでもできることではないことと思います。わかった上で敢えて違う目的に使うということはしばしばあるでしょうが、それはまずわかるという段階を踏んでのことになります。
　複数の機能が搭載されているとなれば、それらを併せて使った時に達成されるものが何なのかを解釈しようとするでしょうし、その上でそれに沿うか敢えて無視するかを判断することになります。私たちが普段から特別意識せずにやっていることですが、そのことがなんとなく煩わしさを生じているということはあると思います。

　Goさんの記事の中で、

アウトラインを個人ひとりが操作するだけでは不十分で、複数の人が自由に操作できる機能を重視している訳です。

　とありました。Scrapboxも共同編集で本領を発揮するツールでしょう。これができるためには、誰が使ってもツールに対する解釈に差が生じない必要があると思います（ただし自由だということ自体をわかるために慣れが多少要るとは思います）。
　少し専門的なツールを採用して教育によってそのツールに対する解釈を統一するというのはよくあるケースかと思いますが、そういう強引さを解消できるのがWorkFlowyやScrapboxのようなツールなのかもと思っています。

　同時にWorkFlowyやScrapboxには無限の解釈があり得ます。いずれのツールも、その設計からユーザーが導き出せるものが個々人で違うと感じます。それはツールが予め定めた読みではありません。きっとここが肝なのだ、と各々が判断して、「じゃあこう使おう」と決めることができるのです。
　そして面白いことに、自分以外の人が導き出した解釈を見ると大抵「なるほど確かに」と納得できます。ちょっと立ち位置を変えて見るとそういう姿が浮かび上がってくる、ということが容易に想像できるのです。
　それは「紙の使い方」が無限なのと同じことだと思います。その無限さを邪魔するものがなければ、ある基本的な仕組みが持つ可能性というのは無限にあるものなのでしょう。WorkFlowyもScrapboxも紙よりは限定的かもしれませんが（紙にはないデジタルならではの自由さを加えてもです）、それでも無限と思えるような解釈の可能性を感じます。
　デジタルツールで追求しうる「基本」はおそらくいくつかの方向性があり得て、それら全てを包括した万事の基本となるツールというのは追究され続けながらもまだ実現されていないと思いますが、WorkFlowyとScrapboxはそれぞれひとつの方向の「基本」を実現しているのだと私は感じています。
　具体的に「基本」とは如何なるものなのかというのはまた別に考える必要があると思いますが、ツールの設計そのものについての見識が私は十分でないので踏み込まないことにします。

　ふわっとした話になってしまいましたが、自分が感じていたことをちょっと頑張って言葉にしてみました。

デジタルツール界のイーブイ？

　余談ですが、WorkFlowyやScrapboxのようなツールはポケモンで喩えると「いつでもイーブイに戻れるイーブイ」という感じがします。進化するもよし、しないもよし。
　イーブイが愛されるのと同じように、WorkFlowyやScrapboxはその可能性の広さと何びとも拒まない愛嬌を愛されるのかもしれません。
　

　ブログを滑らかに書けるようになりたいという話の第十回。過去の記事はブログの書き方ド下手問題からどうぞ。

　短文投稿サイトの重用を避けて諸々をブログに書くことにしようと思い始めたのだが（そう思って既に結構経つのだが）、なかなかそうはいかないでいる。
　誰かが書いた記事を読んだ時に、「あっ、それわかる」「この文すごくいい」といった感想を持つことがあり、それを何らかの形で表現したいと思うのに、それを表現するのが思いの外難しくていつも困っている。自分の中にエネルギーがワッと湧いた気がするのに何も生まれないのである。
　今実際に悩んでいるので、記事を書くことを通じて解決を試みたいと思う。

　湧いてきたのがシンプルに「良いと思った」という気持ちだけなら、その記事のコメント欄に書くか、SNSで言及するのが手っ取り早いだろう。そして筆者の目に留まって、筆者もわーいと喜ぶかもしれないし、筆者にキャッチしてもらえたというので自分も嬉しいかもしれない。それで終わっていいことなら、それでいいと思う。
　ただ、それだと自分の発信としては蓄積にならない。批評性も創造性もないし、コメント欄に書いてしまったら自分がそこに書いたということすら自分の履歴から離れてしまう。発信したい側の人間としては、どうにか自分の発信として意味のある形にしたい。

　選択肢としては二つあるだろう。ひとつは、何かしら膨らませて自分の文章を綴ることだ。今私が目指そうとしているのもこれである。もうひとつは、例えば期間を区切って「今週の気になった記事」というようにパッケージにしてしまうという手だ。記事ひとつあたりにつけるコメントはごく短いとしても、それを複数まとめることで記事として意味を持つ。
　あれこれたくさん読むよという人は、ひとつひとつを膨らませるより記事まとめを作ってキュレーターとして発信するのがいいのかもしれない。あれこれたくさん読むということそのものに十分な価値があるわけである。
　私の場合はそんなにアンテナを張るタイプではなく、知的好奇心に溢れているたちでもないので、多分そういうのは向いていない。それよりも「あっ、これいい」と感じた時の自分の反応の解像度を上げて文章にした方が自分に合っているだろうと感じる。

　そう思うものの捗っていないわけだが、何の苦労もなくするする書ける時も偶にはある。しかし大半は形にならないままになる。元の文章に対するテンションは変わらないような気がするのに、アウトプットには大きな差異が生じる。その違いはどこにあるのかを考えておこうと思う。

　文章にできる形でワッと何かが溢れてくる時、それは一言で言えば「自分語り」になるだろうと思う。そもそも表現というのはある種の自分語りなので当たり前と言えば当たり前の話だ。自分の体験にもこんなことがあった、自分もこれまでにそれを考えたことがある、自分の専門分野とここの部分が重なる、自分の中で今こんなイメージが生まれた……といったことである。自分そのものを語るつもりはなくとも、自分を通さなくては自分なりの文章は出てこない。（するする書ける時というのには自分の知見を元に解説を書ける時というのもあるが、今回はそのパターンは除いて考える。）
　で、テンションは上がったのにいまいち何も生み出せない時というのは、その対象を十分に自分に引き寄せられていないということなのだろう。漠然と「いい」「すごい」「面白い」と思うに留まり、それが如何に鮮やかな感動であっても、「自分語り」に接続できない以上は言葉になっていかない。

　何かを読んでいて、「解釈」が生まれることがある。というか、常に自分の解釈を生みながら読み進めているはずだが、その中でも「これはきっとこういうことなんだ」と強く思うということがある。自分の中では電球がピカーッと光ったような感動がある。じゃあそれが文章になるかというと、案外そうならない。
　よく、「これはこういうことなのだと思いました」という感想に終わってしまうことがあるだろうと思う。自分もそこに留まらざるを得ないこともあるし、人の記事のコメント欄やTwitterなんかでもしばしば見かける。そこには「人によってはその部分をそう解釈するらしい」「その部分がその人にとっては印象的だったらしい」という情報は含まれるが、その人の内側にあるはずの属人的な豊かさはほとんど表現されていない。放たれた言葉がその人の深部を通ってきていないから、その人のことが見えてこないのである。
　別にそういうコメントが駄目という話をしているのではない。そもそも自分語りは義務でも善行でもないのだから、それ以上膨らませる必要を感じていないのならそれでいいのだ。
　ここで言いたいのは、「これはこういうことなんだ」という感動だけでは、その感動の大きさの割に必ずしも表現には結びつかない、という悩みがあることである。人の文章についての咀嚼・解釈に個性はそんなに現れない。読解は筆者が意図する意味合いに迫る試みであって、そこに自分の創造性がやたらと反映されていてもおかしい。やはり咀嚼の次の一歩が必要である。筆者のフィールドの探索の後に自己のフィールドへと帰り、自分のフィールドで何かを芽吹かせることでやっと表現に至るように思う。

　するする書ける時はするする自分語りをしているということになるが、そういう時に自分は一体何を書いていることになるのか、というのは思いの外わからないものではないかと思う。自分で書いているのだが、その書いたものが何なのか自分ではっきりしないのだ。個人的なことを言えば、そもそもはっきりしない領域――私という個人に於ける総合的な領域――を書こうとしているというのもその一因であろう（あるいはそれが唯一の原因なのかもしれない）。
　しかし、もし自分の表現をコントロールしたいのなら、そう博打的なままでいるわけにはいかない。狙って出力できるようでなければと思う。その手がかりとして、今まで実際に自分が滑らかに書けた時のパターンを分析してみるのは有効な手だろう。
　個々人でパターンは異なると思うのでこう書けばよいという話にはならないが、まず私自身について考えてみよう。私が一番饒舌になれるのは、誰かが書いた何かのテーマに関連付けて、自分の人生に実際にあったことを書くことだと思う。「そりゃそう」と思われるかもしれないが、言い換えると「自分の見解」を書くことではないということだ。「そりゃそう」度が少し減ったのではないかと期待するが、自分はこう考える、こう予想する、こう想像する、ということではなく「私の身にもこういうことが実際にあった」という体験を書くことでテーマに寄り添いたいという気持ちがある。そして自分の体験が伴わない想像はおそらくかなり不得手である（ということに今気がついた）。不得手だし多分あんまり興味がない。
　しかし誰かの話に「これはこういうことか」と感動した時というのは、そのままその感動を膨らませるならば「自分の見解」を膨らませることになるだろう。それこそ得意なパターンだ、という人はたくさんいるように思うが、私の場合はどうもそこにうまくいかない原因がある。

　私が開拓するべき道は二通りありそうだ。ひとつは「なんとしても自分の人生に繋げる」という道、もうひとつは「自分の人生に依存しない語りを身につける」という道だ。いずれにせよどちらも必要だと思うが、後者はかなりのトレーニングが要る気がしている。でも格闘しておかないと私にできる語りはそう遠くないうちに枯渇するおそれがある。
　現状、面白いと思ってもらえるものは私自身の解像度を上げることに取り組んだ文章が多いので、前者の自由度を上げるのも私にとっては大事だろうと思う。豊かでユニークな人生経験などというものはないのだが、その代わりに自分の人生をできる限り細かく把握して自在に取り出せるようになりたいと思っている。そういうことにかなり強度の関心があることは確かだ。

　他の手として、自分が活発に取り組める範囲で切り口にテーマを設けるという方法もあるだろう。読んだ記事について、例えば「メタファーを考えてみる」とか「川柳にしてみる」とか「似た話を含む本を取り上げる」とか、何でも良いのだがそういうシリーズを勝手に作って取り組むというのはひとつの取っ掛かりになると思う。
　自分が得意で強い興味がある領域でないと続けられないのが難しいところだが、そういう何かが自分にあればいくらか面白いことができるだろう。

　お読みくださっているみなさんの場合はどうだろうか。
　

　日々様々な記事をインターネット上で読んでいる。たくさん読む方ではないが、ネットを見ていればそれなりの量を読んでしまうものである。
　で、読むのは良いのだが、読んだ後にどうするか。というか、読んでいる最中に湧いてくる感想や思いつきはどうしたらいいのか。

　これまでやっていたのは大体以下のようなことである。

• 読んで面白かったものは丸ごと保存する（Evernoteなど）
• 一部をコピペして保存し、下に感想などを書き添える（Scrapboxなど）
• SNSやチャットツールに共有して感想も呟くことで記録代わりにする（Twitter、LINEなど）
• 心に残った一文はノートに書き写す

　やらないよりはやった方が良いというのでずっとやってきたが、正直なところ全然納得感はないままだった。どんどん溜まっていっているのだが、いまひとつ見返したくならない。

ねぎま式読書ノート

　「ねぎま式読書ノート」というノート術がある。奥野宣之氏が著書『読書は１冊のノートにまとめなさい』で紹介している技法で、抜き書きと自分の感想をそれとわかるようにそれぞれ頭に記号を付けて交互に書いていくというものである。

• 本を読みっぱなしにしない！確実に自分の血肉にする5つの技術 | 読書は１冊のノートにまとめなさい［完全版］ | ダイヤモンド・オンライン

　前提として、これは手間をかけてでも読書ノートを作りたいと思うレベルの良書についてやるもので、全ての本についてこれをやるわけではないとのことである。書き写しには相当な労力がかかってしまうので、現実的にやれる範囲で妥協する必要がある。

　一方、Web記事を読んでデジタルノートにメモを取るという時は、紙の本を読んで紙のノートにメモを取るのとは違って、転記は一瞬で済んでしまう。紙面の制約もないから、上から下へ無限にノートを作れる。特にねぎま式はただ交互に書いていくだけなので、自由に配置しづらいというデジタルツールの制限にも影響を受けない。奥野氏の話を知らなくとも、デジタルツールにメモを取るとなれば自然とねぎま式になるかもしれない。例えばScrapboxで見かけるのは大体当たり前にねぎま式になっている。方法としてはねぎま式とデジタルツールは相性が良いように思われる。
　しかしやはり、紙のノートにねぎま式に書くのとデジタルツールでねぎま式に打ち込むのとでは勝手が違っていると感じる。厳選するかしないかという判断で量的にも質的にも変わってしまうだろうし、またそれ以上に平面のレイアウトが存在しないということが見やすさ（というかパッと見た時の認識しやすさ）を減じている感じがある。紙のノートに書く場合、書いている間はレイアウトを考えてはいないが、結果として何ページのどこに何を書いたかという位置情報が生まれる。
　よく受験生が写真を撮るように教科書を内容を記憶してしまうという話があるが、「何ページのこの位置にこの記述がある」という情報の威力は記述を把握する上で馬鹿にならない。自分の手で作ったノートにはそれが発揮される。デジタルツールでは表示が固定されないし追記でレイアウトが変わったりするので、位置の情報は使いにくい場合が多々ある。

　また、この「表示が変化する」ということが、「自分が作ったノート」への愛着を減らしていると感じる面もある。作り上げている感がちょっと足りないのである。情報が溜まっていけば「これだけ溜めたぞ！」という量的な満足は生まれるのだが、「作った」という感覚がいまいち感じられない（私だけかもしれない）。
　そもそも愛着とか要る？という議論もあり得るだろうが、私は必要としているし、考え直すことで「愛着は要らない」という結論に至ることはないと思われるので、そのそもそも論については考えないこととする。

レーニンのノート術

　レイアウト要素なしに上から下に書き続けるというのがこの傾向を増しているので、デジタルで別の形態を再現できないかと考えることにした。
　次に思い当たったのは、レーニンのノート術である（『哲学ノート』がそれである）。佐藤優氏が著書『読書の技法』で詳しく紹介している。
　片側に余白ができるように抜き書きし、余白に自分の感想を書いておくというもので、本文と自分の感想が位置的に区別されているので見た目に明快である。抜き書きが自分の感想で分断されることがないので、引用だけを追うのも簡単になる。レイアウトとしては学生時代に教科書や参考書で普通に見かけたはずの形式だが、あまりにも普通に見かけるがゆえに、見た目からは逆に意義を見出しにくいかもしれない。
　レーニンが書いたものの実物については、こちらの記事の後半に写真が掲載されている。

• 難しい本を挫折しがちな人のための２つの方法ー読書の手すりと杖（中級編） 読書猿Classic: between / beyond readers

　これをデジタルでやるとすれば下方向には無限に書けることになるだろうが、左右の列の区別やその「幅」の概念があることで、交互に書いていく形よりは位置の情報を感じやすくなる。列の幅を固定し、自動で横方向の伸縮をすることがないようにすれば、感覚としては巻物のような感じになるだろう。

　レーニンノートはレイアウトとしてはシンプルで、紙に書く分には実践は極めて簡単なのだが（片側に余白を取ればいいだけだ）、しかしながらデジタルで再現するとなると地味に面倒である。普通のテキストエディタ類ではできないし、付箋っぽいツールだと長文を扱うのには向かない。自分で作ってみることも考えたが、とてつもなく面倒くさいことになる感じがして諦めた。
　ふと、レイアウトを扱う文書ソフトと言えばWordじゃないかと思ってちょっと試してみた。テキストボックスを使って脇に自分の感想を書いてみたらまあ悪くない。悪くないが、微妙に手間を感じる。印刷レイアウトだと縦方向の連続性が少し失われるのも、今回に限ってはちょっと妨げに感じる。この先ずっとこれを継続するのかと考えるとちょっと無理そうな感じがした。最初のひとつを作ってみた時点で「継続は無理そう」と思ったものが続くはずはないので、惜しいと思いながら却下である。

OneNoteを使ってみる

　子ども時代にWordやExcelを遊び道具にしていた人間なのでまずそれらを思い浮かべたが（関連：Office日誌：思想を自分の手に取り戻そう）、いや今ならそれより相応しいものがあるじゃないかということにちょっと遅れて気がついた。例えば、同じくMicrosoft製のOneNoteである。クリックだけで好きな位置にテキストボックスを生成でき、簡単に好きな幅に調整できる。
　試しに作ってみたのがこちら。

　基本的に今やらんとしていることのターゲットはWeb記事だが、サンプルとして見せるには支障を感じるので青空文庫から適当な文章を探して、高村光太郎『美の影響力』に行き着いた。短い文章だが切れ味鋭くて面白いので是非読んでみて欲しい。
　真ん中が本文をそのままペーストした部分で、左に自分の感想、右に要点を書いている。特に重要な文を太字で目立たせ、キーワードやフレーズにハイライトを付けた。手書きも使えるので、（この例では特に意味をなしていないが）色ペンで波括弧や線を描いてみた。

　OneNoteについては、面白いなと思いながらも普段はプレーンテキストを扱ったツールを重用しているので使い道を見いだせずにいたのだが、これはなかなか良い使途ではなかろうか。
　UIの面で正直不自由を感じる部分がなくもないのだが、それに目を瞑ってでも続けたいという気持ちになる。OneNoteの機能はまだ全然把握できていないので、「OneNoteってめっちゃいいじゃん！」と思う要素をこれから発見できるかもしれない。

　Web記事ひとつに1ページ使ってメモを作るとして、そのままだと埋もれて活用しづらくなっていくだろうと思うので、どこかにまとめの場所を作った方が良いだろう。OneNote内でリンクを使ってそれぞれの要点をまとめたページを作ってもいいだろうし、まとめだけ別のアプリケーションでやってもいいだろうし、厳選して紙のノートに書いてもいい。
　OneNoteにはサブページという階層化の機能があるので、テーマが決まっているなら親ページをそのまとめの場として、サブページに各記事のノートを作っていくというのも良さそうだ。

　とりあえず、しばらくOneNoteを使ってWeb記事の咀嚼と保存をやってみたいと思う。
　

こちらの投稿に関連しての考え事です。

• get it doneからget alongへというパラダイムシフト - by 倉下忠憲@rashita2

こちらを読んでぼーっと考えている時にふと思い至りましたが、そういえば少し前まで「チェックボックスを用意して、チェックしていく」ということに妙に囚われていたような気がします。

一日のことを頭の中で考えてみた時に、チェックボックスが並んでいるようでなければと思っていたところがありますし、一日の終りにはそれらにチェックを入れられなければと思っていたように思います。チェックボックスを並べられることが「まともに生きている」ことの証明であり、チェックを入れられることが「真剣に生きた」ことの証明のような感じがしていたのです。当時からそのように言語化できていたわけではありませんが、今思うとそんな感じです。
仕事ではないことにまで点検項目を用意して、それに「よし」「よし」「よーし」とやっていかないと自分の一日に納得できないという心境です。そして、「よし」「よし」「よーし」とはいかないので、いつも納得できていませんでした。しかし納得しようがしまいが日々は過ぎていき、納得できない日々が延々と続いても私は今日も生きています。

（正確な文脈をわかっておらず）「get it done」と聞いて私はGTDをパッと連想しました。GTDという概念を認識したのは結構後のことで、Evernoteを知ったよりも後なくらいなのですが（ビジネス書の類を読むのは好きな方なのに、全然接触しなかったのです）、そんな私でもGet Things Done的な感覚はいつの間にやら刻み込まれていたようです。
多分私の場合は、バレットジャーナルの影響が大きかったのだと思います。バレットジャーナルという手法が私にそういう価値観を植え付けようとしてきたわけではないのですが、単純にあの「バレット」感に憧れを覚えて、イケてる感じの手帳像を思い描いた時に、そういう生活が手帳に綴られていくのがきっと良いのだろうと思ったところはあると思います。
あるいは「タスク管理ツールが流行っている」という状況もその傾向を後押ししたでしょう。チェックマークをモチーフにしたアイコンのアプリがたくさん並んでいたりするわけです。チェックを見ると何かをチェックしたくなります（私だけかもしれません）。
まあおそらく、倉下さんがご指摘になっている「get it done」というパラダイムの力で、どこを向いてもそういう気分を惹起させられる世界になっているのだと思います。

そういう仕事術的なものに関心を持つ前の若かりし頃、精神的によろしくない状態が続いていたのですが、今思い返してみると、チェックボックスを使うことがなくとも「その日必要なことはやったはず」と頭の中で思えていれば、一応その日の自分の生活に対して不満を抱くことはありませんでした。自分のメンタルのよろしくなさはそこじゃないところに起因していたからです。
しかし、精神的に不調であったせいでやるべきことができなくなってきた時に、私は仕事能力のなさを解決する術を探すことに道を見出してしまいました。仕事術の本や雑誌を色々読んで、色々なことを知りました。それらは私に希望を与えてくれましたし、何より楽しかったのですが、気づかぬ間にちょっとした洗脳を自分に施してしまったような気もします。
私が本当に悩んでいたのは仕事ができるかできないかというレイヤーではなかったのですが、苦悩の結果パフォーマンスが落ち仕事能力が下がったことによって、自尊心が直接的に傷つき、それを癒やすために仕事術に縋り、表面上の仕事能力を上げることで安心しようとしていたと思います。その象徴がチェックボックスです。

もちろんちゃんと生きていくために、やるべきことをリストアップしてそれを遂行していくというのは当たり前に必要ですが、自分は駄目じゃないと思いたいがためにリストを膨らませてもしょうがないのであって、目的の曖昧な「やり終えた」の数稼ぎは自分の人生に何も貢献しないように思います。
人生および生活（仕事のプロジェクトも含む）は有機的で流動的で、その「状態」を可視化するのが難しいので、成果を人に具体的に報告できるようにしたいのもあって自分のアクションがわかりやすくなるような形式を認識の形として採用したくなる気がします。特に、脳内の主語が「わたし」になっているとそうです。しかし世の中の素敵なことは、主語を己以外の何かにして全力を注ぐ中に生まれているのではないか。
私は子育ての経験がないので想像になりますが、もし子どもが生まれて必死に育児に励まなければならなくなったとしたら、今日子どもに対して何をしたかのリストを自分が作りたがるとは思えません。自分が何をやったかより、今日子どもが無事に生きられたかが重要で、それが達成されればそれで良いからです。主語は「わが子」です。忙しすぎて大事なことを忘れる可能性があるからという切実さによってリストは正しく活躍すると思いますが、それはもう自分の精神の傷に当てる絆創膏ではないはずです。

自分語りが長くなりました。

何かをやり終えたとしても、それが望ましい結果につながっていないということはぜんぜんあるわけです。
要は、結果が伴わないにもかかわらず「やり終えたがる」ということの原因を、自分の中に探してみたということになると思います。

日頃あまりにも「スッキリする」ということを求めすぎているとも感じます。ちょっと大げさに言えば「日々スッキリしていかなければならない」みたいな空気を感じます。もっと「ぬるっと生きていく」ことがうまくなっていきたいと個人的には思います。

　それなりのツールを作ろうとすると、それなりに調べ物が多岐にわたることになりますが、そうなると「よくわからないあれをまた見かけた」ということをしばしば体験します。

　自分の目的を速やかに達成したいが、自分の理解が追いついていなくてちょっと避けているものがどうしてもついて回ってくる、という状態です。
　そこでちょちょっと調べて「なるほどそういう意味ねー」となれば話は早いのですが、そうならないから逃げ回って結局遭遇してということを繰り返すことになります。

　二ヶ月目のこの頃に困っていたのは主に三つの概念です。ずばり、アロー関数、コールバック関数、非同期処理です。JavaScriptをわかる人はこれらが如何に避けがたいものかおわかりかと思います。実際に何か作ろうとするならば、それが簡単なプログラムであっても扱わざるを得ないものたちです。
　当時困っていたもの三銃士という話なので、三つの粒度はバラバラです。理解の難易度も実際には大きく差がありますが、当時はどれも同程度に馴染み難いものでした。急に抽象度が上がったような感覚になるのです。
　数学で言えば、平方根、指数対数、三角関数、微積分、行列などの単元に入った時の感覚でしょうか。もちろんわかる人はすんなりわかるのですが、そのステップアップに失敗して数学で挫折したという人も多いでしょう。既に自分の中にある理解の組み合わせが通用せず、正面からの格闘を求められているような感覚です。
　これらについて誤りなく説明できる自信はないですし、解説は世の中にいくらでもあるのでここでは詳しく説明しませんが、混乱している人に寄り添うために自分の混乱を元に書けることを書いておきたいと思います。最初はこうだよね、というお話です。

アロー関数

　アロー関数というのは、関数の書き方の一種で、function～で定義するより簡潔な見た目をした構文です。

// 普通の関数宣言    
function add(a, b){  
  return a + b;  
}  
// アロー関数  
const add = (a, b) => a + b;  

「=>」の部分から「アロー（＝矢印）関数」という名前がついています。
　アロー関数は単に「関数宣言を簡単に書けるようにした」というだけのものではなく、挙動に色々違いがあります。その違いはとても重要で、そこに躓く人も少なくないと思いますが、私の場合はそれ以前にまずこの書き方の見た目に混乱してしまいました。
　上記の例だと引数の部分に括弧がついているので辛うじて関数っぽさがなくもないですが、例えば以下のように書かれるとわけがわかりません。

const f = a => b => a + b;  

　プログラミング脳になっていないと、パッと見た限りでは「fにaを代入、と思いきや矢印がある、けどaはすぐ出てこなくてなんか急にb出てくる」みたいな見え方をします。ちなみにこれは普通の関数宣言で書くと以下のようになります。

function f(a){  
  return function(b){  
    return a + b;  
  }  
}  
console.log(f(1)(2)); // 3  

　「関数を返す関数」というのも初学者の「わけわからないポイント」のひとつですが、とりあえずfunctionの形にしてみれば、括弧なし引数の矢印矢印の連鎖よりかは意味に想像がつくことでしょう。シンプルすぎるアロー関数はかえって理解に苦労することがあります。

　で、「アロー関数ってなんなんだ」という感覚になった時、「アロー関数とは」などと検索をかけても「functionとの違い」を細かく解説されるばかりで、「なんなんだ」感はいまいち解消されなかったりします。「なんなんだ」とは思っているのですが、「なんなのか」を説明されても困るのです。（解説記事が悪いのではなく、「なんなんだ」と思って「アロー関数とは」と調べざるを得ないところに難点があります。求めているものではないものの山に突っ込んでしまうのです。）
　じゃあこれを乗り越えるにはどうしたらいいかということですが、もし私のように「パッと見た時に意味が取りにくくて困惑する」という意味で「なんなんだ」になっているのだとしたら、私に言える答えはひとつです。アロー関数を書きまくるしかありません。それまでfunctionで書いていたものをとりあえずアロー関数で書いてみる。頭の理解をどうにかするのではなく、目が慣れるまで書く。ルートやインテグラルやシグマに目が慣れるまで問題集を解くのと同じです。
　見た目に困惑しなくなった頃に、functionとの違いが気になり始めると思います。そうなったら本格的にアロー関数について勉強することになるでしょう。
　ちなみに私が「おおよそアロー関数をわかった」と思えるようになったのは五月末あたりです（functionとの違いも含めて理解したのがそのくらいということです）。ツールを作る上で、理解しなくてもどうにかなるものの理解は後回しにしてまず作る、というスタンスでやっていたのもあって、なんだかんだ三ヶ月くらい曖昧なままでいたことになります。

コールバック関数

　次はコールバック関数です。コールバック関数とは引数として渡される関数のことです。以下のような関数があった時、引数funcに入れている関数fugaがコールバック関数になります。

function hoge(func){  
  const q = confirm('実行しますか？');  
  if(q) func();  
}  
function fuga(){  
   alert('Hello world!');  
}  
hoge(fuga);  

　ちなみにこの場合hogeの方は高階関数と言うようですが、今のところ「高階関数」というワードがすごく重要と思ったことはありません。
　で、コールバック関数の定義としてはこうなのですが、問題は「コールバック関数の引数に値が渡される」という状況です。上記の例ではfuncに入る関数には何も渡されていないので話が簡単に見えるかと思いますが、値を渡して使う場合の方が多いのではないかと思います。
　さて少し話が枝分かれしますが、コールバック関数に最初に直面するタイミングというのは、自分で高階関数を書こうとする時ではなく、コールバック関数を引数とするメソッドを使う必要が生じた時だろうと思います。具体的にはArray.prototype.find()などです。配列の中から条件に合うデータを探し出す時にコールバック関数が必須になるのです。
　簡単な日記データからデータを取り出す例を書いてみると、たとえばこんな感じです。

const data = [  
  { date: '2023-08-02', text: 'すごく暑かった。' },  
  { date: '2023-08-03', text: '夜にアイス食べた。' },  
  { date: '2023-08-04', text: '今日も暑かった。' },  
]  
const today = data.find((obj) => obj.date === '2023-08-04'); // 2023-08-04のデータを返す  
const soHot = data.filter((obj) => obj.text.includes('暑かった')); // 2023-08-02と2023-08-04のデータを含む配列を返す  

　実際にはDateオブジェクトを使って今日の日付を指定したりしますが、とりあえずfindとfilterに注目してもらいたいので直に値を入れました。
　コールバックわからんちんな人もこの例を見るとfindやfilterの括弧の中にどう書けばいいのかなんとなくわかるのではないかと思います。これを「コールバック関数を引数に渡している」感が出るように書くと例えばこうなります。

function callback1(obj){  
   return obj.date === '2023-08-04';  
}  
const today = data.find(callback1);  
  
function callback2(obj){  
  return obj.text.includes('暑かった');  
}  
const soHot = data.filter(callback2);  

　アロー関数で一気に書いてしまっていたのを別途整理したわけですが、逆に意味がわからなくなったかもしれません。コールバック関数として渡した関数がfindやfilterメソッドの中でどう使われるのか想像できないからでしょう。（ちなみに「obj」という文字列の部分は別に何でも好きに決めていいのですが、何でもいいのだというのは関数を分けて書いてみると明らかでしょう。）
　findなどのメソッドが具体的にどういうコードで出来ているかわかりませんが、メソッドの中で「引数に渡したコールバック関数に配列の各要素を渡し、その返り値がtrueかfalseかを判定して条件分岐」という処理が行われているはずです。
　各メソッドは、引数として渡される関数（コールバック関数）の引数にどんなものをどの順番で渡して処理するかが決まっています。Array.prototype.findなら、配列arrのi番目を判定するとして、引数の一つ目はarr[i]、二つ目はi、三つ目はarrです。つまり、それらを私たちはコールバック関数の中で活用することができるということです。そして各メソッドは私たちが渡したコールバック関数の引数に順番にこれらを入れて実行してみて、trueなら次の処理を実行、というようなことをしていくわけです。if(callback(arr[i], i, arr)){}みたいなことです（あくまでイメージです）。

　しかし最初はそのことがよくわかっていませんでした。「data.find((obj) => obj.date === '2023-08-04');」みたいな文は「こう書くもの」としておまじないのように書いており、これが「関数を渡している」のだという感覚があまりありませんでした。いや、わかってみればこれはどう見たって関数を渡していますし、関数じゃなきゃなんなんだよという話なのですが、関数に関数を渡すという概念がわかっていなかった時は関数を渡した結果それがどうなるのか想像できなかったので、「これがなんなのかよくわからないが、とりあえずこう書く」という理解でfindやfilterを使っていたわけです。この時点でアロー関数自体馴染んでいなかったというのは手前で書いた通りです。
　しばらくして、自分で関数を書いていて「任意の関数をその中で実行させたい」と思う場面が来ました。その時当たり前に「引数として関数を渡して、それを実行すればいいんだろう」と思いました。そして試して期待通りに動いた時、はたと「コールバック関数を必要とするメソッドってつまりこれじゃん」と気がつきました。なぜその瞬間までわからなかったのかわかりません。その瞬間が訪れたのは確か三月末のことです。
　たまたま自分で同じ形のものを作って初めて「あれってこれじゃん」と気づいて理解が一気に進んだというのは、他のことでもいくつかあります。メソッドの説明を読んだだけではよくわからなかったのが、後からまさにその挙動を欲するタイミングができた時に、自分でわざわざ複雑なコードを作ってから「もっと簡単にならないのか？」と思って「あのメソッドってこれじゃん！」と気づいたりします。説明を読んだだけではすんなり理解できないがゆえに多分遠回りをしているのですが、わかった時には具体性をもってわかっているので（まさに目の前に実例があるわけです）、もうそれ以後はポンポン使えるということになります。

非同期処理

　最後は非同期処理です。なんというか、名前からして意味がよくわかりません。「非同期」ということは「同期していない」ということだというのはわかりますが、そもそも「同期」している処理って何？　という話です。Aの存在を認識していないのに急に「非Aとは」と言われてもなんのこっちゃです。
　一言で言うと、「手前のものが終わるのを待って次に行く」のが同期処理で、「手前のものが終わるのを待たないで（よそに投げておいて）次のことを始めてしまう」のが非同期処理です（多分）。「同期」という単語とプログラム的な意味内容が脳内でいまいちバシッとリンクしませんでしたが、とりあえずそういうことだと理解しておかねばなりません。ファイルの読込など規模の大きい処理が必要な時、それが終わるのを待ってから次となるとリソースがもったいないので、他の処理を進めておいてから規模の大きい処理をやる、というような形にする必要が生じるわけです。
　とても難易度が高い概念なのですが、ツールを作るとなるとファイルの読込というのが不可避で、そうなると非同期処理を使うことになります。というのは、ファイルの内容を取得するのに使うfetch APIが非同期処理の形をしているからです。非同期的に処理したいとか考えるまでもなく、そういう形式になっているのでその形を理解しなければ使えないのです。
　一口に非同期処理と言っても、非同期処理にする書き方はいくつかあるので非同期処理とはこの形という話にはなりませんが、とりあえずファイル読込に使うfetch()が必要になるので、それについて書いていきます。

fetch('./test.txt')  
.then(response => response.text())  
.then(text => {  
  // 引数textには「test.txt」の中身の文字列が入っている  
  console.log(text);  
})  
  
fetch('./data.json')  
.then(response => response.json())  
.then(json => {  
  // 引数jsonには「data.json」の中身がオブジェクトまたは配列に変換されて入っている  
  console.log(json);  
})  

　なんじゃこりゃあ。「.then」って何？　responseには一体何が入っていて何が処理されてるの？　というようなことが、初学者にはわかりません。同期処理か非同期処理かという話より、構文の見た目の異質さに戸惑ってしまいます。これまた数学の微積分のごとく、それまでになかった概念と直面した瞬間です。習ってないのでわからないのは当然です。
　これを正しく理解するにはPromiseチェーンというのがわかる必要があります。そんなにべらぼうに難解な話ではないのですが、何しろアロー関数の意味すらあやふやな状態でやっているのです。説明を理解するのはちょっと大変です。全部理解するまで頑張っていたらツール作りが進みません。
　なので私の脳みそを非同期処理にしてしまいましょう。Promiseチェーンの理解という規模の大きい処理は後回しにして、まず目下のツール作りを先に進めてしまうのです。ツール作りの合間にキューが空いたらPromiseチェーンに取り組むことにします。二ヶ月目のこの時点では、とりあえずおまじないを書けるようになれば良しとしました。
　肝心なのは、自分が書いた処理がfetchでデータを読み込んでから行われる必要があるということです。

fetch('./data.json')  
.then(response => response.json())  
.then(json => {  
  // 自分の作った処理がここで実行される必要がある  
  hoge(json);  
  fuga(json);  
})  

　そうなると、ツールで実行する処理というのは関数で綺麗に整理しておかないと大変です。このthenの中にずらーっと書いていってもまあ動きますが、きちんとまとめておいてthenの中に関数をいくつかぽんと置いて実行すると見通しが良くなると感じます。それまではべたべた直に書いて上から順に実行していた箇所が多かったわけですが、これを機に関数の使い方が少し変わっていきました。
　ちなみにPromiseチェーンを（ある程度）理解したのは結構後のことです。自分用のデジタルノートアプリを作るだけなら、fetchでローカルファイルの中身やAPIにアクセスした結果を取ってこれればそれで大体事足りました。

　その後あれこれ試みる中でこの三つに苦手意識を感じなくなった時に、JavaScriptでのプログラミングはぐっと自由さを増したように思います。苦手意識がなくなるのは割と唐突で、ふと「あれ、わかったぞ」という感覚がありました。最初は苦手でも、その周辺をうろうろしていればそのうちどうにかなるものですね。