おい、言語化しろ

はじめに

「言語化」という言葉を聞くたびに、私は少しだけ居心地が悪くなる。この感覚に初めて気づいたのは、数年前の、ある夏の午後だった。後輩エンジニアとの1on1で、私は彼にコードレビューのコツを教えようとしていた。モニターに映るコードを指差しながら、「このコードの何が良くないか、分かる？」と聞いた。彼は首を横に振った。私は言葉を探した。「ここの設計が、将来の拡張性を損なっている」「この命名は意図が伝わりにくい」「ここのロジックは複雑すぎる」。彼は真面目にメモを取った。頷いた。理解したような表情をした。でも、次のレビューでも、同じ問題が繰り返された。その次も。さらにその次も。私は、教え方が下手なのだと思った。説明が足りないのだと思った。もっと丁寧に、もっと具体的に、もっと分かりやすく。そう思って、さらに言葉を重ねた。

三ヶ月が過ぎた。ある日、彼は変わっていた。私が指摘していたような問題を、自分で見つけるようになっていた。的確に、瞬時に、まるで当然のように。「どうやって分かるようになったの？」私は聞いた。彼は少し困った顔をした。「うーん...なんとなく、見れば分かるようになりました」。その瞬間、私は理解した。私がどれだけ言葉を尽くしても、彼に伝わらなかった理由を。そして、三ヶ月後に突然彼ができるようになった理由を。「なんとなく」。この言葉が、すべてを物語っていた。彼は確かに知っている。何が良いコードで何が悪いコードか。しかし、その知識は言葉にならない。なぜそう判断できるのか、説明できない。私も同じだった。瞬時に判断できる。でも、その判断基準を言語化しきれない。言語化しようとすると、何か大切なものが抜け落ちてしまう気がする。

私が三ヶ月間、必死に言語化しようとしていたもの。それは、実は言語化できないものだったのかもしれない。あるいは、言語化してはいけないものだったのかもしれない。この経験が、私に1つの問いを突きつけた。私たちは本当に、すべてを言語化すべきなのか。言語化できないものには、価値がないのか。そして、そもそも「言語化」とは、何なのか。

この問いについて、考え続けた数年間の思考を、ここに記す。矛盾しているのは分かっている。言語化できないものについて、言語化しようとしているのだから。でも、この矛盾こそが、たぶん、この問題の本質なのだと思う。

このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。では、早速はじめていきます。

知識の水面下にあるもの

数年前の後輩とのやり取りを思い返すと、私は1つの事実に気づく。彼は、最初は分からなかった。でも、三ヶ月後には分かるようになった。そして、「どうやって分かるようになったのか」と聞かれても、説明できなかった。これは、奇妙なことだ。彼は明らかに何かを知っている。その知識を使って、正確に判断している。でも、その知識を言葉にできない。

自転車に乗る時のことを考えてみよう。あなたは、バランスを取っている。どうやって？説明できない。でも、確実にバランスを取っている。倒れそうになった瞬間、身体が自動的に反応する。ハンドルを少し切る。体重を移動する。無意識に、瞬時に、正確に。もしこの一連の動作を言語化しようとしたら、どうなるか。「体重を右に3度傾ける。同時にハンドルを左に2度切る。視線は前方5メートルの地点を...」。数百の変数を、リアルタイムで調整している。それを言葉にしようとすると、膨大な説明になる。そして、その説明を読んで理解したところで、自転車には乗れない。なぜか。言語化すると、タイミングが失われるからだ。

自転車に乗る時、身体は並列処理をしている。視覚、平衡感覚、筋肉のフィードバック、これら全てを同時に処理している。そして、処理している間も、状況は変わり続けている。でも、言語は逐次的だ。1つずつ、順番に。言語化している間に、バランスは崩れる。

つまり、知識には2つの形態がある。言葉になる知識と、言葉にならない知識。そして、後者の方が、圧倒的に多い。 私たちが意識している知識は、氷山の一角だ。その下に、巨大な、言語化されない知識の大陸が広がっている。歩く。話す。顔を認識する。危険を察知する。空気を読む。これら全て、言葉にならない。でも、私たちは確実に知っている。

なぜ知識は形を変えなければならないのか

ここで、根本的な問いに向き合う必要がある。なぜ知識は、1つの形に留まらないのか。後輩が「なんとなく分かるようになった」と言った時、実際には何が起きていたのか。彼の中で、知識の形が変わったのだ。

最初、彼は何も知らなかった。次に、私の説明を聞いて、言葉として知った。でも、それだけでは使えなかった。そして三ヶ月後、彼は「見れば分かる」ようになった。説明なしに、瞬時に判断できるようになった。知識は3つの形を経由した。

無知 → 言語化された知識 → 身体化された知識

この変容は、なぜ必要だったのか。答えは、速度にある。

実践の速度は、言語の速度を超える

言語化された知識のままでは、実践で使えなかった。コードを見るたびに、マニュアルを確認し、チェックリストと照合し、判断する。これでは、遅すぎる。コードレビューの場では、瞬時の判断が求められる。「考える」時間はない。「見た瞬間に分かる」必要がある。

言語は、本質的に一本道だ。この文章を読んでいるあなたは、一語ずつ、順番に処理している。「言語」「は」「本質的に」「一本道」「だ」。5つの単語が、時間軸に沿って一列に並んでいる。あなたは、5つを同時に読むことはできない。必ず、順番に、1つずつ。これは、言語の宿命だ。線形性。1次元性。1つずつしか処理できない性質。でも、実践はそうじゃない。

自転車に乗る時、視覚情報、平衡感覚、筋肉の張力、ペダルの圧力、風の強さ、路面の傾き、周囲の音。無数の情報を、同時に、瞬時に処理している。そして、無数の筋肉の調整を、同時に、リアルタイムで実行している。並列処理。多次元処理。すべてが同時に起きている。だから、言語化された知識は、身体化された知識に変容しなければならない。言葉の形から、身体の形へ。逐次処理から、並列処理へ。意識的な判断から、無意識の反応へ。これが、知識が形を変える第一の理由だ。実践には、言語を超えた速度が必要だからだ。

しかし、身体化された知識は、共有できない

ここで、問題が生じる。知識が身体化された瞬間、それは共有不可能になる。私が持っている身体化された知識を、後輩に伝えたい。でも、それは直接伝達できない。なぜなら、言語化できないからだ。そして、言語なしに、人間は複雑な概念を伝達できない。

したがって、身体化された知識を伝えるには、一度言語化しなければならない。

