なぜ私たちは書くのか

Share

何かを問うとき、私たちはしばしば、すでに答えを知っている。

問いの逆説

たとえば、議論の場で質問が出ない光景を思い浮かべてほしい。参加者は質問を考えているようで、実は探しているのは問いではなく、期待する答えの方だ。「こう言ってほしい」という感覚がまずあって、それを質問の形に翻訳しようとしている。少し考えれば自力で辿り着けそうだと気づけば、結局聞かない。

これは怠惰ではない。問いの構造そのものがそうなっている。

一方で、純粋に知らないことを尋ねる場面もある。明日の天気。専門外の事実。自分の経験の外にある情報。これらは情報の要求であり、検索すれば事足りる。便利ではあるが、そこに対話としての深みはない。

この二種類の間に、もう一つの問いがある。答えの輪郭はぼんやり見えている。しかし言葉にならない。自分が何を考えているのか、書いてみるまでわからない。この第三の問いにこそ、書くことの核がある。

自己との対話

書くとは、自分の中の曖昧な感覚を言語に変換する作業だ。変換の過程で、自分が何を考えていたかが初めて明らかになる。言語化された考えに対して、今度は自分自身が批判者として応答する。別の角度から問い直し、矛盾を見つけ、修正し、また書く。

この循環が「自己との対話」だ。

独り言とは違う。独り言には聞き手がいない。自己との対話は、自分の中にもう一人の自分を立てて、その目に耐えうる思考を練り上げる営みだ。書くという形式は、この対話を最も精密に行える手段の一つだと思う。話し言葉は流れていくが、書き言葉は紙面に、あるいは画面に留まる。留まるからこそ、昨日の自分の言葉を今日の自分が検討できる。

「わたし」という寄せ集め

ここで一つの疑念が浮かぶ。

構造主義以降の思想は、「わたし」とは自律した主体などではなく、言語、文化、歴史といった構造の編み目に位置づけられた存在に過ぎないと繰り返し指摘してきた。バルトは「作者の死」を論じ、フーコーは近代的な「人間」概念そのものが歴史的に構成されたものであることを示した。

「わたし」が確固たる中心を持つ主体ではなく、外部の影響が交差する結節点に過ぎないのだとすれば、「自分の言葉で書く」ことにどんな意味があるのか。どうせ寄せ集めであるなら、百科事典のように誰が書いても同じ記述を目指す方が、よほど正確で誠実ではないか。あるいは、検索エンジンに問いを投げ続けることこそが、あるべき知的態度なのだろうか。

だが、百科事典と個人の文章には決定的な違いがある。百科事典は、誰が書いても同じ記述になるように設計されている。それは本当に偉大な営みであり、心底から尊敬している。一方で、個人が書く文章は、膨大な情報の中から何を拾い、何を捨て、どう配置するかという選択の軌跡そのものだ。

「わたし」は確かに寄せ集めかもしれない。だが、寄せ集め方に主体は宿る。

何を吸収し、何を手放し、何をどう並べるか。発話の本質は、自分の内側から何かが湧き出ることではなく、外部を通過した上での編集行為にあるのかもしれない。そして、その編集の仕方にこそ、その人にしかない固有性が現れる。

ニーチェは『ツァラトゥストラ』の中で、精神の三つの変容を描いた。既存の価値を黙々と背負うらくだ。「我欲す」と叫び自由を切り開く獅子。そして何にも縛られず無垢に創造する子ども。この三段階は、外部から受け取った価値をどう引き受け、どう乗り越えるかという問いの変奏でもある。寄せ集めの素材に対してどのような態度を取るか、その姿勢の違いが、書き手の固有性を形作る。

書かなければ「わたし」はいない

では、なぜ書かなければならないのか。

正直に言えば、「書かなくていい」というのが答えの第一歩だ。誰かに強制されるものではない。外部から課される義務として「書きなさい」と言われるなら、それは断って構わない。

しかし、別の意味での必然性がある。

自分の中にある曖昧な感覚は、書くまで形にならない。形にならないものは、検討の対象にならない。検討できないものは、対話の相手にならない。対話の相手にならなければ、「わたし」は散乱した素材のまま、一つの形を取ることがない。

つまり、「書かなければならない」のではなく、書かないと「わたし」がいない。

