読書で手に入れたのは知識ではなく「多面的に考える習慣」だった
読書で変わったのは知識量ではなかった
「本を読んでも、結局あまり覚えていない」
そんな感覚、ありませんか？私自身、長らくそう感じていました。
私は通勤時間や就寝前に読書をするのが日課です。最初は眠気との戦いでしたが、今ではむしろ頭が冴える時間になっています。
ただ、読書を続けてきて気づいたのは、得られた最大の価値は「知識が増えたこと」ではないということです。
知識は検索すれば手に入ります。技術的な問題は Qiita や公式ドキュメントで解決できます。読書でしか得られないものは、もっと別のところにありました。
精神的な豊かさの正体
読書を通じて私が手に入れたのは、「自分なりの答えを持てるようになったこと」 です。
本を読んでいると、自然に疑問が生まれます。「本当にそうだろうか？」「自分の場合はどうだろう？」。その疑問をもとに自問自答したり、調べたりして、自分なりの答えを見つけ出す。
この過程を繰り返すうちに、同じ出来事を複数の角度から解釈できるようになりました。
私はこれを「精神的な豊かさ」と呼んでいます。言い換えれば、物事を多面的に捉えられる度合いのことです。
多面的に捉えるとは
例えば、仕事でよくある場面を考えてみます。
プロジェクトの納期が迫っている中、チームメンバーが「このタスクは終わりそうにない」と報告してきた。
一面的な捉え方: 「なぜ早く言わなかったのか」→ 責任追及に向かう
多面的な捉え方:
- そのメンバーは「言い出しにくい空気」を感じていなかったか？
- タスクの見積もり自体が甘くなかった？自分のレビューに問題は？
- 「終わらない」と正直に言えたこと自体が、チームの心理的安全性の表れではないか？
同じ出来事でも、解釈の角度を増やすだけで、次に取るべき行動が変わります。責任追及ではなく、仕組みの改善に目が向く。これが多面的に捉えることの実務的な価値です。
エンジニアの仕事で活きる場面
読書で育まれた「自問自答の習慣」は、エンジニアリングの現場で日々活きています。
コードレビュー
「なぜこの人はこう書いたのか？」を先に考える。一見非効率に見えるコードにも、制約や背景があるかもしれない。結果だけを見て「こう書くべき」と指摘するより、意図を理解してから提案するほうが、相手の納得感も高く、チームの学びにもなります。
要件定義
クライアントの要望をそのまま実装するのではなく、「なぜこの機能が必要なのか」「本当に解決したい課題は何か」を掘り下げる。表面的な要望の裏にある本質的な課題を見つけるためには、多面的に考える習慣が不可欠です。
障害対応
「誰のせいか」ではなく「なぜ起きたか」「どうすれば再発しないか」に思考を向ける。これも、一面的な見方（犯人探し）を超えて多面的に捉える力が求められる場面です。
好奇心は後からついてくる
「疑問を持つことが大事」と言われても、そもそも好奇心がなければ疑問は生まれない。この矛盾を感じる方もいると思います。
私の経験では、好奇心は読書の「結果」として後からついてきます。
本を読む → 疑問が生まれる → 自問自答する → 自分なりの答えを持つ
→ 答えのレンズで現実を見る → 新しい解釈ができて面白い
→ もっと知りたくなる（= 好奇心）→ また本を読む → ...最初から好奇心がなくても大丈夫です。まず 1 冊読んでみる。それだけでサイクルは回り始めます。
読書を続けるための小さな工夫
私が実践している読書習慣を、並べてみます。
- 通勤電車の中で読む — スマホを触る時間を読書に置き換えるだけ
- 就寝前の 15 分 — 完璧に理解しようとしない。流し読みでも OK
- 気になった箇所をメモする — 「自問自答のタネ」を残しておく
- 技術書と思想書を交互に読む — 脳の使い方を切り替えて飽きを防ぐ
座右の銘で掲げた 1.01 の法則。毎日 1% の積み上げは、読書にもそのまま当てはまります。1 日 15 分でも、1 年で 90 時間以上。小さな習慣の複利効果は、振り返ったときに驚くほど大きいです。
もし「最近、本を開いていないな」と感じていたら、まずは今日、通勤の片道だけでもページをめくってみてください。半年後の自分の見え方が、ちょっとだけ広がっているかもしれません。
関連記事
- 「報われない努力はない」— 運をためるという考え方が、働き方を変えた — 読書がきっかけで努力の定義が変わった話
- 「呼吸するように年を取る」— ジャネーの法則と、時間を味方にする働き方 — 脳を活性化させ続けるための習慣
- 「失敗の科学」— すべての失敗を経験するには、人生は短すぎる — 失敗を蓄積・分析する仕組みの重要性