身体化された知識 → 言語化 → (伝達) → 言語化された知識 → 身体化

この変換の連鎖が、必要になる。

でも、ここに非対称性がある。

身体化された知識を言語化する時、情報が失われる。言語化された知識を身体化する時、新しい情報が生まれる。つまり、変換は可逆ではない。

後輩が獲得した身体化された知識は、私が持っている身体化された知識と、同じではない。似ているが、同じではない。

これが、知識が形を変える第二の理由だ。伝達のためには、身体化された知識を言語化しなければならないからだ。

そして、不完全な伝達が、進化を生む

ここで、重要な洞察がある。もし知識の伝達が完全なら、知識は進化しない。私の知識が、そのまま後輩にコピーされるなら、後輩は私と全く同じように判断する。新しいものは、何も生まれない。

しかし、伝達が不完全だからこそ、変異が生じる。

後輩の知識は、私の知識の変異体だ。似ているが、異なる。そして、その違いの中に、新しい可能性がある。

後輩は、私が見落としていたパターンに気づくかもしれない。私とは異なる視点から、問題を捉えるかもしれない。そして、後輩が発見した新しいパターンを、私が学ぶこともある。彼が言語化したものを聞いて、「ああ、確かにそうだ」と気づく。私の知識が、更新される。

これが、知識が集団の中で進化するメカニズムだ。

不完全な伝達 → 変異 → 選択 → 進化

生物の進化と、同じ原理だ。これが、知識が形を変える第三の理由だ。不完全な変換こそが、知識の進化を可能にするからだ。

翻訳としての言語化

ここで、言語化という行為の本質について、もっと深く考えてみたい。言語化は、圧縮ではない。翻訳だ。 ある言語から別の言語に翻訳する時、元の意味をそっくりそのまま伝えることはできない。ニュアンスが変わる。リズムが変わる。文化的な背景が抜け落ちる。

身体化された知識を言語化する時も、同じことが起きる。身体的な感覚を、言葉に翻訳する。並列処理を、逐次的な説明に翻訳する。その過程で、何かが変わる。失われるものもあれば、新たに生まれるものもある。失われるのは、細部だ。微妙なニュアンス。タイミング。力加減。文脈。これらは、言葉にした瞬間、抜け落ちる。

でも、新たに生まれるものもある。それは、構造だ。関係性だ。パターンだ。身体化された知識のままでは、それは混沌としている。「なんとなく分かる」。でも、言語化することで、構造が見えてくる。「ああ、この判断は、この要素とこの要素を比較しているんだ」「この感覚は、この経験とこの経験から来ているんだ」。言語化は、知識を貧しくする。でも同時に、知識を明晰にする。これが、翻訳の二面性だ。

地図という比喩の限界と可能性

地図を思い浮かべてほしい。地図は、現実の地形を紙の上に表現したものだ。でも、地図は現実そのものではない。山の高さは誇張されている。細かい凹凸は省略されている。色分けは人工的に決められている。つまり、地図は意図的に歪められた現実だ。

でも、その歪みには理由がある。もし地図が現実をそのまま写すなら、地図は現実と同じ大きさになってしまう。それでは、地図の意味がない。地図は、重要な情報を強調し、不要な情報を削ぎ落とすことで、初めて役に立つ。

言語化も同じだ。身体化された知識を圧縮して、重要な部分だけを取り出す。その過程で、必然的に情報が失われる。

料理のレシピを考えてみよう。「塩を少々」。この「少々」は、どのくらいか。

熟練した料理人は、料理の状態を見て、味見をして、瞬時に判断する。今日の湿度は？この食材はいつ仕入れたものか？火加減は適切か？すでに入れた調味料の量は？食べる人の好みは？これらすべてを、無意識に考慮して、「今日のこの料理には、この量」と決める。

でも、レシピには「塩小さじ1/4」と書かれる。これは近似値だ。平均値だ。多くの場合にうまくいく、一般化された量だ。しかし、プロの料理人が持っている微細な調整能力は、この数字には含まれていない。

これが、言語化された知識の本質だ。個別を一般に変換し、文脈を捨象し、近似値を提示する。

この圧縮は、悪いことではない。むしろ、必要なことだ。圧縮しなければ、伝達できない。でも、圧縮によって失われるものがあることを、私たちは忘れてはいけない。

マニュアル通りにやっても、プロのようにはできない。教科書を読んでも、実践はうまくいかない。それは、あなたが無能だからではない。言語化された知識には、身体化された知識の一部しか含まれていないからだ。 地図を見ただけでは、実際にその土地を歩いたことにはならない。

実践知という第三の形

ここで、もう1つの知識の形態について語る必要がある。それは、実践知だ。実践知は、身体化された知識でもなく、言語化された知識でもない。あるいは、両方の性質を持っている。

看護師が患者の微細な変化を察知して、即座に対応を変える。教師が生徒の表情を見て、その場で授業の進め方を調整する。エンジニアがコードを書きながら、設計の問題に気づいて修正する。

これは、「計画を立てて実行する」という単純な流れではない。「実践しながら観察し、判断し、修正する」というグルグル回る流れだ。この実践の中で働いている知識が、実践知だ。

実践知は、身体化された知識の一種だと言える。なぜなら、言語化しきれないから。でも、ただの身体化された知識とは違う特徴がある。それは、その場その場で最善の手を選ぶ判断力だという点だ。

言語化された知識は、一般化された知識だ。「こういう状況ではこうする」というルール。マニュアル。教科書。でも、現実の状況は常に複雑で、文脈に依存していて、予測不可能だ。

実践知は、その複雑さに対処する。「教科書にはこう書いてあるけど、この状況では違うやり方がいい」「マニュアルではAだけど、今回はBが適切だ」。この判断は、どこから来るのか。

それは、過去の経験の蓄積だ。でも、ただの経験ではない。振り返られた経験だ。

創発としての量質転化

私は、プログラミングを始めた頃のことを思い出す。最初の一ヶ月、私は苦労していた。1つのプログラムを書くのに、何時間もかかった。エラーが出る。理解できない。調べる。試す。また失敗する。二ヶ月目も、同じだった。少し速くなったが、本質的には変わらなかった。三ヶ月目も、同じだった。でも、四ヶ月目に、何かが変わった。

突然、コードが「読める」ようになった。以前は意味不明だった構文が、意味を持ち始めた。エラーメッセージが、単なる記号の羅列ではなく、具体的な情報として理解できるようになった。そして、プログラムを書く速度が、劇的に上がった。以前は数時間かかっていたものが、数十分で書けるようになった。何が起きたのか。

