第 218 回 TOEIC の結果

そういえばもう一ヶ月くらい前になるけど、第 218 回 TOEIC の結果が返ってきた。

Listening	Reading	Total
430	415	845

結果として前回から100点くらい伸びた。Listening も Reading も前回の TOEIC よりはきちんと理解して解けたところが多かった。理解できてない問題はきちんと分かるようになった。

「ああ、これは間違いなくこの答えだな」と「うわ、今の会話は全然聞き取れなかった…」が、ちゃんと分かるようになった。 まだまだ前者の割合が低く、後者の割合が高い。前回に引き続いて予想以上の結果がでてるなぁと思った。

やったこと

去年の TOEIC から何をやっていたかというと、ひたすらこの本をやってた。毎日30分くらいこれをやり続けた。

どんどん話すための瞬間英作文トレーニング (CD BOOK)

結果を出すためには日々の継続が大事なんだなぁと改めて感じた。特に語学はね。

先週くらいから、これに加えて iknow を始めて少し英語に費やす時間を増やすことができている。なかなか時間の取れない中で、習慣として少しでも英語に費やす時間が増やせたのはだいぶよい。あとは英会話を始めたいけど、どうやって時間を捻出するか…やはり休日の朝か…。

『基礎からしっかり学ぶ C++ の教科書』を読んで

『基礎からしっかり学ぶ C+の教科書』という本を読んだ。

基礎からしっかり学ぶC++の教科書 C++14対応

著者の方に贈っていただいたもので、こういう経験は初めてだ。 記念に読んだ感想を書いておこうと思う。

よくよく考えてみると、自分はこういうちゃんとした入門書を使ってプログラミング言語を学習した経験がほとんどない。 いつもなんとなくその言語を触れるようになって、発展的な書籍を読む、というパターンがほとんど。 だから、友達に「プログラミングができるようになりたいんだけど、オススメの教科書ある？」と聞かれるとけっこう困ってしまう。

そういうわけもあって、入門者にとってこの教科書が分かりやすいのか、という点は評価できない。 その代わり、少なくとも昔 C++ を触ったことがあるエンジニアとしてどう思ったか、という視点で少し書いてみる。

"macOS"

本の冒頭にこんな一文があった。

... Windows だけでなく、macOS やLinux でも本書の内容は試せます。

macOS の表記が正しく "macOS" になっている。 こういう記述があると「この本は信頼できるな〜」と安心して読み進められる。 それに最新の情報が書かれていることも期待できる。

macOS の話はあくまで象徴的な話で、肝心の C++ についてもきちんと書かれてる。 C++14 に対応したコードが掲載されているのはとても助かる。 仕様、コンパイラごとの実装の違いについてもケアされてる。 入門者向けだからといって、妥協された知識を提供されている感じはしない。

細かなことも書かれている一方、きちんと現場で使える話題も載ってる。 ポインタを使ってリンクリストを実装しましょう、なんて現場で使われないような課題はない（最近だと面接で使われること多いので有用な側面もあるけど）。 特にページが割かれているのはライブラリの使い方（コンテナ、文字列、入出力、スレッド）やメモリ管理（スマートポインタ、コピー、参照、ムーブ）など実践的なところ。 バージョン管理やライセンスについて触れられているのもポイントが高い。最近の教科書では普通なのかもしれないけど。

一方、「プログラミングの経験がそれほどなく、C++ も初めて」という読者を想定した場合に説明が細かすぎるかも、と感じるところがある。 自分のようにコンピュータの一般的な知識があり、数年の開発経験に加えて C++ もある程度分かる、という人間だからこそ「ふむふむ」と読めるのでは？と思う箇所もところどころ。

何も知らない学生がこの教科書を与えられたとしてすべてを理解できるのだろうかと、少し不安を覚える。 まあ、すべてを理解しなくてもいいのかもしれないし、学生は何より若いからどんどん吸収していくだろうけど。

C++ と Java

でも一つ書いておきたいのは、この不安の原因はこの教科書では無く、C++ という言語の大きさと複雑性によるところが多いのかもしれない、というところ。 読めば読むほど複雑で大きく冗長な言語だと思えてくる。

