ユビキタス言語のベースの言語

ドメイン駆動開発（DDD）を謳っている開発案件が、なんだか最近出始めてきたらしい。今日は、このDDDの中での最重要プラクティスのうちの一つである「ユビキタス言語」について思案してみる。

ちょうど一年くらい前、日本のソフトウェア開発現場でも、せめてユースケースだけでも英語化されるといいなあ、という思いを書いた。そこで、「ほとんどの日本の現場では、日本語による要件定義と英語ベースの実装作業との間のどこかに日本語⇔英語のギャップが横たわっていて、これがオブジェクト指向開発の効果的な流れを阻害しているが、要件定義側、特にユースケースの段階で英語化してしまえば、この不経済がかなり解消できると思われる」という事を述べた。

個人的には英語→日本語のギャップが、実はかなり昔から、オブジェクト指向分析やドメイン・モデリングの普及や実施において大きな阻害要因になっていたのではないかと常々思っていたが、意外と取り沙汰される事がない。必然的に問題として認識しようもない英語圏ならばともかく、日本の開発現場では、一応気にはなっている技術者もきっと少なくないはずなんだけど。


さて DDD においては、業務の世界と開発の世界の狭間に、ユビキタス言語---つまりドメイン専門家とのコミュニケーションにおいても、プログラミング言語を用いたコーディングにおいても、常に一貫して使用する事を求められる共通言語---が策定される事になっていて、これが肝だったりする。

で自分が思うに、このユビキタス言語についても、ユースケースと同じ理屈で英語ベースにしてしまってはどうかと。

この英語ベースのユビキタス言語の語彙を用いて、クライアントや業務SEと対話し、ドメインモデルの各要素に名前を与え、プログラム中のクラスやメソッドに識別子を与えるようにすれば、無駄なギャップが解消され、少なくとも英語圏ではほぼ自動的に実現されるレベルの一貫性・直接性に、ちょっとは近づけるのではないかと思う。※1

もちろん、言語の差異の吸収という非英語圏特有の負担を押し付けられてしまっているわけだから、Eric Evans らが考えるオリジナルのユビキタス言語からはちょっと変質してしまうかもしれない。英語の使用により、業務屋にとってもプログラマにとっても、多かれ少なかれユビキタス言語の「難易度」は高まるとは思う。

それでもやっぱり、開発工程全体のどこかで必ず生じるこのギャップを、結局はどこかで吸収せざるを得ないならば、開発序盤、あるいは「上流工程」で英語化してしまうのが一番経済的って気がする。

もちろん顧客によっても、事情は大きく変わるに違いない。社内公用語を英語にするような動きのある顧客では、さして抵抗も強くないはず（楽天だけじゃなく、最近は結構増えてきている）。逆に、余りにも一般教養レベルが低いような層の顧客だと、ワンクッションとしての業務SEを置いて、英和変換させるなどの策を講じないと難しいかもしれない。

あと、単なるユースケースの英語化と違って、ユビキタス言語の場合は文書だけじゃなく会話でも使うだろうから、カタカナ英語を日本語の助詞や助動詞でくっつけたような変な会議風景が現出するかもしれない（完全英語化すれば別だけど）。

まあ、日本語と英語のどちらをユビキタス言語のベースに採用するにせよ、「どっちを選んだときに、どんな作業や問題が発生するか（DDD関連の洋書には普通書かれていない）」について、予めよくよく考えておく事が、DDD導入にあたっては大きなポイントになってくるんじゃないだろうか。

====
※1 あまりにも無学なPGばかりが集まる底辺プロジェクトだと、JavaやC＃等の高水準OOPLが英語ベースであることすら認識されていない事が多い。彼らにとってはプログラミング・コードなんて、記号の羅列としか認識されていないから、そもそもドメインの語彙とか分析とか殆ど関係ない。従ってもちろん DDD も大して意味が無い。