コンテンツにスキップ

おい、言語化しろ

チェック

  • [ ] 本文を確認した
  • [ ] 概要を確認した
  • [ ] タグを確認した
  • [ ] inbox/ 直下へ移行した

概要

「言語化できる知識」と「言語化しきれない実践知」の違いを、コードレビューや教育の経験から考える記事。 専門家が「なんとなく」と言うのは知識がないからではなく、見えている変数が多すぎて一次元の言葉に圧縮しきれないから、という主張が中心。 言語化は不要なのではなく、観察、経験、振り返り、目的意識を通して解像度を上げる営みとして扱うべき、という整理。

本文

この記事は、「言語化できないものには価値がないのか」「本当にすべてを言語化すべきなのか」という問いを、後輩へのコードレビュー指導、身体知、実践知、生成AI、言語哲学の話へ広げながら考えている。

知識の水面下にあるもの

冒頭の経験は、後輩に良いコード・悪いコードを説明してもなかなか伝わらなかった話。ところが三ヶ月ほど経つと、その後輩は筆者が指摘していたような問題を自分で見つけるようになる。理由を聞くと、本人は「見ればわかる」としか言えない。

この「なんとなく」は、知識がない状態ではなく、言葉にできない知識が身体化された状態として扱われる。本人は確かに判断できる。しかし、なぜ判断できるのかを説明できない。

自転車の例が使われている。自転車に乗る人は、視覚、平衡感覚、筋肉の反応、路面の変化を並列に処理している。倒れそうになった瞬間、身体は自動的に反応する。これを「体重を何度傾けて、ハンドルを何度切る」と逐次的に説明しても、自転車には乗れない。

ここから、知識には言葉になる知識と言葉にならない知識がある、という整理に進む。歩く、話す、顔を認識する、危険を察知する、空気を読む。これらは明示的に説明できなくても、人は確かに知っている。

翻訳としての言語化

記事では、言語化を「圧縮」ではなく「翻訳」として捉える。身体化された知識を言葉にするとき、並列的な感覚を逐次的な説明に翻訳することになる。その過程で、タイミング、力加減、文脈、微妙なニュアンスは失われる。

ただし、失われるだけではない。言語化によって、構造、関係性、パターンが生まれる。身体化された知識のままだと混沌としているものが、言葉にすることで「この判断は何と何を比較していたのか」「この感覚はどの経験から来ているのか」と見えてくる。

つまり、言語化は知識を貧しくする一方で、知識を明晰にもする。この二面性が記事の重要な軸になる。

地図としての言語化

言語化された知識は地図に似ている。地図は現実そのものではない。現実をそのまま写すなら、地図は現実と同じ大きさになってしまい、役に立たない。地図は、重要な情報を強調し、不要な情報を削ることで機能する。

レシピの「塩少々」も同じ。熟練した料理人は、食材、湿度、火加減、味見、食べる人の好みを見て、その場の最適量を判断する。しかしレシピには平均化された量しか書けない。言語化された知識は、個別の文脈を捨て、一般化された近似値を提示する。

だから、マニュアルや教科書を読んでも実践がうまくいかないことがある。これは読む人が無能だからではなく、言語化された知識には身体化された知識の一部しか含まれないから。

実践知という第三の形

記事は、身体化された知識と言語化された知識の間に、実践知を置く。実践知は、現場で観察し、判断し、修正する知識。看護師が患者の微細な変化に気づく、教師が生徒の表情で授業の進め方を変える、エンジニアがコードを書きながら設計の問題に気づく、といったもの。

これは「計画して実行する」だけではない。実践しながら観察し、判断し、修正する循環である。一般化されたルールだけでは、複雑で文脈依存の現実には対応できない。

振り返りが量を質に変える

実践知は、経験の量だけでは育たない。経験を振り返ることで、事例の中に隠れているパターンが見えるようになる。

記事では、振り返りの深さが3段階で整理される。

  • 表面の振り返り: 何が起きたかを記録する
  • 中層の振り返り: なぜそれが起きたかを考える
  • 深層の振り返り: その背後にあるパターンを抽出する

「このエラーが出た」だけでは記録に近い。「なぜ出たか」を考えると因果が見える。さらに、「前に見たエラーと同じ構造ではないか」「この設計判断は他でも使える原則ではないか」と考えることで、経験が汎用的なパターンに変わる。

ここに目的意識が必要になる。何を上達させたいのか、何を観察したいのかがなければ、経験はただ流れていく。

言葉を探す行為

言語化は、既存の言葉の中から、自分の内側の形に近いものを探す行為として説明される。靴を試着するように、ある感覚に「不安」「焦燥感」「無力感」といった言葉を当ててみる。どれか一語では合わない場合、複数の言葉を組み合わせる。

この過程で、形のなかった感覚に輪郭が生まれる。重要なのは、新しい言葉を作ることではなく、既存の言葉を試し、組み合わせ、自分の経験に近づけていくこと。

抽象と具体の往復

優れた言語化は、抽象と具体を往復する。最初に「これは不安だ」と抽象化し、その後で「胸の中心が空洞になった感じがする」「肩が内側に引っ張られる」と具体化する。その具体を見直して、「不安というより無力感に近い」と再度抽象化する。

この往復により、経験の解像度が上がる。最初は一つの塊だったものが、複数の要素に分かれる。

解像度としての観察

言語化の質は語彙量ではなく、観察の質で決まる。コーヒーを飲んで「苦い」とだけ言う人と、舌触り、後味、香り、温度変化を分けて観察できる人では、同じ語彙を使っても表現の精度が違う。

