働きながらの学習計画が崩れるのは、勉強時間ではなく下限の設計不足

働きながらプログラミングを学び始めるとき、多くの人が最初にやる計算がある。「1日2時間、6ヶ月続ければ360時間。それだけあれば転職できるレベルに届くはずだ」というような、時間を積み上げる掛け算だ。ゴールが遠くて不安なとき、この計算は驚くほど気持ちを軽くしてくれる。終わりの見えない努力が、いつ終わるか分かるスケジュールに変わるからだ。

だが、この計算式を立てた人ほど、1ヶ月も経たないうちに計画表を見なくなる。中身の割り付けを間違えたわけではない。掛け算そのものの前提が、働きながら学ぶ人の生活と噛み合っていないのだ。なお「続いた理由が気分か決めごとか」という継続の質は独学3ヶ月 続く人の分かれ目で扱った論点だが、本稿が見るのはその手前の話、そもそも量をどう積むかという計画の立て方そのものだ。

掛け算モデルが心地よい理由と、壊れる理由は同じ場所にある

「1日◯時間×◯ヶ月=到達に必要な総量」という式は、毎日ほぼ同じだけの時間を積み上げられることを暗黙の前提にしている。仕事のある日も、残業がある日も、飲み会がある日も、子どもの体調が悪い日も、その日の学習時間はだいたい同じ、という前提だ。

働いていない生活ならこの前提はそれほど乱暴ではない。しかし働きながらの学習では、日によって使える時間の落差がそもそも大きい。ある日は2時間確保できても、別の日は30分、さらに別の日はゼロになる。掛け算モデルはこの落差そのものを吸収する仕組みを持っていない。ゼロになった日は「後で埋め合わせる分」として静かに未来の自分に転嫁されるだけで、計画表の数字は動かない。埋め合わせが積もるほど、残りの日1日あたりに必要な時間はじわじわ膨らんでいく。気づいたときには、計画を立てた時点よりもずっと厳しい掛け算を強いられている。

折れるのは「量が減った日」ではなく「ゼロになった日」

ここで見落とされがちなのが、学習が止まる引き金は「量が足りない日」ではなく「量がゼロになった日」だという点だ。1時間の予定を30分しかできなかった日は、確かに計画からは遅れる。しかし翌日また30分でも1時間でも机に向かえば、学習という行為自体は途切れずに続いている。

ゼロの日は違う。その日は行為として何も残らないだけでなく、「今日はできなかった」という記録が心理的な区切りとして残る。翌日机に向かうとき、続けていた昨日の続きを再開するのではなく、途切れた後にもう一度始める、という一段階余分な負荷がかかる。この再開コストは、単純に空いた1日分の遅れでは説明できない大きさになりやすい。忙しい時期にゼロの日が2日、3日と連続すると、遅れの量よりも「もう一度始める」という心理的な障壁のほうが、学習を止める決定打になる。

つまり掛け算モデルの本当の弱点は、平均の時間数を見誤ることではない。忙しい日にゼロへ落ちることを想定していない、という設計上の欠陥にある。多くの学習アプリが「継続日数」という指標を大きく扱うのも、理解度や総学習時間ではなく、ゼロの日が出たかどうかを映していると考えると腑に落ちる。

増やすべきは1日の量ではなく、ゼロにしない「下限」

ここから逆算すると、学習計画で本当に決めるべき問いが変わってくる。「1日何時間確保すれば目標に届くか」ではなく、「自分の最も忙しい日でも、これだけは崩れずにできる、という下限をどこに置くか」だ。

この下限は、平均的な日の学習量とは別物として設計する必要がある。平均の日にできる量を基準にすると、忙しい日はその基準を割り、割った瞬間にゼロへ滑り落ちる。逆に、最も忙しい日を基準にして下限を決めておけば、平均的な日はその下限を上回るのが当たり前になり、ゼロという最悪の結果そのものが起こりにくくなる。

具体的には、下限は「意志力をほとんど使わずに実行できる量」まで削っておくのが安全だ。目安として大きい数字を置くのではなく、疲れて帰った日、予定が崩れた日でも、迷わず手が動く小さな単位を先に決めておく。その日にやる中身まで事前に決めておけば、判断そのものに使う気力も節約できる。何を触るかで迷う時間が長いほど、下限は簡単に崩れる。

到達までの月数を決めているのは、実は1日の平均学習時間ではない。下限をどこまで低く、かつ確実に守れる形で設計できたか、その一点だ。大きな下限を掲げて時々ゼロに落ちる人より、小さな下限を毎日守れる人のほうが、結果的に総量を積み上げやすい。

それでも下限が崩れ続けるなら、意志の問題ではなく設計の問題

下限を意識して小さく設定したのに、それでも忙しい時期にゼロへ落ちることが繰り返されるなら、そこで責めるべきは自分の根性ではない。多くの場合、その人にとっての「本当に崩れない下限」は、自分一人の決めごとの中には存在せず、締め切りや他者の目という外部の力を借りたときにだけ機能する、というだけの話だ。

これは能力の差ではなく、続き方のタイプの差にすぎない。自分で決めた下限が一人でも守れるタイプなのか、外から締め切りを課されたときにだけ下限が崩れなくなるタイプなのか。この見極めが、独学を続けるかプログラミングスクールは意味があるかで扱ったような伴走の仕組みを借りるかを決める、実質的な判断材料になる。

見極め方は難しくない。過去に自分一人で決めた下限(毎日の運動でも、資格の勉強でも)が、忙しい時期にどれだけ持ちこたえたかを振り返るだけでいい。持ちこたえた経験があるなら、下限の置き場所をもう一段下げれば独学でも十分に機能する。持ちこたえた経験がほとんど無いなら、下限の低さではなく、下限を守らせる仕組みそのものを外から持ち込むほうが近道になる。

まとめ:問うべきは「1日何時間か」ではない

「1日どれだけ確保すれば届くか」という問いは、忙しい日にも同じ時間が使えるという前提のもとでしか意味を持たない。働きながら学ぶ生活では、その前提自体が崩れている。

だから最初に決めるべきは、平均的な1日の学習量ではない。今週いちばん忙しかった日を思い出し、その日でも崩さずに実行できた量はどれだけ小さかったか、その下限を先に測っておくことだ。下限が小さすぎて意味がないと感じても構わない。ゼロに落ちない下限を毎日守れることのほうが、大きな目標時間を掲げて時々ゼロに落ちることより、結果的に遠くまで届く。

こうした「独学かスクールか」「毎日何を触るか」の判断材料になる教材データは、tasklogでも継続的にまとめている。次に毎日の下限で何を触るか迷ったら参考にしてほしい。

https://s-tasklog.com/learn/python