量的な変化（書いたコードの量、経験したエラーの数）が、ある閾値を超えた時、質的な変化が起きた。

これは、相転移に似ている。水を冷やしていく。99度、98度、97度。温度は下がっているが、水は水のままだ。でも、0度で、突然、氷になる。液体から固体へ。状態が変わる。性質が変わる。同様に、学習にも閾値がある。一定量の経験を積むまでは、質的な変化は起きない。同じレベルに留まっている。でも、閾値を超えた瞬間、突然、別のレベルに到達する。

なぜこれが起きるのか。それは、パターン認識の閾値だ。

パターンが見えるようになる瞬間

プログラミングの初心者は、コードを文字の列として見ている。1つ1つの記号を、個別に処理している。でも、経験を積むと、パターンが見えてくる。「ああ、これはループだ」「これは条件分岐だ」「これは関数呼び出しだ」。最初は、意識的にパターンを認識している。「forと書いてあるから、これはループだ」。でも、やがて、パターン認識が自動化される。意識せずに、瞬時に、パターンが見える。

そして、さらに経験を積むと、より高次のパターンが見えてくる。「これはIteratorパターンだ」「これはStrategyパターンだ」。個々の構文ではなく、設計のパターンが見える。この段階的なパターン認識の獲得が、質的な変化を生む。

でも、パターンは、一定量の事例を見ないと、認識できない。3つの事例からは、パターンは見えない。しかし、三十の事例を見れば、パターンが浮かび上がる。

これが、量が質を生むメカニズムだ。

しかし、ここで重要なのは、ただ量をこなすだけでパターンが見えるわけではないということだ。

振り返りという、パターンを可視化する行為

私がプログラミングを学んだ四ヶ月目、何が起きたのか。私は、ただコードを書いていたわけではない。書いては、振り返っていた。「なぜこのエラーが出たのか」「このコードは、前に書いたコードと、どう違うのか」「この解決策は、他の問題にも使えるか」。

この振り返りが、パターンを可視化した。最初は個々の問題が別々に見えていた。でも、振り返ることで共通点が見えてきた。「ああ、このエラーとあのエラーは実は同じ原因だ」「この解決策はあの問題にも使える」。

パターンは、事例の中に潜んでいる。でも、振り返らないと、見えない。

私の知り合いに、二人のエンジニアがいた。

一人目は、十年間、同じような機能を実装し続けた。でも、彼のスキルは、ほとんど向上しなかった。なぜなら、彼は経験を振り返らなかったからだ。ただ繰り返した。同じやり方で。同じミスで。「忙しいから仕方ない」と言って。

二人目は、三年で驚くほど成長した。なぜなら、彼は毎回、振り返ったからだ。「なぜこの設計にしたのか」「もっと良い方法はなかったか」「次回はどう改善できるか」。たった十分の振り返りを、毎日続けた。

この差が、実践知の蓄積を決める。

経験の「量」ではない。経験の「質」だ。そして、質を決めるのは、振り返りの深さだ。

振り返りの三つの深度

振り返りにも、レベルがある。

表面の振り返り：何が起きたか

「今日は、このコードを書いた」「このエラーが出た」「これができた」。これは、記録だ。振り返りではない。

中層の振り返り：なぜそれが起きたか

「なぜこのエラーが出たのか。型の不一致が原因だ」「なぜこの設計にしたのか。拡張性を考慮したからだ」。これは、因果の理解だ。振り返りの始まりだ。でも、まだ不十分だ。

深層の振り返り：パターンは何か

「この型エラーは前に経験したあのエラーと同じパターンだ」「この設計の判断は一般化できる原則に基づいている」「この原則は他の状況でも適用できる」。これが、本当の振り返りだ。個別の事例から、一般的なパターンを抽出する。そのパターンを、次の実践で使う。

そして、このパターンの抽出こそが、量を質に変換するメカニズムだ。

でも、ここで最後の要素が必要になる。それは、目的意識だ。

目的意識という、方向性を与えるもの

量をこなし、振り返る。これだけでは、まだ不十分だ。なぜなら、方向性がないからだ。パターンを見つけることはできる。でも、そのパターンが、本当に重要なパターンなのか。自分が達成しようとしていることに、関連しているのか。これを判断するには、目的が必要だ。

私は、なぜコードを書いているのか。何を達成しようとしているのか。どんな問題を解決しようとしているのか。この目的があって初めて、パターンに優先順位がつく。「このパターンは重要だ。なぜなら、私が解決しようとしている問題に直接関係しているからだ」「このパターンについて、今は重要性が低い」。目的のない量は、ただの反復だ。目的のない振り返りは、ただの分析だ。

でも、目的のある量は、訓練だ。目的のある振り返りは、学習だ。

そして、目的を持った大量の実践と深い振り返りが組み合わさった時、創発が起きる。突然、新しいレベルの理解が生まれる。これが、量質転化の正体だ。

言語化という、形を探す運動

ここまで、知識がなぜ形を変えるのか、そしてどのように質的な変化が起きるのかを見てきた。ここで、もう一度「言語化」という行為の本質に戻ろう。

観察が先、言語は後

「言語化」という言葉を聞くと、多くの人は語彙力や表現力を思い浮かべる。どんな言葉を使うか。どう説明するか。文章の構成は。

でも、それは順序が違う。

言語化の質を決めるのは、対象をいかに的確に、解像度高く観察しているか、だ。言語能力は、その次の段階に過ぎない。

観察が粗ければ、どれだけ豊富な語彙を持っていても、的確な言語化はできない。「美味しい」という感想しか持てない人が、いくら言葉を知っていても、味の繊細な描写はできない。なぜなら、味覚体験そのものが、解像度が低いからだ。逆に、対象を精密に観察できている人は、限られた語彙でも、本質を捉えた説明ができる。なぜなら、何を伝えるべきかが明確に見えているからだ。

言語化が上手い人は、全てを説明しようとしていない。

彼らは何をしているのか。彼らは、自分の中にある言い表せない状態に、近い形のものを探している。

これは、靴を探すことに似ている。あなたの足には、固有の形がある。そして、その形に合う靴を探す。完璧にフィットする靴は、たぶん存在しない。でも、近いものを探す。試着する。歩いてみる。「これは、まあまあ合っている」「これは、ちょっと違う」。

言語化も同じだ。