C++ の大きさは、後方互換性は守りながら、性能面での妥協をせずに言語の抽象度を上げてきた結果です。 後方互換性はなくてもいい、プログラムの性能は低くてもいい、言語の抽象度は低くてもいい、このいずれかに該当しない方とっては、C++は学ぶに値するすばらしい言語だと思います。

（『はじめに』から）

筆者がこのように述べるように、C++ はとても興味深く、後方互換性があり、（正しく書けば）性能の高い、素晴らしい言語だ。

でも、いつのまにか自分にとっては複雑で重たい言語になってしまった。

以前いた会社でアンケートをしたとき、好きな言語の１位が C++ だった。嫌いな言語の１位は Java だった。 詳細は覚えていないけれど、当時、自分は C++ を書いていたし、きっと C++ に投票したのだろう。

今の会社では、C++ をかけるプログラマは一部だけで、Java は全員書くことができる。 そもそも今の会社では C++ を書く機会がない。自分もいつの間にか Java ばかり書く日々だ。

以前は自分でメモリ管理ができる C++ が好きだった。今はもうそこまでやりたくない。 コピー、参照、ムーブを意識し、ローカルストアとフリーストアを使いこなすプログラミングが自分にできると思えない。

いつの間にか歳をとったんだろう。信頼できる他人に仕事を任せられるのならそうしたい。 GC と JVM がある程度のメモリ管理と効率性を提供してくれる Java の居心地は、そこを積極的に離れるほど悪いものじゃない。

またいつか

それでも、この業界にいれば C++ をやろう（or やらなければならない）という時がくるかもしれない。

それがいつになるか分からないけど、その時、きっとまたこの本を手に取ると思う。C++2x なんてものが出ていればきっと改訂されたこの本が出ていると思うし。

今、もしあなたがそういう状況なら、『基礎から学ぶ C++ の教科書』はとてもおすすめですよ。

2017/08 追記

電子書籍版がないのが唯一の欠点ですね、と書こうと思ってやめてしまったんだけど、どうやら Kindle 版も出たようです。

『ディープワーク』を読んで

ディープワークを読んだ（邦訳のタイトルは『大事なことに集中する』）。

大事なことに集中する―――気が散るものだらけの世界で生産性を最大化する科学的方法

内容は rebuild 175 を聞くと分かるのでそちらで…（あとはぐぐるとか…）

rebuild.fm

この本に影響されて Twitter やFacebook を見る回数をかなり減らした。iPhone にはアプリを入れず、ブラウザで見たときは毎回ログアウト。Facebook は特に見る回数が減ったので良い感じだ。

大事なことに集中する、価値があるものに注力する、というのは『ハイアウトプットマネジメント』のテコ作用の話と同じ話だなぁと感じた（最近、復刊されたので読み直している）。

hjm333.hatenablog.com

ちょっと邦訳の質が悪かったので読める人は原著を読んでもいいかもしれない…。あと、著者のブログもあるので気になる方はチェックしてみては。

calnewport.com

『ファスト＆スロー』を読んで

『ファスト＆スロー』を読んだ。

ファスト＆スロー　（上）

ファスト＆スロー　（下）

上下巻に別れた大作でかなり読み応えがあった。

いろいろなところで、同じ内容が重複して書かれていて冗長に感じたが、『読みたい箇所だけ読めるように』という配慮からくるものなのだろう。

内容が多岐にわたり、かつ、示唆に富んでいたので本当は書きたいことはいろいろある。 けど、全部書くとかなり長くなりそうだ。最も印象的な『経験する自己』と『記憶する自己』についてだけ忘れないように書いておく。

喉元過ぎれば暑さ忘れる

ファスト＆スローでは人間の性質を３つの側面から論じている。

• 速くて直感型の『システム１』と、遅くて熟考型の『システム２』
• 完全に合理的な存在『エコン』と、合理的ではない存在『ヒューマン』
• 日々の出来事を経験する『経験する自己』と、それを記憶し思い出して評価する『記憶する自己』

３つめの『経験する自己』と『記憶する自己』について簡単に説明しよう。

経験する自己は日々の生活を経験する自己である。毎日、朝起き、仕事に行き、帰宅し、ご飯を食べ、ベッドに横になる、という日常を経験する役割を担う。 一方、記憶する自己はそれらの出来事を取捨選択して記憶する。また、後から出来事を思い出し、それを評価する役割を担う。

