手が止まったら本を開け - デバッグとしての読書

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

詰まったときの 3 つの選択肢

コードを書いていて手が止まる。「この機能、どう実装すればいいんだろう」「このエラー、何が原因だろう」。

多くのエンジニアは、この瞬間に 3 つの行動のどれかを取ります。

1. Stack Overflow で検索する
2. 同僚に聞く
3. しばらく悩んでから諦める

ここに 4 つ目の選択肢を加えてください。本を開く。

検索と読書の決定的な違い

検索は「答え」を探す行為です。「このエラーの解決方法」「この API の使い方」。具体的な答えが見つかれば、問題は解決します。

読書は「考え方」を探す行為です。「この種の問題にはどういうアプローチがあるか」「この設計判断の背景にある原則は何か」。答えそのものではなく、答えにたどり着くための思考の枠組みを得ます。

検索で見つかる答えは、その場限りの解決策です。読書で得た考え方は、似た問題に何度でも適用できる汎用的な武器です。

「詰まり」の種類と開くべき本

実装方法がわからない

「この機能をどう実装すればいいか」で詰まっている場合、使っている言語やフレームワークのリファレンス本を開きます。目次や索引から該当する機能を探し、サンプルコードを参考にする。

実践的なプログラミングの本を手元に置いておくと、詰まったときにすぐ参照できます。

設計が決まらない

「この機能をどこに置くべきか」「モジュールをどう分割すべきか」で詰まっている場合、設計原則やデザインパターンの本を開きます。自分が直面している問題に近いパターンを探し、適用できるか検討する。

パフォーマンスが出ない

「動くけど遅い」で詰まっている場合、パフォーマンスチューニングやアルゴリズムの本を開きます。ボトルネックの特定方法、データ構造の選択、キャッシュ戦略。これらの知識は検索だけでは体系的に得にくい。

本を開くタイミングのルール

詰まるたびに本を開いていたら、コードを書く時間がなくなります。以下のルールで使い分けます。

• 5 分以内に解決しそうな問題: 検索で解決する
• 5 分考えても方針が立たない問題: 本を開く
• 同じ種類の問題に 3 回以上遭遇した: その分野の本を 1 冊読む

3 番目が最も重要です。同じ種類の問題に繰り返し遭遇するのは、その分野の体系的な知識が不足しているサインです。

デスクに置くべき 3 冊

すべての技術書をデスクに置く必要はありません。以下の 3 カテゴリから 1 冊ずつ、手の届く場所に置いておけば十分です。

1. 言語・フレームワークのリファレンス: 実装で詰まったとき用
2. 設計原則・パターンの本: 設計で詰まったとき用
3. アルゴリズム・データ構造の本: パフォーマンスで詰まったとき用

電子書籍でも構いません。重要なのは、詰まった瞬間に 10 秒以内にアクセスできることです。

読書がデバッグになる瞬間

本を開いて該当する章を読んでいると、直接の答えが見つかる前に「あ、そういうことか」と閃くことがあります。

本の内容が直接的な答えを与えたのではなく、読んでいる過程で自分の思考が整理され、問題の本質が見えたのです。これは、ラバーダッキングデバッグ (アヒルのおもちゃに問題を説明すると解決策が見つかる手法) に似ています。

本を読むことで、問題を別の角度から見る視点が得られる。これが「デバッグとしての読書」の本質です。

関連記事

• エラーが出たときこそ本の出番
• コードを書かない日に読む本

まとめ

コードを書いていて手が止まったら、検索の前に本を開いてみてください。検索は「答え」を、読書は「考え方」を与えてくれます。5 分考えても方針が立たない問題、同じ種類の問題に繰り返し遭遇する場合は、本を開くサインです。デスクにリファレンス、設計、アルゴリズムの 3 冊を置いておけば、詰まりの大半に対応できます。