コードレビューでも同じ。変数名をただ「わかりにくい」と言うのではなく、長さ、具体性、文脈との整合性、ドメイン用語、省略の妥当性、一貫性、発音しやすさなど、複数の要素に分けて見られるかが重要になる。

ただし、観察は背景知識に依存する。「単一責任の原則」を知る前と後では、同じコードから見えるものが変わる。観察力を上げるとは、世界を切り分ける概念を増やすことでもある。

世界は広がるのではなく細かくなる

プログラミングを始めたばかりの頃は、学ぶことが無限に広がっているように感じる。しかし筆者は、実際には世界が横に広がるというより、既に知っているものの解像度が細かくなるのだと述べる。

最初は「コードを書く」という一つの塊だったものが、変数、関数、ループ、条件分岐に分かれる。さらに関数は、純粋関数、副作用、引数、戻り値、テスタビリティ、エラーハンドリング、境界条件などに分かれる。

経験者が「なんとなくわかる」のは、見えている要素が多く、それらを並列に処理しているから。初心者は粗い解像度で見るため言語化しやすい。専門家は見えている要素が多すぎるため、逆に一言で言い切れなくなる。

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

記事は、すべてを言語化すべきではないとも述べる。職人の手の感覚、音楽家の演奏、アスリートの瞬時の判断のように、言語化すると流れや身体性が壊れるものがある。

ムカデの寓話も出てくる。たくさんの足を協調させて歩いていたムカデが、「どの足から動かすのか」と聞かれて考え始め、歩けなくなる。意識化や分析は、時に機能を破壊する。

だから、言葉にできないものを無理に言葉にしない態度も必要になる。曖昧さや沈黙にも価値がある。

実践中と言語化のタイミング

実践の最中には、無理に言語化しない方がよい。自転車に乗りながら乗り方を分析しない。コードを書きながらすべての判断を逐語的に説明しない。

ただし、実践の後に振り返ることは重要。うまくいった理由、違った点、次に改善できることを考える。行為の中では言語化せず、行為の後で言語化する。この区別が大事になる。

生成AI時代の知識変容

生成AIは、コードを書く速度、試せるアプローチの数、生成できるバリエーションを増やす。これにより、パターン認識に必要な経験量へ到達する時間は短くなる可能性がある。

しかし、量だけでは質的変化は起きない。AIが生成したコードをただ動かして次へ進むだけでは、パターンは見えない。人間が「なぜこのコードが動くのか」「どのパターンが使われているのか」「このアプローチの限界は何か」と振り返ることで、AIが提供した量を自分の質へ変換する。

AI時代の人間の役割は、生成物を消費するだけではなく、生成物を観察し、構造を見つけ、自分の実践知へ変換することになる。

言語は世界を切り分ける

後半では、「言語化する前の思考は存在するのか」という問いに進む。言語化という言葉には、言語にする前から感覚や対象が存在し、それを言葉という容器へ移すという前提がある。

しかし、言語にはもう一つの側面がある。言葉があるから対象が見える、という側面。雪を表す言葉が多い文化では、雪の違いを細かく認識しやすい。日本語の「木漏れ日」のように、言葉があることで特定の現象を一つの概念として切り取れる。

プログラミング言語も同じ。オブジェクト指向の言語で考える人と、関数型の言語で考える人は、同じ問題を違う形で切り分ける。クラス、継承、カプセル化で見るのか、関数、不変性、副作用で見るのかによって、見える解決策が変わる。

言語は、既にある認識を伝えるだけの道具ではない。何が見えるかを決める。

言語化の両義性

言語化は翻訳であると同時に発見でもある。自分の判断を相手へ伝える道具である一方、概念を得ることで世界の見え方そのものを変える。

コードレビューで「拡張性」という言葉を使うとき、筆者の判断を伝えるだけでなく、「拡張性」という概念自体が、相手に新しい見え方を与える。この意味で、新しい概念を学ぶとは、新しい言葉を覚えることではなく、新しい切り分け方を得ること。

「言語化」という言葉への違和感

最後に、筆者は最近の「言語化力」ブームへの違和感を述べる。言語化は、本来かなり厳しい営みである。自分の感情を言語化しようとすると、その曖昧さや混合に気づく。自分の思考を言語化しようとすると、矛盾や浅さに気づく。

言語化には自己否定が伴う。自分の理解が不完全だったこと、自分の視点が偏っていたこと、自分が変わる必要があることを受け入れる行為だから。

しかし、今よく語られる言語化は、自己肯定の道具になりがちだと指摘される。「気持ちを言語化できた」で終わり、その感情の正当性や複雑さを問わない。忙しさやSNSの即時反応の中で、深く考える余裕が失われ、自分を揺さぶる言語化ではなく、自分を安心させる言語化が選ばれているのではないか、という問題意識がある。

記事の結論は、言語化は自己を揺さぶり変容させるものであり、自己肯定だけのために使うものではない、ということ。同時に、余裕がないときは無理に言語化しなくてもよい。言葉にならないものを、言葉にならないまま抱えることにも価値がある。

要点

  • 「なんとなく」は無知ではなく、身体化された知識が言語に圧縮されていない状態の場合がある。
  • 言語化された知識は地図であり、現実そのものではない。
  • 経験は、目的意識と振り返りがあって初めて実践知になる。
  • 言語化の前に、対象を高解像度で観察できているかが重要。
  • 熟練者が断言を避けるのは、見えている変数が多いから。
  • 教育や引き継ぎでは、粗い解像度から段階的に細かい判断基準へ進めるのがよい。

タグ

tacit-knowledge #learning #engineering-growth #code-review #communication #expertise