第5回 PowerNewsアンケート結果発表
DBのテーブルやフィールドの名前を日本語で命名するのは?

業務システムから頻繁にアクセスするデータベースのテーブルやフィールド。アプリケーション開発者の皆さんは、このテーブルやフィールドの名前に日本語(ローマ字ではなくマルチバイト言語)を使うことをどのように考えているのでしょうか?
視認性を優先して日本語を使っているのか、それともマルチバイトがソースコードなどに混在することを避けるため、日本語は使わないようにしているのか?
そこで、グレープシティのメールマガジン「PowerNews」読者にアンケートを行い、開発現場の実情を伺ってみました。得られた回答はIT開発分野で多くの著書をご執筆されているWINGSプロジェクト様に総評していただいております。
どうやら、利用しているデータベースによって異なる傾向がみられる(かもしれない)という気になる結果は以下をご覧ください。

アンケート実施日 : 2010年11月25日(木)~2010年12月17日(金)(有効回答数 : 113件)

WINGSプロジェクト様の総評

データベースに日本語を名を使うことについて

拡大して表示する

使用しているデータベース

拡大して表示する

※ 結果チャートはいずれも、WebCharts3Dを使って作成したものです。
※ Flashムービーファイルをご覧いただくためには、「Adobe Flash Player」が必要です。Flashムービーが見えない場合は、こちらより「Adobe Flash Player」をインストールしてください。

今回のアンケートでは、回答者層がSQL Serverに偏っていたため、一概に結論づけることはできせんが、SQL Serverの利用者にとってはマルチバイト命名が浸透しつつある(数字だけを見れば、まだ常識、とまでは行かないようですが)、非SQL Serverユーザーにとってはまだまだマルチバイト文字は使いたくない、という傾向になったようです。選択項目に「日本語は使いたくない」がなかったのが残念でしたが、コメント欄を見る限りは、「なんとなく日本語は使わない」を選択された方の中には「日本語に抵抗がある(使いたくない)」が相当数含まれていたように見えます。

ちなみに、私は非マルチバイト派です。昨今、オープンソース系を含めて、多くのデータベースでマルチバイト文字の利用が問題なくなりつつありますが、それでも環境や連携するツール/ライブラリによっては思わぬ苦労を背負込むことになります。日本語名の読みやすさは絶大な魅力なのですが、現状では、「思わぬ苦労」を避ける方を優先したいという感覚でしょうか。マルチバイト文字によって生じた問題は根が深く、きちんとした知識を持った人間でないと、解決が難しいという事情もあります。皆さんのご意見の中には「海外展開(開発)を考えればありえない」という理由もあったようです。

もちろん、本稿は「マルチバイト文字を使うべきでない」と主張するものではありません。環境が許し、その方が分かりやすいと考えるならば、どんどん日本語を利用していけばよいでしょう。日本語が日本人にとって解りやすいのは異論を差し挟む余地がありません。(私はどちらかと言うと臆病な人間なのですが)あえて言うならば、まだ見ぬ不具合を恐れてシングルバイト文字に固執するべきでもありません。

同じアンケートを、3年後、5年後に取った時に、結果にどのような変化が見られるのかが楽しみです(その時はぜひ「日本語は使いたくない」も選択肢に加えてくださいね>担当者様)。

WINGSロゴ画像

WINGSプロジェクトは有限会社WINGSプロジェクト(代表 山田祥寛)が運営する執筆コミュニティ。Web開発分野の書籍・雑誌/サイト記事の執筆を中心に、海外記事の翻訳、講演等を手掛ける。主な著作は「JavaScript本格入門」「Windows Azure実践クラウドプログラミング」「ASP.NET MVC実践プログラミング」など。2010年12月時点での登録メンバは約35名で、現在も一緒に活動できる仲間を募集中
このページの先頭へ

PowerNews編集部より

WINGSプロジェクト様、総評をありがとうございました。次回、同じ項目でアンケートを行う際には、必ず「日本語は使いたくない」の選択肢を含めさせていただきます。
さて、ここからは、開発者の皆さまからから頂いたコメントをご紹介いたします。