私の中には、まだ形になっていない感覚がある。モヤモヤとした違和感。言葉にならない直感。輪郭のない不安。これらに、言葉という既製の形を、当ててみる。

「これは、不安だ」。試してみる。でも、何か違う。

「これは、焦燥感だ」。これも、少し違う。

「これは、無力感だ」。近い。でも、まだ足りない。

「状況をコントロールできないという認識と、それでも何かしなければという焦燥感が、混ざっている」。ああ、これだ。完璧ではない。でも、かなり近い。

重要なのは、この過程で、私は既存の言葉の中から探している、ということだ。新しい言葉を作り出すのではない。すでにある言葉の中から、自分の状態に最も近いものを見つけ出す。組み合わせる。

そして、見つけた瞬間、不思議なことが起きる。自分の状態が、少し明確になる。言葉という形を与えることで、形のなかった感覚が、輪郭を持ち始める。

抽象と具体を往復する運動

優れた言語化は、抽象化と具体化を往復する。

まず、抽象化する。「この感覚は、不安だ」。

次に、具体化する。「具体的には、胸の中心が空洞になったような感覚がある。そして、肩が内側に引っ張られる緊張がある」。

そして、再び抽象化する。「待って、これは不安というより、無力感に近い」。

さらに、具体化する。「状況をコントロールできないという認識がある。そして、それでも何かしなければという焦燥感がある。この2つが混ざっている」。

この往復を繰り返すことで、経験の解像度が上がる。最初は1つの塊だったものが、複数の要素に分解される。そして、各要素は、さらに細かく分解可能だと分かる。

これは、顕微鏡で細胞を見る行為に似ている。最初は、ぼんやりとした塊しか見えない。でも、倍率を上げていくと、構造が見えてくる。核がある。細胞膜がある。ミトコンドリアがある。さらに倍率を上げると、それぞれの構造に、さらに細かい構造があることが分かる。

言語化も同じだ。抽象と具体を往復させることで、経験の構造が見えてくる。そして、構造が見えることで、理解が深まる。

解像度という、観察の精度

言語化の質を決めるのは、語彙の量ではない。観察の質だ。

コーヒーを飲んで「苦い」と言う人がいる。別のバリスタは、こう言う。「最初の舌触りは滑らかだ。でも、飲み込む瞬間に、舌の奥に残る感覚がある。焦げた木のような渋みだ」。

この違いは、語彙力の違いではない。バリスタは、より精密に味覚を観察している。味覚の時間的な展開に注意を向けている。複数の感覚——舌触り、味、後味——を分離して認識している。そして、その精密な観察を、既存の言葉で表現している。「焦げた木」は、比喩だ。でも、的を射た比喩だ。なぜなら、実際の味覚体験に、かなり近いからだ。

言語化力は、語彙力ではなく、世界を解像度高く捉える力が本質だ。

ただし、観察は、決して絶対ではない。 私たちが何を見るかは、私たちが何を知っているかに依存する。「単一責任の原則」という概念を学ぶ前と後では、同じコードを見ても、見えるものが違う。観察とは、背景にある知識や理論を前提として行われる。

そして、この観察の質を高めるには、どうすればいいか。練習だ。意識的な練習だ。

毎日飲むコーヒーを、本当に味わう。「美味しい」で終わらせない。どこが美味しいのか。最初の一口は？二口目は？冷めてきた時は？苦味は？酸味は？香りは？舌触りは？温度の変化は？

毎日見る景色を、本当に見る。「綺麗だ」で終わらせない。何が綺麗なのか。光の角度は？色の組み合わせは？空間の奥行きは？影の形は？風の音は？

毎日書くコードを、本当に読む。「動く」で終わらせない。なぜ動くのか。どこが良いのか。どこが改善できるのか。この変数名は適切か？この関数の責務は明確か？このロジックは直感的か？

この意識的な観察の積み重ねが、言語化の質を高める。語彙は、その後についてくる。

世界の広がりという錯覚

プログラミングを始めたばかりの頃、私は圧倒されていた。学ぶべきことが、あまりにも多すぎる。プログラミング言語、フレームワーク、デザインパターン、アルゴリズム、データ構造、アーキテクチャ、セキュリティ、パフォーマンス。リストは、どこまでも続く。世界は、恐ろしく広い。そう思っていた。

でも、十年以上経った今、私は気づいた。世界は、広くなかったのだと。

いや、正確に言えば、世界が広いという感覚は、錯覚だった。新しい領域が無限に広がっているのではない。既に知っている領域の解像度が、無限に細かくなっていくだけだった。

最初、私にとってプログラミングは1つの塊だった。「コードを書く」。これが、私の世界のすべてだった。でも、少し経験を積むと、その塊が分解され始めた。「変数」「関数」「ループ」「条件分岐」。4つになった。

さらに経験を積むと、それぞれがさらに分解された。「関数」は、「純粋関数」「副作用を持つ関数」「高階関数」に分かれた。そして今、私が「関数」を見る時、見えているものは何百もの要素の複合体だ。関数名の適切性、引数の数と型、戻り値の明確性、副作用の有無、テスタビリティ、再利用性、パフォーマンス特性、エラーハンドリング、境界条件の処理。これらすべてを、瞬時に、並列に処理している。

世界は広がっていない。ただ、見えるものが増えているだけだ。

コードレビューを例に考えてみよう。プログラミングを始めたばかりの人は、コードを「動く」か「動かない」かで判断する。2つ。

少し経験を積むと、「読みやすい」「読みにくい」を加える。3つか4つ。さらに経験を積むと、もっと細かく見る。「変数名は適切か」「関数は単一責任か」「エラーハンドリングは十分か」。数十の観点。でも、経験を重ねたエンジニアは、そこで止まらない。同じ「変数名」でも、スコープの広さによって適切な抽象度が違う。同じ「関数」でも、ドメインの文脈によって適切な粒度が違う。同じ「エラーハンドリング」でも、システムの信頼性要件によって必要な厳密さが違う。そして、これらすべてが相互に影響し合っている。

区別の数は、無限に増えていく。

これは、世界が広がっているのではない。世界の解像度が、上がっているのだ。

初学者の目には、コードは大きな塊に見える。でも、経験を積んだエンジニアの目には、無数の細かい要素の集合として見える。同じコードを見ている。でも、見えている粒度が、まったく違う。

そして、重要なのは、この解像度の向上に、終わりがないということだ。

どれだけ専門性を深めても、さらに細かい区別が見えてくる。どれだけ経験を積んでも、見落としていた微細な違いに気づく。「ああ、今まで同じだと思っていたこの2つのアプローチは、実は違ったのか」。

