2023年は技術書を読む機会を増やしていく予定です。そこで、『 「技術書」の読書術 』を読んで、技術書の読み方についてTipsを整理しておきたいと思います。なぜなら、本の中でも「技術書」は積読に陥りがちなので、脱積読という点で少しでも「これはいいかも」というものがあれば要点を押さえておきたいと思います。（なお、私は読書が好きですが、読むスピードは亀並みです。）
本書の勧め
読んだ直後ですが、個人的に、この書籍がどのような人にオススメか、お伝えします。
- 技術書への抵抗感をなくしたい方
- 読んでみたものの自分の力になっていないと感じている方
- 効率の良い読み方を知りたい方
- 先輩エンジニアの技術本の選び方を知りたい方
- 電子書籍か紙か選ぶときにモヤモヤしている方
意見が異なる部分も含め、著者の増井さんとIPUSIRONさんの考え方が２人分そのまま書かれています。基本的に、読書術というのは個人差があると思いますので、２人分の考え方を比較しながら読むことができるというのも本書の魅力のうちの一つです。
読書の目的
この本を読んで知りたいことは以下のとおりです。
- 積読に陥らないための工夫
- 紙本か電子書籍かの答え
- 技術本の選び方（オススメ本だけ読むことに弊害はないのか）
- 読む時間の目安
- 読んだあとにした方がいいこと、アウトプット方法
- 技術書への抵抗感の減らし方
- 途中で挫折しない方法
- 読んでみたものの自分の力になっている気がしない、の解決策
- コードがたくさん書かれた技術書の読み方
感想
読んだ上で、なるほどと思った点や、自分の技術書の読み方について整理していきます。
書籍のいいところ
技術的な知識は、インターネット上のあらゆる場所にあらゆる形で公開されていますが、どれも「ポイント」で説明しているに過ぎません。書籍では、そのカテゴリーについて、周辺知識も含めて体系的かつ網羅的に説明されているので、知識を得て視野を広げるという点では、書籍がいいと言えます。ただし、これは技術書を端から端まで読み切る体での話だと思いますので、読み飛ばして知りたい部分だけ読んでいくべきかどうかの話はまた別で。
読書にかける時間
どのくらいで１冊を読むのかは、人それぞれでOKですが好奇心がある期間に読み切った方が良い。
個人的には、好奇心が持続できそうな１日〜３日以内に読み切りたい。
個人的に本を読むのがはやいわけではないので１冊読み終わるまでに結構な時間がかかります。小説とかであればなにも考えずゆっくり読めるのですが、技術書だと違っていて、ゆっくり読んでいるとどこか気持ちが焦ってしまいます。技術の移り変わりは早い、周りの人はもっと早く読んでより多くの技術書を読んでスキルを高めていっている。おそらくこういった気持ちから焦りが生じるのだと思います。
「知りたいこと」にもあげましたが、読む時間の目安について、少し内容がズレますが参考になることが書かれていました。それは「サンクスコスト」を考えること。簡単に言うと書籍代だけで考えるのではなく読書にかける時間についても考えること。これを考えてみると、私は書籍代よりはるかに大きな価値を読む時間として投資していたなと思います。サンクスコストについては、自分のスキル的に難しすぎる本を手にしてしまったときに使う考え方かなと思います。時間をかけて一通り読んでみて、全然分かりませんでした。。。になってしまうと時間がもったいないので、挫折の判断、読むのを一旦やめてみる判断を早めにすることも、サンクスコストについて頭においておけば可能になってくるのかなと思います。
つまり、この「サンクスコストを考える」というのは、自分にあった本を選ぶ上で基準になってくる考え方なのかなと思いました。
１回で読もうとしない
これは、私にとっては「知りたいこと」であげて複数で参考になるものでした。内容としては、３回に分けて読むというものです。
１回目は、本の全体像を理解するために読みます。
目次、まえがき、あとがき、見出し、章や節のタイトルおよび最初と最後の行、太字、箇条書き、図や表に目を通していきます。これをやってみて全く内容のイメージがわかないのであれば、それは今の自分には難しい本だと判断して読むのを後回しにします。これは本屋で書籍を選ぶ段階でやってみてもいいのかもしれません。個人的にはこの１回目の読み方のおかげで技術書への抵抗感がなくなるように感じます。なぜなら、まずはサラッと目を通すだけでいい、難しいと感じたなら読まなくていいという判断できるからそれはそれでいい、全体像が把握できるので読むべき場所が分かり技術書の分厚さに抵抗感がなくなるためです。これを実践するだけでも、技術書の選び方、技術書への抵抗感、途中で挫折しない方法が解決してくるのかなと思います。
なお、１回目の読み方で「章や節のタイトルおよび最初と最後の行」にも目を通すとあったので「それぞれの最初と最後の行を読んでいたら時間かかるし、抵抗感を感じてしまう、サラッとなんてテンションで読めない」と思うかもしれませんが大丈夫です。ここら辺についても工夫できる点が本書に書かれています。私も活字を読むのが遅いので、同じようなことを思っていました。工夫点は、カタカナと漢字と接続詞に目を通していけばOKというものです。ほんとかよと思いましたが本当でした。私は速読術なるものが嫌いなのですが、ここらへんの工夫点は「１回目はサラッと読む」という技術書への抵抗感をなくしてくれるTipsになるので気に入っています。
２回目は、"読む場所"を"体を動かしながら"読みます。
"読む場所"というのは、１回目に読んでみて「ここが読むべき場所かも」という部分です。いまさらの話ではありますが、前述のサンクスコストの話にも関係してきますが技術書やビジネス書を読む際は、目的を明確にしておくのが前提ですので、その目的を達成するためのキーワードが眠っていそうな場所を読めばいいのです。
"体を動かしながら"というのは、コードなどが書かれていれば実際に書いてみてプログラムを動かしてみたり、簡単な図解を作ってみたりするといいと思います。簡単なところだと、付箋やペンなどを使用してマーキングしていくだけでもいいと思います。
ここでは、理解することに注力しましょう。
３回目は、アウトプット用の資料をつくりながら読みます。
この段階では、２回目と同じ部分について、外部への説明が可能になっているかを確かめながら読みます。この読み方をしておくことで、読んだ後の情報発信にもスムーズに進むことができ、かつ理解が足りていない部分にも気づくことが可能です。
複数のプログラミング言語を比較にする
これは、プログラミングを勉強していく上でとても大切だなと思えました。もちろん、スキルがモノを言う世界ですからエンジニアをしていくにあたって多くの言語を扱っていったほうが良いのは知っていました。ですが、「複数の言語を習得する」=「できる仕事を増やす」という考え方をしていた部分が強かった私にとって、「複数の言語を習得する」=「多言語を比較し各々の長所を理解し活用する」という考え方は、とても印象深かったです。読んですぐに、職場の先輩が技術向上の一環でオセロのプログラムを各言語で実装したという話を思い出しました。現状、私は業務で使っている言語や使う可能性がある言語のキャッチアップにとどまっていたので、書籍『達人プログラマー』にもあるとおり、少なくとも１年に１言語を習得していくようにしたいと思います。
電子書籍より紙が好きだけど、どっちでもいい
本書にも書かれている内容ですが、この部分は読む前後で自分の考えは変わりませんでした。書籍でもどっちでもいいスタンスです。個人的にも完全に気分で買っています。表紙が好きだったら紙で買いますし、ネットですぐに読みたかったら電子で買いますし。誰かにどっちがいいか聞かれたときは、交互に買ってみることを勧めます。交互に買ってみて、その人の感覚でこっちの方がいいなって気付いていけばいいと思います。読書の仕方なんて人それぞれ。私は紙の方が好きです。前述の３回に分けて読む方法も、付箋をつかって１回目からがんがんマーキングしていっているので、やりやすいのは紙の書籍だと思っています。
アウトプットってやっぱり大切
私は、アウトプットの重要性も知っていたし、個人ブログも作ってそういう環境も用意していたけど、どこか前向きになれず実行に移せていませんでした。本書で書かれている通り「文章力がないから」と言って自信がなくしているのも、めちぇくちゃ自分だな〜と思いました。ただ、本書ではそういった人の背中を押してくれる内容が書かれています。改めて頑張ってやってみようと思えました。
目的に対する結果
本書を読んだ結果、私の収穫は次の３つです。
- １回目はサラッとでOK。腰を据えて読まない。
- 使っている言語の良いところを理解するためにも複数の言語を学ぶ。
- アウトプットってやっぱり大切。頑張ってやってみよう！
目的についても振り返ってみると次のようになります。
本の内容というより、読んだ直後の私の考えです。本内容にあっていない部分もあります。
- 積読に陥らないための工夫
>>> なってもいいけど時間をかけない。難しかったり好奇心がないなら読まなくていい。 - 紙本か電子書籍かの答え
>>> 今まで通り気分で買うでOK - 技術本の選び方（オススメ本だけ読むことに弊害はないのか）
>>> レベル感を意識。サラッとみて全体像を把握できなければレベル感があっていない等。 - 読む時間の目安
>>> 特にないが、時間がかかっているときはレベル感があっているか再確認する。
>>> 自分の性格上、１日〜３日で読みきった方がいい。 - 読んだあとにした方がいいこと、アウトプット方法
>>> 今まで通り、個人ブログとQiitaでOK。図解を取り入れていきたい。 - 技術書への抵抗感の減らし方
>>> １回目さらっと読み。そこから拾い読み。これだけで読み始めはかなり気楽になる。 - 途中で挫折しない方法
>>> 時間をかけないで読むこと。それが難しいならレベル感が少し高めだから座せるしてOK。
>>> 挫折して読むのをやめてもいいから、その判断を早くする。 - 読んでみたものの自分の力になっている気がしない、の解決策
>>> アウトプットを通して教える機会を作る。そして、レスポンスをもらう。
>>> 「点打ちをたくさんしておくこと。あとでつながるから。」という先輩エンジニアの言葉を思い出そう。 - コードがたくさん書かれた技術書の読み方
>>> 拾い読みの選択が大切。その本を読む目的を明確にして読むべきコードをしっかり選定すること。
>>> その上でコードはしっかり書く。コピペしない。エラーウェルカム。
