英語の技術文書を早く読むにはどうしたらいいでしょうか。

注意: この記事の目的は「技術文書について」「早く大意を読み取る」ことを目的としています。

技術文書でないもの，例えば，小説や詩には当てはまりません。
技術文書を読む場合でも，例えば，「論文を批判的に読むとき」や「扱いが悪いと故障する可能性のあるハードウェアのマニュアルを読むとき」には精読すべきですので，この記事は当てはまりません。

頻出英単語を覚える

もし「英語の技術文書を早く読みたい！」と悩んでいるとしたら，多くの場合，英語の技術文書を読むのに，英単語をほぼ全て辞書を引いている，という状況だったりするのではないでしょうか？

もしそうでしたら，正攻法となる主な対策は，頻出英単語を覚えるということだと思います。

例えば英語で書かれた論文があったとします。聞いたところによると，

70%は頻出英単語トップ1500(だったと思います。うろ覚え)
残り30%のほとんどは専門用語(technical term)

なんだそうです。(要出典)

目標としては，70%の頻出英単語は辞書を引かなくても意味がわかる状態にして，残りの30%だけ辞書を引くという理想的な状態に持っていくように努力をしましょう。

途方もない遠い道のりのように思います？でも，遠そうな道こそが王道なんです。

とはいえ，モチベーションを保つのが難しいと思いますので，英語の技術文書を読むための時間と機会を増やして，根気強く英単語を覚えつつ，でも，以下に述べる方法を使って，要領の良さを手に入れましょう。

英語の技術文書は，全てを読む必要はない！

英語の技術文書を読むときに，先頭から末尾まで，順番に，全て読んでいませんか？

たいていの英語の技術文書は，もっと要領よく，概要をつかむことができるように構造化されているものです。(そうあるべきです。)

以下，英語の技術文書を「読まないで済ませる」方法をご紹介します。

タイトルを読んで，読むべき英文書かどうかを見極める

究極的には，読む必要のない英文書を読まないことが，最速で読むために必要なことです。その最も効果が高い方法は，タイトルだけを読み，あなたが貴重な時間を割いて読むべき英文書なのか，そうでないのかを仕分けることです。

たとえば，膨大な量の英論文などの英語技術文書のタイトルの一覧があるとしましょう。あなたが一番最初にやるべきことは，それぞれのタイトルをざっと読んで，次の3区分に分類することです。

読むべき文書
読むべきか読まなくていいか判別がつかない文書
読む必要がない，もしくは時間があったら読めばいいかな，くらいの文書

次にやるべきことは，状況によって2通りあります。

1 だけ読む
2 だけ読んで仕分けする

この方法で，読むべき英語技術文書が相当絞り込めると思います！

小見出しを読んで，文書全体の構造を把握し，読むべき箇所を絞り込む

たいていの英語の技術文書は，構造化されており，それぞれの構造の先頭に小見出しがついていると思います。