専門家になることは、広い世界を制覇することではない。1つの領域を、無限に細かく見ることができるようになることだ。

コードの向こうに見える世界

そして、さらに経験を重ねると、もう1つの変化が起きる。コードの向こうに、人間が見えるようになる。

しかし、私が見ている「人間」は、客観的な事実ではない。あくまでも私の解釈だ。観察者の視点や意味づけによって、同じ対象は異なって見える。 同じコードを見ても、あるレビュアーは「急いでいる」と解釈し、別のレビュアーは「経験が浅い」と解釈する。バックエンドエンジニアとフロントエンドエンジニアでは、気になる点が違う。それぞれが、自分の専門性という枠組みやナラティブを通して、世界を観察しているからだ。

最初、私にとってコードは、ただのテキストだった。構文。ロジック。データ構造。技術的な要素だけが見えていた。

でも、数年経つと、コードの書き方から、書いた人の思考プロセスが見えるようになった。「この人は、パフォーマンスを重視している」「この人は、保守性を大切にしている」「この人は、急いでいる」。コードは、人の痕跡だ。

さらに経験を積むと、その人が置かれている状況も見えてくる。「このチームは、テストを書く文化がないのかもしれない」「この組織は、技術的負債を抱えているな」「このプロジェクトは、納期のプレッシャーがあったんだろう」。

コードレビューで、私は今、こんなことを同時に見ている。

技術的な側面：「この関数は責任が多すぎる」「このデータ構造は非効率だ」「このエラーハンドリングは不十分だ」。

人間的な側面：「この実装者は、この概念を理解しきれていない」「でも、一生懸命考えた跡がある」「この質問の仕方なら、防御的にならずに受け入れてくれるかもしれない」。

組織的な側面：「このコードの品質から、チームに時間的余裕がないことが分かる」「テストがないのは、テスト文化がないからだ」「リファクタリングの提案は、今は受け入れられないかもしれない」。

ビジネス的な側面：「この機能の優先度は高いから、完璧を求めすぎると納期に影響する」「でも、この部分は後で拡張する可能性が高いから、今直しておくべきだ」「この技術的負債は、半年後のリソース計画に影響する」。

同じコードを見ているのに、見えている世界の次元が、まったく違う。

初心者は、コードを見る。1次元だ。少し経験を積むと、コードと設計を見る。2次元だ。さらに経験を積むと、コードと設計と、それを書いた人が見える。3次元だ。

そして、十分に経験を積むと、コードと設計と人と、その人が置かれている組織と、その組織が抱えているビジネスの制約が、同時に見える。多次元だ。

これらすべてが、相互に影響し合っている。

技術的に最適な解決策が、組織の成熟度的に実現不可能なこともある。ビジネス的に正しい判断が、技術的な負債を生むこともある。人間関係の問題が、コードの品質に表れることもある。

新人の頃、私は純粋に技術的な判断をしていた。「このコードは良い」「このコードは悪い」。白か黒か。

でも今、私の判断は、常に文脈に依存している。「このチームの現在の状況を考えると、このコードは許容範囲内だ」「この納期とビジネスの重要性を考えると、今はこの技術的負債を受け入れるべきだ」「でも、次のスプリントで必ずリファクタリングする時間を確保しよう」。

解像度が上がるとは、細かく見えるようになることだけではない。複数の次元を、同時に見えるようになることだ。

そして、これらの次元の中でバランスを取る判断ができるようになることだ。

技術だけを見ていた時は、判断は単純だった。でも、人間と組織とビジネスが見えるようになると、判断は複雑になる。トレードオフだらけだ。完璧な答えはない。「状況による」が増える。

言語化の困難さの本質

私がコードレビューで後輩に指摘していたことを思い出す。「この変数名は、意図が伝わりにくい」。

後輩には、変数名は変数名だった。1つの塊だった。でも、私の目には、変数名は複数の要素の複合体として見えていた。長さ、具体性、文脈との整合性、ドメイン用語の使用、省略の適切性、一貫性、発音のしやすさ。

私は、新しい知識を持っていたのではない。同じ対象を、より細かく見ることができただけだ。

これが、「なんとなく分かる」の正体だ。

初心者は、粗い解像度で世界を見る。だから、判断に時間がかかる。意識的に、1つずつ、要素を確認しなければならない。

でも、経験を積むと、解像度が上がる。同時に、多数の要素を見ることができる。そして、パターンが見える。「ああ、このコードは、あのパターンだ」。瞬時に、無意識に。

解像度が上がると、判断が速くなる。そして、「なんとなく分かる」状態になる。

ここで、言語化の問題に戻ろう。

解像度が低い時は、言語化が容易だ。「このコードは動く」。1つの特徴を、1つの言葉で表現できる。

でも、解像度が上がると、言語化が困難になる。数百の特徴を、どうやって言葉にするのか。技術的な側面だけでなく、人間的な配慮、組織の文脈、ビジネスの制約。これらすべてを、どうやって一度に説明するのか。1つずつ列挙すれば、膨大な説明になる。でも、それでもまだ、すべては言語化できない。

だから、専門家は「なんとなく」と言う。言語化しきれないから。

でも、これは知識の欠如ではない。知識の豊富さの表れだ。見えているものが多すぎて、言語という1次元のメディアに、すべてを押し込めることができないだけだ。

そして、ここで1つの逆説が生まれる。

世界を深く知れば知るほど、言語化が困難になる。

初心者は、自信を持って説明できる。なぜなら、見えているものが少ないから。すべてを言語化できる。

でも、専門家は、躊躇する。「これは複雑で...」「一概には言えなくて...」「状況によるんだけど...」。なぜなら、見えているものが多すぎるから。例外を知っているから。文脈の重要性を知っているから。技術、人間、組織、ビジネスという複数の次元を見ているから。そして、それぞれの次元で、異なる評価軸があることを知っているから。

これは、専門家が曖昧だからではない。専門家の見ている世界の解像度が、言語の解像度を超えているからだ。

新人が「このコードは動きます」と自信を持って言う。技術的な次元しか見ていないから、判断は明快だ。

でも、ベテランが「状況によりますが...」と前置きする。なぜなら、技術、人間、組織、ビジネスという複数の次元を見ているから。

世界は、複数の次元に広がっている。専門性を深めることは、これらの次元を同時に見られるようになることだ。

段階的な解像度の向上

だから、教育には段階が必要だ。

