技術書の読書術を学んでみた

目的

現状の学習スピードに課題を感じている。時間をかけている割に、技術のキャッチアップに時間がかかっているように思う。
技術本の読書術を学び、より効率的にインプットを行えるようにしていきたい。
まとめサイトを参考に、取り入れられる視点が無いか探していく。

技術書で本当にスキルアップできる読み方とは？『「技術書」の読書術』の著者は「動くコードを自分で書く」

codezine.jp

　最初はとりあえず1冊の本に書かれている内容を把握するために読みます。使わないものを詳しく知っても意味がないため、「そんな機能があるんだな」というくらいで読み飛ばすのです。

これは知ってはいたが、できていない。意識してやってみたい。

そして、基本的な概念や使い方を確認します。その本で使われているソフトウェアであればインストールしてみて、数行のソースコードであれば入力して試してみてもいいでしょう。
このとき、うまく動かない、となったり、すぐに解決できないと感じたりするのであれば、とりあえず飛ばします。大切なのは「何がどこに書かれているか」を把握することです。

この「とりあえず飛ばす」っていうのをせずに、上手くいかないところに時間をかけてしまっている。

書籍『達人プログラマー』では「毎年少なくとも一つの言語を学習する」ことが推奨されています。実際、毎年でなくとも、2つ、3つとプログラミング言語を学んでいくと、1つのプログラミング言語では得られなかった知識が得られます。

これは今のところピンと来ない。理屈は分かるけど、どうなんでしょうか。フロントエンドは日々新しいライブラリが出てトレンドが変わっていく気がするので、Reactをマスターするだけでも大変だと思うけど、バックエンドの話かな...？「達人プログラマー」は一度読んでみたい。

よいコードより動くコード

学習段階で素早くインプットするために、まずはコード書いて動かすというのが大事

最初からきれいな「よいコード」を書くことを考えるのではなく、まずは汚くても「動くコード」を書くことを心がけます。たとえば、その本の全体を一度読み終えた段階で、章単位で学んだことを使って、何か動くものを作ります。本に書かれている内容をコピーするのではなく、ゼロから何か新しいテーマを考えて作ってみるのです。

これをちゃんとできるようにしていけば、早く成長できそう。そのあとちゃんとプロジェクトコードレベルにもっていくのは当然必要だけれども。

【技術書の読書術 実践してみた】3の発想で3冊の本を読んでみた

dev.classmethod.jp

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

「3の発想」というのが面白い。たしかにこの視点は技術書を読む時にとてもマッチしそう。技術書との相性のズレを埋められるし、複数から共通した部分を理解する意識が、1つに時間をかけすぎてしまうのを防ぐ気もする。

3の発想に基づいて以下のように視点が異なる本を3種くらい読むことで実務で使えるレベルになるでしょうと述べられています。

1冊目： 入門レベルの本
2冊目： 専門書
3冊目： 逆引き

たしかに、いきなり専門書レベルに手を出すと、難しく感じてしまいそう。何事も段階を踏むことでスムーズにいく。

学習を効率化してくれる読書術

zenn.dev

学習を効率化させるために読書をするにあたってやってはいけないことを最初に述べる。それは以下の3つである。

本を最初から最後まで順番に読む
本に書いてある内容を暗記する
すべての内容を理解する
これらのことをやめるだけで読書の効率が大幅に上がる。学習のために本を読むなら全部を読むのは絶対にやめよう。

はい。これは理解しました。やっぱりそうですよね。

読書はインプットするだけでは無駄に終わってしまう。学習のために読書をするなら、その読んだ本の内容を具体的に自分が活かせられるように具体的なアクションプランに変換してそれを実行しよう。それが難しいならSNSやブログ等に自分の感想や要約をアップしても構わない。なんでもいいので、自分が目に見える形でアウトプットを残しておくことが非常に重要である。

読むだけで満足するな。その読んだ本の内容を学習や仕事に活かせられるように最大限の工夫を凝らすべきである。

すごく同意。そのためにこのはてなブログも始めたし、なるべくたくさんコードを書くようにしている。

ほとんどの場合、本に書いてあることの10割が役立つことはない。学習のために読書をするなら、辞書やリファレンスのように読み進めることが重要である。必要な知識や考え方は、常に書籍の中のほんの一部にすぎない。興味のない部分やわからないところは積極的に読み飛ばそう。本をよむ上で最初にやっておきたいことは目次を熟読することである。目次にはその本の内容や要点がすべて書かれている。目次を読んで気になる部分や学びたいところをピックアップして読んでいこう。

目次に着目するのは面白い。

学習を加速させるインデックス読書術

qiita.com

本は、あなたの外部ストレージです。

必要なのは

その本に何が書いてあるか、なんとなく把握している
必要なときに本を引いて調べられる
ということです。

極端な意見。たしかにそうか。

読んだものをすべて覚えておきたがるのは、
食べたものをみな身体にとどめておきたがるようなものだ。

ショーペンハウアーさんの名言。良いこと言うなあ。

マーシャル・マクルーハンはこう言っていました。

トンカチは腕の拡張であり、望遠鏡は眼の拡張、
メガホンは声帯の拡張であり、車は足の拡張ということになる。[4]

技術書も同じですね。
それは私たちの脳を拡張し、技術力を拡張する。

あらゆるメディアは人間のなんらかの心的ないし身体的な能力の拡張である。[4]

だから、本を本と思わない方がいい。

ロマンと哲学。

一番いけないのは、わからないままに読み進めることです。
これはだいたい失敗します。
謎が徐々に大きくなって、最後は紙面の上を視線がスベるようになるだけです。

読めないということも、また財産です。
読みたいという気持ちが、また学習に向かうでしょう。
大事なのは読んだふりをしないこと。

読めないことも、また財産。。。名言。わからないままに読み進んでいいと思ってやってたけど、たしかに視線がすべって何も得られない感覚はあった。読むのやめちゃっていいんですね。

本にもウェブにも教科書的なものと、参考書的なものがあります。

教科書は定義が書かれていますが、参考書は理解するための道筋が書かれています
教科書は正確性を重視しますが、参考書はわかりやすさを重視します
教科書は網羅的に書かれていますが、参考書は濃淡つけて解説しています

これも入門書→専門書→逆引きの例のことかな

優れた技術書を体得することは、エンジニアのレベルに直結します。
つまり、読書術はエンジニアのレベルをあげるための
最上のチートコードだということです。

よく一冊ずつ丁寧に読み進める人がいますが
（稀に本当にそういう読み方がハマる人もいますが）
たいていの人はただ遅く読んでいるだけです。

つまみ食い上等、読み飛ばし上等で、
何冊も何十冊も書物をカラダに通していきましょう。
いつしかそれは、あなたの手足となっているはずです。

良いまとめ。