2019年に当時の河野外相が「日本人名は外国語表記においても伝統的な姓-名の順がいい」と発言して以来、パスポート等の外国向けの公用文書ではその順で表記するようになった。今回のオリパラでも日本人選手達は姓-名の順で堂々と紹介されていた。西洋言語を使う際に姓名を西洋風にひっくり返すのは日本人くらいで、韓国人や中国人を含めて外国人は自国の伝統にしたがって自己紹介している。私は昔から日本人のそういった姿勢がどうにも卑屈かつ滑稽だと感じていたので、この変化は喜ばしい。
そのいっぽうで、私が専門とする業務システム開発の世界では奇妙なことが起こっている。DBのテーブルやフィールドを英語表記する純日本プロジェクトが少なくないのだ。日本語がわからないプロジェクトメンバーが関与するわけでもないのに、いちいち英語になっている。データモデルもそんな調子で、ただでさえわかりにくいモデルがますますわかりにくくなっていたりする。
日本人たる者が英語など使うべきではない、などと戦時中のようなことを言っているのではない。じっさい私は、英単語を省略したフィールドIDは筋がいいと感じている。顧客コードはCDCUSTOMER、標準売価はPRSTDSELL、といった調子だ（CDはCode、PRはPriceを表す）。ただしテーブルIDについては、AT010,AT020といった短めの記号表現でいいと考えている。開発作業の一場面において、関係するテーブルの数は10個をなかなか超えないゆえに、短期記憶に収まるからだ。反対にフルスペルの英単語を長々とつなげたものだったりすると悲惨で、短期記憶に収まらないだけでなく、綴りを間違わないように気を付ける羽目になる。
プログラミングするならそれだけでいいのだが、関係者がデータモデルやドキュメントとして眺めるために、フィールドやテーブルを日本語表記するための工夫が要る。一部のRDBMSでは、各フィールドにコメントとして日本語表記を添えることが出来る。しかし、テーブルIDの他に日本語表記のテーブル名を扱えるRDBMSを私は知らないし、フィールドコメントを使えないRDBMSも多いので、開発基盤のサポートが必要だ。CDCUSTOMERに対する「顧客コード」、AT010に対する「組織テーブル」といった調子で、日本語表記を組み込める辞書機能を持つ開発基盤が欠かせない。
「コードベース開発」は英語指向
ところがそのような工夫をせずに、テーブルやフィールドの英語表記に異常にこだわるプロジェクトがある。その理由は明らかで、オブジェクト指向開発（とくにドメイン駆動設計,DDD）しているゆえだ。ようするにシステム定義が「オブジェクト指向言語のコード」を基礎としているためである。
じつは私自身、オブジェクト指向開発するときには英語表記に徹する。モデリングツールとローコード基盤をJavaで自作したのだが、合計10万行を越えるソースコード上では、クラス名も変数名もメソッド名もコメントもすべて英語である。何のためかというと、ソースコード全体の統一感を高めて可読性と保守性を確保するためだ。日本語が混じれば木に竹を接いだようになるのは明らかで、オブジェクト指向開発に「英語指向」の側面があるのはよくわかる。
ただし、英語指向であることを「プログラミングなんてそんなもの」と一般化するのは間違いだ。試しに日本語のプログラミング言語が普及していると想像してみよう。変数名やメソッド名を漢字かな混じりで定義するほうが良いように思えないだろうか。ようするに、利用する実装手段がシステム記述のあり方を強く規定するということだ。残念ながら日本語のプログラミング言語は普及していないので、現状ではオブジェクト指向言語を使う限りシステム記述が英語指向になることは避けられない。
つまり本稿での問題は、日本企業の業務システムを「英語指向の開発言語」を用いてゴリゴリと開発することの是非である。日本国内で活動している企業向けであれば、9割以上が「日本人の、日本人による、日本人のためのシステム」であろう。そういうものに対して定義情報が英単語だらけになるような開発方針を取ることに合理性はあるのか。
不合理を通り越して滑稽だ。たとえばJavaやPythonの英語指向は、プログラムの外側に配置されるDBのテーブルやフィールドの命名に及んでしまうほど強力である。英語が達者な技術者ばかりではないので、要素定義が英語であるゆえの可読性や保守性の低下は避けられない。英語が不得意な技術者が設計すると最悪で、わかりにくさに拍車がかかる。それを補うほどにオブジェクト指向開発の生産性が高いわけでもないし、自由度の高さゆえに品質のバラツキも大きい。オブジェクト指向とRDBの相性の悪さもつきまとう。
仮に英語が堪能かつ超優秀な技術者を揃えることができたとしても、決定的な問題が残る。「顧客の語る業務用語と定義要素名とを一致させ、技術者との共通言語（ユビキタス言語）とすべし」というDDDの基本テーゼと沿いにくい点だ。顧客が語る業務用語が日本語であれば、コード中に記載される変数名も同じ日本語であるべきだ。しかしDDDではこの当たり前が簡単ではない。
日本語でのユビキタス言語を実現するために、英語・日本語の辞書を作るとか、ローマ字表記でがんばるといったさまざまな工夫がなされている。しかしその不撓不屈たる努力の方向性がそもそも間違っている。理想的には、テーブル名、フィールド名を含めてコード上で用いる変数をすべて漢字かな混じりにすればいいのだろうが、ほとんどのプロジェクトにとっては敷居が高い。乗り越えたとしても、英語を基礎とするプログラミング言語でのコード主体のシステム記述としては、やはり木に竹を接いだようになる。では、どうすればいいのか。
「仕様書ベース開発」はローカル言語指向
業務システム開発の分野では現在、オブジェクト指向開発のような「コードベース開発」を避ける動きがある。生み出される峨々たるコードの大山塊こそが、システムの保守性を低下させる最大の原因だからだ。コードベース開発に代わる手段が、「データモデルと仕様書を書けばいきなり動作する開発基盤」を用いた新たなスタイル「仕様書ベース開発(*1)」である。そういった基盤を私は、業務システムというソフトウエア分野（ドメイン）に特化しているという意味で「ドメイン特化基盤(DSP,domain specific platform)」と呼んでいる。
ローコードツールを代表とする業務システム向けのDSPが、日本、ポルトガル、ウルグアイといった非英語圏で生み出されている事実は示唆的だ。DSPそのものはオブジェクト指向開発されているので、ソースを開けば相変わらず英語だらけではある。しかし、DSP上でアプリとして立ち上がる「実行可能な仕様書」はローカル言語で記述される（図１）。結果的に日々のシステム開発・保守作業は、ローカル言語で書かれた仕様書を淡々と書いているだけにしか見えなくなる。あの間抜けな「誰かにプログラミングしてもらうための仕様書.xlsx」を書く必要もない。ただし「ノーコード」ではやれることが限られるので、コード（軽量言語でのスクリプト）は書く必要はあるが、集中管理できる程度の量で済む。
けっきょく、DDDをはじめとする従来のコードベース開発の問題は、日本企業向け業務システム開発においては無理無駄ムラの多い「外国語（英語）指向開発」であったゆえに生じている。いっぽう、仕様書ベース開発は、ローカル言語を基礎とする真正の「ユビキタス言語指向開発」を支えてくれる。「日本企業の業務システムなのだから、日本語で記述しよう」という当たり前の開発方針が受け入れられる。それは、何語を使おうと日本人が名前を姓-名の順で表明するくらいに自然なことだ。
業務システムの分野では、DSPを使った仕様書ベース開発を積極的に導入しよう。生産性を桁違いに高めるためだけではない。日本語でのユビキタス言語に徹したシステム定義を基礎にすることで、内製化率や保守性を高めるためでもある。いっぽうのコードベース開発は、DSPそのものやユーティリティ系のソフトウエアを開発するための手段として活用すればよい。海外の技術者とつながるために英語表記にこだわる意義もある。要するに道具にはそれぞれ使いどころがあるので適宜に使い分けよう、というまっとうな話だ。それくらいのスマートさがなければソフトウエア開発なんて無理という話でもある。
*1.正確な用語を用いれば「外部DSL（ドメイン特化言語）を用いた開発」となろうが、わかりにくいので、「コードベース開発」と対比させて「仕様書ベース開発」とした。