「喉元過ぎれば暑さ忘れる」という言葉が示すように、私たちは経験する自己を軽視し、記憶する自己を重視している。これは意図的に行われているのではなく人間に備わった性質である。そのため、この性質は根本的に変えることはできない。

その結果、長期間の緩やかな苦しみよりも、短期的な激しい苦しみを避ける傾向にある。経験する痛みの総和は後者の方が少ないにも関わらず、私たちは短期的な激しい痛みをとても嫌がる。

幸福に関しても、毎日の穏やかな少量の幸せよりも、短期的な激しい幸せを追求する。経験する幸福の総和は前者の方が多いにもかかわらず、短期的な幸福を選択しがちである。

人間の人生は一般的に長期であるため、総和を無視し、短期的な絶対量のみを追求するのは合理的ではない。この「合理的ではない」という点は本書のテーマの１つでもある。そう、人間は合理的ではないのだ。

（ちなみに、不合理という言葉はネガティブな印象が強すぎるため使わない、というのが筆者の考えである。経済的な合理性を真として、それで説明できない人間を不合理とするのはあまりに乱暴である、と筆者は主張する）

２つの自己の矛盾

確かに人間は記憶する自己を重視している。私が大学時代に所属していたサークルは練習が厳しく、理不尽な規則があることで有名だった。練習は強制参加で、自分の出場しない試合も応援として参加しなければならない。大学生活という人生で一番自由な時間を辛い経験に消費してなんの意味があるのだろう、と悩んだ。

先輩達は「卒業した時、絶対やってきてよかったと思える」と声を揃えていっていた。確かに、自分も振り返るとそう思っている節がある。最後の大会でサークルが優勝した時の嬉しさは格別だったし、今でもその光景は覚えている。

この本を読んでいて、あれがまさに記憶する自己の重視なんだ、と気づいた。

一方、年収750万円以上では生活の幸福度が上昇しない、という研究結果がある。これは直感に反するように思える。年収７５０万円の人と年収１億円の人が同じ幸福度なのか、と。

この研究での幸福とは『経験する自己』の幸福だ。大富豪も中流家庭も日々の生活はそれほど変わらない。朝起き、ご飯を食べ、夜寝る。これらの点は年収が750万円より上だとしてもそこまで大きな変化はない。

この研究結果を引用し、年収の増加による幸福を否定するような言説を目にする。しかし、この２つの自己にまで言及されていることは少ない。先に書いたようにこれはあくまで『経験する自己』の幸福であり、『記憶する自己』の幸福は明確に異なる。

『記憶する自己』は年収の上昇に伴ってより幸福になる、という研究結果が出ている。年収が10億円あればリゾートで素晴らしい体験を送ることができる。世界的な富豪であれば宇宙にだって行けるだろう。よりよい体験ができ、それらの思い出にふける時、記憶する自己はより幸福になる。

年収の増加によるこのような幸福の否定は、『記憶する自己』の否定でもある。

幸福になるには

人間の性質上、『記憶する自己』を過大評価する傾向は取り消せない。やはり『記憶する自己』は重要であり、年収７５０万円よりも年収10億円の方が幸福であろう。

しかし、『経験する自己』を過小評価しすぎると、日々のクオリティオブライフを下げることになる。私たちは『記憶する自己』を過大評価してしまうのだから、『経験する自己』をもう少しだけ大事にしてもよいのかもしれない。

Communicate!【The Pragmatic Programmer】

エンジニアとしてコミュニケーションは非常に重要だ。

エンジニアはコミュニケーションをとる必要があるし、上手にコミュニケーションできれば得るものも大きい。この章ではよいコミュニケーションを取るための心がけが挙げられている。

• 何が言いたいかを知る
• 相手を知る
• タイミングを選ぶ
• やり方を選ぶ
• 見栄えを良くする
• 相手を巻き込む
• 聞き役になる
• 素早く返答する

これらを意識してコミュニケーションすれば、きっと、素晴らしいコミュニケーションができるだろう。

---

