別室日記 2026-04-22 terang: ユビキタス言語

terang.icon

AI.icon

1. 「用語警察」への警告：定義の過大評価

エンジニアは「正解としての定義」を一度決めれば、世界がその通りに動くと信じがちです。石橋氏はこれを「定義の過大評価」と呼び、それが「ユビキタス言語」という看板の下で「用語警察（正しい言葉以外を認めない抑圧）」を生んでいると批判しています。

kawasima氏の視点: 「用語集（名詞リスト）では不十分だ。振る舞い（文法）まで厳密に書け」

石橋氏の視点: 「厳密に決めること自体に固執しすぎると、現実に適応できなくなる（摩擦が生じる）」

2. 「コンテキスト（境界）」の不在への懸念

石橋氏が最も危惧しているのは、エンジニアが「ユビキタス言語」には熱心だが、その前提条件である「境界づけられたコンテキスト（Bounded Context）」を軽視している点です。

ドメイン駆動設計（DDD）において、言葉が「一意」であるのは、あくまで「区切られた特定の文脈の中」においてのみです。

石橋氏は、文脈を無視して「会社全体で言葉を統一しよう」とするような動きは、言語の本質（多義性や流動性）を理解していない「文系的な知性の欠如」であると指摘しています。

3. 「訂正可能性」による連帯

ここで東浩紀氏の『訂正可能性の哲学』が引用されているのが非常に示唆的です。

家族的類似性: 言葉の意味は、厳密な定義（境界線）によって決まるのではなく、重なり合う緩やかな類似性によってつながっている（ウィトゲンシュタイン）。

AI.icon

この二人の緊張感は、「言葉をどこまで固定すべきか」という一点にあります。

kawasima氏（深さの追求）:

「言葉を厳密にしろ。さもなくばそれは言葉（言語）ではない」

エンジニアが「用語集」だけで満足し、コード（振る舞い）に落とし込めない「思考停止」を批判しています。ミニ言語という「強い規律」によって、曖昧なドメイン知識を叩き直そうとする、プロフェッショナリズムとしての厳格さです。

石橋氏（広がりの受容）:

「言葉を固定しすぎるな。言葉は文脈（コンテキスト）で変わるものだ」

エンジニアが「唯一の正解」を求めて、他部署や他人の言葉遣いを矯正しようとする「傲慢さ（用語警察）」を批判しています。言葉の揺らぎや変化を許容する「対話的な柔軟性」を求めています。

緊張関係の図式：

「論理的整合性のために言葉を削ぎ落としたい（kawasima）」vs「社会的な共存のために言葉の多義性を残したい（石橋）」という、システム的な正しさと社会的な正しさの緊張関係です。

AI.icon

1. 現実的なのはどちらか？

結論から言えば、「フェーズと規模」によって、どちらも現実的になります。

少人数の開発・実装フェーズでは「kawasima氏」が現実的：

「ステータスがAのときだけBができる」というルールを曖昧にすると、必ずバグになります。実装者が「用語集だけではコードが書けない」と悩むのは日常茶飯事です。そこでミニ言語を使って振る舞いを固定するのは、「動くソフトウェア」を作る上では極めて実用的な処方箋です。

大規模組織・要件定義フェーズでは「石橋氏」が現実的：

「顧客」という言葉一つとっても、営業部と経理部では意味が違います。ここで「言葉を一つにしろ（kawasima的厳格さ）」を強行すると、現場は混乱し、プロジェクトは政治的に自壊します。異なる文脈を認め、定義のズレを「訂正可能」な状態にしておくことは、「組織として合意」を作る上での現実的な生存戦略です。

2. 現場のエンジニアにはどう聞こえる？

現場の視点からは、どちらも「今の自分たちの課題」によって理想論に見えることがあります。

「kawasima氏は理想論だ」と言われる場合：

「ドメイン記述ミニ言語なんて覚える暇はない」「仕様が明日変わるのに、そんなに厳密に書いていられない」という、スピード重視の現場。

「石橋氏は理想論だ」と言われる場合：

「哲学の話はいいから、データベースのカラム名を何にするか決めてくれ」「言葉が揺れているせいで、誰のコードが正しいか分からない」という、混乱の真っ只中の現場。

AI.icon

1. t_wada氏：翻訳による「意味の蒸発」を防ぐ

t_wada氏は、「ソースコードにも日本語（ドメインエキスパートの言葉）をそのまま使え」と言っています。

何と言っているか:

エンジニアが「おや？」と気づくきっかけは、エキスパートと同じ言葉を共有しているときにしか生まれない。

kawasima氏との関係:

kawasima氏の言う「Lexicon（語彙）」の精度を極限まで高める提案です。「正しい英単語を探す」ことよりも、「概念の識別」を優先せよという点で、kawasima氏の「厳格なモデリング」を強力にサポートしています。

石橋氏との関係:

無理な英訳（＝エンジニアによる言葉の再定義）を拒否し、現場の文脈（コンテキスト）を尊重せよと言っています。「用語警察」になるのではなく、「現場の言葉の観察者」であれという姿勢です。

2. naoya_ito氏：モデリングとは「霧が晴れるプロセス」である

naoya_ito氏は、「ドメインモデルの構造を、ああでもないこうでもないと毎日考え続けるプロセスそのものが重要だ」と言っています。

何と言っているか:

DDDとは、単に本にあるパターン（エンティティ等）を当てはめることではなく、複雑な業務の背後にある「構造」を明らかにするための、泥臭いディスカッションの継続である。

「この構造なら、あのユースケースもシンプルに解けるぞ！」と、もやついていた霧が晴れる瞬間（整合する瞬間）を目指すこと。

実装とモデリングは「両輪」であり、コードを意識しない空理空論は意味がない。

kawasima氏との関係:

kawasima氏が提示した「ミニ言語」などの道具を使って、実際に「ああでもないこうでもない」と格闘した先にある「到達点」を語っています。kawasima氏の道具を使って「霧を晴らす」のがnaoya氏の実践です。

石橋氏との関係:

「本を盲信（固定化）せず、常に考え直せ」という態度は、石橋氏の言う「訂正可能性」そのものです。ただし、石橋氏よりも「最終的には一つの整合した構造（強いモデル）に辿り着かなければならない」という、エンジニアとしての実装責任を強く意識しています。

4人の視点の統合図

この4人の発言を合わせると、ドメインモデリングという営みの全体像が見えてきます。

1. t_wada（素材）: 現場の言葉（日本語）をそのまま使え。翻訳して意味をこぼすな。

2. kawasima（道具）: 名詞のリストで満足するな。ミニ言語（文法）を使って、振る舞いの構造を厳密に書け。

3. naoya_ito（プロセス）: 毎日ディスカッションを続け、構造を練り上げろ。霧が晴れるまで考え抜け。

4. 石橋（倫理/態度）: ただし、辿り着いた答えを「絶対の正解」として他者に押し付けるな。常に訂正できる余地を残せ。

現実論としての回答

「現場のエンジニアには理想論に聞こえるか？」という問いに対して、この4人の統合された視点は、むしろ「これなしでは、複雑なシステムは作れない」という切実な現実論です。

なぜ現実的か:

「薬品」と「医薬品」を混ぜて作ってしまったシステムを後から直すコストは、初期に日本語で議論するコストの数百倍になります。naoya_ito氏の言う「霧が晴れる」体験なしに作られたシステムは、複雑怪奇なスパゲッティコードになり、最終的に誰も触れなくなります。

やっぱそうだよなー、用語だけでは足りないという違和感を綺麗に言語化してくれてた

僕個人は用語というより概念を定義する

操作や表現の仕方や他概念との関連も内包される