読書アンチパターン

TL;DR

エンジニアの知的生産術を読んで自分の読書方法を鑑みたときに「これって読書アンチパターンでは?」と思ったものを残しておく。 全てが改善されるとは思わない、少しでも改善していけたら御の字というスタイルです。

せっかくなのでアフィリエイトのリンク貼ろうと思ったらKindle版が予約できるようになっていたのでさっそくポチった。

前提条件:

対象者:

  • ぼく

前提:

  • エンジニアの知的生産術の第4章「効率的に読むには」を読了していること
  • 技術書や実用書
    • 娯楽小説をそもそも早く読む意味はない。

結論:

  • 基本的に買うな、読むな
  • 読むなら厳選しろ
  • いま必要なものだけ読め
  • 脳内音読やめろ

ということです。

アンチパターン:脳内音読やめろ

静かな音読をしてしまっている。 脳内、もしくは声には出ていないが文章を音読してしまっているパターン。

ぼくは脳内音読派だったんだけどそのスピードでないといまいち頭に情報が入らない、ということで自覚はしていたのだけど脳内音読を継続していた。 ところがそもそも技術書の読み方を変えて一度目はさっと読んで、わからないところだけ何度も読むみたいな方法に変えるにはここが絶対にボトルネックになるのでここ変えないとどうしようもねえな!ってなったアンチパターン

小説とかは音読でも脳内音読でも問題ないと思います。 っていうかアニメ化とかされるとその印象にめちゃくちゃ引きづられるし、そのほうが楽しかったりしますよね。 娯楽小説はそれでいいのだー!

アンチパターン:定期的に嫁

小説は一気にガーッと読んでしまったほうがいい。 毎週末読むとかすると先週読んだ内容のかなりの部分を覚えていないので平日1時間読むとかそういうある程度の粒度が必要。 そのほうが週末に集中して読み切るよりも精神的コストが低い。 最悪1日読めない、あるいは今週厳しいとかあっても調整が効く。週末集中パターンだと調整が効きにくい。

アンチパターン:YAGNI式選書

必要なものだけを買え、そして買うべき書籍を厳選しろ。 ちょっとおもしろそうとかで買うとだいたい積むだけで読まない、最悪なのでやめろ。 興味を分散させるのは集中に対する最大のノイズ。

アンチパターン:目的が明確でないものは買わない、読まない

選書段階で「この本を読むことで期待するもの」が明確でないならまだ必要じゃない。 その手に持った技術書や実用書は棚に戻すんだ、いいな?

アンチパターン:遅延評価的勉強法

辞書的に引っ張ってくる技術書を買うことがまれによくある。 が、基本そういう書籍は本棚の肥やしになりやすく、また本当に必要なら会社で買ってもらうほうがいい。 本当にそれが必要になってから買うべき。

アンチパターン:読書メモは詳細読みのときに取る

通読時にメモ書くと時間が取られてしまい、スピード感がでない。 明らかに知らない、わからない単語などはむしろメモを取るべきだが、通読時にメモを取るとそれがボトルネックになって全体のスピードを落としてしまっているとは以前から感じていた。 詳細読みを行うときにだけ気になったやわからないこと、違和感を感じたところや私見をメモする形にするのが一番いいのではないか。 そもそもいまでもメモ取るところは知っていることではなく、知らないことが書かれたケースが大半なので通読時にメモしなくてもあまり影響なさそう。

アンチパターン:インなんとかさんはだいじだよ

目次を見て半分以上なに言ってるかわからないものは買わない→自分の知識レベルがだいぶレベルが低いのでミスマッチ

目次みてほぼほぼ内容が想像できる→自分の知識レベルですでに定着しているレベルのものをもう一度読み直す必要はあまりない、ミスマッチ

目次みて7割想像できるが3割がわからない→対象読者として一番レベル帯が近いものであることが多い。買い、但し読書の目的があいまいな場合はなし。

アンチパターン:図式カラー本は選書から外す

なにを目的とするか次第だが図が多すぎるものは初心者向けであわないことが多い。 カラー本は色という情報源が増えてしまい、ノイズになりがちな割に学習という意味で有効だったことがあまりない。 また再利用性(何度も読み直すこと)がほぼない、一度読んで古本屋にGo!するケースがほとんど。

啓蒙書とかは好きにしてくれ、俺は知らん!という感じです。

