英語を学んできた履歴と現状
自分が何のためにどういうふうに英語を学んできて、現在どうなっているか、ということをなんとなく書きたくなったので書きます。とくに推敲をせずにメモ書きくらいのつもりで書いてます。ご了承ください。
まずは私の職業、英語学習の動機や性格などについて書きます。似たような人には役立つ可能性があります。全然当てはまらない人は読んでもまったく役に立たないかもしれません。
- ソフトウェア技術者
- 英語はソフトウェア技術者、とくに技術オタクとやりとりするために身に着けたい。それ以外はどうでもいい
- 好きなこと、得意なこと、必要に迫られたことはできる。それ以外はまったくできないしやる気もない
では私の約40年の人生でどうやって英語を学んできたか、何がうまくいってを書いておきます。
- ~小学校6年生: 英語学習の機会なし。現在は授業でやるそうだが、私のころは英語の教科が無かった。
- 中学1年生~高校3年生: 授業で習ったことをやっていた。他はとくになし。6年間ずっと苦手意識を持ったまま過ごす。センター試験は200点中76点だったはず。
- 大学B1~M2: コンピュータについての情報を英語で読むことが多くなり、readingについては上達する。興味のある内容だったことと文法が平易だったことが役立った。B4からは研究用に英語論文を読む機会があったので、それも役立った。writing,speaking,listeningは使う機会がなかったのでほぼ成長しなかった。
- 社会人になってから今まで(15年くらい): 必要に迫られて仕事を通じてreading,writing,listening,speaking,全てが成長した。それ以外は色々やってみたが、どれも長続きしなかった
- reading,writing: バグ報告や機能追加のpatch descriptionやその後のやりとりが中心。日によって濃淡あれど、だいたい毎日使っていた。TOEIC向けの勉強や英語学習教材による勉強はどれも長続きしなかった。
- listening,speaking: 仕事の会議、およびカンファレンスでの発表、その時の質疑応答などを通じて鍛えた。どちらも使う機会はそれほど多くはなく、数か月に一度ほど。listeningについてはカンファレンスのセッション動画を通じても学習した。その他英語の映画やドラマを見て学習しようとしたことがあったが、長続きしなかった。
上記のような学習を通じて得た現在の英語力は次のようなものです。
- ソフトウェア技術に関するもの
- reading: マニュアルのようなしっかり書かれた文書ならそこそこ。8割くらいはすらっと読める。文法で苦しむことはそれほどないが、単語がわからないことは多々ある。githubやslackでよくある文法が適当な英語は読むのが辛い。スラングやSFネタとか入ってるとさらに厳しい。
- writing: 日本語で書くのに比べて半分かそれ以下の速度。それなりに通じる文書が書けているはずだが、たまに「なんて書いてあるのかわからなかった」といわれることが依然ある。三単現のsとか冠詞とかは適当になりがち。
- speaking: かなり文法がハチャメチャなものは喋れる、が、けっこう途中で言い直したりと苦労する。また、「こういうことを言いたいの？」と聞き返されて何度か問答をしてやっと通じるということがよくある
- listening: 結構辛い。何度も聞き返すことや、「それはこういう意味ですか」と何度か聞き返してようやく理解ということがよくある。
- それ以外のもの
- 興味がないのでそもそも使う機会が少ないが、ソフトウェア技術に関するものより苦手なのは確か。readingとwritingはソフトウェア技術についてのものより3~5倍ほど大変。リアルタイム性が求められるspeakingとlistening、とくに後者がかなり辛い。日常会話はかなり困難だし、TVや映画は全然ダメ。
- 10年くらい前にTOEICが800点くらいだった。たしかreadingのほうがlisteningよりもだいぶ点が高かったはず。いまはどうかわからないが、readingは昔より高く、listeningは同じかやや低いという数値が出るかなと推測している
いままでの学習履歴を振り返って思ったことは次の通りです。
- 「英語を覚えたい」という目標の設定考え方がそもそも間違っていて、最初から「英語話者の技術オタクとうまくやりとりしたい」にしていればもう少し効率的だったかもしれない。そうすると必要なことがかなり絞られてくる
- 興味がないものを題材に学ぼうとしてもつまらないし効率が悪いしでいいことがない。「映画とかドラマを見るといいよ、必要なら字幕つけたり低速再生したり」と言われたりして何度かやってみたが、そもそも日本語でも映画やドラマを見なくて大して興味がないので辛くてしょうがなかった。で、もうやらないことにした
- 自分の性格に合ったことをやるのが一番
というところでおしまい。これが誰かの何かに役立てば嬉しいです。
人を真似るときに気を付けていること
凄い人、尊敬する人などの真似をしたくなることがあります。IT技術に関係ないところでいうと、ちょっとした仕草や服装、髪型、などなどです。本記事では仕事のやりかたを改善するために私が現在やっていることを書いておきます。
現在わたしの身近には要領がよくて作業効率が高い、かつ、強烈に頭が切れるという人がいます。わたしはこの人に学ぶことが多いので真似をしているのですが、真似ようとしていることは前者だけです。なぜなら要領の良さというのは「全体を俯瞰する」、それをもとに「ゴールにつながるものだけをやる、それ以外はやらない」「優先順位をつける」など、ある程度は訓練によってなんとかなりそうなものという思いがあるからです。これに対してキレッキレの頭脳というのは生まれ持ったものであって、かつ、訓練に変えられるようなものではないと思っているので真似しません。
この考え方については別記事にも書きました。
satoru-takeuchi.hatenablog.com
第二に、身心の作りが違う他人と同じ土俵で勝負しようとするのをやめました。たとえば一日4時間睡眠で平気といったようなショートスリーパー、業務でのプログラミングに疲れたら趣味プログラミングで疲労を回復させるアンデッドモンスターのような人がいるのも否定しませんが、自分ではどうなるかを試してみたところ、残念ながら自分はそうはいかないという認識をしました。その結果、無理なものは無理、自分のハードスペックに合ったことをするのが一番、と思えるようになりました。
こういうことが思えるようにならないと「自分はどうしてできないんだ」「一向に改善しない」と疲弊することになります。かくいう私も過去には疲弊していました。
ここまで述べたことは本記事の読者からするとソフトウェア、あるいはアルゴリズムの改善はできるけれどもハードスペックは変えようがない、という例えをするとしっくりくるかもしれません。いずれにしても、できる人のことを闇雲に全部真似ようとするのではなく、まずは「この人はどこがすごいのか」というのを洗い出した後にわが身を振り返って、これなら真似できそうというものを見つけて楽そうなものから真似すればいいのではないかと思います。
「モモ」を読んだ
少年文庫の本だけれども刺さるのは少年ではなく大人ではないかと思います。大変面白かったです。なかなかお目にかかれない、自分の考え方を変える本の一つでした。
本の内容を具体的に紹介するのはやめておきますが、いつも「時間がない、時間がない」とイライラしながら効率を求めて忙しくしている人に読んでほしい本です。何か思うところがあるのではないでしょうか。わたしはこれを見て「もう少し丁寧に生きよう」、「仕事以外で効率を求めるのは控えよう」と思うようになりました。
休みの日は休めばいい
以下の記事にマージしました。
satoru-takeuchi.hatenablog.com
昔この記事を書いたのを忘れて似たような記事を書いたのと、両者とも似たようなことを書きつつ違うことも言っていたのがその理由です。
「概説 中国史」を読んだ
これまで中国の各時代の歴史についての本をいくつかばらばらに読んできたのですが、その後に、これらが現在の中国にどのようにつながっているのかを知りたくなって買ったのがこの本です。教科書的に淡々とその時々に起きたことを述べていくスタイルなのですが、退屈になることはまったくなく、すらすらと読めました。数十冊にわたるごっついシリーズではなく高々数百ページずつの上下巻というのが飽きっぽいわたしに丁度よかったです。これからまた各時代について深堀りした本を読む気にさせてくれました。そのときもこの本をまた参照することになるでしょう。
趣味でプログラミングをはじめようとするときの様々な誘惑
趣味でプログラミングをはじめようとする人が陥りがちな罠と、それについてのわたしの考え方について書きます。一部については私が実際にひっかかった罠で、それ以外は自分以外の人を見ていて思ったことです。仕事だと話は変わってくるのですが、それについては触れません。
情報量が多い昨今、「さあプログラミングをはじめよう」となっても、目の前には次のような様々な選択肢が待ち受けています。
初心者はこれらのうちのどれを選ぶべきかというところでまず躓いて、まったく先に進めなくなることが多々あります。ただ、このへんは使ってみなければわからない好みの部分が非常に多いので、まずはフィーリングで適当に選んで、合わないものがあれば別のものに乗り換えればいいと思います。なんなら複数を使い分けてもいいんです。
迷いで頭がいっぱいになってしまったら、自分のやりたいことはプログラミングをはじめたいことであってツールを選びたいわけではない、とにかく手を動かしてプログラミングしないと何も始まらない、ということを思い出してもらいたいと思います*1。
参考までに、たとえばわたしは次のような流れで使うツールを選んできました。
- プログラミング言語: なんとなくCがかっこよさそうという理由ではじめて、そのままOSカーネル屋さんになったので使い続ける。日々の作業を楽にするためにbashやらRubyやらを覚えた。Pythonは流行ってたので使ってみようと思ったが音楽性の違いを感じて大して使わないまま、現在は「そこそこ読めるけどあんまり書けない」という状態になっている。あとは仕事でGoを使うようになって、かつ、気に入ったので今も愛用している。
- OS: 最初はWIndowsを使っていたが、Linuxインストールブームの火が残っていた大学4年生のころに「なんとなくかっこよさそう」「すごそう」という理由で使い始めた。いろいろなツールが無償で手に入って便利だったので、そのまま今に至る。WindowsやmacOS上での開発については、やる必要を特に感じていないのでやっていないだけ
- テキストエディタ: Linuxに入門したころ、当時流行っていたemacsとvimの2つのうちのどちらかを選ぼうと根拠の無い決意をして、2つ評価をして上で、より気に入ったemacsを使うようになった。その一方で、vimもrootで作業するときなどに使っている。その後15年ほど経過した去年、.emacsの編集に疲れていたころに「俺は別にエディタの設定をしたいわけでもelispを愛しているわけではないなあ」と気づき、かつ、VSCodeが複雑な設定をしなくてもよくて楽らしいと聞いた。使ってみたら実際その通りだったので、emacsを完全引退して今も使い続けている。
この考え方に異論がある人はいくらでもいるでしょうが、これは「私の意見」なので、とやかく言われる筋合いはありません。みなさんも最初はフィーリング、その後は人の意見を参考にしつつも、あくまで自分の感性を信じて心地よいものに次第に移っていけばいいと思います。
これ以外にも「プログラミングするからには開発を支援するツールをマスターしなければ」と、必死に次のようなものの網羅的な知識を得ようとして疲弊している人をよく見ます。
- gitなどのバージョン管理システム
- CircleCIなどのCIツール
- Redmineなどのバグ管理システム
これらについても、こだわり出すといつまでたってもプログラミングをはじめられないので、まずは小さなプログラムをたくさん書みることをおすすめします。その後に実際に困ったときに使い始めて、かつ、必要なところだけを徐々に覚えていくとよいでしょう。
とくにgitは機能が異常に豊富で、マスターしようなんて思うとかなりキツいですし、そんなことをする必要もありません。実際わたしもgitのコマンドで知っているのはおそらく20個ほどだけですし、それらのオプションについても知らないもののほうが多いです。
上記のツールが必要になるタイミングは典型的には次のようなときでしょう。
- gitなどのバージョン管理システム: ソースコードのどこをどんなふうに変更したかがわからなくなったとき、安定版と開発版を分けたくなった時、複数人で開発をするとき*2。
- CircleCIなどのCIツール: マージ前、リリース前の手動テストが苦痛になったとき
- Redmineなどのバグ管理システム: 複数人で開発するようになったとき。脳内で問題を覚えておくのが苦痛になったとき
いろいろ書きましたが、最後にまとめ。枝葉末節にこだわらず、本来やりたいことをするのを最優先に考えましょう。たのしくプログラミングしましょう！
