この記事はChatGPTとの壁打ちで生まれた文章を編集して作成したものです。
はじめに
前回の記事では、ノートで同じ書き出しを繰り返す際に使っていた「〃」をきっかけに、伝統と革新について考えました。
便利だから導入した新しい方法が、いつの間にか「こう書くものだ」という規範へ変わる。そして一度捨てられた古いやり方が、後になって新鮮なものとして戻ってくる。
そこからJavaの後方互換性や、Kotlin・Scalaとの進化の違いについても考えました。
今回の記事も、きっかけはノートでした。
しかしテーマは少し違います。
前回と同じノートを後から見返してみると、自分の文章の中に、
こと
と、
事
が混在していることに気付きました。
出版物だったら、おそらく編集や校正の段階で何らかの統一が行われるでしょう。
しかしこれは自分しか読まないノートです。
私は、
まあ、意味は分かるし、このままでいいか
と思い放置しましたが、その後もこの些細な「表記ゆれ」が妙に気になりました。
なぜ正式な文章では表記の統一を求めるのに、自分だけが読むノートでは平気なのだろう。
そもそも、なぜ現代日本語では「こと」と「事」のように、同じ語を漢字とひらがなで使い分けるのだろう。
さらに考えていくと、この問題は自然言語だけではなく、プログラミング言語のコーディング規約や、Java・Kotlin・Scalaの広まり方にまで似た構造を持っているように思えてきました。
今回は、この「こと／事」から話を始めてみようと思います。
「こと」と「事」の話
「こと」と「事」は、単なる字体の違いではない
文化庁の現行の公用文指針では、形式名詞について、
事 → こと
時 → とき
所・処 → ところ
物・者 → もの
という仮名書きを基本とします。一方で、「事は重大である」「法律の定める年齢に達した時」「家を建てる所」のように、より実質的な対象を指す場合には漢字を使う、という区別をしています。
たとえば、
彼が来ることを知っている。
の「こと」は、「事件」「出来事」のような独立した物事を強く指しているわけではなく、前の文を名詞化する形式名詞です。
対して、
それは重大な事だ。
なら、「事柄」「出来事」に近い語彙的意味が残っているので「事」が自然になり得る。
つまり日本語では、同じ「こと」という音であっても、
語彙的意味が濃い → 漢字
文法的機能が強い → ひらがな
という方向性が存在します。
これは非常に重要です。
「漢字にできるなら漢字にする」という単純な体系ではないのです。
漢字とひらがなには「意味の濃度」のようなものがある
ある語が元々持っていた具体的な意味を薄め、文法的な働きを担うようになることがあります。
「こと」だけでなく、
～してみる
～していく
～してくる
～していただく
も同様です。
「見る」「行く」「来る」「頂く」が本来の動作を表す場合は漢字ですが、
ちょっと考えてみる
状況が変わっていく
問題が見えてくる
説明していただく
では補助的な文法機能が強くなるため、現行の公用文指針でも仮名書きを基本としています。
したがって現代日本語の漢字・仮名交じり文には、極端に言えば、
漢字＝語彙的な骨格
ひらがな＝文法的な接着剤
という傾向があります。
もちろん完全な規則ではありません。しかし、日本語母語話者はこの違いをかなり無意識に利用しています。
だから、「彼が来る事を知っている」と書いても読めますが、「彼が来ることを知っている」の方が多くの現代人には「普通の文章」に見える。
これは「事」が間違っているからというより、文字種そのものが統語構造を視覚的に示しているからとも考えられます。
「ひらがな」を「平仮名」とあまり書かないのも面白い
考えてみれば、「ひらがな」そのものも面白い。
もちろん、
平仮名
という表記は存在します。
しかし一般的には、
ひらがな
と書くことが多いです。
しかも「ひらがな」という語をひらがなで書くと、その文字列自体が、
これがひらがなです
と実演しています。
一方、
平仮名
と書くと、少し国語学的・専門用語的に見えます。
同じ語なのに、
ひらがな
→ 日常語・親しみ
平仮名
→ 分類語・学術的
という社会的ニュアンスが生まれる。
これは、文字種そのものが社会的意味を持つという好例でしょう。
社会学的には「表記規範の身体化」と考えられる
日本語は、
- 漢字
- ひらがな
- カタカナ
- アルファベット
が共存している言語です。
そのため、同じような意味でも、
ありがとう
有難う
かわいい
可愛い
きれい
綺麗
こと
事
のような選択が生まれます。
このとき私たちは意味だけを選んでいるのではなく、同時に、
- 硬い
- 柔らかい
- 古風
- 現代的
- 専門的
- 日常的
- 親しみやすい
- 重々しい
といった印象も選んでいます。
つまり日本語では、
何を書くか
だけではなく、
それをどの文字体系で見せるか
まで表現の一部になっています。
ここからさらに面白い解釈ができます。
私たちは学校で、「これは漢字で、これはひらがな」という規則を一語ずつ完全に暗記しているわけではありません。
大量の文章を読むうちに、
～することができる
～というもの
～するとき
このように
さらに
したがって
といった文字列を何万回も目にします。
すると、「なぜか分からないけれど、こっちの方が自然」という感覚が形成されていきます。
社会学的に言えば、これはある種のハビトゥスとして考えられます。
明示的な規則を参照しなくても、
「この文章、なんとなく漢字が多くて硬い」
「ここを『事』にすると妙に古臭い」
「『頂く』より『いただく』の方が自然」
と感じる。
規範が頭の中のルールブックとして存在しているというより、読む・書くという反復経験によって身体化されているのです。
それなのに、なぜノートでは「こと」と「事」が混じったのか
ここからが今回の本題です。
私たちは普段、形式名詞なら比較的自然に「こと」と書いているはずです。
それなのに個人的なノートでは、「こと」と「事」が混在していた。
しかも後で気付いても、
別に直さなくていい
と思った。
これは表記規則を知らなかったからではありません。
むしろ、
出版物なら訂正されそうだ
と思った時点で、規範そのものは認識していました。
それでも直さなかった。
つまり、
規範を知らないこと
と、
規範を適用しないこと
は別なのです。
話し言葉なら、この現象は分かりやすいでしょう。
友人との会話なら、
マジで？
と言う人でも、面接の場では、
本当でしょうか？
と言える。
彼らは「マジで？」しか知らないわけではありません。場面によって言語の使い方を切り替えています。
書き言葉にも同じことが起こります。
たとえば、
法律
論文
新聞
技術記事
SNS
チャット
日記
個人ノート
では、求められる文章の形式が違います。
特に自分だけが読むノートでは、
書き手 = 読み手
です。
そのため、
他人に誤解されないか
この表記が媒体の規則に合っているか
全体で表記が統一されているか
といった問題の重要度が下がる。
結果として、
こと
事
こと
事
が混ざっていても意味が分かるなら、そのままでよくなるのです。
出版物では「正誤」だけでなく「揺れ」が消される
出版物になると状況は変わります。
そこには、
著者
↓
編集者
↓
校正者
↓
出版社・媒体のルール
↓
読者
という複数の人間が関わり、
意味は通じるからいい
だけでは済まなくなるからです。
文章全体として、
- 同じ意味なら同じ表記にする
- 特定の媒体の用字に合わせる
- 読者が途中で引っ掛からないようにする
といった作業が行われます。
ここで重要なのは、
編集者は必ずしも「間違った日本語」を「正しい日本語」に直しているわけではない
という点です。
むしろ、
複数の可能な表現から、その共同体で採用する表現を選び、揺れを減らしている
と考えた方が近いです。
（文化庁の現行指針自体も、公用文での原則だけではなく、一般向けの解説・広報では「分かりやすさ」「親しみやすさ」を優先して仮名書きを選ぶことがある、と明示しています。つまり公的な規範ですら、媒体と読み手による調整を認めています）
民俗学的に見ると、個人ノートは「書記の民俗」を保存している
ここは民俗学的にも面白いところです。
正式な出版物だけを見ていると、
日本人は非常に規則的に漢字とひらがなを使い分けている
ように見えるかもしれません。
しかし実際の、
- 日記
- 手帳
- 授業ノート
- メモ
- 家族への伝言
などを見ると、
こと / 事
ため / 為
とき / 時
できる / 出来る
ください / 下さい
といった揺れが普通に現れます。
これは単なる「間違い」として片付けるより、
編集される前の生の書記行為
と考えた方が面白いでしょう。
言ってみれば出版物が「正装した日本語」なら、ノートは「部屋着の日本語」です。
部屋着だからといって、その人の服装文化でないわけではない。むしろ、公式の場では消される習慣がそこに残っています。
民俗学的には、そうした私的文書は、
人々が規範を実際にはどの程度守り、どこでは気にせず、どんな揺れを許容しているのか
を観察できる資料になります。
「気付いたけれど直さなかった」という行為
今回、特に興味深かったのはここでした。
私は「こと／事」の揺れに気付いたにもかかわらず、直しませんでした。
前回の記事の「〃」では、
無意識に
「どうしたら我々は～」
と書く
↓
形式の不統一に気付く
↓
消しゴムで消す
↓
〃に戻す
ということをしました。
あのとき私は、規範を発見して、そのまま執行しました。
一方、今回は、
「こと」と「事」が混じる
↓
後から気付く
↓
でもノートだからいい
↓
そのまま残す
となりました。
前回が、
自分で作った規範（＝革新）に自分が拘束される
話だとすれば、
今回は、
社会から受け取った規範（＝伝統）を、私的空間では緩める
話だと言えます。
ここからJavaへ
日本語とJavaの規範を並べてみる
上記の構造は、プログラミングにもかなり似ている部分があると考えられます。
たとえばJavaを書くときにも、
コンパイルできるかどうか
と、
Javaらしいコードかどうか
は別問題です。
さらに、
Javaらしいか
と、
この会社のJavaコードとして許容されるか
も別問題でしょう。
ここには自然言語と同じような階層があると言えます。
両者をおおまかに対応させると、
| 日本語 | Java |
|---|---|
| 日本語の文法 | Java Language Specification |
| 辞書・公的な表記指針 | Java API・JEP・公式ガイド |
| 出版社の用字用語集 | 企業・チームのコーディング規約 |
| 編集・校正 | コードレビュー・静的解析 |
| 個人ノート | 個人開発 |
| 表記ゆれ | コーディングスタイルの揺れ |
と考えられます。
ここで面白いのは、
下へ行くほど「正しさ」がなくなる
わけではないことです。
むしろ、
社会的に要求される一貫性の強さが変わる
のです。
Java公式は「出版物」よりさらに厳しい
個人Javaコードなら、
var names = new ArrayList<String>();
と、
List<String> names = new ArrayList<>();
が別の場所に混ざっていても、動くなら大きな問題にはならないと思います。
しかしJavaそのものを変更する側では、そうはいかない。
新しい構文やAPIを導入するときには、
- 既存ソースコード
- 既存バイナリ
- ライブラリ
- JVM
- reflection
- IDE
- フレームワーク
などへの影響まで考えなければいけません。
自然言語にたとえるなら、
新しい表記の方が分かりやすいから採用しよう
だけではなく、
過去30年分の出版物が新しい表記法でも読み続けられるか
まで問われるようなものです。
だからJava公式の保守性は、単なる古風さではありません。
組織的Java開発は「出版社の表記基準」に似ている
企業でJavaを書く場合は、Java言語仕様だけ守ればいいわけではありません。
たとえば、
for (...)
と、
stream()
のどちらを好むか。
varをどこまで使うか。
DTOをrecordにするのかclassにするのか。
Optionalをどこで使うのか。
これらはJava言語仕様だけでは決まりません。
チーム固有の、
このプロジェクトではこう書く
という規範があり、これは、
「こと」と「事」はどちらも読めるが、この媒体ではこの場合『こと』にする
という編集方針に似ています。
個人開発はかなり「ノート」に近い
一方、個人プロジェクトなら自由度が高くなります。
昨日は、
items.stream()
と書いたのに、今日は、
for (var item : items)
と書いてもいい。
recordを試したり、昔ながらのPOJO（Plain Old Java Object。依存関係や特別な動作を持たないシンプルなJavaオブジェクト）に戻ったりしてもいい。
明示型とvarが混ざっていても、
自分が読めるし、今はこれでいい
と思えばそのままにできる。
これは、
「こと」と「事」が混じっているけれど、自分のノートだから直さない
という感覚にかなり近いです。
しかし個人開発でも、完全には自由ではない
ここでも社会学的な部分が出てきます。
個人開発だからといって、誰もが完全に独自のJavaを書くわけではありません。
たとえば多くのJava開発者は、
class UserService
とは自然に書きます。
しかし、
class user_service
とはあまり書きません。
コンパイラ以前に、
なんとなくJavaらしくない
と感じるからです。
これは、
「彼が来る事を知っている」でも読めるけれど、「こと」の方が自然に見える
のと似ている。
個人プロジェクトでは規約を外しているつもりでも、長年読んだ大量のJavaコード、IDE、自動補完、教材、OSSなどによって、Javaらしさが身体化されているのです。
プログラマーにも、ある種のコーディング上のハビトゥスがあります。
ではJava・Kotlin・Scalaはどう違うのか
この「規範と共同体」という見方をすると、Java・Kotlin・Scalaの違いも少し違って見えます。
単純に、
Java 古い
Kotlin 新しい
Scala 高機能
と比較するより、
それぞれがJVMという共同体へどのような形で参加しているか
を見る方が面白いでしょう。
Java――すでに制度化された言語文化
Javaは、単なるプログラミング言語というより、すでに巨大な制度になっています。
そこには、
- JVM
- 標準API
- フレームワーク
- 企業システム
- 教育
- 開発ツール
- 長年蓄積されたコード
が存在します。
そのためJavaの進化は、
新しい言語文化を作る
より、
巨大な既存文化を壊さずに改訂する
作業になります。
これは日本語の標準表記を突然全面改定できないことと少し似ている。
Javaはすでに「みんなが使っているもの」なのです。
Kotlin――既存文化の内部へ入り込める改革
KotlinはJavaとは立場が違います。
Kotlin公式はJavaとの相互運用性を明確に設計上の特徴としており、既存JavaプロジェクトへKotlinを段階的に追加する公式チュートリアルまで提供しています。
そのため既存Javaプロジェクトに、
Java
Java
Java
Java
と存在するところへ、
Java
Kotlin
Java
Kotlin
と徐々に導入できます。
つまりKotlinは、
Java文化を全部捨てて別世界へ移れ
という言語ではありません。
むしろ、
Java社会と会話できるまま、別の書き方を持ち込む
言語です。
Java自身では難しい、
- null安全性
- より簡潔な構文
- 拡張関数
- 独自の型システム上の工夫
などを、Javaと接続したまま導入できます。
言語文化の比喩で言えば、
既存の標準語と十分通じる、新しい文体
に近いです。
革命ではあるが、亡命ではない。
Java圏の内部から利用できる改革言語、とでも言えるでしょう。
Scala――より専門化された言語文化
Scalaはまた違った形で発展してきました。
ScalaもJVM上でJava資産を利用できるが、より大胆な抽象化を選択してきました。
関数型プログラミングや高度な型システムなど、
言語そのものの表現力をどこまで広げられるか
という方向へ強く進んでいます。
自然言語で考えるなら、
日常語とは別に発達した専門的文体
に近いかもしれません。
数学・哲学・法学などでは、日常語にはない複雑な表現を専門共同体が発達させていますが、それは、
普通の日本語より優れている
ということでも、
分かりにくいから劣っている
ということでもなく、要求されている表現能力が違うだけです。
Scalaにも、似た性格があると思います。
三言語は「人気」ではなく「社会への入り方」が違う
この観点から整理すると、
Java
すでに社会制度化した言語。
既存の規範を保ちながら徐々に更新する。
Kotlin
既存Java文化と高い相互運用性を持ちつつ、新しい規範を内部へ持ち込む。
Scala
同じJVM基盤に接続しながら、より独自性の高い言語文化を形成する。
となります。
つまり三者の違いは、
どれが最も進んでいるか
だけではなく、
既存共同体とどれくらい距離を取り、どの程度その規範を引き継ぐか
の違いでもあります。
「こと／事」とJava・Kotlin・Scalaはどこでつながるのか
ここまでかなり遠くまで来たように見えます。
しかし最初のノートへ戻ると、構造は意外と似ているでしょう。
個人ノート
↓
「こと／事」が揺れる
↓
意味が分かれば許容する
個人開発なら、
個人コード
↓
for / Stream
class / record
var / 明示型
が揺れる
↓
本人が理解できれば許容する
しかし共同体に入ると、
出版物
↓
表記を統一する
組織開発
↓
コードスタイルを統一する
さらに言語そのものになると、
Java
↓
過去の利用者を壊さないよう
規範そのものを慎重に変更する
となります。
ここには一貫した構造があります。
標準化とは「揺れを減らすこと」なのかもしれない
かなり抽象化すると、自然言語でもプログラミングでも、
個人的な実践
↓
さまざまな揺れ
↓
共同体が形成される
↓
相互理解のための規範
↓
標準化
↓
規範の内面化
という流れが生まれます。
ところが人間が再び私的な領域へ戻ると、
社会的規範
↓
個人空間
↓
拘束力が弱まる
↓
揺れが再び現れる
という逆方向の動きも起こり得ます。
「こと／事」は、その小さな表れだったと言えるでしょう。
しかし、その「揺れ」から次の規範が生まれることもある
ここで前回の「伝統と革新」の話ともつながります。
規範は最初から存在するわけではありません。最初は誰かの個人的な癖や便利な工夫にすぎないけれど、そのうち「その書き方、便利だ」と思う人が増えていくことがあります。
共同体へ広がる。
ツールが対応する。
ドキュメントに載る。
やがて、
こう書くのが普通
になる。
つまり、
逸脱
↓
便利な工夫
↓
共有
↓
慣習
↓
標準
↓
規範
という経路も存在します。
これは自然言語でも、プログラミング言語でも同じです。
今日の「正しい書き方」の中には、過去には新奇だったものがたくさん含まれています。
規範はどこから来て、いつ人を拘束するのか
私は自分で作った「〃」という規則に自分で拘束された。
社会から受け取った「こと／事」の表記規範を、意図的に執行しなかった。
Javaでは、
- 個人開発なら規範を緩められる
- 組織開発なら共同体の規範が強くなる
- Java公式では過去の歴史そのものが規範になる
という段階がある。
こう考えると、「正しい書き方」というものは単純な一枚岩ではありません。
言語そのものの規則
社会的慣習
組織の規則
個人の癖
が重なってできています。
そして私たちは、その全部に常に従っているわけではありません。
場面ごとに、
これは守る
これは今回は気にしない
と選択しています。
おわりに
今回の思索は、
「こと」と「事」がノートの中で混じっていた
という、本当に小さな発見から始まりました。
しかし考えてみると、その中には、
- 日本語の漢字・ひらがなの使い分け
- 文法化
- 文体
- 表記規範
- 社会的なレジスター（使用域）
- 編集と校正
- 個人の書記習慣
- ハビトゥス
- 標準化
- プログラミング言語のコーディング規約
- Javaの後方互換性
- Kotlin・ScalaのJVM文化への参加方法
までつながる構造がありました。
そして前回の「〃」の話とも合わせるなら、さらに一つの問いが浮かんできます。
人間は規範に従っているのか、それとも規範を作り続けているのか。
おそらく答えは、その両方なのでしょう。
私たちは既存の規範を身につけ、その規範に拘束される。
しかし同時に、私的な場ではそれを緩め、新しい書き方を試し、ときにはその逸脱が別の人へ伝わる。
そして十分に広まれば、かつての逸脱が次の規範になる。
自然言語もプログラミング言語も、完成した体系ではありません。
人々が実際に使い続けることで、規範と逸脱のあいだを行き来しながら変化していきます。
だとすれば、ノートの中に残った「こと」と「事」の揺れも単なる書き損じではなく、社会的な言語規範と個人的な書記行為が接触した小さな痕跡だったのでしょう。