言葉の定義にはこだわりすぎないようにしたいね

enk
·

この方のポストを見て、「僕はエンジニアの中でもとりわけ言葉にこだわるタイプなんだよな……」ということを思った。そしてま〜たしかに摩擦が生じることもあるなと。

この本は、読んでみようかなと思う。(ちなみに同著者の『訂正する力』は読んで、とても面白かった)

それはそうと、僕がふだん「定義を過大評価」しているかというと、そうでもない気もするなあという感覚もあって(まあ自分のことだからそう思うのは当然かもだけど)、そのことについてちょっと考えてみようかと思う。

自己弁護するというよりは、できるだけ批判的に考えてみよう。できるだけね。

さて、僕がなぜ言葉(の定義)にこだわるかというと、言葉は意味に通じているからだ。仕事上のコミュニケーションを取ったり、ソフトウェアを作るとき、探索し、掴み、交換したいのは「意味」だ。そして、ふつう違う言葉には違う意味がある。

「ふつう違う言葉には違う意味がある」というフレーズは、批判の余地がありそうだ。人は異なった人生を送ってきているので、違う人が違う言葉で同じ意味を示していることもある。そう考えると、一般的な仕事上のコミュニケーションでは、言葉遣いを厳密に「揃える」必要はないということがわかる。個々人が個々人のコンテキストをもち、それぞれの言葉を使っていても、「意味」が大まかに通じていれば十分問題ないケースは少なくない。

一方で、ソフトウェアを作るときはそう簡単にはいかないと思う。コードにはあいまいさが許されない。だから、たとえば(あまりいい例ではない気もするけど……)「登録する」という言葉を使っている人と、「書き込む」という言葉を使っている人がいたとき、その意味の同一性は十分疑うに値する。たとえば、「登録する」と言っている人は「追記」を想定していて、「書き込む」と言っている人は「上書き」を想定しているかもしれない(改めてうまい例ではないなと思うが、イメージはできると思う)。ここで、普段使っている言葉が「登録」だとしよう。そんなとき僕は、「その "書き込む" というのは普段で言うところの "登録" のことでいいんですよね?」と確認する。

もちろん、「念のためですが、書き込むといっても上書きしたいということではなくて、いつも通り追記でいいんですよね?」と聞いてもいいだろう。ただ、日常からみんなが注意深く同じ言葉を使うようになれば、都度確認する必要も減るし、確認漏れによるミスも減るので、その方がいいと思い、僕は同じ言葉を使う方を好んでいる。

ここに批判を加えるとすれば、僕は同じ言葉を使う(また、使わせられる)ことにストレスを感じないが、他の人は感じている可能性がある、ということだろう。仮に同じ「結果」が得られるなら、ストレスの少ない手段の方がよい。

これについては、周りの人がどれくらいのストレスを感じているか検証したことがないので、正確にはわからない。ただ、全体で結構トントンくらいかもな、という気はしている。エンジニア中心の集まりならたぶん言葉を揃えるメリットの方が大きいだろうし、エンジニアが少ない集まりなら違うアプローチの方が効果的になる可能性が高そうな感じもする。ただ、ソフトウェアを作る場面ではたいていエンジニアが多数派になるのと、エンジニアの理解が最終的なコードに直結するので、純粋な効率だけを考えれば(エンジニアにやさしい)「言葉を揃えるアプローチ」の方がいいとは思うなあ。

こう考えてみて、(改めてではあるけれど)「言葉を揃える」というのはアプローチの一つにすぎず、その有効性も場面による、ということが確認できた。

『訂正可能性の哲学』、今度読んでみよう。