一章

書店で本を探すコツ

短時間で本の難易度や内容を把握するには、はじめにや前書きの部分を読んでみる。ここには著者がその本に込めた想いや読者ターゲット、書籍の概要などが書かれている。

重要なのはこの時点で自分が知りたい情報なのかを知ることです。

読者レベルを想定しているかどうか

タイトルが『C言語入門』とあっても、これが「ほかのプログラミング言語を学んだ人のためのC言語の入門書」ということがある。こうなると、そもそも「プログラミングとは何か」、「変数とは」、「関数とは」という説明は簡素に書かれているため、入門書なのに理解できず挫折してしまう。

C言語を学んだことがないけど、他の言語の基礎なら分かる初心者
ぷろぐらみんぐ？おいしいの？な初心者

言葉の上では同じ初心者だが両者は大きく異なります。
事前にどういった層を対象にした本なのか調査しておくことで、ギャップを防ぐことができます。

全く違うジャンルの本を読む

技術書を読むような技術者は世の中全体では圧倒的に少数であり、ITと関係しない仕事をしている多くの人は、専門的な知識なしにPCやスマホを使っています。そのような人たちがどのようなところで困っているのか、何を求めているのか、ということを知ると、それが自分の仕事に役立つことがあります。そして、このような雑誌を眺めていると、世の中のトレンドに気づくことにもつながります。

技術書を読むような技術者は全体で見たら少数でしかないため、世の中の課題やトレンドを知るためにも全くジャンル本を一度読んでみましょう。

レビューや書籍は「書いている人」を見る

一方で、個人ブログの書評は役に立つことが多いものです。特に、実務に関わっているITエンジニアのブログで、ときどき書評を書いている人がいます。このような場合、その人の経験や興味もあわせて読めるため、本の難易度なども想像できます。

同じ技術書でも実務歴や経験年数によって書籍の難易度や本人の理解が大きく異なるので、ブログであればレビューしている人のプロフィールなどで経歴が記載してあれば一読してみましょう。

図書館は期限があるから積読になりにくい

図書館を使う別のタイプのメリットとして個人的に感じるのは、「期限」の重要性です。夏休みの宿題ではありませんが、期限が決められていないとダラダラと過ごしてしまい、最後に焦ってしまう人は少なくありません。

いわゆる締切効果が発生するため「あとで読めばいいや」とはなりにくいです。

期限までに返さなければいけない締め切り効果と、せっかく借りたんだからといったサンクコストバイアスのような状況を利用し集中して読むことが理論上できると思います。

私も夏休みの宿題は最終日にやっていたのでなんとなく理解できる。

二章

良書を選び続けることは不可能

良書は基本的に多くの人から支持されているものを一般的に示します。
例をあげるとAmazonのレビューや本屋大賞などでしょうか。
時間に追われている身からすればできる限り良書だけを読みたいはずです。

しかし良書だけを読み続けるのは不可能な理由が2つ存在すると本書では語っています。

①一般に悪書・良書といわれている本が、あなたにとってもそうとは限らない　他人が悪書・良書と判断しても、あなたにそれが当てはまるとは断言できません。

これは上記の初心者本の話に近いかもしれません。
技術書であれば本人の知識量によりますし、小説であれば好みの作風などで捉え方が変化します。

②悪書との出会いは避けられない　この世にはとても数え切れないほどの技術書が存在します。Googleの調査によると世界には1億3000万冊の本が存在すると推定されています。読書を続けていけば、あなたにとっての悪書（あるいは相性の悪い本）との出会いから逃れられません。多読であればなおさらです。

毎日200冊の新刊が出ると言われる世の中で、多読をしているとどうしても悪書にはひっかかります。
実際に悪書をひいてしまった場合や、今の自分には合わないと判断した場合は損切りや流し読みをするのが適切です。
無駄な時間を過ごすのであれば、さっさと損切りして次の本を探しにいきましょう。

レベル感のあった本を選ぶ

技術の習得という観点でいえば、自分のスキルから見て少し難しい本であれば効果的に学習できます。たとえば「半分ぐらいは知らないが、読めばなんとかなりそう」、「2割ぐらいはすごく難しそう」といった印象を受ければ、ちょうどよいレベルといえるでしょう。

最初は分かるけど、途中に理解できない部分があれば、一度飛ばしてざっくりと読んだ後に分からなかった箇所を復習します。

現在読んでいる本では少ししか解説していなくても、他の本では詳しく解説されていることも多いので、個別で調べてみることが重要です。

『３』の発想、一つのテーマで３冊の本を読む（入門書、専門書、逆引き）

