ソフトウェアエンジニアに必要な英語

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

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

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

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

英語を学ぶ目的

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

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

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

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

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

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

英語の読解

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

OSSのREADMEに始まり、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" というところです。これも雰囲気で、「文書が返されてから経過した時間」と理解してはいけません。

まず、"at the time" と "the" がついているので、特定の時刻の話をしているということが分かります。そうすると、 "it was served" が関係節で "the time" を修飾しているのだろう、と予想が付きます。つまり "document's age at the time / it was served" となっているわけです。 "document's age at the time" だけ取り出して眺めると「その時刻における文書の年齢」という意味になりそうです。そして "it was served" がその "time" を修飾しています。ここまでくれば、 "time" の直後に関係代名詞の "when" が隠れていることが分かるでしょう。すなわち "document's age at the time (when) it was served" なので「文書が返されたタイミングにおける文書の年齢」ということになります。

最終的な和訳はつぎのようになります。