重要なテクニックはたった四つ
本書『現場で困らない！ ITエンジニアのための英語リーディング』で紹介される、英語をすらすら読めるようになるテクニックはたった四つしかありません（もちろん英語の基礎やある程度の語彙は前提となります）。
一つ目は「英語の語順で理解する」。学生時代の名残からか、英語を読むときにどうしても日本語のように文章の後ろから前へ戻るように訳してしまいがちです。しかし、これはNG。英語の語順のまま意味を理解していくほうが素早く読めます。
二つ目は「スラッシュ・リーディング」。先頭から読んでいくにしても、1単語ずつだと時間がかかります。なので、数語単位をスラッシュで区切るようにして、ひとかたまりずつ意味を把握するようにしましょう。スラッシュの位置は前置詞や関係詞、接続詞などを目安にするとわかりやすいですね。
三つ目は「スキャニング」。ドキュメント全体から自分が欲しい情報だけを狙って読む方法です。必要な情報が見つかるまではざっと読み飛ばし、ここだというところを見つけたらじっくり読みます。これは日本語の記事を読むときでも同じではないでしょうか。そもそも、目的は英語を読むことではなく、英語で書かれているドキュメントから必要な部分だけを抽出することです。
四つ目は「スキミング」。ドキュメント全体の要点だけを押さえて読むことを言います。概要を理解するのに役立ちます。タイトルや目次、まとめはもちろん、結論や強調を表す言葉（therefore、summary、actuallyなど。ディスコース・マーカーと呼びます）があれば、その単語の次に大事なことが書かれていることがわかります。
これらのテクニックを意識して読み慣れていけば、仕事の効率が上がり、最新情報から遅れてしまうことも減るでしょう。知らない単語で引っかかるかもしれませんが、同じ単語で何回も引っかかって調べているうちに覚えられるので、気にせずどんどん先に読み進めていくことが大切です。
本書では、ITエンジニアが仕事中によく読む11のドキュメントについて、それぞれを読むうえでのコツを解説しています。ここでは入門として、UI、コミット・メッセージ、APIリファレンス、仕様書の読み方を紹介します。
UI――命令、確認、指示、エラーを読み取る
ソフトウェアの利用時には、多くの英語に遭遇するでしょう。UIのテキストにはボタンやメニューなどの「ラベル」と、確認やエラーなどの「メッセージ」があります。
ラベルはほとんど単語だけで構成され、多くても2、3語です。動詞や名詞が中心ですね。メッセージはラベルよりは長く、文章の形をしています。文の要素が省略されることが多く、慣れていないと意味が掴みにくい場合があります。
AndroidのGoogle Playでは、アカウントにサインインする際、メールアドレスを入力する欄の下に「Need help finding your account?」と書いてあります。これは文頭の「Do you」が省略された形です。簡単な例ですが、訳しにくい文章が現れたら、何らかの語が省略されている可能性を疑いましょう。
また、Windows 10でGitをアンインストールしようとすると、「Are you sure you want to completely remove Git and all of its components?」と訊かれます。人間側の命令に対し、コンピューター側からの確認には疑問文が使われるわけです。ちなみにこのような文章を読むときは、主語と動詞に注目すると読みやすくなります。
UIの英語に関しては短いものがほとんどなので、それほど手間取らないかもしれません。省略されている単語を見落として意味を間違える、ということがないように気をつけましょう。
コミット・メッセージ――主語を省略し、動詞を使って端的に表現
コミット・メッセージはGitHubなどのソースコード・リポジトリーにコミットする際に書くメッセージで、開発者が別の誰かに向けてコミット内容を簡潔に記述します。通常はコマンドラインやWebサイト上で読まれます。
専門的で難しい単語が多く出てきますが、特定のプロジェクト内での用語は限られるうえ、頻出する動詞も「fix、revert、merge」など決まっています。これらの意味を押さえておけば、そこまで読みづらい英語ではありません。
ただし、コミット・メッセージも主語を省略して動詞から書くのが一般的です。「Add」だけでなく「Added」や「Adds」もありうるので、主語が省略されていることは留意しておきます。
コミット・メッセージは他者のやり取りで利用されるものなので、同じプロジェクトにいるメンバーと文脈や文化を共有することが理解の早道です。
APIリファレンス――メソッドは動詞で簡潔に説明
少し読むのに時間がかかるようになってきたかもしれません。APIリファレンスはプログラミング言語の使い方を参照する際に使う資料ですが、全体を読み通す必要はなく、そのとき必要な部分を見つけて目を通すのが肝要です。「スキャニング」の出番ですね。
概要（Summary）と詳細（Detail）が明確に分かれていることが多いので、まずは概要を見ます。コンストラクター、メソッド、プロパティーといった項目が見出しになっている場合もあります。そこで必要な情報が見つかれば、あとは辿って読むだけです。
APIリファレンスで中心となるメソッドの説明では、動詞から始まるテキストで簡潔に済ませることが多いです。「Closes the file.」などがそうです。UI、コミット・メッセージと同様に、語が省略されていることを意識しておいたほうがいいでしょう。
仕様書――目次で全体像を把握し、用語集で誤解を防ぐ
ここまではテキスト自体が短く、読む必要のある部分も少ない（ただし独特の表現がある）事例で解説しました。最後に、ITエンジニアならいろいろな意味で悩まされることもある仕様書の読み方を見ていきましょう。
仕様書はAPIリファレンスと同様に、概要・目次が先にあって詳細が記述されていることがほとんどです。製品やサービスが満たすべき要件、基準をまとめてあるので、曖昧さがないよう義務・禁止・推奨などの表現（特に助動詞）も頻出します。今回上掲したドキュメントはソフトウェア要求仕様書です。
仕様書はきちんと読むことで製品を開発できるようにすることが目的なので、読み手が理解しやすい構造になっています。まずは目次を眺め、全体像を掴みましょう。普通の本を読むときには目次を飛ばす方もいると思いますが、仕様書では目次の把握が欠かせません。
語の特徴としては、先程挙げた助動詞がよく見られます。mustやshouldなど、意味はわかっても英語の中での順位はイメージしづらいのではないでしょうか。最も強いのが「must、shall」です。次に「should」、そして「may」と続きます。「shall」はとりわけ頻出しますが、日常的な英語ではあまり使いません。それほど強い表現だということは覚えておいてください。
また、仕様書には書き手と読み手の間に誤解が生じないよう、言葉の意味や定義を記述した用語集がついていることがあります。「Definitions」という項目や、ドキュメント末尾の「glossary」がそうです。「index」にはあるキーワードがどこに記載されているかがまとめられているので、スキャニングに使えます。
英語をすらすら読めれば楽しい
IT技術用語は日本語でもカタカナ語として定着しているものが多く、語彙を増やすのはそれほど難しくないかもしれません。そのうえでIT分野でよく使われる用語を日本語であっても知っておけば、英語を読み意味を把握する際には役立ちます。
先述したように、本書で紹介するテクニックはある程度の英語力を下敷きにしています。特に語彙は重要です。しかし、IT系の英語ドキュメントでは小説のような巧みな表現は好まれず、端的で簡潔な表現が好まれます（英語とIT英語は異なるとすら言われます）。別のドキュメントを読んでいても同じ単語が何度も登場するでしょうから、新しく覚えるのもそれほど辛くはない……かもしれません。
IT英語が読めるようになれば、その分だけ仕事の効率が上がり、幅も広がるはずです。なにより、英語をすらすら読めれば楽しいんです。本書では他にもニュースや技術ブログ、マニュアルの読み方も解説していますので、ぜひ試してみてください。