皆さんから頂いたコメント

日本語を使うプロジェクトに入ったことがありません。最近までローマ字表記の上、短縮する表記方法を採用しているPJにいましたが、短縮しすぎて元の名称が通じませんでした。
海外にも拠点があるため、日本語以外の環境で使用する可能性がありそうなものについては、日本語は使用しません。
なんとなくじゃなくて、絶対使いません。
将来、ソースを公開するときに日本語を使うと外国の人が読めないでしょ?
普通、使わないんじゃないの?
プログラムコード内に、DBからクラスを自動生成した際、日本語名のプロパティが生成されてしまうのが恐いです。日本語名のプロパティでは、痛い目を見たことがあるからです。Windows上でプログラムを実行する時、XPと2000でシステムの文字コードが異なるため、ソース内に生成された日本語のプロパティがOSによっては読めず、ハンドルできない例外が発生しました。それ以来、『ソースにマルチバイトのシンボルが生成される可能性のある行動は禁止』というルールを課しています。
日本語のテーブル名はアルファベットのコードと交じると視認性が悪い。同一の言葉でも、命名者によって異なる意味合いになる場合が多く、日本語だからといって、必ずしも効率UPにつながるわけではなく、設計者の手抜きに使われることが多い印象。SQL Server 2008以降のSSMSにある、インテリセンスの効用を受けにくい。
むしろVB.NETで作ってるときは、テーブル名やフィールド名にアクセスするための変数やプロパティも日本語を使ってもいいのではとさえ思います。統一されていればですが。
まず漢字変換のON/OFFが面倒である。ツールがMBCSを考慮していない場合など、MBCSの使用はトラブルの元となる。識別子はアルファベット+数字の組み合わせが基本だと思う。
・プログラム開発では、総ての層で同じ名前を使うべきだと思う。なぜ仕様書とプログラムコードで違う名前を使うのか?
・業務で利用している言葉を英語にすると、ニュアンスが変わってしまうことがある。
・英語にしたがために訳が間違っている、スペルが間違っているものがある。
・別に翻訳表をつくるのか?
「なんとなく」ではなく、絶対に使わない。オフショア対応でできなくなるので。
昔やったら気持ち悪くて。今は翻訳サイト頼みの怪しい英語での命名です。
SQL入力するのに、いちいちIM起動するのもかったるいし、わかりやすく見せるために作るサンプル以外は使いません。
日本語にこだわりはないのですが、日本語で行けるものに関しては日本語を使用する事が多いです。
昔はANKが当たり前、日本語は邪道(特にOracle)とか言っていましたが、今では当たり前のように日本語使ってます。お客さんがデータ活用する際など、直感的で便利ですよね。
マルチバイトで使用した場合の問題点や技術背景は知っているうえで、マルチバイトでも使えるのだから使えばいいし、無理に非マルチバイト列名にこだわらなくてもいいと思います。
複数のデータベースで動作するアプリケーションを作成してるので、移植性を考えて、使いません。外国人スタッフを入れたときに、説明とか面倒になりそうだから、やっぱり使わないと思います。
ユーザに追々管理を任せたいAccessで作ったような、ちょっとしたアプリは日本語を使いますが、それ以外は使わないです。
日本語名を使うことにより、以下が軽減されると考えています。

・SQL文に日本語コメントを書く手間
・英語名を考える手間
・開発者によって英語名のセンスがばらつくことによっての統一感の無さ