このアンチパターンから外れる例としてはデザイン関連が挙げられる、視覚的にどう捉えるのか?が脳内で合成できるレベルではないので最初からカラーのほうがわかりみがある。 それ以外のケース、HTMLの組み方とかああいうのは本当に無駄金だなって感じだった。

あとカラーや図が多いとお値段が高くなりがち。お財布的にも厳しいし重い。Kindleだと重さは関係ないけど。

アンチパターン:input → build → outputのサイクルの粒度が大きすぎる

いままでは1冊読む→読書メモから必要そうな文章を組み立てる→ブログ書くのサイクルだったがこれだとサイクルが遅すぎる。 例えば最初の章の内容をきちんと説明できないことが多い、これでは理解しているとは言えない。

1章読む→読書メモ書く→誰かに説明する、図説できる、くらいの粒度がベター。

技術書によっては章だと大きすぎるとかあるので粒度は適当に自分で考えて調整。 読書メモそのものは組み立てるためのパーツなのでアウトプットに含まない。

組み立てたものを説明したり、図説できたりすることのほうが理解しているかどうかのリトマス試験紙として妥当。

理解できていないな?と感じたら、再読リストにその章を突っ込むか付箋紙とかで印つけて読み終わったときにもう一度読み直す。

アンチパターン:パターン毎で読書方法を変える

Aが理解できていることが前提として後述のBが説明される、プログラミング言語を新しく覚えるときなどはこのパターンが多い。 エンジニアの知的生産術だと数学がそうだと書いてあった、足し算わからんのに方程式わからんよな?みたいな話。

ところがそうでなく、読み飛ばしても問題ないケースもある。 これらのいま読んでいる、読もうとしている技術書がどちらなのかを理解したうえで読み方を変える。

多くのケースは読み飛ばしても大丈夫なことが多い。ところが教科書のようなものは前提条件を積み重ねていくのでそうではない。 このあたりは目次みたり、実際に軽く読んでみて判断するしかない。

また前提条件が必要になる場合、理解せずに次に進んでも意味がないので時間がかかりすぎため、それを念頭においておくこと。 時間かかるなら他を優先して読んだほうがいいとかそういうこともあるよね。

アンチパターン:一定数読んだらご褒美をあげる

最重要なのは必要性だがそれだけで技術書を読み続けると正直つまらないし、疲れる。

なので一定書籍数読んだら自分で興味があって買っていたが必要性がそれほど高くないけど興味があって読みたいものを読む。

報酬があるとなんとなく読み切ろうという気になりがち。 娯楽小説とかも含む、クソエモ本は実用書でも技術書でもないのでご褒美本に入れる。

アンチパターン:買ったときに読まずに積読してしまう

基本的に小説でも技術書でも同じなのだけど買ったときが一番「読むぞ!」というモチベーションが高い。 読んでるうちにモチベーションが上がるケースもあるけどそんなのは数年に1度くらいのエッジケースなので考えない。

なので「必要」だから「買った」のに積読してしまうとモチベーションは下降し続ける。 そしてある一定積読したし、そのうち読むだろゾーンで下降が収まり、それ以降読むまでモチベーションが上がることがほぼなく一定の位置を保持してしまう。

こうなると読むぞ!という気持ちに持ってくるまでのフットプリントが大きくなりすぎてしまう。 なので買ったら少なくとも1章くらいは購入日に読む。

当然先に読まないといけないものがあるのに購入してはいけない、発売日に買う必要性は読者であるぼくにはない…やりがちだけど。

まとめ:

基本的に買いすぎ、集中の分散しすぎが積読の大きな原因。 読む速度の遅さは脳内音読のせいだなって感じ。

積読速度 >>>>>> 読む速度なのでできるだけ買わない、買うなら選書段階でしっかり時間をかけないといけない。

ここを改善するだけで大きく読書スピードが上がりそう。 勘違いしてほしくないんだけど、速く読むことそのものには意味がないし、それを目指しているわけじゃない。

ただあまりにも足りていないものやことが多すぎるので技術書や実用書を読んでなんとなくわかって気になれる程度にはレベルを上げておきたい、という目的のために読書スピードの改善を行う必要があっただけの話。

エンジニアの知的生産術でも書かれていたけど「読書は手段、目的は別」、特に技術書や実用書は。 小説の場合は読むことによって目的が達成されるのでこの限りじゃないし、小説は楽しんで読みたいじゃんね。