『エンジニアの知的生産術』の感想

はいどーもおはようございます。
わたくし、自分をエンジニアだと思いこんでいる自称無職のツミオです。
本日は『エンジニアの知的生産術』の感想記事を書いていきたいと思いますよ。

著者について

僕は約一年前の記事で『コーディングを支える技術』について絶賛しました。
その著者さんが書いたのが本書なんですね。
著者さんが同じだとは買った後で気がついたのですが「この方の説明ならスラスラ読めるだろうな」と安心できましたよ。
実際、内容はかなり噛み砕いて説明してくれています。

前半はプログラマ向けの説明が多い

1~2章あたりまではプログラマ向けの説明が非常に多い印象です。
プログラマとして何かしらの活動をしたことがないと、用語の理解が難しいように思います。
ただ中盤以降はプログラマ向けの説明はほぼないため(たまーに出てきますが)、序盤を乗り越えればプログラマ以外の方でも十分に読めるのではないでしょーか。

受動的な学びを超えて

本書の最初の方で「受動的な学びしかできないままだと、周りの人は「この人は言われたとおりに動くことしかできない人だ」と考え、決まりきったやり方を繰り返すタイプのしごとを与えるようになります。自分で学ぶことができない人の考え方を変えるのは難しいからです」と書かれています。
これは本当にその通りだと思います。
僕も意識していろいろな分野に手を出しており、学び続けることは大切だなあと実感しています。
ただ僕はこんな体たらくですから、今すぐ役立つ知識を学んでいるというよりは、単に興味が出ること、面白そうだと思ったことを学んでいます。
それがお金に繋がるかどうかは微妙なのが玉に瑕……。

共通部分を学んでいるだけという罠

「プログラミングの言語には共通部分が多いから、一つしっかり学べばあとは軽く学ぶだけでOK」みたいな言説はよく見かけますよね。
本書はこれを真っ向から否定していますが、僕は「JavaScriptとC#に関してはそこそこ正しい」と思っています。共通する考え方、書き方はかなりの部分を占めています。
ただ、本書でも指摘されているようにそれは「今までに学んだ言語と共通部分の多い言語が習得できるだけ」「あなたが新しい分野にチャレンジしていないから」「あなたは新しい概念をほとんど学んでいません。効率良くたくさん学んだつもりになって、実際はあまり新しいことを学んでいない」だけなのかもしれません。
僕も肝に銘じておきたいと思いますよ。
最近だとRxの勉強をしたり、DIコンテナを使ってみたりしています。

タスクを一つに絞る

やる気が出ない原因ってよくわからないことが多いですよね。
本書では「タスクを一つに絞れていない」ことが原因の一つだと指摘しています。
僕もこれは思い当たる節があります。
trelloでタスクを書き出したとき、一つのタスクが大きいと「で、結局どれからやればいいんだ?」と思ってしまうことが多々ありました。
これは「タスクが一つに見えるようで、実際には複数のタスクを無理やり一つにまとめている」だけに過ぎません。
最近は一つのタスクを小さく小さくするようにしているので、以前よりも「今何を片付けるべきか」が明確になってきました。

思い出そうとすると自信がなくなる

普通勉強をしたあとって、時間をおいて確認(復習)しますよね。
復習すると「自分があまり思い出せないという事実を直視し、そのことによって自信をなくした」という実験結果があるそうです。
これは驚きました。
ただ確かに自分の経験を引っ張ってみても、怖くて復習しなかったことが何度かあるなあとは思いましたw
ですがもちろん復習した方が記憶の定着率はよいです。
復習しない人は自信に満ちつつも成績が悪く、復習する人は自信があまりないわりには実際の成績がよいのですね。
自信を喪失することはよいことだと思って、これからもガンガン復習していこうと思いましたよ。
会う人会う人に「もっと自信もっていいと思いますよ。何でそんなに自信がないのかよくわからない」みたいに言われるので、もう少しポジティブにいきましょうかね……。

KJ法の紹介

有名なやつなので、KJ法という言葉くらいは聞いた方もいるのではないでしょーか。
それについても長々と説明されています。
もちろん著者の方オリジナルのやり方も紹介されていますが、僕はあんまりこの部分は興味出ませんでした。

ボトムアップでグループ編成

本書の中で「ボトムアップでグループ編成すること」というやり方が紹介されていました。
例えば動物を分類するとき、最初から「これは鳥類」「これは爬虫類」などと分類するのではなく、個別の動物を見て「こういう動物を鳥類と分類しよう」と考えましょうね、というやつです。
これはゲーム制作のフォルダわけに応用できるなと思いました。
もちろんゲーム制作はどのようなファイルが出てくるかある程度予想できる部分もあるので、そこは最初に作っておき(例えばTexturesフォルダとScriptsフォルダなんかは絶対用意しますよね)、細かいフォルダわけは実際の制作過程を見ながら作っていく、という感じです。
クラス設計ができたあたりでフォルダ作るのがいいのかなあなんて思いました。もう少し実践してみて、良い方法を探っていきたいですね。

知識の総量だけではない

知識の総量は多ければ多いほどいいと思います。
ですが、Aという分野について博識な人が、Bという分野についても博識とは限りません。
これは当たり前ですよね。僕の周りのプログラマの人も、プログラミングの特定の領域については僕なんかよりも深い知識を持っている方ばかりですが、例えば文学の知識では僕の方がおそらくは深い知識を持っているでしょう。
例えば直木賞と芥川賞の区別がつく人すら多分ほとんどいないと思います(一応書き添えておくと、それが悪いと言っているわけではないです。ただの例です)。
ですが僕も文学を専門に修めている人よりは文学についての知識の総量は少ないでしょう。
このとき、何かの拍子に文学の知識とプログラムの知識の両方が必要になったとします。するとプログラムの知識の総量と、文学の知識の総量はそれぞれプロ中のプロよりは少ないはずの僕が、二人の専門家の架け橋になれるかもしれません。
そういう生き方もあるのだなあと勉強になりました(ただ個人的なことを言わせてもらうと、どっちか一つの専門を極めた方がやっぱりかっけぇよなぁとは思いますw)。

終わりに

最近はゴリゴリのプログラミング本ばかり読んでいたので、軽めの本を一冊読みたいなと思って本書を購入しました。
実際、脳みそを空っぽにして読めました。

次に読む本は『Game Programming Patterns』です。
これはずっと前から「再読したい」と思っていた本なので今から楽しみですね。

ほなそんな感じでまた。

フォローする