ソフトウェアエンジニアと英語の話というのは、しばしば話題になります。 それだけ多くの人が英語について気にしていると思うのですが、「英語やらなきゃ」と言っている人に話を聞くと意外と動機が漠然としている印象があります。

果たして日本企業で働くソフトウェアエンジニアにとって英語は必要なのでしょうか？必要だとしたら、どういう英語が必要なのでしょうか？ この記事は、そのあたりの疑問を自分なりに整理するために書きました。 いつもの固い記事とは違って、他の記事も参照していないし、勢いで書かれた内容となっていますが、ご容赦ください。

なお、この記事はエンジニアの英語力 - 怠惰を求めて勤勉に行き着くに触発されて、 Androidアプリのビルド待ち時間に書かれています。エモい記事を書いてくださったしろやまさんと、Androidアプリのビルド時間、それに業務時間中に記事を書くことの理解をしていただけた会社に感謝します。

あ、あと、一応自分が働いているFablicという会社のAdvent Calendar 2017の1つでもあります。よかったら他の記事も読んでみてください。

英語を学ぶ目的

fushiroyamaさんも言っているように、英語は手段です。では、私たちソフトウェアエンジニアが英語を学ぶ目的はなんでしょうか？

人によって異なると思いますが、ここでは「業務遂行のため」としましょう。 身も蓋もありませんが、お給料のためです。たつきです。日銭を稼ぐために英語を学ぶのです。

そして、おそらくですが、多くの日本のソフトウェアエンジニアの場合は以下の前提が成り立つのではないかと思います。

  • 日本企業に勤めている
  • 同僚に英語話者はいない
  • RFCやStackoverflow、GitHubのissueなど英語で書かれたドキュメントは読む必要がある
  • 業務で話したり聞いたり書いたりする必要はそんなにない

やや恣意的に前提を選んだ気配もありますが、とりあえず、こうおきます。 中には海外カンファレンスにばりばり登壇したり、OSS活動などで日夜GitHubにissueを書いたりメーリングリストでバトルを繰り広げている人もいるかもしれませんが、とりあえずはこう前提をおかせてください。

ちなみに、自分は新卒で入った会社が外資系だったため、配属直後にUSのマネージャーとテレコンして全然聴き取れなくて先輩に泣きついたり、イタリア訛りの営業さんとのミーティングで深夜に議論という名の喧嘩の仲裁をする羽目になりましたが、 そういう人の場合はまた話が違ってくると思います。

必要な英語能力

さて、前提をなかば恣意的に選んだおかげで、必要な英語能力はおのずと明らかになったかと思います。そう、読解能力です。 ソフトウェアエンジニアの仕事の多くで英語文書の読解は必要になります。

OSSのRAEDMEに始まり、RFCも英語（多くは日本語訳されていますが）ですし、Androidエンジニア向けのドキュメントも主に英語です。

なんだよ、リーディングはできるんだよ、と思った貴方、本当にそうでしょうか。

日本人はスピーキングやリスニング、ライティングに比してリーディング能力が優れていると言われます（要出典）。 それでも、これも観測範囲内の経験でしかありませんが、意外と英語の読み間違いをしている人を見かけます。

ブログ記事などでしたら、そんなに問題にはならないかもしれませんが、仕様であったり厳密さが必要な場合だったりすると、ともすると致命的な間違いになりかねません。

たとえば、次の英語の意味をぱっと取れるでしょうか。

An origin server SHOULD obtain the Last-Modified value of the representation as close as possible to the time that it generates the Date field value for its response.

これはRFC 7232の2.2.1節の内容です。

試しに30秒ほどかけて、これを翻訳してみてください。

いいですか？

こちらがRFCの日本語訳の該当個所になります。

生成元サーバは、［［ 自身が応答に対し Date ヘッダ値を生成する時刻 ］に可能な限り近い，表現の Last-Modified 値 ］を取得するべきである。

RFC 7232（日本語訳）からの引用です。