最初は、粗い解像度で教える。「このシステムは、Kubernetesで動いています」。

次に、少し解像度を上げる。「Deploymentを使っていて、レプリカ数は3です」。

さらに解像度を上げる。「リソース制限を設定していて、requestsはCPU 100m、メモリ128Mi。limitsはCPU 200m、メモリ256Miです。Liveness ProbeとReadiness Probeも設定していて...」。

でも、本当はもっと細かい。なぜこのリソース値なのか。requestsとlimitsの比率をこうした理由は。QoSクラスへの影響を理解しているか。Probeの初期遅延とタイムアウトの設定根拠は。PodDisruptionBudgetは。Affinityルールは。PriorityClassは。HPAとVPAの使い分けは。ノードのリソース圧迫時の挙動は。そして、なぜこのインフラ構成を選んだのか。組織のスキルセットは。予算の制約は。ビジネスの成長見込みは。これら無数の判断が、「レプリカ数は3です」という一言の背後にある。

徐々に、徐々に、解像度を上げていく。一度にすべてを伝えようとしない。なぜなら、受け手の解像度も、段階的にしか上がらないから。

これが、知識の伝達が時間を要する理由だ。

情報の量の問題ではない。解像度の問題だ。そして、次元の問題だ。受け手の世界の解像度が上がるまで、細かい区別は伝えられない。受け手が複数の次元を同時に見られるようになるまで、多次元的な判断は共有できない。

世界は、広くない。ただ、解像度が無限にある。そして、複数の次元がある。

そして、専門性を深めることは、この解像度を上げ続けることだ。そして、見える次元を増やし続けることだ。終わりはない。どこまで行っても、さらに細かい区別が見えてくる。新しいパターンが見えてくる。見落としていた微細な違いに気づく。そして、新しい次元が見えてくる。

これが、学びに終わりがない理由だ。世界が無限に広いからではない。世界の解像度が、無限に細かくなっていくからだ。そして、世界は、複数の次元で構成されているからだ。

言語化すると価値が失われるもの

でも、ここで立ち止まって考えるべきことがある。

言語化すると、価値が失われるものがある。

職人の手に染み込んだ技術。音楽家の指が覚えている感覚。アスリートの瞬時の判断。料理人の微妙な味の調整。

これらを無理に言語化しようとすると、何が起きるか。技術が、死ぬ。

職人が、自分の技を言語化しようとする。「まず、木目を見て、ここに刃を入れて...」。でも、説明している間に、職人は気づく。自分が本当にやっていることは、これじゃない。もっと微妙で、もっと複雑で、もっと直感的だ。

そして、説明に従って作業をすると、うまくいかない。なぜなら、言語化した瞬間、技術の本質が抜け落ちているからだ。

音楽家が、自分の演奏を分析しようとする。「この音は、もっと強く。このタイミングで、指を...」。でも、分析している間に、音楽が死ぬ。音楽は、分析の対象ではない。流れだ。感情だ。身体と楽器の一体化だ。それを言葉にした瞬間、ただの技術的な指示になる。

言語化は、対象を固定する。でも、固定された瞬間、生命が失われる。

これが、言語化の暴力性だ。言語化は、流れているものを止める。動いているものを固定する。生きているものを標本にする。

そして、標本は、生きている生物ではない。

ムカデの寓話がある。ムカデは、何百本もの足を完璧に協調させて歩いている。ある日、「どの足から動かしているのか」と聞かれた。ムカデは考え始めた。そして、歩けなくなった。

意識化は、時に機能を破壊する。言語化は、時に価値を失わせる。

だから、すべてを言語化しようとしてはいけない。言語化できないものを、無理に言語化してはいけない。そして、言語化すると価値が失われるものは、言語化せずに、そのまま保存すべきだ。

沈黙にも、価値がある。曖昧さにも、価値がある。矛盾にも、価値がある。言葉にならない何かにも、価値がある。

いや、むしろ、言葉にならないからこそ、価値がある。

言語化すべきものと、すべきでないもの

では、何を言語化すべきか。

私の考えはこうだ。他者との協働を可能にするものを、言語化すべきだ。

ここで言う「他者」には、未来の自分も含まれる。半年後、一年後の自分は、もはや別人だ。今の文脈も、今の意図も、驚くほど忘れている。だから、未来の自分のために言語化する。それは、時間を超えた協働だ。

一人で自転車に乗る限り、乗り方を言語化する必要はない。でも、他人に教えようとすれば、ある程度の言語化が必要になる。

その言語化は、不完全だ。言語化されたルールだけでは、自転車には乗れない。でも、まったく無言で教えることも、困難だ。言語は、身体的な模倣と試行錯誤を、補完する。「もっと前を見て」「ペダルに力を入れて」。こういう言葉が、学習を助ける。

コードも同様だ。一人でプロジェクトを進めるなら、最小限のコメントで済む。しかし、チームで開発するなら、設計意図、トレードオフ、制約条件を言語化する必要がある。

その言語化は、コード自体をすべて語るわけではない。でも、それはチームメンバーがコードを理解し、うまく修正するための、補助線となる。「このクラスは、将来的に拡張する可能性があるため、interfaceを定義している」。この一行のコメントが、半年後の自分や他のメンバーを助ける。

つまり、言語化は、独立した目標ではない。それは、協働のためのインターフェースだ。

したがって、必要な言語化の量と精度は、協働の必要性によって決まる。全てを言語化する必要はない。ただ、共有すべきものを、共有可能な形式で提示できればよい。

そして、言語化すべきでないものもある。

個人的な感覚。創造的な直感。美的な判断。フロー状態。無意識の判断。

これらは、言語化すると、かえって失われる。

これは私の実感だが、感覚的に掴んでいたものを、誤った言語化をしてしまって失われた経験がある。うまく説明できない「何か」を無理やり言葉にした瞬間、その繊細なニュアンスが消えてしまった。言語化という行為が、対象を固定し、単純化し、本質を取りこぼす。そういうことが、ある。

だから、言語化のタイミングが重要だ。

実践の最中には、言語化しない。ただ、流れに身を任せる。自転車に乗りながら、乗り方を考えない。コードを書きながら、書き方を分析しない。演奏しながら、指の動きを意識しない。

でも、実践の後に、振り返る。「なぜうまくいったのか」「何が違ったのか」「次回はどう改善できるか」。

これが、行為の中の省察と、行為についての省察の違いだ。行為の中では、言語化しない。でも、行為の後に、言語化する。そして、その言語化が、次の実践を導く。