『「3」の発想』（芳沢光雄著）という本がある。

「2」の発想の場合、積み木でいえば、Aが倒れかかってくればBも倒れてしまう。接し合う歯車でいえば、Aが回ればBも回る、ということである。Aの運動が、Bに影響する。2つの関係だから、その先に思考が及ぶことはない。AとBの完結した世界である。　一方、「3」の発想を考えてみると、積み木でいえば、3つ存在することである。まず、Aが倒れかかってくればBも倒れる。Bが倒れれば、次にあるCも倒れてしまう。ドミノ倒しの最少、「A→B→C」の連鎖である。「A→B」となり、「B→C」となれば、多分「C→D」と人は考える。完結しない世界、連鎖する世界、である。

これらは2つではその間の関係しか見えないけど、3つ考えればそこから先に発想が広がっていくことを解説しています。

自分の仕事に関係のない技術であれば、とりあえず入門書だけ読む人は多いでしょう。自分の仕事に直結する内容であっても、ある入門書を読んで、次に専門書を読む、という人は多いかもしれません。これは順番としては正しいのかもしれませんが、ここで終わってしまうと、思考がそこで止まってしまう可能性があります。
（中略）
実務でどうやってその技術を使おうか、と考えたときに、事例が欲しい場合がよくあります。　このような場合、「逆引き」と呼ばれる本が役に立ちます。本の場合、「逆引き」というと、目的からその実現方法を紹介した内容であることが一般的です。つまり、多くの解説書が技術を解説して、その技術を使って様々な応用を考えるのに対し、逆引きの場合は応用の事例が先に示されて、それをどうやって実現するのか解説しているのです。

技術は習得しても実務や個人開発等で実装しなくてはいけないいので、実例を知るためにも逆引きが有効なことを知ることができた。

入門書を3冊見比べてみる

仮にPythonを学んだ人がJavaの入門書を3冊読んだする。

そうしたときに3冊に共通して書いてあることが大事な要素だと判断できるでしょう。
これは1冊しか読まなかった場合には絶対に判断できないことです。

私もジャンルは違いますが投資の本を3~4冊読んで「長期のインデックス投資」がどの本にも書いてあったので、いちばん重要なことなんだろうなと理解することができました。

デメリットをあげるとすれば新品で買う場合、技術書であればどうしてもお金がかかるのでメルカリや図書館、Kindleの割引やキャッシュバック時に購入するのが良いでしょう。

３つの視点で考える

本でも同じで、「この本を読んでも役に立たない」という感想を見かけることがありますが、それが役に立つか、仕事に直結するか、ということには関係なく、興味があることから手をつければいいのではないでしょうか。仕事として必要だから、という理由だけでなく、将来に何か役立つかもしれないから勉強する、遊びとして楽しんでいるうちに自然と身につく、いずれも選択肢にあるといいな、と思っています。

役に立つかどうかは分からないけど、自分が興味を持てたかどうかで判断し勉強してみる。
意外と役に立たないと思っていたことが、思わぬタイミングで役立つときがあります。

私自身24年しか生きていませんが、この短さでもあったので興味を持った分野は積極的に触れてみると良いと思います。

紙の本ではなく電子書籍を利用したほうがいいときの例

検索を使いたいもの（固定レイアウトは除く）
漫画、小説
雑誌

読書にかける時間を時給換算し、サンクコストの考え方を取り入れる

さきほども少し触れましたが、今読んでいる本はあまり面白くない、または難易度が高いと感じたときにダラダラ読むのではなく、早めに損切りをしましょう。
技術書の場合は単純に自分のレベルが追いついていないことがほとんどだと思うので、一時的に手放すか本棚にしまっておきましょう。

その本をよむ目的（ゴール）を決める

私がこの本を読むにあたっての目的は以下の通りです。

技術書や本の読み方を知る
アウトプットの仕方を知る
アウトプットを継続できる仕組みを知る
これらを踏まえて実際にアウトプットをしてみる（今書いているように）

買う目的を前もって決めておき、それらの目的が達成できただけでも良しとしましょう。

本を読む時の読み方について

1度目は流し読みをする

これは新聞の見出しを読むように、賞や節、タイトルと最初の数行をざっと眺めます。

2度目は手を動かしながら読む

技術書であればサンプルコードなどを実際に手を動かしながら読んでいきましょう。
読むだけではやはり頭に定着せず、やってみて思わすエラーに遭遇するかもしれませんがそれも良い体験です。

3度目はノートにまとめながら読む