確かにSQL文を記述するときに日本語と英語の切り替えは面倒と感じますが、上記メリットはその面倒を補って余りあると思っています。また、そのままの日本語名でソースコードもクラスやプロパティの名前に用います。これにより、ソースコード中でなにが予約語や組み込みのクラス部分で(for, if, Listなど)、何が自作のクラスやプロパティなのかの区別がついてこれも役立っています。
MS-DOS時代からの名残か?日本語使用するのに不安感があるのが本音。一般的な実情はいかがなものでしょうか?
DBに限らず、トラブルを未然に防ぐためにも、コンピュータ名、アカウント名など、基本的に英数字しか認めません。
テーブル名、フィールド名に日本語なんて使いません。かっこ悪いじゃん!
テーブルやカラム名にマルチバイト文字を使用したら、select文を発行するときに面倒な気がします。日本人が英語になれるためにも、なんでも日本語化させるのは反対です。
日本語だと何を定義している項目なのかわかりやすいが、かなり違和感があり、なじめません。
入社時から、先輩方が日本語を普通に使ってたので、そういうもんだと…。でも、他部署の先輩がプロジェクトに投入されたとき、「ソース書くときにいちいち『アルファベット』と『かな』を変えにゃおえんのんがめんどくさいんじゃー!」と怒ってました。
UTFがきちんとサポートされたなら、使えるかもしれないが、非常に危険である。
「なんとなく」ではなく絶対に使わない。(半角スペースも含め)本当にたまに全角文字の名前で起きるバグもありますし、SQL文を作成するときに面倒ですよ。
何となくじゃなくて断固として日本語は使わない。最初入社した会社で7年間おもりしたシステムは日本語を使用していたが、今となってはOracleでは日本語はダブルクォートでくくらねばならず、煩雑。日本人としてわかりやすいのは理解できるが、使わない。
分かりやすいのが一番だと思います。でも、機種依存文字を使うのはやめて~(今仕事で使っているOracleのDBで使われています)。
視覚的に解りやすい=ミスが減る=良い品質 かな?
日本語を使うのははIMEのon/offがとてもうっとうしい。しかし、英語やローマ字で良いカラム名が思いつかない事もある。使わないで済むなら使いたくない。
選択肢が偏ってませんか?無いのでなんとなくを選択しましたが、違和感があり、日本語を使わないルールもあります。
日本語のテーブル名・項目名が分かりやすいのですが、どのプロジェクトでも禁止してますよね。ここは日本なのに…。
昔からの慣習で余り考えたことがない。アルファベットや記号等の1バイト系文字にしておくのが無難。
最近ではどんなDBシステムでも日本語使って問題無いんですか?無いのなら積極的に使っても良さそうだけど、そこが知りたい!あと、ウチは日本人しかいないけど、日本人以外がメンテする可能性があるなら、日本語ってどうなんだろ?
日本語項目…良いと思うのですがね。
昔は問題があり全角禁止だったが、今は特に問題なく使えるので見易さで全角を使っている。
将来、他システムの連携などで、文字化けすると困るので。
絶対に避けるべきと思います。デメリットとして、ツール利用時の文字化け、大文字小文字の認識、コーディングコストがかかる、ソートしづらいなどが思いつきます。これを超える恒久的なメリットがはたしてあるのでしょうか?可読性を高めるためにマルチバイトを採用する方もいるかとは思いますが、個人的にはシングルバイト文字利用に比べ、可読性はまるで高まっていないと感じています。
SQL文を書くときに日本語を打つのが面倒なので、日本語は使用しないです。
Windows系の人は日本語、もしくはローマ字表記の人が多いですね。
日本語でローマ字表現を使う。
海外にソフトウェア開発や運用保守を依頼するケースを考えると、基本的には、英語でシステムが構築されている方が良いと考えます。
ソースにコメント以外でマルチバイト文字が入るのが不自然に感じます。DBの命名はヘボン式ローマ字表記で統一しています。
Oracleのカラム名30バイトの制限(変更できる?)に困ることがあります。特にUTF-8だと、日本語は3バイトになりますので、実質10文字しか使用できません。
昔は、開発側が好きにできたのでリスクのある日本語は使用しなかったのですが、現在は、日本企業向けのシステムは、分かりやすく日本語で命名する。そのリスクは開発側が負うということが一般常識になってきています。
データベースオブジェクトにせよ、クラス名やメソッド名にせよ、表している内容が何を指し示しているかが開発者間で共有できるのであれば、日本語を使うことは特に問題はないと思います。ですが、やっぱり日本語のテーブル名やフィールド名には抵抗があります…。
なんとなく…、ただ何となく…英語の方がしっくりくるからでしょうか。
汎用機時代の標準化が見直されていないため、日本語を使っていない。
4~5年前より、キー項目以外はほとんど日本語名ですね(キー項目を日本語にするとデバッグ用のSQLを書くときに面倒ですから)。
入社当時はDBのテーブルやフィールド名に日本語を使用することには、なんとなく抵抗がありましたが、担当になったシステムで日本語表記が使われており、1、2年くらいそのシステムを小規模改修および保守していたところ、全く気にならなくなりました。
ユーザーが直接目に触れないのであれば全て英数字とします。ユーザーが直接利用する可能性があれば日本語も使用します。
Access以外では、その様な発想は無い。大文字、小文字すらこだわりたい。が、使うだけの人は日本語が良いんでしょうね。
アクセスでは使用することがあるが、SQLServerでは使用したことが無い。
私は日本語の推進派ですが、必ず案件ごとの標準規格作成時に強い反発にあいます。
SQL Server、Accessでは普通です。Oracleでも特に問題はありません。むしろ、問題がないデータベースで、問題ない範囲の文字コードを使うのであれば、日本語でつけるべきとも思います。下手に背伸びして英語を使うと、わかりづらくなると思います。ただし、アルファベット、英数字は、半角文字でつけるべきだと思います。
Oracleはローマ字で…。
プログラムコーディングのし易さ、メンテナンスのし易さ(スペルミスなど)を優先すると、日本語有りが普通だと思います。但し、オブジェクトの先頭にオブジェクト種(TBL)を付与するなど幾つかのルールも設定しています。
・日本語の場合、あいまいさがあるため、「コンピューター」「コンピュータ」など同じことを示すのに記述が異なってくる可能性があるので、極力使用しません。
・型付きデータセットなどを使用するときに、コードに日本語が交じってしまうので、気持ち悪いので使いたくないです。
・実際の業務では数百以上のテーブルが存在しますが、日本語だとSQL Server Management Studio からツリーリスト表示された個所がすぐにみつからないので、個人的に嫌いです。
もう10年くらい日本語で命名しているが特に問題になったことはない。「ー」はコーディング時に紛らわしいのであまり使わないようにしているが使っても動作には問題が出たことはない。
開発後、運用段階の際に一切、直接テーブル構造を見ないのであれば、英語にすべきだと思う。しかし実際には、改修する時(初回開発と改修で同じ開発者とは限らない)や運用時に、何らかの理由で直接テーブルを見る必要があるなら、日本語を使用する方がフレンドリーだと思う。
たとえば、勘定総元帳、原価帳簿みたいなテーブルを作成する時に、アルファベットではきついと思う。
辞書を引く?あんたが辞書引かないとわからなかった単語をほかの人に読めというのは酷である。え?ローマ字。いや、もー日本語でよくね?
実際に日本語を使った方がよいのかどうなのか疑問です。
プログラミング言語使ってるなら英語に慣れている人は多いだろうけど、
マルチバイト文字つかうとスゴイ違和感があると思います。
このページの先頭へ
第1回 PowerNewsアンケート結果 - あなたは今、どのVisual Basicを利用していますか?
第2回 PowerNewsアンケート結果 - 現在、使用しているMicrosoft® Excel®のバージョンはどれですか?
第3回 PowerNewsアンケート結果 - 東京23区以外でもITイベントやセミナーをもっと増やすべきだ!
第4回 PowerNewsアンケート結果 - 現在、使用しているMicrosoft® Excel®のバージョンはどれですか?-Part2
第5回 PowerNewsアンケート結果 - DBのテーブルやフィールドの名前を日本語で命名するのは?
第6回 PowerNewsアンケート結果 - 現在、使用しているMicrosoft® Excel®のバージョンはどれですか?-Part3
第7回 PowerNewsアンケート結果 - 主に業務で使用する開発言語はなんですか?
第8回 PowerNewsアンケート結果 - 現在、使用しているMicrosoft® Excel®のバージョンはどれですか?-Part4
このページの先頭へ