エンジニアにとっての「大事なのは英語ではない、技術だ」。あるいは「とはいえ英語ができないとスタートラインにも立てない」。英語圏blogのdev.toでそんな議論を見かけた、君ら英語使っとるやないの...というところでその要約。筆者の感想は些末なので末尾に。
How to Get Better at English: Guide For Developers (英語が上手になる方法。開発者のためのガイド) という記事。こんな話で始まる。
I saw a post recently where a developer raised very valid points on why English isn't a skill they should be measured with: My English is not perfect. Why would you hire me?
最近、ある開発者が、なぜ英語は評価されるべきスキルではないのか、という非常に正しい指摘をしている投稿を見た。
"My English is not perfect. Why would you hire me?"
正しい指摘とはこれ。「私の英語は完璧ではありません。なぜ私を雇うのですか?」
要点を抜いてみる。(以下箇条書き部分はおよそ翻訳とサマリ)
- 良い開発者とは?
- 1. アルゴリズム的思考、つまり、各要素が最終結果に至るまでのステップである論理連鎖を用いてソリューションを構築するスキル。
- 2. 学ぶ意欲。プログラミングは、大学を卒業してから一度も本を読んだことがない人のためのものではない。我々、開発者はたくさんの本を読む。少なくとも、そうあるべきだと思う。
- 3. 優れたプログラマーは自分の仕事の価値を理解していなければならない。"自分の仕事の結果は、顧客のビジネスを改善するのに役立つのか?私の仕事の結果は、お客様のビジネスを向上させるのに役立っているのか、私の請求書を支払った人に利益をもたらしているのか。彼らは私のサービスに満足しているだろうか"
- で、気づいたが、完璧な英語というものはない。なぜか?それは、現代のIT業界では本当に重要ではないから。私は、ロシア、ウクライナ、中国、南アフリカなどの素晴らしい開発者をたくさん知っている。彼らは皆、英語のスキルが完璧ではないにもかかわらず、ヒーローのようにコードを書く素晴らしい人たちである。彼らがアメリカのクライアントと仕事をするときは、ほとんどがテキストチャットでコミュニケーションをとっている。私もそうしている。
- テキストチャットは、開発者とそのクライアントを含むすべての人が、議論の重要な瞬間を保存するのに役立つが、一方で、長時間の音声通話をするときには難しい。私の母語には冠詞(aとthe)がないので、時々、冠詞を混同する。また、英語の動詞の形を間違えてしまう。「過去完了」のはずのフレーズを「過去単純」で言ってしまったり(その逆もあり)。
- しかし私は怖くないし、文法を崩すリスクを取ることを恐れたこともない。なぜなら、私はいつも「クライアントは私を完璧に理解している」と思っているからだ。完璧かどうか?はどうでもいい。
- ビジネスにおいて最も重要なことは、お互いに理解し合うこと。英語が下手だからといって、開発者としての資質に問題があるわけではないし、仕事ができなくなるわけでもない。
- なぜ私を雇うのか?もちろん、誰を雇っても構わないし、必ずしも私でなくても構わない。が言いたいのは、プログラミングのスキルセット(いわゆる「ハードスキル」)は、ネイティブのように話せる能力よりもはるかに重要だということ。
翻って "How to Get Better at English: Guide For Developers "
Answer記事。この記事はこんな話で始まる。
好むと好まざるにかかわらず、流暢な英語はプログラマーにとって不可欠なスキルだ。
特に先進国ではほとんどの人が流暢な英語に慣れ親しんでいる。文法が悪いと聞こえが悪く、聞き手の注意は散漫になる。良かれと思ってやったことでも、聞き手は無視しなければならないのだ。
で、こんな例を上げている。
2013年、Facebookは、あるセキュリティ研究者からの深刻な問題のバグレポートを複数回無視した。彼の英語力が低かったため、報告が真剣に受け止められなかったからである。
英語が堪能だと、さまざまなチャンスが広がる。自信を持って人と接することができる。他の人が興味を持つような記事やガイドやツイートを書くことができる。英語が苦手なことは、あなたのキャリアにとってハードルになる可能性があるということ。
幸いなことに、英語が上手になることは、プログラミング言語を学ぶことと大差ない。ただ、練習が必要なだけである。
文法だけではない?
- 英語というスキルについて語るとき、私たちは文法に焦点を当てる。しかし私は、文法はほんの一部に過ぎないと考える。いくつか例を挙げてみよう。
Sentence A: The new Software doesn’t fulfill our requirements.
Sentence B: The new Software doesn’t have the things we need.
- 技術的には、どちらの文章も文法的には正しいが、" fulfill our requirements "は、フォーマルすぎてぎこちない。Bの方がシンプルで、ネイティブスピーカーの言い回しに近い。
Sentence A: I have invariably loved you.
Sentence B: I have always loved you.
- invariablyを辞書で調べると、"in every case or on every occasion; always. "と定義されている。しかし、この言葉は通常、プロセスやモノに適用される(人にはほとんど適用されない)。誤った文脈でこの言葉を使うと、非常に不自然に聞こえてしまう可能性がある。ある単語がどこに当てはまるかを理解するには、時間が必要。
- つまり疑問があるときは、最も簡単な単語を使おうということ。
流暢さの3つの要素
- 英語を流暢に話せるようになるには、3つの面で上達する必要がある。
- 1. 文法を正しく理解する。おそらく、最も重要な部分。人は、不器用な文章には寛容だが、時制や動詞を間違えることにはそれほど寛容ではない。
- 2. 単語とその適切な使用法を知ること。残念ながら、「語彙力とは、たくさんの単語を知っていることだ」というひどい考えを持っている人も多い。しかし良い語彙力とは、単に空想上の単語とその意味を学ぶことではなく、それらをいつ使うべきかを知ること。
- 3. 作文。良い文章を一言で表すとしたら、"エフォートレス "。良い文章とは、読むのが楽で、読む人の心を最も邪魔しないものだ。以下例。後者は簡潔なだけでなく、代名詞の使用が少なく、文脈の切り替えを避けることができるので、はるかに読みやすい。
Macbeth was very ambitious. This led him to wish to become king of Scotland. The witches told him that this wish of his would come true. The king of Scotland at this time was Duncan. Encouraged by his wife, Macbeth murdered Duncan. He was thus enabled to succeed Duncan as king. (55 words.)
マクベスはとても野心的でした。そのため、彼はスコットランドの王になりたいと願っていました。魔女は彼のその願いが叶うことを告げた。この時のスコットランドの王はダンカンでした。マクベスは妻に促されてダンカンを殺害した。こうしてマクベスはダンカンの後を継いで王になることができたのです。(55文字)
Encouraged by his wife, Macbeth achieved his ambition and realized the prediction of the witches by murdering Duncan and becoming king of Scotland in his place. (26 words.)
妻に励まされたマクベスは、ダンカンを殺害し、彼の代わりにスコットランドの王になることで、野望を達成し、魔女の予言を実現した。(26語)
しかし文法書から始めるべきではない
- 文法書は時間の無駄である。あるX動詞の第2形や第3形は何かと聞かれても、過去分詞の説明を求められても、私には何の手がかりもない。
- ルールを暗記して学習するスピーカーはいない。自然に身についていくものである。
- これは、プログラミング言語の学習と大差ない。コードを書かずに構文やAPIを学ぼうとすると、必然的に退屈な作業になる。一貫してコードを書くことで、より良い結果が得られる。
上達するには?
- 魔法の弾丸はない。実践によって学ぶ。
-
何でも読む
- 最も重要なこと。本だけではありません。あらゆるものを読む。記事やエッセーも読む。尊敬するオンラインマガジンを手に入れて、そのコラムを読む。お気に入りのコミュニティ(Hacker NewsやGood subredditsなど)をフォローして、議論やディスカッションを見る。人々がどのようにコミュニケーションをとっているかを見る。すべてが、言葉の使い方や文章の作り方に関する知識を増やしてくれる。
-
ビデオやポッドキャストを見る
- 講演、ドキュメンタリー、ライブの会話、ポッドキャスト、チュートリアルなどを見ると、人々が実際にどのように話しているかを理解するのに役立つ。派手な言葉は使われていない。
-
Google検索する
- 何か困ったことがあったらGoogleで検索する。私は何百もの単語や文法の疑問を、その使い方を検索することで解決した。"have vs had"、"always vs invariably"、"simple vs simplistic "など。
- Grammarlyを使う
-
添削してくれる人を探す
- 訂正されるのは少し恥ずかしい(あるいは腹立たしい)と思うかもしれないが、自分のミスを見つける近道である。
-
定期的に書く
- 書く。書く。書く。ちょっとした意見でも、日記でも、物語でも。自分が想像していたよりもはるかに多くの間違いがあったとしても、気を落とす必要はない、それがあなたを向上させる。
-
賢くならないこと
- 私が見てきた良い文章のほとんどは、斬新な言葉を頻繁に使っていません。シンプルに書く。
- 良くないのは、上達しないと思い込んでしまうこと、批判的なフィードバックを敬遠してしまうこと。
"Good luck!"
感想
文中の文法とニュアンスの違いは本当に、読書量がモノを言いそうです。という点ではソースコードをいかに毎日読むか書くかと変わらないという点は同意する。しかしまあ
- 日本人が日本国内で日本語話者のエンジニアと開発をする。
- 日本人が日本国内で非日本語話者のエンジニアと開発をする。
- 日本人が海外で英語ノンネイティブな非日本語話者のエンジニアと開発をする。
- 日本人が海外で英語ネイティブな非日本語話者のエンジニアと開発をする。
、のケースにもよると思います。1なら公式ドキュメンテーションを読めればいいし、2なら向こうが日本語に寄り添ってくれるし等など。1より4が絶対に優れた製品を作るエンジニアであるということもないと思います。だから多分これ(英語力)も自身のスキルセットのひとつとして選び取るしか無いと思うのですが、どれも完璧にいかないならせめて謙虚でいないといけないなあ、などと、議論を眺めていて思いました。
参考記事
英語の技術文書を早く読むには - Qiita
公用語が英語の組織で、日本人エンジニアがオススメする英語学習お役立ちツール【2022年初版】 | Money Forward Engineers' Blog
以上なにがしか、参考になれば、さいわいです。