この文章の難しい箇所は “as close as possible to the time” というところです。なにかとなにかが出来る限り近い必要があるのですが、それが何か、というのが分かりにくいところだと思います。

そして、もっともやっていけないのは、雰囲気で理解してしまうことです。 これはLast-Modifiedヘッダの生成の話なので、つまりDateに最も近い必要があるのだろう、と適当に見当を付けた場合、微妙に間違った理解になります。

もう一度英語を見直してみましょう。こんどは、”as ~ as possible” などの修飾を省いて、基本的な骨格だけ取り出します。そうすると

An origin server SHOULD obtain the … value … close to the time that …

となっていて、「〜した時刻に最も近い値を返すべき」となっていることに気付きます。 なお、ここで “the time that” という関係節が “the time when” と同じであることは知っている必要があります。

つまり、この文章は「Dateヘッダが生成されたタイミングに最も近いLast-Modified値を返すべき」と言っていて、要するにHTTPヘッダを生成するタイミングにおける該当リソースのLast-Modified値を返すべき、ということを言っているわけです。

これは、実用上はそんなに問題にならないかもしれません。おそらくDate値とそれが生成されたタイミングというのはそれほどずれないからです（このへんの理解が間違っていたらご指摘ください）。 とはいえ、RFCではより厳密に定義しているので、そのニュアンスが汲み取ろうとすると、このような読解能力が必要となります。

軽視されがちだけれど大事な文法

さて、さきほど読解能力と一口に言いましたが、読解能力とはなんでしょうか。

ここからは持論になりますが、自分は英文法を知っていることと、それを利用して文の構造を読み解く力であると考えます。

英文法というのは、あれです、中学でやった三人称単数のsとか、趣味がギターというときの play guitar に冠詞のaは付けない、とかいうあれです。

英語を読んでいると、ネイティブの人にとっては無意識に理解できることが、私たちのような英語が第二言語の人にとっては、意味がまったく取れないという事態によく出会います。 そういうとき、英文法だけが英語の理解への手掛かりといっても過言ではありません。

たとえば冠詞が付いているかいないかで意味は変わりますし、三人称単数のsは文の係り受けを読み解くときに大変な助けになります。 あれほど嫌いだった文法が、こと読解になると心強い味方になるのです。

試しに、もう1つ例を見てみましょう。 こちらは、とあるライブラリのコメントです。

the max age of a document should be defaulted to 10% of the document’s age at the time it was served

こういう短い文章は文脈がないだけに意味が取りづらいことがあります。

この文の肝は “document’s age at the time it was served” というところです。 なんとなくデフォルトで文書の年齢の10%をmax ageにしているんだな、ということは分かりますが、最後の “at the time it was served” はなんでしょうか。 これも雰囲気で、「文書が返されてから経過した時間の10%を〜」と理解してはいけません。

ここは “age at the time (when) it was served” なので「文書が返されたタイミングにおける文書の年齢」ということになります。

このように関係節が隠れている文はぱっと意味が取りづらいのですが、最後の部分が過去時制になっていることに気付くと、関係節になっているんだなということが分かります。

余談ですが、翻訳でもっともやりがちなミスは先入観でこういうことを言っているのだろうと思うことです。 文を訳すときは無心になって謙虚に英語に向きあいましょう。

その他に大事な英語能力

この記事では読解能力、とくに文法が大事という話をしましたが、他にも大事な能力はあります。

たとえば速読もその1つです。あれは英語圏でも本が出るくらいテクニックがあるようですが、トピックセンテンスを探し出して読むという訓練をするだけでもちょっと速くなります。 また、ポッドキャストやカンファレンスの発表を聞いて勉強したいならどうしてもリスニングは避けて通れません。 本気で外資系や英語圏で働くつもりなら、スピーキングも大事でしょう。

それぞれが何のために英語を学ぶか、ということを明確にしておくと、より効率的な勉強ができるのではないでしょうか。