Q&A
> ローマ字でもヘボン式なのか訓示式なのか、そういったところもきちんとすれば、問題ないでしょう。
どうでもいいでしょ、そんな事。
現在、立ち上がったばかりのプロジェクトにおいて、プログラムにおける命名規則を決めているところです。
業務で使用する用語について、個人的にはローマ字を使用したほうが良いと思っています。
しかし、ググってみても、メンバーの意見も、「プログラムにはローマ字を使うべきではない」「国際化の社会において英語を使用すべき」という意見が大半のように思えます。
中には、「ローマ字でプログラムが書かれていたら初心者だと思う」とさえ書かれていました。
そこで、皆さんの参加されているプロジェクトや個人的な考えでもよいので、実際のところ、
- 本当にローマ字非推奨なのか
- なぜローマ字は非推奨なのか
を教えていただきたいです。
個人的には以下の理由より、業務で使用する用語においてはローマ字を使うべきだと考えています。
- まず前提として、「コミュニケーションの円滑化、業務知識の把握効率化」という観点から、クライアントやプロジェクト内のメンバーで使用する言葉使いは統一したほうがよいと思っている。業務用語の適切な英語訳が存在していたとしても、それをコーディングに用いると、クライアントのミーティング／マニュアル等で使用する言葉（つまり日本語）とコーディングで使用する言葉（つまり英語）が異なるので、ミスコミュニケーションや業務知識の欠落の原因などになるのではないかというリスクがある。
- 作成するシステムは日本語でリリース＆利用対象者が日本人であるため、業務で使用する用語も必然的に日本語である。そのため、それらを日本語から英語に変換するコストが無駄と感じる。さらに、特に、メンテナンス時はそれを逆に翻訳して読まなくてはいけないので、可読性も悪くなる。
- プロジェクト内に英語ネイティブが一人もいないので、そもそも適切な英語に翻訳できている保証がない。（「～区分」や「～種別」など、業務特有の言葉において、「～Type」「～Kind」「～Class」どれが適切なのかネイティブでないので判断できないと思う）
- 結果、できあがったものはヘンテコ英語の恥ずかしいものになる危険性がある。
[補足]
ちなみに、業務で使用する用語でないもの（たとえこちらに挙がっているような単語）は英語のほうが良いと思います。これは、標準ライブラリなどのAPIとして一般的に使用しているメソッド名などだからです。これらの用語はプログラマとしては英語のほうが良いと思います。
再補足
すみません、質問の仕方が良くありませんでした。
上の補足に書いたつもりでしたが、 Add や Find 、 Initialize といった一般的な用語については英語が良いと思っています。
ここでローマ字にしたほうが良いと私が考えているのは「業務で使用する用語」です。
たとえば「顧客種別」という用語があった場合、それをビジネスロジックに落とし込む際にクラス化することになると思うのですが、以下の理由より、 KokyakuShubetsu としたほうが良いと思っています。
CustomerType、CustomerKind、CustomerCategoryなど、どれが適切なのかはもとの日本語が業務用語なので難しい- この「顧客種別」は実際は「顧客の年齢別にカテゴライズしたもの」である。しかし、クライアントが「顧客年齢層」ではなく「顧客種別」という名前を使用しているので、ミーティングでは「顧客種別」という言葉を使用している。そういう背景があり、メンバーやクライアントとのコミュニケーションを考えるとローマ字を使用したほうが良い気がする
全てが全て以上のような特殊パターンではありませんが、そういうものが少なからず存在する限り、業務で使用する用語（単語）は、ローマ字で統一したほうが良いと思っています。
あれはローマ字、これは英語とするよりは、「業務用語はローマ字」としたほうがプログラムの見通しもよくなると思うからです。
後出しになったようですみません。実際のプロジェクトで起きていることをオブラートに包む表現が難しかったので、質問の意図がうまく伝わっていなかったのかもしれません。
回答13件
0
こんにちは。
まず、基本はそのソフトウェアをメンテナンスする人たちの多くがローマ字を選択するのであればローマ字もありと思います。
関数名等にも漢字を使える処理系ならば同様に漢字もありと思います。
そして、私個人の優先順位的には英語＞漢字＞ローマ字ですね。
ローマ字を選びたくない理由は以下の通りです。
- 単語が長い
関数名等はなるべく省略しない方が好ましいと思うのですが、ローマ字は長くなりがちです。長過ぎる関数名は可読性を落とすし、省略した単語も可読性を落とすのであまり選びたくないです。
- キャメル・ケースにせよスネーク・ケースにせよ混乱しそう
助詞を単語として扱うのかどうか悩ましいです。スネーク・ケースで助詞を単語にすると辛いと思います。list_wo_shutokuにせよ、listwo_shutokuにせよ如何なものかと。
- 外来語を英語表記するのかローマ字表記するのか無駄に悩みそう
居ないとは思いますがrisuto_o_gettoなんて書く人がいたら、正直絶望を感じます。かといってlist_wo_getもどうかと思います。
素直にget_listと書きたいです。
- 正直ソフトウェア技術の発祥は英語と思います
なので、僅かでも英語に慣れるようにした方が、プログラマとして成長を期待できると思います。
漢字をあまり使いたくないのは、慣れもありますが、漢字を使えない処理系を使えない問題も大きいです。
【再補足を受けて追記です】
要は可読性／メンテナンス性をより良くする選択をするべきと思います。
私の個人的な経験上は英語で統一したい（私はC++erですので業務システムを開発することはまずない）ですが、確かに「売掛金」のような経理用語を英訳すると却って酷いことになりそうです。同様に当該システムで定着している専門用語が日本語なら、無理に聞きなれない英語に翻訳するより日本語のままの方が可読性／メンテナンス性は良くなると思います。
投稿2017/09/23 07:30
編集2017/09/23 09:59
総合スコア23274
0
その業界独特の用語ですと英語の対訳が存在しないはままあるのはなんとなくわかります。「寿司」は"Sushi"であるように、それはそのままでも良いんじゃ無いのかなと思いはします。他にも、「年度」というのは、英語だと種類毎にわけて("fiscal year"や"academic year"等)使われているようですが、日本語では独立して「年度」と言ったりするので、対訳が難しいです。「年度別統計」をどう訳すのかとかも、Google翻訳では"Yearly Statistics"としてますが、これでは「年別統計」で「年度」が消えちゃいますので、こういうのが問題になるのではないかと思っています。
この問題は適切な対訳となる英語が存在しないとき、それだけ日本語(ローマ字)にするのか、全部日本語にするのかという問題だと受け止めました。たぶん、ほとんどの業務用語については、Google翻訳とWikipediaの力を借りれば、適切な対訳が見つかると思います。それほど手間では無いですし、対訳表を作ってみんなで見れば良いだけです。問題は日本の業界独自すぎて対訳が無いときです。
私はそのままローマ字でいいと思います。例えば「忍者」は"Ninja"です。隠れる(忍ぶ)人だから"Hiding Man"かなとかしたら、途端にただのかくれんぼしている人に思えてきます。「モンブラン」を「白山」と言うぐらい違和感があります。安易な直訳は、その言葉の本質は失われ、逆に意味が不明になってしまいます。つまり、無理に英語にしてもうまくいかない日本語はたくさんあるのです。それはそのままでも「日本からの外来語である英語だ」と言い切れば、きっと、"Ninja"や"Sushi"や"Geisha"や"Fujiyama"や"Harakiri"や"Tsunami"や"Typhoon"のように英語に思えるはずです。
ということで、私としては、きっちり対訳表を作ることだと思います。適当な対訳が無かったら「これは日本独自だから英語圏には存在しないです。つまり、ローマ字表記が正式な英語です」と言い切れば、ネイティブの人からみたらどう思われるかなんて気になりません。ローマ字でもヘボン式なのか訓示式なのか、そういったところもきちんとすれば、問題ないでしょう。
投稿2017/09/23 12:12
編集2017/09/23 12:29
総合スコア21741
> "Ninja"や"Sushi"や"Geisha"や"Fujiyama"や"Harakiri"や"Tsunami"や"Typhoon"のように英語に思えるはずです。
どんな業務っすか？ そんな言葉が必要になるシステムって。
まー、ないこたー、無いとは思いますけどね。そんなことに焦点を絞って語ることに、なんか意味があるんですか？ 議論したいだけ？
別に名詞についてローマ字表記つかうなとは言わないけど、使うべきかどうかなんて、普通に考えてわかるでしょ？ 業務なら。
打ち合わせとかすれば簡単にコンセンサスも取れるだろうし。
敢えて一生懸命、日本語のローマ字表記する事象について語りたがる精神構造が理解できないっす。
なんか、低評価がつけられないのでしょうがないからコメントだけしておくことにするっす。
他に言ってる人がいたから僕は言わなかったんだけど、全然分かってないですよね。
Zuishinさんとtouwaerioさんがずっとまえに言ってた。
> その日本語、意味が通じますか？
> 英語であれば綴りの違いで区別できる単語が日本語では分かりにくくなりませんか？
> 方言が入りませんか？
> スラングが入りませんか？
> ローマ字だと逆に読みづらいと思います
ほんと、これ。読みにくいんですよ、とにかく。ローマ字って。
なーんでその程度のことに気づかないのか不思議でしょうがないっす。
コメントを読む限り、luckerさんが言いたいことは
「全ての業務用語に英語の対訳は存在するから、ローマ字を使うか迷うという選択がそもそもありえない」
と言う主張でしょうか？そうであれば、ご自分の回答にその旨を書けばよろしいのでは無いでしょうか？そのような回答に編集したのであれば、私が低評価を付けた理由から外れますので、低評価は取り下げます。
> コメントを読む限り、luckerさんが言いたいことは
> 「全ての業務用語に英語の対訳は存在するから、ローマ字を使うか迷うという選択がそもそもありえない」
> と言う主張でしょうか？
どんな読解力してるんですか？ ち・が・い・ま・す
これでOK？
取り下げようが何をしようが、しようとする権利はこっちにある。それがteratailすよ。
luckerさんが何が言いたいのか私には全く理解できないことがわかりました。申し訳ありませんが、私にはそこまでの読解力はありません。理解力が足りない私にもわかるように、luckerさんの主張をわかりやすくご自分の回答に書いていただくと助かるのですが、質問者でも無い私のお願いなど聞いてくれるわけがありませんから、後は口を噤むことにします。
うん、だから、英語で書け、以上。わかりやすい。
> "Ninja"や"Sushi"や"Geisha"や"Fujiyama"や"Harakiri"や"Tsunami"や"Typhoon"のように英語に思えるはずです。
これ、全部英語だからね。アメリカンピーポーは大抵分かるから。
例えば「見守る君」という製品について、英語にする時、「watcher」って製品で売り出すかえ？
一生懸命“対訳”とか語ってるの、アホじゃないの？ としか思えないな―。
ありがとうございます。
荒れてしまって申し訳ありません。
今回の質問の仕方が適切ではありませんでした。
特殊な業務用語や英語で表しにくいものはローマ字で、それ以外は英語でということですよね。
参考にさせていただきます。
0
個人的な考えとしてはどちらかといえば質問者さんの意見に賛成の立場です。
- setUrikakekin
- setAccountsReceivable
上記どちらをメソッド名にするかと考えた場合に1.の方を選択したくなります。
英語になっていてもGoogle翻訳でつけたようなよくわからないものであったり、
"区分"を"kbn"のように変数名につけている業務システムをみたりもします。
上記の"Accounts receivable"も"売掛金"の機械翻訳を参照して記述していますので英語的に正しいものかきちんと判断できていません。
ただ、何が業務用語で何がそうではないのかを区別できるのであれば、用語集を作ることもできるのかなと思います。
用語の対訳がきちんと設定できていれば、変な英語でもだいたい大丈夫のように思います。
変数名もメソッド名も、対訳や説明を日本語のコメントで記載していればIDEが拾ってくれますので追いかけるのはそれほど大変ではありません。
業務用語でないから英語で、としたものがヘンテコになる可能性もありますので、線引きが難しい問題かと思います。
ヘンテコになるのを恐れてずっと英語が分からないままというのも残念です。
最終的にはプロジェクトメンバー間で合意ができる形に落ち着くとは思いますが、皆が納得できる方針となることを願います。
投稿2017/09/23 07:38
退会済みユーザー
総合スコア0
ありがとうございます。
少なくともメンバーの英語力は決して高いとは言えません。ですので、大体の場合、機械翻訳を使用すると思います。となると、おっしゃっている通り、英語的に正しいかを判断できないままクラス名が出来上がることになるので、その点を危惧しています。
それと、線引きが難しいという件も確かにその通りですね。英語力が低いからと言って、ずっと英語力が低いまま（機械翻訳に頼りっきり）というのはおっしゃる通り残念です。
一点、反論をしたいわけではないのですが、対訳表について考えをお聞かせいただければ幸いです。
今回のプロジェクトでは、対訳表を作成した場合、数十個の訳語が出来上がります。（この点後出しになり申し訳ありません）
それを追いかけていくと、コードの可読性が低くなるかなと思います。
また、コメントに日本語訳を書くならば、最初から日本語（≒ローマ字）を使用するのがシンプルなのではないかと思います。
文字のみのやり取りなので、誤解を招くかもしれませんが、頂いた回答に反論がしたいわけではないです。よろしくお願い致します。
遅くなり申し訳ありません。届くかわかりませんが、頂いた内容に返信します。
ローマ字として記述した場合のデメリットとして考えられるのは、同音異義語を区別できないために意図通りに必ずしも伝わらない可能性があるということです。
一例として、全部ひらがなで記述した文書を誤読無く読めるかというのは、おそらく平安時代から続く日本人の悩みの種のように思います。
そのような場合を考えるとローマ字での定義時もコメントでの補足は必要だと考えます。
ですので、コメントで確認するのであれば、実際の定義名は何でもいいとまでは言いませんが、制約は少なくなるものと思います。
これはデータベース設計における物理名と論理名のような対応と想定しています。
論理名は、顧客、ユーザー、開発者で同じ認識を持つことが理想です。
業務で使用される用語と、画面に表示されるものや設計書、プログラムで扱うものが同じであることはDDDでのユビキタス言語のように、認識の齟齬を回避するためにも重要だと思います。
物理名は、プログラムやデータベースを実装する際に利用する内部的なものですので、区別できて、論理名との対応がわかれば大丈夫です。
また、過去にも同様の質問があり、様々な意見が出ているようですのでご紹介します。
https://teratail.com/questions/22739
https://teratail.com/questions/21720
0
私は質問者の意見も一理あると思います。ケースバイケースではないでしょうか。
その業務が世界的に見ても一般的な業務で（国際会計基準の経理とか）、かつその用語の意味が世界共通でほぼ定着しているような場合には、この機会に頑張って英語の用語を覚えるのも良いと思います。
しかしながら、実際には英語と日本語で完全に用法や意味が同じとなる用語というのは、特定業界用語の場合、意外と少ないというのが（海外の技術者といつも仕事をしている）私の実感です。日本語では一つの用語で済むのが、英語では場合によって二通りの用語を使い分けなければならないことや、英語では長い文章で説明しなければその概念を説明できない用語なども結構あります。
従って、その業界用語の訳語が英語で既に定着しているものであれば、英語を使っても問題ありませんが、そうでないものを無理やり英語にすると、今度はそれをネイティブの人に見せても理解してもらえない可能性があります。
私の個人的な意見としては、（プログラミングの世界で）一般的な用語はなるべく英語で慣れておいた方が良いが、日本独自の業界用語はローマ字のままにした方が良いと考えます。つまり、ネーミング規則として、英語だけ、あるいはローマ字だけ、というのは、どちらもあまり好ましくないという考えです。
投稿2017/09/23 07:42
総合スコア89
0
ローマ字賛成です。
理由は以下
・直感的に用途を理解できるのでソースコードを読む時間を削減できる。
・命名に悩む時間を削減できる。
・間違った単語を使う心配が少ない。プログラマの殆どはおばかさんなので、英語を読めない。
・タイプミスが少ない。プログラマの殆どはおばかさんなので、英語を書けない。
・単数複数形の区別がたぶんない。
・英語にするには困難な言葉もある。
・プログラム言語はだいたい英語ベースなので、予約語や避けるべきワードを気にする必要がない。
・単語の区切りが意味の区切りと一致する。先の回答にあるようにUrikakekin（一単語） vs AccountsReceivable（二単語）
以前こんなプロジェクトに遭遇しました。
Construct ←工事情報を管理するクラス
Contract ←契約情報を管理するクラス
コンストラクタという言葉自体使うべきでないのに似たようなクラス名で混乱させてくるひどい命名。
あと単語が長くなるかどうかはケースバイケース。本件では無視してよいでしょう。
反対意見の殆どは英語カッコイイ！！って思ってるだけですね。
作業効率を重視するなら間違いなくローマ字です。
ついでに
英単語にした場合のメリットは
・（意味はわからないけど）カッコイイ！！
・ライブラリの殆どは英単語ベースで命名されているので、見た目の親和性は高い。
こんなもんですか。
投稿2017/09/23 09:17
総合スコア200
あのね、僕がマイナスなのはteratailはアホばっかだからしょうがないんですけど、
この質問であなた、真面目に話してマイナス評価はヤバイスよ？ だからインラインしますね。
>・直感的に用途を理解できるのでソースコードを読む時間を削減できる。
ローマ字自体が読みづらいっす。
>・命名に悩む時間を削減できる。
あなた達の脳力のもんだいっす。勉強してください。
>・間違った単語を使う心配が少ない。プログラマの殆どはおばかさんなので、英語を読めない。
間違ったって良いんす。リファクタリングできない能力の方が問題っす。
>・タイプミスが少ない。プログラマの殆どはおばかさんなので、英語を書けない。
あなた達の脳力のもんだいっす。勉強してください。
>・単数複数形の区別がたぶんない。
単複間違えてても大した問題じゃないっす。リファクタリングすればいいっす。
>・英語にするには困難な言葉もある。
固有名詞とかの話っすか？ 貴方が太郎さんだとして、英語名は bold man になるとか思ってるっすか？
>・プログラム言語はだいたい英語ベースなので、予約語や避けるべきワードを気にする必要がない。
単一単語でネーミングするからそういうことになるっす。避けるのなんか簡単っす。
>・単語の区切りが意味の区切りと一致する。先の回答にあるようにUrikakekin（一単語） vs AccountsReceivable（二単語）
一致したら、なんか美味しいんすか？ どうでもいいっしょ。
>以前こんなプロジェクトに遭遇しました。
>Construct ←工事情報を管理するクラス
>Contract ←契約情報を管理するクラス
>コンストラクタという言葉自体使うべきでないのに似たようなクラス名で混乱させてくるひどい命名。
やったー！ 新しい英単語覚えられた！
You、sが見えてないでしょ？ コン“ス”トラクトとコントラクト、ぜんぜん違うでしょ？
やったー！ 一つ賢くなった！
>あと単語が長くなるかどうかはケースバイケース。本件では無視してよいでしょう。
You、１行の文字数が制限されてるCOBOLERの方ですか？ ご愁傷様です。
>反対意見の殆どは英語カッコイイ！！って思ってるだけですね。
見やすく書きやすいと思ってるだけっす。
>作業効率を重視するなら間違いなくかな推奨と併せてローマ字です。
GHQが日本にローマ字化を行わせようとしたのに覆って現在でも漢字利用が行われてるの、なんでだと思ってますのん？ 勉強しましょうよ、歴史を。
>英単語にした場合のメリットは
>・（意味はわからないけど）カッコイイ！！
なんすか？ かっこよさでメシ食ってるひとっすか？ モデルっすか？
>・ライブラリの殆どは英単語ベースで命名されているので、見た目の親和性は高い。
なんすか？ 見た目重視っすか？ 実用性度外視っすか？ ミーハーっすか？
>こんなもんですか。
ちゃいます。
以上です。
ありがとうございます。
今回のメンバーを見る限り、私も作業効率で言うとローマ字のほうが良いと思っています。
「英語カッコイイ！！」というのは、近々メンバー内で話し合いがあるので、そのときに確認してみようと思います。
私も、この部分がひっかかっていて、Zuishinさんがおっしゃるように論理的に「今後の海外進出の可能性」や「非日本人のプロジェクト参加」をメンバーが見越して英語を主張しているならよいのですが、ただ単に「英語がかっこいいから」が理由だとちょっと違うかなと思います。
> あと単語が長くなるかどうかはケースバイケース。本件では無視してよいでしょう。
これは、「ローマ字を使用した場合は単語が長くなる場合があるかもしれないが、」という前提ですよね。恐らく勘違いされている方がおられるようなので、一応書かせてもらいました。
将来いるかどうかわからない外人のために英語を使うんなら、コメントもドキュメントも社内メールも全部英語にしなきゃならないですが、そう主張する人はいます？
いないんなら、「今後の海外進出の可能性」や「非日本人のプロジェクト参加」は方便ってことだと思います。
そりゃ、方便でしょうよ。マジでそんなの信じてたんですか？
> そう主張する人はいます？
勿論居ますよ。個人的なこだわりを正当化するために後付けで理由をかき集める、WhyとWhatが逆転しちゃってる人は沢山いますから。
このページの一番上に居る人が、どう見てもそうでしょ？
前に、知らんアルゴリズムについてネット検索して出てきたコードをガバッと取ってきて、処理内容を一つずつ解析していったら意味の分からない変数があって「こりゃ一体何だ？」と思って調べてみたらルーマニア語だった…みたいのがあったなぁ。
英語で書いてくれと。他はみんな英語なのに。
プログラム自体がある程度難しいことやってるので『まぁ、しゃーねーか』ってなったけど、クソみたいなコードをローマ字変数・メソッド名とかでネット公開してるのを見ると「What a heck! Are Japanese all nuts?」と、思っちゃうんですよね…
0
ローマ字というのは本来アルファベットのことですが、ここでは日本語のローマ字表記のことと受け取ります。
業務ということであれば独自の指針があるでしょうから既にあるならそれに従ってください。
無い場合、可能であれば英語にした方がいいと思います。
メンテするのは必ず日本人ですか？
絶対にインド人の社員が入ることはありませんか？
オープンソースになることはありませんか？
国際的なプロジェクトになることはありませんか？
海外資本が入ることはありませんか？
その日本語、意味が通じますか？
英語であれば綴りの違いで区別できる単語が日本語では分かりにくくなりませんか？
方言が入りませんか？
スラングが入りませんか？
投稿2017/09/23 07:05
総合スコア28673
ありがとうございます。
確かに、「絶対に」ということはないかもしれないですね。
そういう意味では無理やりでも日本語にしたほうがいいのかもしれませんが、やはり「現時点でのコミュニケーションを円滑にする」というのと天秤にかけると、ローマ字のほうがよいという気がします。こういうリスクヘッジはプロジェクト固有のことなのかもしれませんが・・・。
方言やスラングというわけではないですが、たとえば一般的な用語ではない業務で使用する用語こそ、ローマ字にしたほうがコミュニケーションの齟齬がないのかなと思います。
日本語を使った方がいい場合は間違いなくあります。sushi を fish and rice ball と書く必要はありません。
ただ、仰るケースは本当に日本語を使った方がわかりやすくコミュニケーションが円滑になるのでしょうか？
他のメンバーはそうなると考えていないわけですよね？
補足を読みましたが、私ならこのケースで種別という単語は日本語英語に限らず使いません。
年齢層(AgeGroup)を強く推します。会議でも用語の変更を推します。そしてこれは業界用語でなく一般的な言葉です。
だーから言ってるじゃないですか。
> 2017/09/23 16:52
> な・お、この回答についたマイナスの数は、中学生英語すらおぼつかないグラマさんの数です。
って。
中学生英語すらおぼつかないやつが業務に携わって「ローマ字表記すべき」とか言って、全否定されたらマイナス評価するみたいなのが、このスレッドの成り行きなんです。
すべきことは、ローマ字表記の推奨・否を語ることじゃなくて、「お前ら勉強しろ」以外に無いんですよ。
ちなみに、Generationじゃないっすか？ “クライアントが「顧客年齢層」ではなく”って言ってるから。
たけし「ジェネレーション・ギャップくらい分かるよ馬鹿野郎！」
0
プログラム全般でいえば、メンバーの意見に共感します。
ただ、今回のケースで言えば、
一般的な業務用語（業界で使用される専門用語）と言うよりは、
その業務システム内で独自の意味を持つ「業務上の固有名詞」なので、
「固有名詞を英語訳するか？」という問題に思えます。
固有名詞をその意味ズバリで、かつ一般的な意味に誤解されず、プログラムに使うシンプルな英語に翻訳するのは、かなり難易度が高いんじゃないかなと思います。
（例で出てきているケースだけであれば可能かもしれませんが、他にも山ほどあるのだと想像します）
なので、私なら
システム開発方針や規約にあたるドキュメントにそのあたりの説明と、
使用する全固有名詞とその意味、ローマ字の表記が記載されていれば、
それで良しとすると思います。
投稿2017/09/23 14:18
総合スコア18778
0
あるスコープ内での「専門用語」を「一般化した用語」に置き換えるべきか？という問題として回答します。
ここでのスコープとは、ある特殊な学術用語や、そのシステムを利用する一企業や業界内でしか通じない用語などでの「特殊な学術分野」や「一企業や業界」を指します。
それらの用語は、一般化した用語に置き換えるよりも、そのまま使うほうがよいと思います。
その用語は、プログラムコードの外でも使われることがありえます。
たとえばDBのテーブル名や外部システム連携上のCSVファイルの列名などです。
そのため、そのシステムを利用する情報システム部（DBのテーブル定義なども見る人）や外部連携先が分かりやすい用語を用いるべきと思います。
もちろん、コード内ではその用語を別の用語（英単語）に置き換えて処理してもよいのですが、面倒です。
すなわち、私の場合はコーディング規約よりも**（用語の）命名規約**を優先するようにしています。
蛇足
その用語名を冠する数値を変数としてコード上で扱う場合、その変数がどんな単位なのかを明確にするようにしています。
それが量[hoge]なのか速度[hoge/sec]なのか？、単価[円/単位数量]なのか金額[円]なのかなど。
投稿2017/09/23 13:16
編集2017/09/23 13:20
総合スコア38352
すっげー、どうでもいいレス。全然質問の内容に対してアプローチしてない。
あーなたも、訳分からんコメントつけてくれたのでね。
マイナス評価できないから、逆コメントするしかないっす。
たしか１日当たりの低評価できる数に上限があったはずです（５回だったかな？）。
日をあらためて試してみてください。
もちろん、そのつもりです。
0
日本語はひらがな、カタカナ、漢字で書けるから読みやすいだけで
ローマ字だと逆に読みづらいと思いますが
結果、できあがったものはヘンテコ英語の恥ずかしいものになる危険性がある。
多分ローマ字で書いたほうがヘンテコで恥ずかしいものになる気がしますが。
投稿2017/09/23 07:21
退会済みユーザー
総合スコア0
>日本語はひらがな、カタカナ、漢字で書けるから読みやすいだけで
だからといって
function 顧客情報マスタを参照して30代男性を抽出する()
{
hoge();
：
}
みたいなのが出来る言語でそれをやって良いということにも成らないんだから、
どのみち、日本語表記自体が狂っちゃってるって事ですよ。
ありがとうございます。
おっしゃられる通りかもしれませんね。確かに出来上がるものとしては、ヘンテコな英語よりもヘンテコなローマ字のほうが恥ずかしいものになる可能性があります。
それでもセマンティクスを維持するためにローマ字という選択肢はありなのかなと思っています。例えばプロジェクトに新規メンバーが参加した際、実際の業務で使用する言葉とコーディングの名称が異なるときに、ミスコミュニケーションが発生するのではないか、などです。
ただし、これも他の回答者様がおっしゃられている通り大役表みたいなものがあれば、そこまで大きな問題にならないのかもしれませんね。
「ローマ字を回避してまで間違った英語を使用するのは恥ずかしい」と思い込んでいましたが、そうではないという見方もあることがわかりました。ありがとうございます。
0
私も英語賛成です。たとえば、メートル法が主流の世界でSun（寸）とかShaku（尺）とか言われても困ります。インチの世界でも同じです。
まあ、プロジェクトメンバの中で「ローマ字推し」が多いならばそのコミュニティの中ではそれも間違いではないと思います。ただし、私は参加したくないです。
もっとも、この話題は論理的な議論にはならないというのは当然です。**論理的な回答は存在しないでしょう。**社会的背景、文化の話題です。究極的には以下の通りです。
###プロジェクトの中の会議や打ち合わせで決めてください。
プロジェクトの外部に回答を求められても困ります。（「デファクトスタンダードについて聞きたい」ならば英語であることに間違いはないと思います。まあ、このような質問ではないと本人が否定しているので参考ですが）
投稿2017/09/24 04:18
総合スコア4853
0
個別対応すべきところを一般化しようとして混乱しているように見受けられます。
コーディング規約はプロジェクトメンバーの合意がなければ履行が困難となります。ご質問ではメンバーは概ねローマ字表記を認めることには反対のようですから、合意は厳しいでしょう。いろいろローマ字表記にすべき理由を書かれていますが、この場で納得を得られてもプロジェクトメンバーに納得してもらえない限り無意味です。
無理に押し通せば反発を食らってモチベーションの低下につながります。
それをふまえて、もし私が命名規則を決めるとしたら、
- ローマ字表記不可
- ただし、対訳表に記載のある用語はそれに従うこと
とし、対訳表を用意します。落としどころとしてはこれが最良だと考えます。もし表記に不満が出たとしても個別に議論すればすみます。対訳表はすべての用語を網羅する必要はなく、注意すべき用語だけを書いておけば良いでしょう。
ローマ字云々を抜きにしても、同じものが人（部署）によって呼び方が違っていたり、同じ用語が人によって訳が異なったりすることもあるので、用語の統一という意味でも、対訳表あるいは用語集のようなものは用意すべきです。新入社員や派遣等のメンバーがいる場合は特に重要です。
投稿2017/09/24 02:08
総合スコア5944
0
ベストアンサー
非常に残念です。
今回の質問は「私を認めてくれ」という意図は一切ありません。
- ローマ字の使用についてみなさんはどういうお考えか
- なぜ英語を推奨するのか（ローマ字を推奨しないのか）
以上を聞きたかっただけです。
これは私の質問の仕方がよくありませんでした。
回答をして頂いた方、恐らく不快な思いをさせてしまいました。申し訳ありません。
- 明らかに意図が伝わりずらい質問である
- 質問と関係のないコメントが乱立する
以上の点から、不適切な質問であると判断し、運営側に質問自体を削除リクエストします。
ご迷惑をおかけして申し訳ありませんでした。また、ご回答していただいた皆様、ありがとうございました。
投稿2017/09/24 01:37
退会済みユーザー
総合スコア0
だーから、こういうことする奴だからマトモに相手にされなかったって、何で分かんないんですかね？
冒頭で「非常に残念です。」って何なんですのん？
「ご迷惑をおかけして申し訳ありませんでした。」って結語と、全然合致してないじゃないすか。
0
既に回答を一つしましたが、全く主旨の違うことを言いたくなったので敢えて別回答とします。
この場合問題は日本語と英語のどちらを使うかということではなく、「種別」という言葉を選んだことが諸悪の根元のように思います。
極端に言えば、年齢層も種別、性別も種別、職業も住む地域もプロパティは全て種別、それらを全て kind や type や class と命名し、kind なら年齢で type なら性別、そのように使い分ける……そこまで酷くはないでしょうが、近い環境にあるのではありませんか？
age は中学で習う英単語です。決して業界独自の言葉ではありません。まずこれを顧客種別と命名するような環境をどうにかしてください。そうすればおそらく類似の問題の多くが片付きます。
投稿2017/09/23 08:45
総合スコア28673
詳細は語れないですが、「客層種別」というのはシステムで長年使用された用語なのです。（そして今回のプロジェクトはその長年使用し続けてきたシステムの後継にあたります）
さらにクライアントもその用語を使用し続けているという事実があります。
おっしゃる通り、そもそもの名前が適切でないのですが、以上の背景があり既に変更することができないのです。
しかし、今後の機能拡張時には「種別」という言葉を安直に使用しないように心がけるべきですね。ありがとうございます。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2017/09/23 14:09 編集
退会済みユーザー
2017/09/23 14:53
2017/09/23 15:24
退会済みユーザー
2017/09/23 15:50