これは義務ではなく条件だ。「わたし」として存在したいなら、何らかの形で書く、あるいは語ることは避けられない。書くか書かないかは選択であり、その選択には帰結が伴う。

以前、サルトルの文章を読んだとき、「結局、結論は本を書けということか」と思わず苦笑してしまったことがある。実存の問題をあれほど突き詰めた末に出てくる答えが「書く」だとは、正直拍子抜けだった。サルトルの思想を体系的に理解しているとは言い難く、あくまで私の大雑把な読みに過ぎない。

だが今になって思えば、あの苦笑は早計だったかもしれない。サルトルが「実存は本質に先立つ」と述べたこと、人間は自分自身を不断に作り上げていく存在であるという洞察と、書くことで初めて「わたし」が立ち現れるという認識は、どこかで重なっている。書くことは結論ではなく出発点なのだ。

他者なくして自己はない

ここまで「自己との対話」を強調してきたが、重要な補足がある。

自己との対話は、閉じた営みではない。

レヴィナスは、他者の顔との出会いが倫理の出発点であると論じた。自分の殻に閉じこもることは、自己との対話ではなく、対話の拒否だ。外部との接触がなければ、編集する素材も、批判する視点も生まれない。「わたし」は豊かになるどころか、縮小していく。

自分の力不足を痛感しながらも、他者と向き合うこと。他者との対話で揺さぶられ、自分の前提を問い直すことで、自己との対話はより深くなる。独善と自己信頼は紙一重だが、根本的に異なる。真実を常に疑いながら、それでも自らの判断を手放さないこと。この緊張の中にこそ、書き続ける力がある。

書くことは、公に行うことで一層その力を増す。誰にも読まれない日記にも意味はある。しかし、不特定の読者という他者の視線が加わることで、書き手は自らの論理をより厳しく吟味するようになる。その緊張が、思考の精度を押し上げる。

結論よりも道筋を

最後に一つ。

「結論から話せ」という言い方がある。効率を重視する場面では合理的な作法かもしれない。だが、思考を深めるという営みにおいて、結論だけを取り出すことにはあまり意味がないと思う。

いかにそこに辿り着いたか。どこで立ち止まり、何に迷い、何を選んだか。その道筋にこそ、書き手の固有性がある。

結論だけが欲しいなら、百科事典や検索エンジンを当たればいい。それらは結論を効率よく提供するために設計された、優れた仕組みだ。しかし、他者の思考の軌跡を辿ることでしか得られないものがある。書き手が何を選び、何を捨て、どう迷ったか。その過程そのものが、一つの固有な思考として読者の前に立ち現れる。

結論は点に過ぎない。道筋こそが線であり、その線の引き方にこそ、書くことの意味がある。

Read more

Dependabotの対応が面倒なのでRenovateを導入する

Dependabotくんはある程度の依存関係の更新を通知してくれるが、山のようにprojectを抱えているとなんとも痒いところに手が届かない。 ということで、Renovateを使ってみる。 Build software better, togetherGitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.GitHub ここからGitHub Appを入れる。 あとは、指示に従ってポチポチするだけで、超かんたんだった。 感想 自動化最高。

By Sakashita Yasunobu

nodejsのバグを見つけたのでPRを投げてみた

概要 要するに、node --testで特定のバイナリを標準出力に書くと、テストランナーが固まったり、異常終了したりするバグです。 バグ自体は既知のものだったようで、修正がされていました。 test_runner: infinite loop in FileTest#drainRawBuffer when child stdout contains FF 0F followed by large size bytes · Issue #62693 · nodejs/nodeVersion v25.9.0 (also reproduced on v24.14.1 LTS, v22.21.0 LTS, v23.4.0) Platform Darwin 25.

By Sakashita Yasunobu
青空文庫のParser

青空文庫のParser

青空文庫のParserを作ってます。 GitHub - P4suta/aozora: Pure-functional Rust parser for 青空文庫記法 (Aozora Bunko notation): ルビ, 傍点, 縦中横, 外字, 返り点, indent containers, page breaks.Pure-functional Rust parser for 青空文庫記法 (Aozora Bunko notation): ルビ, 傍点, 縦中横, 外字, 返り点, indent containers, page breaks. - P4suta/aozoraGitHubP4suta Rustで作ってますが、配布物はcargoのほかにnpm/pypiでも入手できます Documentation * Playground — try it in

By Sakashita Yasunobu