実際に本の内容を試したあとはそれを記録に残します。
取り掛かる前に、その本で注目したいポイントを自分で整理しておくことで、以下のようなメリットがあります。

どんな箇所で詰まったのか
それらをどうやって解決したのか

上記のような出来事がもう一度発生した際に、解決するまでの時間を短縮できます。
このときに実際に手を動かしてみて「私ならこうするだろう」といった自分の意見も添えておくと視野が広がってきます。

プログラミングは目的ではなく手段

これは実体験ですが、やはり作りたいものをイメージしてから本を読む方が効率が良いです。

基礎の基礎は学んでおくべきだと思いますが、それ以降はゴールから逆算してどういった内容を学ぶべきなのか書き出していくことで、モチベーションの低下を防ぐことができると思います。

その時点で使わないものを学習しても脳のメモリを割いても忘れてしまうだけなので、「こんなのあるのか～～」程度に読み飛ばしましょう。

複数のプログラミング言語を比べながら読む

私の場合は最初に触った言語がPythonだったので、Javaの基礎を学んだときめちゃくちゃお堅い言語だなと感じました。
しかしPythonで型定義しなかったことによって何度もエラーを吐いたことがありました。

Javaでは型定義が必須なため、Pythonしか学んでいなかったらその重要性を知ることができなかったと思います。(Pythonにも型定義はありますが当時は知らなかった)

フローチャートを描いて可視化する

実際にコードを書くときにフローチャートで可視化することは以下のようなメリットがあります。

複雑な処理を可視化できること
抜けや漏れがなくなること
頭の中を整理できること

動くものをつくる

実務であれば例外ですが、個人の勉強など学習段階であればとにかく動くものを作りましょう。
どこかの国のすごい人も「完璧よりまず終わらせろ」といったことを言っていた気がします。そのためこの記事もまとめきれてはいませんが投稿しています。
動かしてから改良していけば良いのです。

積読の解消法

常に本を持ち歩き、いつでも読める状態にしましょう。
今ならスマホ一つで本を読むことができるいい時代でなので、手ぶらでも読書できます。

そして通勤など毎日決まった時間はスマホをいじらないなどルールを決めましょう。
少し脱線しますが、私は片道30分の電車通勤で以下のようなルールを課しています。

行き

SNSは見ない
本を読む
動画を見るなら学びのあるものだけに限定する

帰り

SNSは見ない
本を読む、またはアニメを見る

帰りは仕事で脳が疲労している状態なので、アニメを追加しています。

私は万人受けしているYouTuberを殆ど見ていないので、アニメの部分は「好きなチャンネルの動画を一本見る」といった風に変えるのも良いとおもいます。

重要なのは動画を見るにしても、誰の動画を見るのか具体的にすることです。
でないとYouTube Shortのような無限時間回収マシーンの虜になってしまいます。

過去に学び終えた本を再読する

再読には以下のようなメリットがあります。

以前の読書では見落としていた箇所を発見できる
既知の情報を頭で整理し直すことで、理解を深めたり新たな気づきを得ることができる

技術書の場合、当時分からなかった部分も経験や時間を積んだあとであれば理解できるかと思います。

読書記録をつける

本のタイトル、開始日、読了日、躓いたところや分からなかった部分あたりをメモします。
個人的に記録は一番大事です。
私は勉強日誌というのを昨年からつけていますが、日別や週ごとに勉強時間の差異を確認できて重宝しています。

記述内容としては以下のとおりです。

勉強内容（具体的に）
勉強した内容の記述（つまづいた箇所や気づき）
一言コメント（本日の勉強の感想）

これらを毎日つけるようにしています。
最低限のルールだけ敷いてあまり厳しくはしないのが継続するコツです。
一言コメントではそのひの気分や、なぜ目標勉強時間より多くできた（少なかった）のか記述します。

場所を問わない

積読の解消法でもふれましたが、基本的にいつでも本を読めるように持ち歩いておくほうがよいです。

電子書籍で全端末同期しておく
カバンには常になにかしらの本を入れておく

単純接触効果を利用して読む回数を増やしていきましょう。

媒体を問わない

紙や電子書籍だけではなく、YouTube、オーディオブックなどの音声コンテンツも利用していきましょう。
私はオーディオブックを使ったことがないので、気になる本が対応していたら試してみようと思います。

一冊90分で読む時間制限読書法

時間制限読書法とは定めた時間内に一冊を読了することを目標にすることです。
この90分というのは人間がもつ集中力の持続時間を基準に考えられているため、難易度によっては半分の45分でも良いと思います。
時間制限読書法では以下のようなメリットがあります。

集中して読書ができる

