はじめに
プログラミング玄人の皆様ならご存じの通り、エンジニアはメンドウな人が多いです。（ここで炎上）
プログラミング初心者ならまだ指摘された経験がないかもしれませんが、例えば
if (式)
{
処理
}
か
if (式) {
処理
}
を同じプロジェクト内で混合すると怒るエンジニアは（かなり）いますし、
JavaScriptで無意味なセミコロン;をつけるかつけないかで宗教戦争が起きます。
プログラミングを知らない人、初心者からすると「そんなのどうでもいいだろ」と思うでしょうが、エンジニア界隈ではこういった記法に神経質な人がむしろマジョリティです。（あえてその是非は議論しませんよ）
先ほどの2例はプログラムコードの書き方についてのコーディング規則に関するお話になり、もちろん重要な側面もあります。
（簡単な話、他の人が書いた関数を使うときに大文字スタートだったり小文字スタートだったりが混合して一々確認しないといけなくなると、しんどいですよね？）
しかし、自然言語のコミュニケーションにもその神経質さが現れています。
あえて引用はしませんが、Twitter上で、「応募者の履歴書の経験技術欄を見たら、reactと書いてあった。だめだこりゃ＾＾；」という旨の人事のツイートに対して、フォロワーのエンジニアは「うんうん！それはだめだ！」「エンジニアは大文字小文字ですら正確に扱う仕事だ！」と同調しているのがほとんど、という状況を見かけたことがあります。
ちなみに正解は「React」と書くことです。
こういった不文律に対して、エンジニア界隈新入りはコミュニケーションの段階で知らず知らず理不尽に見下される可能性、怖いですよね。正直、新入りにとっては初見殺し的で可哀想な風潮だと思います。
そこで、今回は新入り、部外者にとっては思わぬ「地雷」になりそうな言葉遣い・書き方についてご紹介します。
先ほど紹介したようなプログラムコードの規則についてはコーディング規則と検索するといっぱい議論されていますので、こちらはこちらで必ず目を通すべきです。（これもまたメチャクチャだと見下されるどころか怒られる原因になります）
予め私見を述べておくと、僕自身はコミュニケーションに関しては伝われば十分と考えていて、言葉遣いの不慣れさだけで相手を評価するのはくだらないことであると感じております。しかしその一方で現状のエンジニア界隈に迎合しないと仕事できないので、不文律を明文化したいという試みをしています。ここに述べる事項に賛同する意図はなく、あくまで紹介をしています。
話し言葉・書き言葉共通
用語の誤用・乱用
これは知的産業全般に言えることですが、用語の誤用・乱用は鋭く指摘されます。「それぐらいニュアンスで分かるでしょ」というレベルでも指摘してくるエンジニアはいます。
例えば「リファクタリング」
これはざっくり言うと、「プログラムコードの手直し」であるということは皆さんの共通認識ではないでしょうか。
しかし、しっかりした定義では、「外部仕様を変えずに内部仕様を変更すること」です
簡単に言い換えると、プログラムのロジックや記述を改善しても、その結果・挙動を変えてはいけない、ということです。
なので、例えば「UIの見た目も変えて改善した」場合は「リファクタリング」と言ったら怒られますし、ユーザーの操作手順に変更が起きたら怒られます。バグの修正ももちろん外部仕様が変更されているので「リファクタリング」ではありません。気持ちは全然分かるはずですのにね。
これは解釈の問題で正直懐疑的ではありますが、クラス構造・メソッドの連関をスッキリさせることも、「クラス構造をリファクタリングした」といえども「コードをリファクタリングした」とは言えない（単一のコードから見たらクラス構造は外部なので）、という人もいます。
英単語の品詞の使い分け
中学校高校の英文法を忘れてしまった・やってない方は少し辛いお話かもしれません。
例えばユーザーの何らかの達成率を表すテーブルの名前を
Accomplish（動詞）にすると、妙な目をするエンジニアはけっこう多いです。
Accomplishment（名詞）にしろ、ということですね。
日本語にすると「達成する（動詞）」という名前の表はけっこう妙ですよね。
これはコード規則の範疇といえばそうかもしれないし、コミュニケーションの範疇にも含まれるタイミングがあるのではないでしょうか？（良い例が出てきたら追記します）
書き言葉
キャピタライゼーション
キャピタライゼーション(capitalization)とは、「大文字(capital)にする（ize）こと（tion）」です。
英文を書くときに、文章の最初、固有名詞の最初は大文字にする慣習ですね。
これが一番の気を付けるポイントです。
冒頭の通り、これに敏感なエンジニアは多いです。僕も適当に記事にgit、githubと書いていたら全て修正する編集リクエストをいただき、初めてそのような風潮があることに気が付きました。
要するに、プログラミング言語、フレームワーク、ツール類は公式の名称通りの記法をするべきとされています。
unityではなくUnity、vueではなくVue、というように。
気を付けるべきなのは複合語の名称で、GithubではなくGitHub、JavascriptではなくJavaScriptです。
記法の不統一
コード規則の文脈でも怒られますが、コミュニケーションでも気を付けるべきであるとされています。（これも知的産業あるあるですね）
例えば
- 同じアイテムゲットを「獲得」と表現したり「取得」と表現したりとバラバラ
- 「サーバー」だったり「サーバ」だったりする。
どっちでもいいけど、どっちかにするべき、ということです。（たまに「サーバー」じゃなくて「サーバ」や！とキレる謎の人がいますが、さすがにこれは人の好みなのでケアしきれません）
慣習からの逸脱
コード規則の議論をインプットした人なら分かると思いますが、エンジニアは慣習に保守的であるのが善しであるという風潮があります。その方が人によってバラバラな記述にぶち当たらなくとも済むようになりますしね。
その風潮は、コミュニケーションにも及びます。
例えば、かなり一般論ですが、「, .」を使うか「、 。」を使うか。
論文では「, .」を使うように指導されますし、社外文書では「、 。」を使わないと変な会社だと思われますよね。
分かりやすさのためにスラングを使っても場面と使うべきではない場面もある。
慣習には（完全な悪習でない限りは・そのメリットが認められる限りは）従いましょう。
しかしSNSの場合は、ありもしない慣習を勝手に作って押し付けるのはどうかと思いますけどね。
マークダウンのタグの使い方
QiitaやGitHubのReadmineでまとまった文書を書くタイミングのお話です。
タグの用法通りにタグを使いましょう。これは前節の慣習の尊重と同じようなお話じゃないですかね。（かくいう僕もあまり気にせず書いているので、物書きエンジニアからするとこの記事も怪しいかもしれません）
特に見出しタグが罠になります。
h1 h2 h3 h4タグの使い分けですね。
これらに番号をついているのは、文書を構造化する役割を持っているためです。Qiitaの記事の目次欄もこのタグ通りに表示されています。
その使い方が構造的ではなくぐちゃぐちゃに、それぞれのタグの見た目重視で書いていると、見下されてしまいます。
数か月前、意気揚々と自分の経験を語った数年目エンジニアの記事（いわゆるポエム記事）をわざわざ引用して、「見出しタグの使い方がめちゃくちゃ。今までドキュメンテーションなんて気にしなかったんだろうなと分かり、エンジニアとしての程度が知れる」というような、ギリギリ人格否定のような記事を見たことあります。（通報したらオブラートになっていました）
話し言葉
口頭コミュニケーションは言語以外の様々な要素も含めて意思疎通が行われるため、とりわけ気を付けるべき項目は、書き言葉に比べては少ないです。
読み・発音間違え
正直、あるあるではないでしょうか。
Ajaxは「エージャックス」です。
授業などで音声ベースのプログラミング学習をしてきた方はちゃんとインプットできているかと思いますが、参考書などの文字ベースで学習してきた人には厳しいところがあります。
読み方・発音間違えもまた見下されポイントになってしまいます。
最後に
下記で皆様にアイデア出しを手伝っていただきました。ご協力ありがとうございます。
https://qiita.com/konbraphat51/questions/7f02115630293e6c1125
他にも「このようなものもある！」という場合は編集リクエストあるいはコメントでお知らせいただけると追加いたします。