ただし、その言語化さえも、慎重であるべきだ。すべてを言葉にしようとしない。言葉にできるものだけを、言葉にする。そして、言葉にならない部分の存在を、認める。

生成AI時代における知識の変容

ここで、現在の文脈に話を戻そう。

生成AIの登場は、知識の変容プロセスに、何をもたらしたのか。

AIは、スピードと量を劇的に増やした。コードを書く速度。試せるアプローチの数。生成できるバリエーションの数。

これは、パターン認識の閾値に到達するまでの時間を、劇的に短縮する可能性がある。以前なら数ヶ月かかっていた量を、数日で経験できる。

でも、ここで重要なのは、ただ量をこなすだけでパターンが見えるわけではないということだ。

AIが生成したコードを見る。動かす。次のコードを生成する。また動かす。このサイクルを高速で回すことはできる。しかし、振り返りがなければパターンは見えない。

量が増えても、振り返りがなければ、質的な変化は起きない。閾値は超えられない。

これが、生成AI時代における人間の役割だ。

AIが生成したコードを、振り返る。なぜこのコードが動くのか。どのパターンを使っているのか。このパターンは、他の問題にも使えるか。このアプローチの限界は何か。

この振り返りを通じて、AIが提供した量を、自分の質に変換する。

そして、もう1つ重要なのは、目的意識だ。

AIは、膨大な可能性を提示する。でも、その中から、何を選ぶか。どの方向に進むか。これを決めるのは、人間だ。

目的がなければ、AIが生成する大量の選択肢の中で、迷子になる。でも、明確な目的があれば、AIは強力な探索ツールになる。「こういう問題を解決したい」「こういう制約の中で、最適なアプローチを探している」。この目的を持って、AIと対話する。

つまり、生成AI時代において、知識の変容プロセスは、こうなる。

AIが量を提供する → 人間が振り返る → パターンが見える → 質的な変化が起きる → 身体化された知識が更新される → より高度な目的を持って、AIに問いかける → さらに多くの量を経験する → より深い振り返り → ..

この循環が、新しい学習のサイクルだ。

でも、ここで注意すべきことがある。

AIが生成するものは、言語化された知識だ。コードも、説明も、提案も、すべて言語の形をしている。

これを身体化された知識に変換するには、実践が必要だ。AIが提案したコードを、実際に使ってみる。動かしてみる。失敗してみる。修正してみる。この実践の中で、初めて、言語化された知識が身体化される。

AIは、言語化された知識へのアクセスを、劇的に増やした。でも、身体化のプロセスは、依然として人間の中で起きる。そして、そのプロセスには、時間がかかる。

だから、AIを使っても、学習の本質的なプロセスは変わらない。

言語化された知識 → 実践 → 振り返り → パターン抽出 → 身体化された知識

このサイクルは、依然として人間の中で回る。AIは、このサイクルの速度を上げる。でも、サイクルを飛ばすことはできない。

人間は言葉を通して世界を認識している

「言語化」という言葉が隠している前提

最後に、根本的な問いに戻ろう。そもそも、言語化する前の思考は、存在するのか。

私が「今日は疲れた」と思う時、その「疲れた」という感覚は、「疲れた」という言葉より先に存在しているのか。それとも、「疲れた」という言葉があるから、この身体のだるさを「疲れ」として認識できているのか。

考えれば考えるほど、分からなくなる。

ここで、「言語化」という言葉そのものについて、考えてみたい。

この言葉には、ある前提が潜んでいる。「言語にする以前から、その感覚や対象が存在した」という前提だ。まず感覚がある。それを、言葉という容器に移し替える。これが「言語化」だと。

この理解では、言語はツールだ。すでに存在する何かを、伝達可能な形式に変換するための道具。でも、言語にはもう1つの側面がある。「語られて初めて、その対象が見える」という側面だ。

言語の持つ「ツール的性質」は重視される。でも、「世界の開示」という性質は、忘れられがちだ。

言語が世界を切り分ける

たとえば、ある文化には、雪を表す言葉が数十種類ある。粉雪、湿った雪、固まった雪、解けかけの雪。それぞれに違う言葉がある。

これを聞いた時、私たちは通常こう考える。「彼らは雪の細かい違いを認識できるから、言葉がある」。つまり、認識が先、言葉が後だと。

でも、逆なのだ。言葉があるから、違いを認識しやすくなる。

言語は、世界を分割する。その分割線は、恣意的だ。でも、一度引かれると、私たちの認識を構造化する。

日本語には「木漏れ日」という言葉がある。木の葉の隙間から差し込む光。英語には、対応する単一の言葉がない。"sunlight filtering through trees"と説明しなければならない。

日本語話者は、木の葉の隙間から差し込む光を見た時、それを1つの概念として認識できる。英語話者も、もちろん同じ光景を見ることはできる。でも、それを「1つのもの」として切り取る認知的なツールを、持っていない。これは、些細な違いに見えるかもしれない。でも、積み重なると、世界の見え方が変わる。

プログラミング言語も同じだ。

オブジェクト指向言語で考える人と、関数型言語で考える人は、同じ問題に対して、異なる解決策を思いつく。それは、言語が提供する抽象化のツールが、異なるからだ。

「クラス」「継承」「カプセル化」という概念で考える人。「関数」「不変性」「副作用」という概念で考える人。同じ問題を見ても、見えているものが違う。

言語は、ただ既存の認識を伝えるツールではない。言語は、何が見えるかを決める。

つまり、私たちは、言語を通して世界を認識している。言語化する前の「純粋な経験」など、どこにもない。

経験は、常にすでに、言語によって構造化されている。

言語化の両義性

ここまで、このブログ全体を通じて、私は「言語化」という言葉を使ってきた。身体化された知識を言語化する難しさ。言語化による情報の損失。

これらの議論は、言語をツールとして捉えている。すでに存在する知識を、言葉という形式に変換する、と。

でも同時に、私は別のことも語ってきた。新しい概念を学ぶことで、世界の見え方が変わる。「拡張性」という言葉を知ることで、それまで見えなかった問題が見えるようになる。

これは、言語の世界開示的な側面だ。

言語は、ツールでもあり、世界を開くものでもある。

そして、この二つは矛盾しない。

コードレビューで後輩に「この設計は拡張性を損なっている」と言う時、言語はツールとして機能している。私の判断を伝達している。でも同時に、「拡張性」という概念そのものが、問題の見え方を規定している。この言葉がなければ、後輩はこの問題をこの形では認識できない。

