今年新卒で入社した、エンジニアのJ.S.です。先日、当ブログでUXに関する海外ブログを紹介しました。エンジニアでも、英語を使う機会があるかと思います。自発的に海外ブログを読むなど、能動的な理由であれ、検索していたらStack Overflowが出てきたなどの受動的な理由であれ、ちょっと英語ができれば便利ですよね。ただ、いきなり英語を勉強しよう思っても、

  • 何から始めればいいかわからない
  • モチベーションがつづかない

といった課題に当たることが多いでしょう。そこで今回は、初心者の方でも簡単に始められるGitHubのPull Requestを使った英語の勉強法を紹介します。

Pull Requestを選んだ理由

短い会話形式であること

Pull Requestは、バグの修正や問題点の改善のために行われるため、ピンポイントの問題にフォーカスしている場合がほとんどです。そのため、ひとつひとつの議論が比較的短く、すぐに読むことができます。また、技術的な単語がある場合がありますが、それ以外は、簡単な英語で書かれています。

相乗効果が期待されること

Pull Requestを読むことで、英語の勉強になるだけでなく、そのリポジトリで現在どんなバグや問題があるかを知ることや、どういった修正が行われたかなど、理解を深めることができます。また、興味のある分野を勉強するほうが、頭に入りやすかったり、継続しやすいというメリットもあるでしょう。

では、実際に、Pull Requestを引用して、読み始めようと思います。今回は、PHPCakePHPのリポジトリのPull Requestから引用させていただきました。

1. 簡単なものから始める

pull_request_1
引用元:https://github.com/php/php-src/pull/498
typoとは、日本語でも使う場合がありますが、綴りミスのことです。grammerは文法のことなので、このタイトルは、「綴りミスと文法ミスの修正」という意味になります。「このくらいわかるよ」という方も多くいらっしゃると思いますが、まずは簡単なものから始めることで、英語を勉強する敷居を低くすることができると思います。

その後のコメントも簡単な英語でシンプルに纏められています。

merged, thanks 「マージしたよ、ありがとう」

この文章も一見、主語がないため、学校の英語とことなり驚かれるかもしれませんが、口語の会話では、主語が省略されることが多いです。

ちなみに、Pull Requestのコメントが、No description provided.となっていると思います。これは、Pull Requestを送った人が説明を付け加えなかったことを意味します。説明がいらないというものは、必然的に、内容が簡単なものになります。

英語に苦手意識を持っている方や、初めてPull Requestを見る方は、こういった、No description Providedと記述されているものや、簡単そうなものから読むとよいでしょう。

2. 単語や文章を分解する

pull_request_2
引用元:https://github.com/cakephp/cakephp/issues/2937

このPull Requestは、意訳すると以下のようになります。
「278行目をコメントアウトを外すと、シンタックスエラーが出るよ」
「ありがとう。これ俺のミスだー」

英語を読むこともなく、文末にコードを見ればセミコロンがないことに気づきますが、文章を読みたいと思います。
Uncommentingが一見難しい単語に見えてしまうかもしれません。しかし「Un/comment/ing」のように分解すると、コメント(comment)を外す(un)ことと連想することができます。

また、文章自体も次のように分解することができます。

Uncommenting / line 278 in the app/Config/core.php/ causes/ a syntax error

さらに、重要な部分だけ残すと、Uncommenting causes a syntax error「コメントアウトを外すとシンタックスエラーが起こる」と訳せます。

このように大枠を理解してから、line 278 in the app/Config/core.php (core.phpの278行目)という細かい情報を、もう一度見ることで、理解が早まります。もっと長い文書だとしても、文や単語を分解して重要な部分に注目することで、理解がしやすくなります。

3.フレーズに触れる

pul_request_3

引用元:https://github.com/cakephp/cakephp/pull/2961

一旦、意訳します。

ovidiupruteanu:
「モデルにschemaNameがセットされてると、TABLE_NAME = ‘schema_name.table_name’を探すようになっている。でも、実際は、TABLE_NAME = ‘table_name’ AND TABLE_SCHEMA = ‘schema_name’を探すべき」

markstory:「反論はある?良い修正だと思うけど。」

jippi:「ユニットテストがないのが気になるなー」

markstory:「こういう場合、テストは難しいなー」

当たり前ですが、Pull Requestは、マージされる場合もされない場合もあります。そのため、マージするかしないかという議論がなされます。ここで着目したいのが、「Any objections to this?」です。objectionは、ここでは反論という意味です。エンジニアだとオブジェクト?と思ってしまうかもしれません。意見を求めるときには便利なフレーズです。

こういったフレーズは、意味を覚えると、英文を理解しやすくなるだけでなく、自分がPull Requestを送る場合など、議論に参加しやすくなります。また、フレーズを知らなかったとしても、知っているフレーズを元に推測することができます。

今回の例だと、springs to mindというフレーズを仮に知らなかったとしても、unit testやmissingという言葉を知っていれば、テストがされていないんだなーと推測することができるでしょう。missing(欠けている)等は、エラーメッセージでよく見ると思います。
error

エラーメッセージを含めフレーズに触れることも英語の習得の近道です。

英語のフレーズは、Qiitaでもいくつか取り上げられていました。
英語コミットコメントに使えるオシャレフレーズ集
英語のコメントや issue で頻出する略語の意味

4.議論に触れる

最後に、少し長めのものを紹介します。(一部抜粋)またtypoですね。
pull_request_4
引用元:https://github.com/php/php-src/pull/395

Pull Requestの内容自体は簡単で、typo fixes(綴り間違い)です。ところが、簡単な綴り間違いで終わらず、議論が続けられます。
pull_request_5

これまでに紹介したポイントを踏まえ、意訳すると以下のように訳することができます。(※わかりやすいように幾つか区切りを入れました)

Whereby /such fixes are nice,/ do you actually run the tests/ after them?/ Last time such fixes came in/ I could count at least 3 testfails./ That’s of course not bad,/ but costs time/ to figure out.

「いい修正だね。だけど、少なくとも3つテストに通ってないよ。実際にテストはやったかい?」

Not yet…/ I spent a half an hour /to guess how I should,/ but I failed.

「実は、まだなんだ。30分掛けたけどどうすればいいかわからない。」
Could you please send me some instructions/url?
「ヒント(指示かURL)を教えてくれないかい?」

さて、細かい解説は割愛しますが、この議論を見ると、特段難しい単語は使用されていないことがわかります。仮に、wherebyやsuchという単語がわからなかったとしても大意を取るのに支障はありません。難しい物を読むよりは、簡単なものをたくさん読んで、英語になれるということをまず目標にすれば良いでしょう。また、目に触れる英語の量を増やすだけでも少しずつ慣れるのではないでしょうか?

まとめ

今回は、Pull Requestを引用いて、いくつかの英語を理解する上でのポイントを紹介しました。Pull Request以外にも、GithubのRead Meであったり、Stack Overflowであったり、エンジニア向けの英語の教材はたくさんあります。あえて、英語を勉強する時間を取らなくとも、仕事や業務で調べることがあった際に、英語のものを読むことで、徐々に英語力を身につける事もできるでしょう。

また、積極的にPull Requestを送ることで、エンジニアとしての成長も期待できると思います!