エンジニアになるのに英語は必要?
エンジニアになるのに英語は必要?
はじめに
「エンジニアになるために英語は必要でしょうか?」
もし私がそのように聞かれたとしたら以下のように答えます。
「身につけていると便利な場面が多いのは間違いないですが、英会話やTOEICで出るような文法問題はあまり必要ありません。エンジニアならではの方法で英語を身につけるのが良いと思います。」
なんとも微妙な回答です。この回答をもう少し分解してわかりやすくお伝えしようと思います。
英語を身につけていると便利な場面
先ほど英語を身につけていると便利だと書きましたが、ではどんな場面で役に立つのでしょうか?
- 変数名や関数名を決める時
- フレームワークやライブラリのドキュメントを読む時
この2つが最も多い「エンジニアにとって英語が役立つ場面」だと思います。その他役立つ場面としてはエラーを解決するためにググる時やYouTubeなどで海外のエンジニア系ユーチューバーの動画を見たりGoogleのカンファレンスなど日本語に翻訳されないイベントを見たりする場面があるかと思います。
変数名や関数名を決める時
リーダブルコード という有名な本にも書いてある通り変数名や関数名はプログラム自体の読みやすさにとって非常に大事な要素となります。その際に意識すべき点が2点あると思います。
1つ目が「ワードのチョイス」です。
例えばある要素の表示非表示を切り替える関数があったとします。あなたはその関数に名前をつけなければいけません。切り替えという単語と表示非表示という部分に分けて考えます。
まず「切り替え」という日本語を英語に直すと
- switch
- toggle
などの単語が挙げられるかと思います。
表示非表示に関しては「hidden」という単語が考えられるでしょう。
では
-
switchHidden() にするのか
-
toggleHidden() にするのか
のどちらが良いのでしょうか?
結論を言うとtoggleHidden() の方が良い書き方だと言えるでしょう。GitHubで検索するとこちらの方がかなり多くヒットします。"toggle" という単語は日本ではそこまで一般的な英語ではなく、switchの方が一般的ですしなんとなく正しそうにも聞こえます。
現にネットで一般的にはどちらが使われるのかと調べたところネイティブの方が「switchの方が使われる」というような意見を仰っていました。もしかしたらプログラミングにおいてはswitchという単語は条件分岐に使われることが多いので関数名などでは被りを避けてtoggleを使うようにしているのかもしれませんね。
この場面では
- toggleという英単語を知っている
- 関数名ではswitchよりtoggleの方が一般的であることを知っている
という2つの条件を満たしていれば適切な関数名を英語でつけられた、ということになります。
意識すべき点の2点目が「品詞」などの簡単な文法知識です。
例えば要素の表示非表示を真偽値(Boolean)で管理しているとしましょう。
プログラミング言語によって違いはありますが真偽値の変数名は
is + 形容詞
で表されることが多いです。(余談ですが関数やメソッド名は動詞から始まり、文字列や数値は名詞で定義するのが一般的だと思います。)
要素の表示非表示なので上述の通り
hide = 隠す
というワードがチョイスされます。あとは真偽値をつける際の慣習に合わせてhideを形容詞化してisHiddenという変数名にしてあげれば正しく命名できたと言えるでしょう。
この時に品詞への意識が少なく、
isHideやisHiding などとしてしまっては他の人が読みづらい汚いコードになってしまうでしょう。
Githubでこの3つの変数名がどれくらいの割合で使われているか調べてみます。
- isHidden:5,980,271件
- isHide:126,483件
- isHiding:50,924件
ご覧の通り大きな差がついています。
変数名や関数名をつける際には、国際基準でエンジニアにとっては「どの英単語が一般的なのか」や「品詞」について意識することが重要だと言えます。
このように、エンジニアがよく使う英単語や基本的な品詞を知っていることは読みやすいプログラムを書く上で非常に大事だと言えるのです。
単語に関しては「エンジニア 英単語」などでググるとよく使う英単語をまとめてくれているサイトが見つかります。それらを覚えるだけである程度対応できるのではないでしょうか。品詞に関しては、普段から意識して使うことで自然と身についてくると思います。
使用するフレームワークやライブラリのドキュメントを読む時
フレームワークやライブラリは基本的にGitHubのコミュニティをベースに育てられることが多いです。グローバルなプロジェクトであることが多いのでドキュメントやイシューは当然英語で書かれます。(中国系のプロジェクトでは中国語が第一に使われることもあるようですね)
日本語への翻訳は基本的にされない、もしくは遅れてされるのどちらかだと思います。また、大抵はボランティアの方の善意に頼っていることが多いので依存するのは危険です。
また、最近はこうしたフレームワークやライブラリを日本語で解説した記事や動画が多く作られるかと思いますが本来であればこうした教材にも頼り切るべきではありません。公式ドキュメントであれば、そもそも書いてくれるのが作者なので誰よりも仕様について正確に理解していますし他のコントリビュータや世界中の開発者の目に晒されるので情報の信頼性という意味ではそれ以上に高いドキュメントは存在しないと言えます。こうしたドキュメントを中心にしながら補助的な役割で記事や動画を見るのが良いかと思います。
なので英文読解ができると
- 最新かつ正確な情報を入手することができる
という凄まじいメリットを享受することができます。
ただ、DeepLなどの高性能な翻訳ツールを使えば日本語でも読めるレベルになるとは思います。私も長い文章の時はDeepLを使うことがあります。DeepLを使いながら不自然な部分は自力で読むなどのやり方も可能でしょう。
結論
昔、実務未経験で入社したアメリカ人のエンジニアと一緒に仕事をして驚いたことがありました。彼が持ってくる情報がどれも正確で最新のものだったのです。また彼自身新しい知識を身につけるスピードが非常に早かったのをよく覚えています。どうやってるの?と聞いたら「公式ドキュメントを読んでるだけだよ」と言っていました。
もちろん彼が優秀だったのは間違いありませんが彼と同程度に優秀でも英語を使えない日本人が彼と同じスピードでエンジニアとして成長できるでしょうか?私はできないと思います。
それくらい英語ができることはエンジニアにとって有利なことなのです。ただし上で書いたようにエンジニアに必要な英語と一般的な英語には乖離があります。「エンジニアには英語が必要だから」と言って文法書を読んだり英会話学校に通ったりするのは当初の目的からは遠回りになるのではないでしょうか。
まずは四苦八苦しながらドキュメントを隅々まで読み込むことを習慣にしてはいかがでしょうか?
私も日本語でググってなんとなく理解したつもりになっていることが多いですが、改めて公式ドキュメントの重要性に立ち返るべきだとこの記事を書きながら思いました!
一緒に英語に親しんで、綺麗なコードを書きましょう!
乗っかっちゃってすみません。英語ってワーキング言語って言われていますよね~。仕事で使う言語。英語で検索してなんとか解決方法みつけたとかってみなさん経験あるんじゃないでしょうかね。貴重なナレッジありがとうございます。