独学プログラマーが「本の沼」にハマる原因と抜け出し方
この記事は約 6 分で読めます。
「次に読むべき本」を探し続けていませんか
入門書を 1 冊読み終えた。次は何を読めばいいだろう。ネットで「おすすめ技術書」を検索し、リストに載っている本を買う。読み終えたら、また次の本を探す。気づけば本棚には 20 冊の技術書が並んでいるのに、自分で何かを作った経験がない。
これが「本の沼」です。独学でプログラミングを学ぶ人が繰り返し報告する詰まり方で、本を読むこと自体は悪くありません。問題は、本を読むことが目的になり、コードを書くことが後回しになっている状態です。
結論を先に書きます。抜け出す手順は 3 つです。今開いている本を閉じて 50 行のコードを書く。エラーが出たときだけ本に戻る。次の 1 冊は「おすすめリスト」ではなく作りたいものから逆算して選ぶ。以下はその理由と、実行するときにつまずきやすい点です。
なぜ沼にハマるのか
理由 1: 本を読んでいる間は「失敗しない」
コードを書くと、エラーが出ます。思ったとおりに動かない。自分の無力さを突きつけられる。一方、本を読んでいる間は、理解できている気分になれます。失敗のストレスがない。
本を読む行為は、学習している実感を与えてくれます。しかし、それは「理解した気分」であって「できるようになった」こととは違います。
理由 2: 「準備が足りない」という錯覚
「まだ自分には知識が足りない。もう 1 冊読んでから作り始めよう」。この考えは一見合理的ですが、実際には永遠に「準備完了」の日は来ません。
プログラミングは、泳ぎ方の本を 100 冊読んでも泳げるようにならないのと同じです。水に入らなければ始まりません。
理由 3: 何を作ればいいかわからない
入門書を読み終えた後、「じゃあ何を作ろう」という段階で手が止まる人が多い。本は「こう書けばこう動く」を教えてくれますが、「何を作るべきか」は教えてくれません。
沼から抜け出す 3 つのステップ
ステップ 1: 今読んでいる本を閉じて、50 行のコードを書く
完璧なアプリを作る必要はありません。50 行でいい。今まで読んだ本の知識を使って、何でもいいから動くものを書いてください。
- じゃんけんゲーム
- 今日の天気を表示するスクリプト
- TODO リストのコマンドラインツール
- 自分の好きな言葉をランダムに表示するプログラム
題材は何でも構いません。重要なのは「本を閉じてエディタを開く」という行動の切り替えです。
作りたいものが思い浮かばない場合 (理由 3 の状態) は、発明しようとしないでください。すでにあるものの一部を作り直すのが早い。使っているアプリの機能を 1 つだけ切り出す、本のサンプルコードに入力欄を 1 つ足す、といった改造から始めれば、題材を考える負荷なしに手が動きます。
ステップ 2: エラーが出たら本に戻る
50 行のコードを書く過程で、まずエラーが出ます。そのとき初めて本に戻ってください。「エラーが出たから本を開く」と「なんとなく不安だから本を読む」は、まったく別の行動です。
前者は具体的な問題を解決するための読書。後者は不安を紛らわすための読書。沼にハマっている人は、後者の読書を繰り返しています。
実践的なプログラミングの本は、手を動かしながら読むほど引き出せる情報が増えます。同じページでも、自分のコードが動かない理由を探しながら読むと、通読では飛ばしていた注意書きが目に留まります。
ステップ 3: 「読む → 作る → 読む」のサイクルを回す
本を 1 章読んだら、その章の内容を使って何か小さなものを作る。作る過程でわからないことが出てきたら、次の章を読む。このサイクルを意識的に回してください。
「全部読んでから作る」ではなく「少し読んで、少し作る」。この粒度の切り替えが、本の沼から抜け出す鍵です。
「次の 1 冊」の選び方を変える
沼にハマる人は、「おすすめリスト」から次の本を選びがちです。代わりに、自分が作りたいものから逆算して本を選んでください。
「Web アプリを作りたい」→ Web フレームワークの本を 1 冊選ぶ。「データ分析をやりたい」→ pandas の本を 1 冊選ぶ。目的が先、本が後。この順序にすると、読み終える前に「その本が要るのか」を自分で判定できるので、リストを埋めるための購入が減ります。
読書量の目安
独学の段階では、「読む時間」と「書く時間」の比率を 3:7 にすることをおすすめします。1 時間の学習時間があるなら、20 分読んで 40 分書く。
この比率は目的で変わります。設計やアーキテクチャ、アルゴリズムのように、書く前に概念を持っておいたほうが手戻りが少ない領域では、読む比率が上がって構いません。入門段階で足りていないのは、たいてい「書く」時間のほうです。
もう 1 つの落とし穴は再発です。1 つ作り終えた直後は達成感があるので、次の題材を決める前に「次に読むべき本」を探し始めます。作り終えたらその場で次に足す機能を 1 つメモしておくと、本探しに戻る前に手が動きます。
関連記事
まとめ
「本の沼」の正体は、失敗を避けたい心理と、準備が足りないという錯覚です。抜け出すには、今読んでいる本を閉じて 50 行のコードを書くこと。エラーが出たときだけ本に戻る。「読む → 作る → 読む」のサイクルを回すと、本は沼ではなく、詰まった箇所を解く道具として使えます。
この記事は役に立ちましたか?
関連用語
関連記事
自分で作りたいものがあると本は 3 倍読める
「Web サイトを作りたい」「ゲームを作りたい」。作りたいものがあると、本を読むモチベーションが劇的に変わります。目標の見つけ方と本の選び方を紹介します。
スタックオーバーフローのコピペを卒業する日
Stack Overflow からコードをコピペして動かす段階から、自分で設計して書ける段階へ。この成長の壁を越えるために技術書が果たす役割を解説します。
ゲームが好きならプログラミングの本も読める
ゲームの攻略本を読んだことがあるなら、プログラミングの本も読めます。攻略本とプログラミング本の共通点から、読書のハードルを下げます。
エラーが出たときこそ本の出番
プログラミング中にエラーが出ると焦りますが、そんなときこそ本が役に立ちます。エラーと本の付き合い方を、初心者向けにやさしく解説します。
本を読んでもすぐにコードが書けなくて当たり前
本を 1 冊読み終えたのに、いざコードを書こうとすると手が動かない。これは普通のことです。読書とコーディングの間にあるギャップと、その埋め方を解説します。
本を読んだらすぐパソコンを開こう
プログラミングの本を読んだら、すぐにパソコンを開いて手を動かしましょう。読むだけでは身につかない理由と、読んだ直後にやるべきことを紹介します。