技術者が1~3年目で成長するかは自習するかに依存してる。業務とは別に勉強する方法を叩き込めば誰でもそれなりに出来るようになる。 そんなわけで僕の所属している会社では年に5冊指定した本を読ませてレポートを書かせている*1。
なぜレポートを書かせるか
僕の所属している会社が採るような大学生は自習しない。分からないことや知りたいことがあっても本を買わない。業務をやるうちに実地で学べることはあるのだけど、実際に自分がやっていることが世間でどれくらいの位置づけなのか知っておくとなお良い。理想的な手法が使えているのか、それとも現場に合わせて翻訳して使っているのか。本に書いてあることと一致していれば普遍的なことなので覚えておけばいいし、書いていないことをやっているなら、下手をうっているか、現場に合わせた調整をしたかどっちか。そういうことを知っておくと違うプロジェクトに移ったときに同じ名前でちょっと違うことをやっても対応できる。それが経験なのだ。座学だけではわからないが座学がなくてはわからない。そんなわけで技術者は本を読んだ方が良い。ひと月しか使わない技術なら入門書一冊買って流し読めばいいいし、一年以上使う技術なら三冊ぐらい買ってつまみ食いすると色々な流派があることが分かってよい。
若いやつはどういうわけか本を読まない。以前はそれがなんなのかよくわからなかったが、どうやら本の読み方を知らないらしい。自習の仕方を知らないのだ。そこで本を読ませたうえでレポートにまとめさせることにした*2。
レポートの内容
どういう意図をもってレポートの構成決めたのか説明しよう。レポートの構成は次の通り
- 概要（著作、著者、著者経歴）
- 要約(150文字)
- 面白かった章とその理由(400文字)
- 理解できなかった章とその理由(200文字)
- 仕事に活かせそうな知識、活かせそうな状況と活かし方(400文字)
最初に種明かしをすると、これは読書感想文の書き方。章立てをテンプレにしただけ*3。
概要と要約
要約は罠だ。ペーペーが10時間程度で本を要約することは不可能だ。実際のレポートに書かれているのはAmazonの内容紹介のコピペだ。だがそれでいい。これと概要を合わせると本のポジションがわかる。そうすると本を読むときの迷いが減って読むのが楽になるなる。デザイナーの人が書いているからプログラマの気持ちは分かっていないとか、初心者むけだから多少のごまかしがふくまれているとか、ゲーム屋さんが作っているから業務屋さんとは視点が違うとか。「この本はなんであるか？」を意識して読むのは大事だ。
面白かった章とその理由
「面白かった」は主観だ。主観で書けよって意味である。本の説明をしてもらいたいんじゃなくて、どこに興味を持ったか書いてほしい。人によってどの章を取り上げるかはまちまちだ。個性が出るのでレポートを読んでいて面白い。
本を読むのは主観なのだ、全然客観じゃない。だけどいつの間にか同じ本を読んだら感じる主観は一致してないとおかしいって思いこむ。「このときの作者の気持ちを答えなさい」って設問に適応してきたからだけど、それを捨てさせるために「面白かった」ことを聞いている。
理解できなかった章とその理由
本を「理解できなかった」は当たり前なのだ。本に書いてあることを100%理解するのは、参考文献を一通り読んでもたどり着けるかどうか分からない領域だ。それに本の書き方がクソだから理解できないということもある。「理解できなかった」内容を別の本で読んでみたら簡単にわかった、なんてことはよくある。「分からない」と言うのは恥ずかしいのだけど、自分が何を分かっていないか把握しないと次に読む本は選べない。恐れず向きえあるように「理解できなかった」ことを聞いている*4。
仕事に活かせそうな知識、活かせそうな状況と活かし方
具体的に目的を持てということだ。技術書を読むときは目的を持って読んだ方が効率よく読める。「○○について知ろう」とか「○○って書いてあるはずだから確かめる」とかがよい。目的があれば、目的以外はわからなくても諦めがつく。目的がないと漫然と全体を読んでなんとなくわからないという感想を抱いて本が苦手になってしまう。知りたいときに知りたいことが分かれば十分。残りの部分は必要になった時に改めて読めば、それでよろしい。
読ませている本
以前のエントリで挙げているので割愛。
以上だ。よく学びよく遊べ、腕の良い技術者に成れ。
蛇足
僕は技術書の読み方をフォトリーディングの本で学んだ。けど、こういう考え方になるにはこの本だけでは足りないと思う。それでも参考に上げておく。
![[新版]あなたもいままでの10倍速く本が読める](http://ecx.images-amazon.com/images/I/51tddy2sm0L._SL300_.jpg)
