Hase流学習法
本が読めない人でもちゃんと理解をするためにどうやって学習・読書した内容を身に着けるかを書こうと思います。
はじめに
本が読めん。
いや、正確に言うと、読めはする。文字は目に入るし、意味は分かる。でも、それが脳みそに定着してくれない。数分後には消えている。技術書の内容が易しかろうが関係なく、消える。
これは僕個人としてはかなり深刻な問題だった。 「勉強したいのに、出来ない」という状態がここ数カ月続いていた。なので、そもそも自分の記憶がどう動いているかも整理して、それに合わせた学習法を思い出してみることにした。
この記事はそれの備忘録である。
僕の記憶の特性
まず自己観察からしてみて、以下が僕に当てはまる傾向だった。
- 視覚・聴覚どちらの情報も、inputはされているが定着せずに棄却される
- 一方で、 自分で出力したものは残る。「覚える」というよりも「体が慣れる」という表現が近しい。
- 文学小説だったり、チャットみたいな短いやり取りや単発的な記憶は強く残る
- 技術書のように前に行ったり戻ったりする読み方をすると情報がその中で落ちる
面白いなーと思ったのは、AIとの対話が自分とかなりフィットしていることだった。読むだけだと消えるけど、対話だと残る。
なぜ、技術書だけ落ちるのか
自分なりに整理した結果がこれ。
「読字」でもなく「技術書というジャンル」でもなく、参照区間の長さにある。
文学小説とかチャットは、情報が入ってから出力が得られる(理解・返答)までが早い。in→outのサイクルが短い。この短さのおかげで、ワーキングメモリ上の情報が消える前に処理が終っている。
技術書はそうはいかんのだ。「10ページ前で定義した用語を50ページ後で参照する」みたいな読み方を要求することもある。外部に書きださない限り、その参照を頭の中だけで保持し続けないといけない。in→outの区間が引き伸ばされる。自分の場合、この区間で情報がきれいさっぱり、捨てられる。
内容が難しいから読めない、ではなく、構造的に読めないということになる。
じゃあどう読むの？
方針は単純で、技術書の読み方をチャット形式に寄せる方針。
基本フロー
- A4の紙を用意する(1枚につき1テーマ、超えてもいい)
- 本の内容、および「僕はこう理解した」という仮説を殴り書きする
- それをAIに読み込ませて要約・構造化させる
- 記事として残す
ポイントなのはこの 2の手書き であること。3以降はあくまで検索可能な形で外部に残すための工程で、記憶にほぼ寄与しない。だからObsidianとかNotionとかでもいい。
定着の核心は手を動かした時点で完了している。
なぜ、書くと残るのか
調べたら、これって学習心理学的にも理屈があるらしい。
- 生成効果(generation effect): 自分で情報を再構築・出力すると、受け取るだけより記憶痕跡が強くなる
- 運動記憶の関与: 手を動かして書くという行為自体が視覚的な記憶とは別の記憶系統を使うらしい。片方が機能しにくくとも、もう片方で代償できる
- 多重符号化: 同一の情報を視覚と運動の両方で処理すると、想起(思い出す工程)の手がかりが増える
僕の「体が慣れる」という感覚は、たぶん２つ目のことを言ってると思う。
単一の本を線形に読まない
もう一つ効いていると思うのが、複数の書籍の似たテーマを横断してみるというやり方。
同一のテーマについて複数のソースを照合する行為自体が、すでに受動的な読字ではなく能動的な比較・統合作業になっている。最初から生成寄りの処理になるので、そもそも「読む」フェーズが存在していない。
そして、その統合作業を紙の上で一度に済ませるから、あとから本文を見に行くという必要がなくなる。さっき言ってた「参照区間が長すぎる問題」がここで解消される。
細かい話
実際に今までの記憶から考えて思ったのが
- 色分けは不要: ペンを持ち替えるっていう動作がそもそも無駄。in→outのフローが途切れる。構造を分けたいなら矢印・囲み枠・インデントで足りる。
- 太いペンを使う: 写真撮ってAIに読み込ませる関係上、読み取り精度が落ちたらまずい。あと、筆圧をかけられる方が、運動記憶の刺激に良い。
- A3より、A4: シンプルにA3はデカいことに気が付いた。A4なら、クリアファイルに入れられる。小さいほうが良い。
この方法、明らかに遅い
そう。遅い。
でも、比較対象が間違えると、判断を誤る。
普通の読書は確かに早い。というか、僕は割と読み飛ばす派。だからかは知らないけど、定着率がほぼ０だった。時間当たりの読んだページ数が多くとも、時間当たりの「実際に身についた知識量」で見たら、実質０だった。
今の方法は明らかにページ数で見たら1200%遅い。けど、書いた内容はほぼ確実に残る。「実際に身についた知識量 / 時間」で比較すれば、むしろこっちの方が早い可能性がある。
認知心理学に、望ましい困難(desirable difficultyっていう概念があるらしい(初知り)。手間がかかって遅く感じる学習方ほど、長期的な定着率が高い、というトレードオフのことで、まさにこれだなと思った。
全部にやる必要性はない
とはいえ、全部にやっていたら時間が溶ける。人生有限時間しかない。
最初は「使い方 vs 設計・概念」で分けようとしてたけど、荒かった。頻度の軸が抜けてた。めったに使わないAPIと、毎日書く提携パターンが同じ「使い方」バケツに入ってしまう。
最終的に落ち着いたのがこの２軸。
- 想起の即時性: それが必要となった瞬間、立ち止まって調べる余裕があるか
- 再取得コスト: 忘れてしまったとき、検索で済むか、自分で再構築・再判断する必要があるか
| 再取得コスト:高 (自分で再構築が必要) | 再取得コスト:低(検索で済む) | |
|---|---|---|
| 即時性:高(止まると流れが止まる) | 最優先でやる(手書き→要約→記事化) | 軽めの反復で定着(写経、タイピング練習) |
| 即時性:低(止まって調べられる) | 索引・グロッサリー程度のメモ | 何もしない。完全に外部記憶に任せる |
例えば t.Fatalf の書き方そのものは再取得コストは低い。忘れても30秒で復元可能。でも「このテストでFatalfを使うべきか、Errorfを使うべきか」という判断基準は再取得コストが高い。これは調べ直しが効かず、コードを書く判断そのものににじみ出る。
オライリー本が検索的な読み方で足りるように見えるのは、実際に大部分が参照型の内容だからで、この判断自体は正しいと思う。でも、章の頭の設計思想の解説とか「なぜその機能が存在しているのか」の部分は再取得コストが高いことが多いのでそれだけ拾って手書きで各、という混在した読み方が一番効率が良さそう。
判断が難しい
ここで詰まった。読めば読むほど、全部が大事に見えてくる
これは判断基準の問題ではなく、読んでいる最中に判断することが原因だと思った。まだ全体像を知らない段階で「これは即時性が高そうだ」を毎回考えているのは不可能だと悟った。むしろ、全部が同じくらい未知に見えて当然だった。
なので、判断は未来に任せることにした。
- 読んでる最中は一律で参照するだけにとどめる
- 後から何回も参照している場合、実際の判断に聞いたと分かったものだけ昇格する
判断ミスのコストが非対称なのもポイントで、もし重要なものを軽く扱っても、あとで困ったときにもう一回見に行けばよい。でも、クソどうでもいい内容ですら記事化していると、時間と体力両方失う。
迷ったら、とりあえず読み飛ばす方が損失が小さいことに気が付いた。
まとめ
- 自分の場合、読めない原因は難易度ではなく 参照区間の長さ
- 対策は in → out のサイクルを短く保つ。手書きで出力してから次へ進む
- 定着の核心は 書く工程。AIへの読み込みも記事化も、記憶ではなく外部化のための工程
- 全部に重い方法をかけない。即時性 × 再取得コスト で振り分ける
- 振り分けは読んでいる最中ではなく、使用実績を見て事後的に 決める