天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

技術書を読む時に最近気をつけていること

今日は、最近技術書を読む時に気を付けていることをメモ代わりにまとめてみます。

概要

大まかには、過去に書いた以下の記事の方法を継続して今も本を読んでいます。

aki-m.hatenadiary.com

ただし最近は、技術書に関しては特に、上記に書いた読み方に少し工夫を加えて、読み方が変化しつつあるので、本記事ではそのメモを書いていきます。

最近気をつけていること

メモをscrapboxに取る

元々はmdファイルにまとめていたのですが、最近はscrapboxを使うようにしています。
mdファイルよりも使いやすいなと考えているのは以下の点です。

  • リンクで、曖昧な用語には説明するページを別で切ってそこに飛ぶことができる
  • 本を読むモチベーションになる(本を読むにつれてページが充実してくるので、その充実度が上がる過程を楽しむことができる)
  • タグで、別の本との関連性を表現し、すぐに飛ぶことができる(他の本とのシナジーが生まれやすい)

発生する事象に寄与している要因を意識して読む

読んで実際に現場でも使えるレベルになったものと、読んだけど今一つ活かせる感じがしていない本を比べた時、後者の場合は「Aという操作をするとBという動作になる」といったレベルの知識になっていることに気が付きました。

このレベルだと、本に書いてある例や前提と使いたい場面がマッチした時は役に立つのですが、そうでない場合(大体の場合はこちら)は「何となく考える手がかりは分かるけど、いざ自分の手で何かしようとしても上手くできない」という状態に陥ることが分かりました。
そのため、「Aという操作をするとBという動作になる」レベルに知識が留まっている時は、意図的に「Aという操作をすると、Cという理由でBという動作が起きる」や「D, Eという前提がある時、Aという操作はD, Eの~によってBという動作を引き起こす」という形に変えて文章を読むようにしています。

筆者のコンテキストを探る

本を読む前に、筆者のコンテキストを探るようにしています。具体的には、筆者の経歴を年表にしてまとめたり、他の文献や発表資料をようにしています。
こうすることで、以下のようなメリットを享受できると考えています。

  • 筆者の文章の癖を掴む
  • 筆者の発想の前提背景にある分野を知っておく(挫折した場合は、対象分野でより難度が低い技術書を選ぶのも手ですが、筆者の前提背景になっている別の本や参考資料を読むと挫折から復帰できる可能性があります)
  • 筆者を深く知ることで楽しんで読めるようにする*1

今後の改良点

今後は、本を読むための本を幾つか読んでみたいな、と思っています。
以前の記事に貼った記事のお陰で、幸いにもそこまで労さずに本を読めるようにはなったのですが、人間の理解する仕組みや学ぶ仕組みなどを中心に、体系的な知識というのも少し仕入れたいなと思っています。

個人的には、読書に関してはまだまだ得られる学びを増やす余地はあると思っていて*2、得られる学びを増やすために時間を費やす価値も十分あると思っているので、少しずつ試行錯誤を重ねていきたいと思っています。

*1:自分は知っている人が書いた文章だと楽しく読めるみたいです

*2:最高のレベルとしては、本を読んだら著者と同等の知識を手に入れることができるようになることだと考えているため