言語化は、翻訳であると同時に、発見でもある。

そして、この認識が、重要な示唆をもたらす。

言語化の質を高めることは、語彙を増やすことではない。世界を見る解像度を上げることだ。

そして、解像度が上がると、以前は見えなかったものが見えるようになる。区別できなかったものが、区別できるようになる。1つだったものが、複数に分かれる。

これは、単なる言葉の問題ではない。認識の問題だ。世界の見え方が、変わる。

新しい概念を学ぶとは、新しい言葉を覚えることではない。新しい切り分け方を獲得し、それによって世界が別様に見えるようになることだ。

「言語化」という言葉が使われる違和感

そして、ここまで語ってきて、私は冒頭で感じた違和感に、再び戻ってくる。

「言語化」という言葉を聞くたびに感じる、あの居心地の悪さ。

この数年、「言語化力」「思考の言語化」「感情の言語化」といった言葉を、至る所で目にするようになった。まるで、言語化さえできれば、すべてがうまくいくかのように。

でも、何かが違う。そう感じ続けてきた。

今なら、その違和感の正体が、少し分かる気がする。「言語化」という言葉が、本来の厳しさを失って、語られているのではないか。

少なくとも私が経験してきた言語化は、苦しいものだった。自分の感情を言語化しようとすると、その感情の曖昧さに気づく。「怒っている」と思っていた。でも、違う。無力感と焦燥感と羨望が混ざっている。そして、その複雑さに向き合うのは、痛みを伴う。

自分の思考を言語化しようとすると、その思考の矛盾が見えてくる。Aだと思っていた。でも、実はBも正しい。AとBは矛盾している。この矛盾を認めることは、自分の考えの浅はかさを認めることだ。

言語化には、一種の自己否定が伴う。少なくとも、私にとっては。

自分の理解が不完全だったと認める。自分の視点が偏っていたと気づく。自分が変わることを受け入れる。これは、楽なことではない。

でも、今、広く使われている「言語化」という言葉は、この厳しさを含んでいるだろうか。

「私の気持ちを言語化できた」。そこで終わる。その気持ちの正当性を問わない。その感情の複雑さを掘り下げない。ただ、「言語化できた」という事実が、安心材料になる。

これは、たぶん、偶然ではない。

仕事は忙しくなり、常に成果を求められる。SNSは即座の反応を要求し、熟考の時間を奪う。情報は溢れ、深く考える前に次の情報が流れてくる。

私たちは、葛藤したり苦悩したりしながらものを考える余裕を、失いつつあるのかもしれない。

だから、自分を揺さぶる言語化ではなく、自分を肯定してくれる言語化が求められる。自己を問い直す言語化ではなく、自己を確認する言語化が選ばれる。

私は、この変化を批判したいわけではない。余裕がないのは、事実だろう。誰もが、必死に生きている。

ただ、「言語化」という言葉を使う時、私たちは注意深くありたい。

言語化は、自己肯定のツールではない。言語化は、自己を揺さぶり、変容させるものだ。

自分の矛盾に向き合う覚悟。自分の無知を認める勇気。自分が変わることを受け入れる強さ。

これらを伴わない言語化は、言語化の名に値しない。それは、思考の停止だ。成長の放棄だ。

だから、もし「言語化しよう」と言うなら、その厳しさも引き受けるべきだ。そして、もし余裕がないなら、無理に言語化しなくてもいい。

言葉にならないものを、言葉にならないまま抱えていることにも、価値がある。

曖昧さを保留すること。矛盾を抱えたまま生きること。これらもまた、大切なことなのだと思う。

おわりに

このブログを書き終えて、私は少し不思議な気持ちになっている。数年前、後輩に「なんとなく」と言われた時、私は焦っていた。どうやって教えればいいのか。どんな言葉を使えば伝わるのか。万能な説明を探していた。でも、今なら分かる。万能な説明など、存在しない。言語化は、常に不完全だ。身体化された知識を言語化する時、必ず何かが失われる。それは、言語化の欠陥ではない。言語化の本質だ。そして、それでいいのだと思う。言語化しきれないからこそ、共同作業に意味がある。マニュアルを読むだけでは分からないからこそ、一緒に働く価値がある。言葉にならない何かを、空気感で伝え合う。その過程で、新しい知識が生まれる。

「おい、言語化しろ」。この言葉は、一見、すべてを言語化することを要求しているように見える。でも、私はもう、そうは思わない。この言葉は、むしろ、こう言っているのだと思う。「言語化できるものを言語化しろ。でも、言語化できないものを、無理に言語化するな」。協働のために必要なことは、言語化しよう。設計の意図、判断の理由、制約条件。これらを共有することで、チームは機能する。でも、すべてを言語化する必要はない。無意識の判断、身体の感覚、創造的な直感。これらは、言語化しないままでいい。言語化すると、かえって失われるから。そして、言語化する時も、謙虚でいよう。「これは、私の視点からの言語化だ」「他の見方もあり得る」「これは、全体ではない」。この謙虚さが、言語化の暴力性を和らげる。

身体化された知識、言語化された知識、実践知。3つの知識は、それぞれに価値がある。それぞれに限界がある。一方から他方への変換は、必ず何かを取りこぼす。でも、不完全な変換を繰り返すことで、知識は循環する。深まる。豊かになる。この数年間、私は「言語化」という言葉の違和感と向き合ってきた。そして、今、私はこう思う。言語化は、必要だ。でも、すべてを言語化する必要はない。言語化できないものには、価値がある。沈黙にも、曖昧さにも、矛盾にも、価値がある。

言語化は、道具だ。協働のための、理解のための、成長のための、道具だ。でも、人間の全てを、この道具に還元することはできない。言語を超えたところに、私たちは存在している。だから、言語化しよう。でも、言語化できないものを、忘れるな。

参考文献

言語化するための小説思考

こうやって頭のなかを言語化する。

ことば、身体、学び　「できるようになる」とはどういうことか (扶桑社ＢＯＯＫＳ新書)

熟達論―人はいつまでも学び、成長できる―

人生の大問題と正しく向き合うための認知心理学 (日経プレミアシリーズ)

「何回説明しても伝わらない」はなぜ起こるのか？　認知科学が教えるコミュニケーションの本質と解決策

私たちはどう学んでいるのか　――創発から見る認知の変化 (ちくまプリマー新書)

知識創造企業（新装版）

経験する機械　――心はいかにして現実を予測し構成するか

訂正可能性の哲学