読書メモは未来の自分への手紙である

この記事は約 5 分で読めます。

半年前に読んだ本の内容を覚えていますか

半年前に読んだ技術書のタイトルは思い出せる。でも、具体的に何が書いてあったか、どの章が印象に残ったか、自分がどう感じたかは曖昧になっている。

これは記憶力の問題ではありません。人間の脳は、使わない情報を忘れるようにできています。半年間使わなかった知識は、脳が「不要」と判断して薄れていきます。

読書メモは、この忘却に抗うための仕組みです。しかし、メモの本当の価値は「忘れないため」ではなく、「未来の自分に文脈を伝えるため」にあります。

なぜ「要約」ではなく「手紙」なのか

多くの人は読書メモを「本の要約」として書きます。「第 3 章: SOLID 原則について。S は単一責任の原則で…」。これは本の内容の圧縮であり、本を読み返せば同じ情報が得られます。

未来の自分に本当に必要なのは、本の内容ではなく「あのとき自分が何を考えていたか」です。

「第 3 章を読んで、今のプロジェクトの UserService クラスが単一責任に違反していることに気づいた。認証、プロフィール更新、通知の 3 つの責務が混在している。来週のリファクタリングで分割を提案する」。

このメモは、半年後に読み返したとき、本の内容だけでなく「あのときの自分の課題」「あのときの判断」「あのときの気づき」を蘇らせてくれます。

未来の自分に伝わるメモの書き方

1. 「今の自分の状況」を書く

本の内容だけでなく、読んでいるときの自分の状況を一言添えます。

• 「新しいプロジェクトのアーキテクチャを検討中に読んだ」
• 「コードレビューで設計の指摘を受けた直後に読んだ」
• 「転職を考え始めたタイミングで読んだ」

読書ノートの本を参考にすると、メモの取り方自体を体系的に学べます。

2. 「刺さった一文」を引用する

本の中で最も印象に残った一文をそのまま引用します。要約ではなく、原文のまま。

半年後にこの一文を読み返すと、その章全体の内容が芋づる式に思い出されます。一文が記憶の索引として機能するのです。

3. 「次にやること」を書く

読書メモの最後に、「この本を読んで、次に何をするか」を 1 行書きます。

• 「月曜日に UserService のリファクタリングを提案する」
• 「次のコードレビューで凝集度を意識して指摘する」
• 「来月の 1on1 でこの本を後輩に薦める」

この 1 行が、読書を行動に変える橋渡しになります。

メモの保存場所

デジタルがおすすめ

紙のノートは手書きの温かみがありますが、検索できません。3 年分のメモから「SOLID 原則について書いたメモ」を探すのは、デジタルなら一瞬、紙なら数十分です。

Notion、Obsidian、Google Docs、プレーンテキスト。ツールは何でも構いません。重要なのは検索できることと、長期間アクセスできることです。

GitHub に置く方法

エンジニアなら、読書メモを GitHub リポジトリで管理する方法もあります。Markdown で書き、コミット履歴が読書の時系列を記録してくれます。公開リポジトリにすれば、ポートフォリオとしても機能します。

1 年後に読み返す体験

読書メモを 1 年間続けて、年末に全メモを読み返してみてください。

「1 月はエラーハンドリングに悩んでいたのか」「3 月に設計の本を読んで、4 月のプロジェクトで実践したんだな」「8 月に転職を考えていたけど、結局残ったのか」。

メモは読書の記録であると同時に、自分の成長の記録です。1 年前の自分が悩んでいたことが、今の自分には当たり前になっている。この変化を実感できるのは、メモを残した人だけの特権です。

メモを書く時間がない人へ

「メモを書く時間がない」という人は、メモのハードルを下げてください。

本を読み終えた直後に、3 行だけ書く。

1. この本で一番印象に残ったこと
2. 今の自分の仕事にどう関係するか
3. 明日から何を変えるか

3 行なら 2 分で書けます。完璧なメモより、不完全でも書いたメモの方が、未来の自分にとって 100 倍価値があります。

関連記事

• 技術書の読書メモ術 - 読んだ内容を確実に定着させる記録法
• 技術書の読書ログを GitHub で管理する - エンジニアらしい記録法

まとめ

読書メモは本の要約ではなく、未来の自分への手紙です。本の内容に加えて、読んだときの状況、刺さった一文、次にやることを書く。デジタルで保存し、1 年後に読み返す。3 行でいいから書く習慣をつければ、読書の価値は何倍にも膨らみます。