読書の質が向上し、締め切り効果で誘惑からも身を守ることができます。

悪所のリスクを軽減できる

悪所なのに時間をかけてしまうことも防ぐことができます。
良書なのに短い時間で読んでしまったらどうするの？？となりますが、もう一度読めば良いと思います。
大事なのは無駄な時間を浪費しないことです。

パレートの法則を用いる

本のジャンルによって向いている読書法は変わっていきます。

技術書を例に挙げると、知識を吸収するといった目的があるのでどんな読み方でもOKなのです。
パレートの法則はいわゆる80:20の法則とも言われており、本で当てはめるとすると全体のうち20％で本の要点が80％まとめられているとも解釈できます。
実際にこの20％を見極めるのが困難ですが、一つの参考要素として片隅に入れておきましょう。

電子書籍のメモやノートを取る

私はKindleを主に利用しているので、使い分け方法などを紹介します。

固定長レイアウト（ハイライトが使えないもの）

スクショしてPDFにしておきGood Notesなどで直接書き込めるようにするのがおすすめです。
スクショするときはPC版のKindleで連続してスクショできるようなコードを走らせています。
またこちらの方法で取得したPDFを他の人に譲渡するのは著作権の問題に関わるので避けましょう。

リフロー形式（一般的な形式）

ハイライト機能を用いてそのときの感情やメモに利用しています。

読書記録を用いる

先述しましたが1番重要な箇所です。理由は2つあります。

進捗を数値化できる

積読や読書中、読了済みが明確になります。読書の進捗次第では

この本が読みやすかった理由はなにか
逆に読みにくかった、やめてしまった理由はなにか

これらを明確にすることができ、今後の本選びの参考になるからです。

過去を振り返りやすい

人は忘れる生き物です。
また振り返りの意味でもこんな技術や本に関心を持っていたんだなと一目でわかります。

三章

アウトプットは必要不可欠

同じ本を読んでいても人によって解釈の違いが生まれ、本の内容を誤って解釈している可能性も考えられます。
アウトプットをし、お互いに考えや気づきを得ることでモチベーションの向上や知識を深めることができます。

ブログを書く（技術記事を書く）

ブログや技術記事を書くことで頭を整理することができ、過去の自分がどのようなことを考えていたのか振り返ることができます。

ここで重要なのはインプットが足りない！といって書かないことです。

インプットが足りない
なら本などを読んでみよう
分からないことが多い。。。
もうちょっと勉強しよう！
- インプットが足りない。。。（以下省略）

このようなループから解消することができず、いつまでたっても文章を書けるようにならないためです。

そのため先ほどのループを改善するとしたら、

インプットが足りない
なら本などを読んでみよう
分からないことが多い。。。
とりあえずアウトプットしよう

こうすることで不足している部分や、学んでおきたい箇所が明確になり次の目標も立てやすくなります。

本を読むときは自分ならではの視点をもつ

本の内容を全て鵜呑みにするのではなく、自分ならこう考えるといった独自の考えを意識するのが大切です。

仮に読みにくい本があったら、なぜこの本は読みづらいのか、どうすれば読みやすくなるだろうかといった自分なりの視点を持つことです。

大事なのは「自分ならこう考える」のように考えながら読むことで理解が深まります。

アウトプットの結果を気にしない

技術記事を例にすると、結果としてめちゃくちゃなものを書いてしまっても気にしないことです。
本当に誤っていたらご指摘を受けるだけです。
そのため一種の楽観主義が役に立ちます。

レビューを鵜呑みにしない

全く見ないのも問題ですが、レビューには以下のような傾向があります。

そもそもレビューをする人はあまり多くない
- レビューする人自身、それが習慣になっている
良いレビューよりも悪いレビューの方が投稿されやすい
本人の認識より難易度が違うからといって悪いレビューをする人もいる

大学の数学科を出ている人が数学の基礎本をよんで簡単すぎる！というのと同じです。
先述しましたが、基礎本でもどういった人を対象にした基礎本なのかを見極める必要があります。
レビューを参考にして購入するなら、評価を＋0.5~1.0程度増しても問題ないです。

終わりに

最初は引用で進めていきましたが、あまり頭でまとめられていない感があり途中から変更しました。
技術書の読書術ということもあり、そういった本の読み方に重きを置いてますが、他の本でも利用できそうな箇所が多く勉強になる部分が多かったです。

しいて欠点を挙げるとすれば、私の要約力不足でしょうか。。。
この記事を書くだけでもかなり時間を使った気がします。
重要な部分を見極めるというのは難易度が高く、まだまだ訓練が必要だと感じました。