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

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

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

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

このとき取られる行動は、たいてい次の 3 つのどれかです。

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

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

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

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

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

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

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

実装方法がわからない

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

実践的なプログラミングの本を手元に置いておくと、詰まったときにすぐ参照できます。ただし言語やライブラリのバージョンが上がっている場合、本の記述と現行の仕様が食い違うことがあります。手元の本で当たりをつけ、最終確認は公式ドキュメントで取るのが安全です。

設計が決まらない

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

パフォーマンスが出ない

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

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

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

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

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

デスクに置くべき 3 冊

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

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

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

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

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

本の内容が直接的な答えを与えたのではなく、読んでいる過程で自分の思考が整理され、問題の本質が見えたのです。これは、Andrew Hunt と David Thomas の「達人プログラマー」で紹介されたラバーダック・デバッグと似た働きをします。アヒルのおもちゃに向かってコードを 1 行ずつ説明していくと、説明が詰まった箇所に自分の理解の穴が現れる、というものです。

本を読むときも、書かれていることと自分がやろうとしていることを照らし合わせる形で、頭の中を言葉に置き換えていきます。説明する相手が本になっただけで、問題を別の角度から見る視点が得られます。これが「デバッグとしての読書」の中身です。

関連記事

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

まとめ

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