独学プログラマーが「本の沼」にハマる原因と抜け出し方

3 分で読めます
入門学習法技術書

この記事は約 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 行のコードを書くこと。エラーが出たときだけ本に戻る。「読む → 作る → 読む」のサイクルを回すと、本は沼ではなく、詰まった箇所を解く道具として使えます。

共有:Xはてブ

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

関連用語

関連記事

自分で作りたいものがあると本は 3 倍読める

「Web サイトを作りたい」「ゲームを作りたい」。作りたいものがあると、本を読むモチベーションが劇的に変わります。目標の見つけ方と本の選び方を紹介します。

スタックオーバーフローのコピペを卒業する日

Stack Overflow からコードをコピペして動かす段階から、自分で設計して書ける段階へ。この成長の壁を越えるために技術書が果たす役割を解説します。

ゲームが好きならプログラミングの本も読める

ゲームの攻略本を読んだことがあるなら、プログラミングの本も読めます。攻略本とプログラミング本の共通点から、読書のハードルを下げます。

エラーが出たときこそ本の出番

プログラミング中にエラーが出ると焦りますが、そんなときこそ本が役に立ちます。エラーと本の付き合い方を、初心者向けにやさしく解説します。

本を読んでもすぐにコードが書けなくて当たり前

本を 1 冊読み終えたのに、いざコードを書こうとすると手が動かない。これは普通のことです。読書とコーディングの間にあるギャップと、その埋め方を解説します。

本を読んだらすぐパソコンを開こう

プログラミングの本を読んだら、すぐにパソコンを開いて手を動かしましょう。読むだけでは身につかない理由と、読んだ直後にやるべきことを紹介します。