最近、こういうことが書かれた他の本を合わせて読んでいて、コミュニケーションについてはすごく意識している。しかし、いろいろ考えすぎて自分の言いたいことがあまり言えなくなっている気もする。きっと、だんだん上達して慣れていくんだろうけれど、元来持った性質もあると思い、なかなか難しいなぁと感じている。

これで第１章は終わり。特に目新しいことは書いてなかった。あと、説明の仕方が少し回りくどいかな。２章以降も読もうとは思ってるけど、ブログにまとめようかは迷っている…。

Your Knowledge Portfolio【The Pragmatic Programmer】

知識ポートフォリオを構築して適切に管理しよう。 知識ポートフォリオは投資におけるポートフォリオと同じような視点で管理するとよい。各アイテムの間でバランスを取り、リスクの高いアイテムと低いアイテムを組み合わせよう。

ただし、もっとも重要なのは定期的に投資することだ。 定期的に知識に投資することが成功の秘訣だ。

具体的なアクションの一例を挙げる。

• 一年に一つ、新しい言語を学ぶ
• 本を読む。そして、それを習慣付ける
• 勉強会に参加し、ネットワーキングする
• 知識を常に最新に保つ

書籍や Web から得た知識を批判的に考察することも重要だ。 商業主義を甘く見てはいけない。

検索で上位に来るページが、必ずしも正しいとは限らないのだから。

Diversity

この本では、知識ポートフォリオにおける多様性の重要性を説いている。一方、Soft Skills では業界の専門性の重要性を説いていた。

業界の専門性を重視した方が自分をマーケティングしやすいからだ。

「Web の EC からエンタープライズまで手広く 10 年間やってました。」

というエンジニアよりも、

「不動産の法律業に関する IT 部門で 10 年開発してました。」

というエンジニアの方が自分をマーケティングしやすいでしょう、というのがその理由。

専門性を高めると需要は少なくなる一方、自分の価値は高まる。

専門化によって機会を失うことは増えるだろう。しかし、専門性を高めることでしか得られないチャンスが多くあるし、チャンスをものにできる確率が増える、とのこと。

自分は技術の多様性はある方だと思うが、業界の専門性が皆無なのでここはどうにかしないといけないと感じている…。

言語を学ぶ

一年に一度言語を学ぶことはとてもいいことだと思う。でも、同じような言語を学んでいると「学習」という観点からだと効果が少ないように思える。せっかくだから Go とか Swift ばかり触ってないで Prolog とかを触ってみるのがいいと思う。あと、「触ってみましたー」程度だと「何か新しい事をしている」という楽しみは得られる反面、技術的にはあまり得るものがないように思える時もある。

でも、『定期的に』新しいものを触る癖をつけるということがきっと重要で、ぐだぐだ言い訳せずに定期的に新しいものを触る癖をつけるべきだなぁ、と反省した。

Good-Enough Software【The Pragmatic Programmer】

完璧でバグのないソフトウェアはありえない。

だからといって悲観する必要はない。 ユーザーにとって、経営者にとって、そして私たちの心の平穏にとって、充分なクオリティというものが存在する。完璧でなくても充分よければそれでいい。

ユーザーは明日の完璧なソフトウェアよりも今日動く充分よいソフトウェアを欲している。 プログラマはいつプログラミングを終えるべきか常に考えなければならない。 充分よいソフトウェアを、今日ユーザーに提供しよう。

どうせ完璧なソフトウェアは存在しないのだから。

完璧を目指すのは悪か。

「明日の完璧なソフトウェアより、今日動くソフトウェアがほしい。」

この発想はこの本が書かれた当時よりも一般化していると思う。むしろ最近では『明日の充分よいソフトウェアよりも、今日の動くソフトウェア』を提供することが増えているように思える（根拠はない）。

完璧なソフトウェアを目指すこと自体は悪いことではないと思う。完璧を目指していれば、いつの間にか充分よいものになっていることが多い。とりあえず動くものを作っておけばよいというメンタリティで充分よいものはできない、と僕は思う。

ただ、この本が述べているように、「完璧なものになるまでリリースしない」という姿勢は良くない。常に完璧なものを目指しつつ、現実（納期や技術力）に負けて筆を置き、ユーザーの審判を受ける。というのが一番 Pragmatic な姿勢なのではないかと思った。