効率良く読書する

2016-08-16 / [reading]

こうするといいよ、ではなくてこうしてみようかと思う、という草案と計画の話です。 できるとは言ってない案件。

問題

なんだか本を読んでも知識の定着全然してなくない? ということに気づく。

プロセッサやLinuxカーネルの本を読んで感じた。

分析

今まで読んで身になった本ってなんだろう。

最近読んだ本ってなんだ。

  1. 人月の神話
  2. FP in scala
  3. 数学は言葉

人月の神話は各となる主張についてはとても印象に残っているが、 枝葉末節については全く覚えていない。 まあそれはそれでいい。 ソフトウェア開発のプロセスの話については大概そんな感じだろう。 発見のあったトピックをよく覚えていくというスタイル。

FP in scalaはFreeモナドの構成方法とDSLのtranslationが強く印象に残っており、 haskellプログラミングにも多いに役立っている。 実践を踏んだからこそ身になっているとも言える。 つまりhaskellで実践できる環境があったから。

数学は言葉は簡単な例題を問いたりしたので、 幾分印象に残っているけれど積み残したε-δ論法がまだ習得していない。というか理解していない。 つまり読書は終わったけれど、知識の定着には個人的に不満がある状態。

読書のゴールとはなにか

読書した結果として「内容を理解した」という状態はなんだろう。もう普遍的命題すぎる。

が、一つ解っているのは「得た知識が使えるようになっている」という状態を「理解している」とみなすということ。

使うまで解らないということだ。 数学の定理も検算するまでは解ってないのと一緒。問題を解けないならそれは理解していない。

つまり読書に伴う演習問題の設定が重要だ。

学校の授業でもノートとったりノートまとめ直したりするだけだとあんまり理解してる実感ない。 結局テスト問題とか解いた時にはじめて理解不足に気づくって感じ。

読書における課題の設定

読書と一口に言ってもいろんな本がある。本によって必要な課題は違うはずだ。分類してみよう。

プログラミング

自分でコードを書いて動かさないと駄目だ。 目次を読んで初歩的な演習をこなすことが目標となる。

開発とマネジメント

実践が難しいところ。大概の場合組織を巻き込むので。 ここはまだ解法がない。

ハードウェアとコンピュータ・サイエンス

これも実行の難しい分野。 プログラム書いてエミュレートするのがいいのだろう。

数学

大体練習問題がついているのでそれを解くのがいいだろう。

映画・小説

とりあえず話の筋をevernoteにメモってはいるけど、ただの書き下しなのであまり効果がないような。 もう少しプロットやサブプロットを構造的に表現できないと再利用性ない。

読書環境

と言ってもですね、電車の中で本を読んでてプログラムなんか書けるわけないんですよ。

じゃあ朝書くか? 別のタスク処理が多いから無理ではないか。

マインドマップ

マインドマップ書くといいよ、ってよく聞く。 メモとるのにはいいのだけれど実践には結びつきにくい。 さらにマインドマップはスマホ環境ではとてもメモ取りにくい。

Evernote

なんとかevernoteを有効活用できないかな。 テキストのメモって線形だから木構造やグラフ構造を作りにくいんだよな。

と思いながらブログ記事を参考にしている。

でもあまり参考にならず。

まとめ

まとめられるほどの結論がない。 ただ読書メモをとりあえずevernoteでとってみようと思う。

追記

evernoteでメモとりながら読んでる。

気がついたことメモしたり、自分なりのまとめをメモすると 知識に何かうまい輪郭のようなものが与えられる気がする。 その輪郭が記憶をたどる時の手がかりになる気がする。

割といい方法ではあるとわかってきた(今更だけど)。

ただ、最近の勉強内容は自分で問題を問いたりソースコードを読んだりしないと 理解に到達しなさそうなものが多いのでちょっと困ってる。

電車の中で数学問題を解く方法さえ確立できれば状況は一変するのだけれどね。