はじめに
本記事は「Webなんでも勉強会」という勉強会で話した内容をベースに、時間の都合で端折った話などを書き加えたものです。
ちなみにコードやそれに関する用語はKotlin(およびJava)を前提としています。
この記事で話すこと
関数名やら変数名に日本語、というかマルチバイト文字が使えるプログラミング言語ってあると思うのですが、実際コードの中で日本語を使うのってどう思いますか？
例えばこんなのです。これは医療保険を表すクラスをKotlinで書いてみたものです。
私は肯定的に思っているのですが、なぜ肯定的なのかを書いていきたいと思います。
class 保険(val 保険者番号: String,
val 記号: String,
val 番号: String,
val 枝番: String) {
val is後期高齢者: Boolean
get() = // 後期高齢者かどうかを判別するプロパティ
fun 内容表示(): String {
// 保険の内容を表示する関数
}
}
class 患者(val 保険一覧: List<保険>)
メリット
まずはどんな点が良いと思っているのかを説明します。
わかりやすい
何と言っても、コードが分かりやすいです。
さっきのクラスを使って、後期高齢者の保険があるかを判定するコードを日本語と英語でそれぞれ書くとこんな感じです。日本語の方がスッと頭に入ってくるのでは、と思います。
患者.保険一覧.any { it.is後期高齢者 }
patient.insuranceList.any { it.isOlderSeniorCitizens }
テストコード
特にテストコードにおいて、テスト関数の分かりやすさ、つまり「何を対象としたどういう観点のテストなのか」が分かりやすいことって超重要です。
なので日本語になっていると分かりやすくて助かります。
@Test
fun 保険者番号に数値以外が含まれれば例外がスローされること() { ... }
@Test
fun 保険者番号の先頭が0であっても例外はスローされないこと() { ... }
@Test
fun 枝番が数値1桁の場合には2桁になるようゼロ埋めされること() { ... }
@Test
fun 枝番が空文字の場合にはゼロ埋めされないこと() { ... }
日本語なので、これがそのままテスト設計としても使える、というのもありがたいです。
テスト設計に何か問題がある場合にも、英語で書かれているより気づきやすいと思います。
英訳しんどい問題
コードで扱う言葉によっては、英訳に苦労する場合があります。例えば、先程の「後期高齢者」のような日本の制度で出てくる言葉や、業界の専門用語で苦労することが個人的には多かったです。
codicのようなネーミングを考えてくれるサービスもありますが、それを使えば全部解決！というものではないですね。
最近だとChatGPTに案をいくつか考えてもらったりとか、GitHub Copilotみたいな自動生成系のサービスに助けてもらったり、というのも方法としてはありそうです。
ただ、どういう方法で英訳を出すにせよ、コードを読む側に回った場合、馴染みのない（ないし無理矢理感のある）英語がちょいちょい出てくると結構しんどいです。
前出のコードで後期高齢者をOlderSeniorCitizensとしたのは、codicが出してくれたネーミングをそのまま使ったんですが、これを見てパッと「後期高齢者のことだ」とは分からないこともあると思うんです。
こういう英訳に悩む言葉と出会ったとき、「日本語をそのまま使う」選択肢があると結構助けられることがありました。
ユビキタス言語
皆さんの環境ではユビキタス言語って定義されているでしょうか。
私は残念ながらユビキタス言語を使う環境にいたことがないので、この項は私の実経験では話せないのですが、ユビキタス言語のことを考えると、やっぱり日本語を使うことの利は大きいのではと思っています。
システムのユーザーが日本人の場合、ユビキタス言語も日本語のはずです。
さっきの医療保険で言えば、ユビキタス言語として定義される言葉はInsuranceではなくて保険のはず。コードで扱うときにはそれを英訳してしまうとなると、定義とは違う言葉を使うことになってしまいます。
情報が失われる可能性
当たり前ですが、日本語は英語と一対一対応してるわけではありません。そのため、訳すことで情報が部分的に失われてしまう可能性があります。
これの分かりやすい実例を書かれている方がいらっしゃったので、Mitsuyuki Shiibaさんのブログ記事から引用させてもらいます。
ある日PdMが「医薬品がどうこう」と言って、エンジニアが「お？」ってなって「薬品と医薬品は使い分けています？」「あぁ、そう言われてみればそうですね！」みたいな話をして、僕らの中では「薬品」と「医薬品」が別のものとして認識された。もし「薬品」がコードの中で「Medicine」と書かれていたら、エンジニアは医薬品と薬品の違いに気づかなかったと思う。
Mitsuyuki Shiibaさんのバックエンド環境ではローマ字でYakuhinとされているそうなので、その点は違うのですが、日本語は日本語のまま扱ったほうが良いという点は共通しているかと思ったので、引用させてもらいました。
デメリット
とは言え良いことばかりではないよね、ということでデメリットも書いていきます。
日本語の読み書きが必須
当たり前なんですが、日本語の読み書きができないといけないです。
「日本語だと分かりやすい」などのメリットを書いてきましたが、それは日本人（というか日本語の読み書きに苦がない人）にとってはという話です。日本語の分からない人がいる場合、ここまで書いてきたメリットの多くは消えてしまいます。
組織によっては、この時点で論外でしょう。
ネット上で見かけた意見としては、オフショアに出せないとか、社内公用語が英語になったらどうするみたいなのもありましたね。
なんか問題起こりそう
ありがちな話として、コードに直接日本語（というかマルチバイト文字）を使うと何か予期しない問題が起こりそうで嫌、というのがあります。
これに関しては「気持ちはとても分かるけど、私は日本語が原因の問題は経験したことがない」としか言えることがないです。
この辺りは、プログラミング言語やフレームワークが変わったら違うとか、自社開発なのか受託なのかとか、事業内容とか、社風とか、そういう諸々が変わればリスクも変わると思います。
なので、「やってみたけどダメだった」とか「そんなのウチでは許されない」みたいな話をお持ちの方がいれば教えてもらいたいです。
半角と全角の切り替えが面倒くさそう
これはネット上の意見としてもよく見るし、発表したときにも頂いた感想なんですが、個人的には煩わしさを感じた記憶はないです。
一つ言えるとすると、関数名などは先頭を英語にすると（例えばget保険内容とか）途中まで半角のまま書けるので、そこからIDEなどの入力補完を使えば、半角全角の切り替えはしなくても済みそうです。
ただ前述の通り私はその点を気にしたことがなかったので、一番は慣れの問題なのかなぁと思ってます。
結局ドキュメントとか書く時は半角と全角の切り替えを普通に頻繁にやりますし。
高すぎる自由度が仇になる
日本語で書けると、自由度が高すぎるゆえに、それが逆に仇となるケースもありました。特にテスト関数のような、文章を書くケースで顕著だったように思います。
ちょっと具体例出せないのでわかりにくいかもしれないですが、文章を書く時のその人のクセがそのまま出てしまいがちということです。各々が自由なフォーマットで書き始めると、他の人のコードを読むのが結局つらくなります。
私のいたチームでは、コードレビューなどの機会を通してちょっとずつ認識合わせをしていくことで、この問題に対処しました。
チーム内で話し合って、最初からフォーマットをある程度決めてしまっても良いかもしれないですね。
その他
パッケージ名には使わなかった
日本語使えるけど私の経験では使わなかったな、という部分もあって、それはパッケージ名です。jp.co.hoge.foo.bar.保険みたいなパッケージは作りませんでした。
意識的に避けていたというよりは、そもそも使いたいと思ったことがなかったですね。発表資料を作りながら情報を整理している中で「そういえばパッケージでは使ったことなかったな」と初めて気付きました。
ただ、改めてパッケージ名で日本語を使うことについて考えると、メリットがデメリット（リスク）を上回っていないのではという感覚もあります。主な理由は以下の2つです。
あんまり英訳に困らない
パッケージ名になるのってある程度大きな分類を作る（比較的メジャーな）言葉なので、英訳で困るような言葉を使うことは少ないです。
ディレクトリ名になってしまう
パッケージ名はそのままディレクトリ名にもなります。
プログラミング言語に直接関係ない、ミドルウェアやらOSやら各種設定ファイルやらにも影響を与えるので、「なんか問題起こりそう」感がより強くなりそうです。
まとめ
日本語の分かる人だけで開発および運用されている環境であったり、専門用語が多くて英訳に苦労している環境であれば、日本語をそのまま使うという選択肢は、結構助けになってくれるものだと考えています。
「プロダクトコードで使うのはさすがに無理」な場合は、テストコードだけでも使ってみると効果を発揮してくれると思います。
もちろん実際に使う場合はチーム内で合意を取ることは大前提です。
ルール作りなども含めて、メリットとデメリットの天秤についてチーム内で認識を合わせてから取り組む必要があるかと思います。
本件は結構人によって意見が違う内容だと思いますので、ご意見等あれば、ぜひ聞かせて頂けると嬉しいです。