たとえば，Software Engineering の Wikipedia (https://en.wikipedia.org/wiki/Software_engineering) の場合，小見出しだけ拾い上げると，次のような構造になっています(2020年5月22日現在)。

(タイトル): Software Engineering
(タイトル直後に書かれている短い要約): Software engineering is the systematic application of engineering approaches to the development of software. Software engineering is a branch of computing science.
History
Definitions
Fields
- Software requirements
- Software design
- Software development
- Software testing
- Software maintenance
Education
Profession
- Employment
- Certification
- Impact of globalization
Controversy
- Criticism
See also
References
- Citations
- Sources
Further reading
External links

構造は入れ子構造になっています。たとえば，Profession は Employment, Certification, Impact of globalization で構成されています。Profession は全体で，Employment, Certification, Impact of globalization はそれぞれ部分を構成しているはずです。

なので，もし全体の内容がよくわからなかったら(この場合は Profession)，部分を構成する小見出し(ここでは Employment, Certification, Impact of globalization)を読めば類推できます。

構造を把握したら，あなたの現在の目的に合わせて，読むべき箇所を絞り込みます。

たとえば，この英語技術文書を読むべきかどうかを判断するのが目的でしたら，タイトル直後に書かれている短い要約だけ読みます。

もし読むのは既に決めているのでしたら，小見出しを見て，興味があるかどうかで分別し，その中から，あなたが今，一番興味がある箇所から読みます。

もちろん，その箇所を読もうとしたときに，前の箇所で書かれている説明を読まないと理解できないような箇所に遭遇することになると思います。その場合は，そういう場合になってはじめて，構造に戻って読むべき箇所を絞り込みます。

この方法を取り入れるだけで，相当読むべき箇所を絞り込めましたね！

もし，この方法に当てはまらないような英語の技術文書があった場合，どうしても読む必要がある場合を除いて，その英語技術文書は読むに値しないので，思い切って捨ててしまいましょう！あるいはどうしても読む必要がある場合でも，代わりを探しましょう！

ちなみに論文の査読の場合は，この作法ができていない英論文は，構造化されていないことを指摘した上で reject します。

各パラグラフ(段落)の先頭と末尾の文だけを拾い上げ，パラグラフ同士の関連性を導き出すような接続語句を識別し，パラグラフ同士の関係性を把握した上で，読むべき箇所を絞り込む

英語の技術文書の場合，パラグラフ(段落)は，次のような原則で構成します。

先頭もしくは末尾の文が，そのパラグラフを代表する文(主文)となっている。その文だけ読めば，パラグラフ全体の意味がわかるように構成されている。
先頭もしくは末尾の文に，前後の段落との関係性を表すような接続語句が含まれることが多い。

まず最初に後者の，前後の段落との関係性を表すような接続語句を拾い上げます。

(確かそのような典型的な語句を紹介している良質の文献があったのですが，もし思い出したら後で追記します)

日本語で書くと，典型的には次のような感じになっています。

まず第一に，(第1パラグラフの内容)
次に，(第2パラグラフの内容)
あるいは，(第3パラグラフの内容)
最後に，(第4パラグラフの内容)

この場合は，全体の構成としては，次のようになっています。

(1)第1パラグラフ → (2) (第2パラグラフ or 第3パラグラフ) → (3) 第4パラグラフ

こういう要領で，パラグラフ同士の関係性を把握し，全体の構成を構造的にイメージします。 その上で，読むべき箇所を絞り込みます。

パラグラフの主文(パラグラフの先頭か末尾の文)だけを読んで，パラグラフの大意を把握する

前述の通り，英語の技術文書の場合，パラグラフ(段落)は，次のような原則で構成します。

先頭もしくは末尾の文が，そのパラグラフを代表する文(主文)となっている。その文だけ読めば，パラグラフ全体の意味がわかるように構成されている。
先頭もしくは末尾の文に，前後の段落との関係性を表すような接続語句が含まれることが多い。

ここでは前者の性質に着目します。

たとえば，Software Engineering の Wikipedia (https://en.wikipedia.org/wiki/Software_engineering)の Software Development は次のようなパラグラフ1つで構成されています。

Software development, the main activity of software construction: is the combination of programming (aka coding), verification, software testing, and debugging. A Software development process: is the definition, implementation, assessment, measurement, management, change, and improvement of the software life cycle process itself. It heavily uses Software configuration management which is about systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration and code throughout the system life cycle. Modern processes use software versioning.

主文の候補は先頭と末尾の文，すなわち次の2つです。

Software development, the main activity of software construction:[1][25] is the combination of programming (aka coding), verification, software testing, and debugging.
Modern processes use software versioning.

それぞれの文を読んでいきます。この場合は，前者，すなわち先頭の文が主文であることがわかります。

最初は，主文だけ読んで大意を把握します。主文以外の文については，後ほど必要になってから読みます。

文を先頭から構造を読み取っていき，読むべき箇所を絞り込んだ上で，解釈する

たとえば，次の文を読む必要があるとします。

Software development, the main activity of software construction:[1][25] is the combination of programming (aka coding), verification, software testing, and debugging.

文を先頭から構造を読み取っていき，読むべき箇所を絞り込みます。

Software development: これは名詞句なので，主語の候補になりそうだということが読み取れます。
the main activity of software construction:[1][25]: これはカンマ, で区切られた名詞句なので，Software development を言い換えたものである可能性があります。なので，さしあたっては読み飛ばして良さそうです。
is: Be動詞ですので，全体の文型が SVC であることが読み取れます。そうすると，次のことが読み取れます。
- 主語の候補と目した Software development が主語であることが確定します。
- is の直後に来る語句は補語，すなわち Software development と等しい語句である可能性が高いです。
the combination: 補語であり，名詞です。そのことから，次のことが読み取れます。
- software development = the combination 〜です。
- the がついているので，既に出てきた語句であるか，後に続く語句で修飾される特定の物であることを意味します。ここでは，前に何も出てきていないので，後者が該当します。
- したがって，the combination の後に続く語句を読み取る必要があることがわかります。
the combination of programming:
- of は，「ofの前にあるもの(ここでは the combination) がofの後に続くもの(ここでは programming)の一部である」ことを意味します。
- programming は名詞の役割をすることができる単語です。
- したがって，the combination of programming でひとまとまりの語句であることがわかります。
programming (aka coding):
- aka というのは，also known as の略です。すなわち，「...として知られる」という意味の慣用句の省略形です。
- したがって，programming を言い換えると coding であることが読み取れます。
- もし programming の意味がわからなかったとしたら，coding の意味が読み取れれば，代わりをしてくれることがわかります。
- したがって，programming と coding のどちらかさえ意味がわかればOKだということになります。
programming, verification,: カンマ, で区切られているので，programming と verification が対等な関係にありそうだということが読み取れます。なので，このまま，読み進めていきます。
programming, verification, software testing, and debugging.:
- カンマ, で続いて，and で結んでいるので，これらの4つの語句が対等な関係であり，それらが並列している状態であることがわかります。
- 既に programming は名詞の役割だと読み取っていました。
- なので，programming, verification, software testing, debugging はいずれも名詞句であることが読み取れます。

以上を踏まえると，この文は次のように要約することができます。

Software development is the combination of programming, verification, software testing, and debugging.

S(Subject 主語): Software development
V(Verb 動詞): is
C(Complement 補語):
- the combination
- of
- 並列(and)
  - programming
  - verification
  - software testing
  - debugging

そうしたら，この文の大意をつかむことができますね！

まとめ

英語の技術文書を早く読むのに，遠い道のりですが，確実に効くのは次のことです。

頻出英単語を覚える

英語の技術文書は全て読む必要はありません！次の要領で，効果的に読むべき箇所を絞り込んで，大意をつかむことができます。

タイトルを読んで，読むべき英文書かどうかを見極める
小見出しを読んで，文書全体の構造を把握し，読むべき箇所を絞り込む
各パラグラフ(段落)の先頭と末尾の文だけを拾い上げ，パラグラフ同士の関連性を導き出すような接続語句を識別し，パラグラフ同士の関係性を把握した上で，読むべき箇所を絞り込む
パラグラフの主文(パラグラフの先頭か末尾の文)だけを読んで，パラグラフの大意を把握する
文を先頭から構造を読み取っていき，読むべき箇所を絞り込んだ上で，解釈する

こんな風にすれば英語の技術文書を早く読むことができますよ！

次に機会があったら，「英語の論文を早く読む」方法について説明したいと思います。ではまた！

追記: DeepL などの機械翻訳を使う方法と比べてどうなのか？

DeepL の使用について言及するコメントを Twitter でいただきました。

あの DeepL といえど，そこそこ誤訳してくれるというのと，DeepL を使った場合でも，論文全部突っ込んで読むのは，それなりに時間がかかりますので，紹介した方法は DeepL にかけるべき英文を厳選し，かつ誤訳を防ぐ，誤訳に気づきやすくなるための方法だと自負しています。

私が紹介している方法を究めると，何も考えずに DeepL にかけるよりも，技術文書の大意を早く掴めると考えています。

たとえば100ページの英語の技術文書を読むとします。何も考えずDeepLをかけるとしたら，100ページ全部を翻訳にかけて日本語で読みます。ポイントとなるのが，100ページの日本語を読むのがボトルネックになるという点です。しかも翻訳口調なので通常の日本語よりも時間がかかります。

これに対し，私の紹介する方法では，まず小見出しだけピックアップします。100ページにも及ぶ技術文書であればたいてい目次 Contents がありますので，ここを読むことだけに集中します。自分の興味に合わせて読むべき対象を絞り込みます。

ポイントとなるのは，100ページ全部は読まないという点です。最短の場合，1文読んだら用を果たすことができます。私が暗黙に設定しているゴールは，英語の技術文書を読んで，自分にとって必要な情報を引き出すということなのです。

20ページの場合でも，目的によっては，何も考えず全部 DeepL にかけるよりも早く読むことができます。同じロジックです。

例えるならば，DeepL をかける方法はO(n)のアルゴリズムであるのに対し，私の紹介する方法はO(log(n))のアルゴリズムみたいなイメージです。つまり，何も考えずに DeepL をかける方法は，日本語で全て読むことになることから，少なくとも文書の長さに比例した時間がかかることになります。それに対し，私の紹介する方法は，探索的に読むべきフォーカスを絞ってから読むことから，それよりももっと短く読むことができます。