週末 2 時間の「深読み」が平日の仕事を変える

2 分で読めます
読書術学習法技術書

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

隙間時間の読書だけでは足りない

通勤中の 15 分、昼休みの 10 分。隙間時間を使った読書は習慣化しやすく、ページ数を稼ぐには有効です。しかし、技術書の中には隙間時間では歯が立たない本があります。

設計原則の本、アーキテクチャの本、アルゴリズムの本。これらは 1 つの概念を理解するのに前後の文脈が必要で、15 分刻みで読むと毎回「前回どこまで理解したか」を思い出すところから始まります。結果、同じページを何度も読み返すことになり、一向に進みません。

こうした本には「深読み」の時間が必要です。

深読みとは何か

深読みとは、1 つのテーマに 2 時間以上集中して向き合う読書のことです。ただ長時間読むのではなく、以下の 3 つを意識します。

  1. 立ち止まって考える: 著者の主張に対して「本当にそうか」「自分のプロジェクトではどうか」と問いかける
  2. 手を動かす: コード例があれば実際に打ち込み、パラメータを変えて挙動を確認する
  3. 書き出す: 理解した内容を自分の言葉でノートに書く。書けない部分が理解できていない部分

隙間時間の読書が「インプット」だとすれば、深読みは「インプット + 咀嚼 + アウトプット」のセットです。

週末 2 時間の確保方法

「週末にまとまった時間を取る」と言うのは簡単ですが、実行は難しいものです。家族との時間、家事、買い物。週末には週末の忙しさがあります。

現実的なのは、土曜か日曜の午前中に 2 時間だけ確保する方法です。朝食後から昼食前まで。午前を選ぶ理由は、この時間帯が誰にとっても最も頭が働くからではありません。集中しやすい時間帯そのものは朝型・夜型で分かれます。午前に置く利点は、後から入る用事に押し出されにくいことと、午後の予定を犠牲にせずに済むことです。

ポイントは「毎週同じ曜日の同じ時間帯」に固定すること。「土曜の朝 9 時から 11 時は読書」と曜日と時刻まで決めておけば、毎週「今週はいつ読むか」を考え直す手間がなくなります。逆に「週末のどこかで」という決め方だと、他の用事が入った時点で消えます。潰れた週の代替枠 (日曜の同じ時間帯など) をあらかじめ決めておくと、1 回飛んだだけで習慣が終わるのを避けられます。

深読みに向く本の選び方

すべての技術書を深読みする必要はありません。深読みに向くのは以下のような本です。

  • 設計原則やアーキテクチャパターンを扱う本
  • 1 つの概念を多角的に掘り下げている本
  • コード例が豊富で、手を動かしながら読む前提の本
  • 自分の実務に直結するテーマの本

逆に、リファレンス的な本や、広く浅くトピックを紹介する本は隙間時間で十分です。

ソフトウェア設計の本は深読みの効果が特に高いジャンルです。

深読みの具体的な進め方

最初の 30 分: 章の全体像を掴む

まず、その日に読む章を最初から最後まで一気に通読します。細部は気にせず、全体の流れと結論を把握することが目的です。

次の 60 分: 精読と手を動かす

通読で気になった箇所に戻り、じっくり読みます。コード例は実際に動かし、図表は自分でも描いてみます。「なぜこの設計を選んだのか」「別の方法ではダメなのか」を考えながら読み進めます。

コード例を動かす前提の本では、環境の用意だけで 60 分が溶けることがあります。処理系やライブラリの入れ直しが必要そうな本は、前の週のうちに動く状態まで作っておくと、深読みの時間を読解に使えます。

最後の 30 分: 書き出しと振り返り

読んだ内容を自分の言葉で 5〜10 行にまとめます。要約ではなく、「自分の仕事にどう活かせるか」の視点で書くのがコツです。来週の月曜日に試せることを 1 つ決めて書き留めておくと、読書と実務がつながります。

平日の仕事が変わる瞬間

週末の深読みの効果は、翌週の仕事で実感します。

コードレビューで「この設計は○○パターンに近いけど、ここが違う」と具体的に指摘できる。設計会議で「この本にこういう事例が載っていた」と引き合いに出せる。後輩の質問に「それは○○という概念で、こう考えるといい」と体系的に答えられる。

ただし、本に載っていたという事実そのものが結論の根拠になるわけではありません。事例を持ち出すときは、自分たちの状況とどこが同じでどこが違うのかを一言添えます。そこを省くと、本の名前が議論を打ち切る権威として働いてしまいます。

これらはすべて、隙間時間の浅い読書では得にくい成果です。

関連記事

まとめ

隙間時間の読書と週末の深読みは、役割が違います。隙間時間はページを進めるため、深読みは理解を深めるため。週末の午前中に 2 時間だけ確保し、通読 → 精読 → 書き出しの 3 ステップで読む。この習慣を続けた分は、翌週の設計の判断やレビューで使える言葉として返ってきます。

共有:Xはてブ

この記事は役に立ちましたか?

関連用語

関連記事

30 代エンジニアが読書で取り戻す「設計の言語化力」

経験年数は十分なのに設計意図を言葉にできない。30 代エンジニアが直面する「暗黙知の壁」を、技術書の読書で突破する方法を解説します。

技術書を読むベストな時間帯はいつか - 朝型 / 夜型エンジニアの読書事情

技術書を読む時間帯を、睡眠と記憶についてわかっていることとエンジニアの実体験から考えます。朝の通勤中、昼休み、夜の自宅、それぞれの長所と短所を比較します。

コードを書かない日に読む本

休日や有給休暇など、コードを書かない日にこそ読むべき本があります。実装から離れた日に読むと効果が高い本のジャンルと、その理由を解説します。

日曜日の午前中に 1 章だけ読む生活

読書習慣がない人でも続けられる、最小限の読書ルーティンを紹介します。日曜の午前中に 1 章だけ。この小さな習慣が、1 年で約 50 章分の知識になります。

子育てエンジニアが月 2 冊読むためのタイムハック

子どもが生まれて自由時間が激減したエンジニアへ。育児と両立しながら技術書を読み続けるための、隙間時間の見つけ方と読書スタイルの工夫を紹介します。

技術書の読書スピードは気にするな - 遅読のすすめ

技術書を速く読むことに価値はない。1 冊を時間をかけて深く読む「遅読」が、なぜ速読よりも身についた実感につながるのか、その仕組みと向かない本の見分け方を解説します。