「したほうが良いこと」を「しない」勉強法
社会人が何かを勉強するとなると、その時間の確保が重要になります。
前回は、タイパを高めるために社会人は寝るべきだという記事を書きました。
今回は、「したほうが良い」ことはやるな、という話をします。
決して逆張り芸人ではありません。まぁ聞いてください。
した方がよいことリスト
勉強するときに、「した方が良いこと」は以下のようなものです。
覚えるべき内容は完璧に覚えてから次に進んだ方が良い
重要なことはノートにまとめるなどして、徹底的に理解した方が良い
プログラムのコードはコピペせずに手打ちで全部打ち込んで練習する方が良い
紙のノートに手書きをする方が学習効果が高いという噂もあるので、手書きでなんでもまとめた方が良い
「まぁ、そりゃそうじゃろ」という内容だと思います。
"した方が良い" == "必須"
=> false
そもそも「した方が良い」って何でしょうか。
そんなことを言い出したら・・・
毎朝5時に起きて毎日1時間ランニングをした方が良い
毎日勉強は5時間した方が良い
残業はせずに学習時間を確保した方が良い
スマートフォンは見ない方が良いのでSNSは全部アカウント削除した方が良い
身体の調子を保つために毎週整体に通った方が良い
月収は1億円の方が良い
みたいな主張もまかり通るわけです。
「いやいやそんな大袈裟な」と思うかもしれませんが、
では具体的に、どのラインならOKになるでしょうか？
もちろんベターを追い求めることは大切ですから、「〇〇した方が良い」という思考自体が不要とは言えません。
しかし、自分の生活や習慣を決める軸を、その考えに任せすぎると危険である。とは言えそうです。
ちなみに小見出しの "した方が良い" == "必須" => false というのは、「した方が良い＝必須 ではない」をrubyの構文で表したものです。
ほな、何を「しない」か？
「した方が良い」という考え方は、うまく線を引いてカットしてあげないと「月収は1億円の方が良い」と同列の夢物語、理想論になる可能性があります。
では、何を「しない」ようにするべきか？
僕の提案は、一旦「ぜんぶ」です。
全部いったんやめましょう。
全部ナシにしてから考える
さて、全部一旦やめました。
早起きも、毎日5時間の勉強も、月収1億円も、
まぁいったん忘れましょう。
そのうえで、「いちばん大事なこと」から考えます。
いちばん大事なことを決めるためには、
「なぜそれをするのか」といった動機が重要になってきます。
もう少し具体的に言うなら、「いま勉強したい内容がどのステップか？」を考えてみると良いです。
ステップごとに頭と手の使い方は違う
たとえば僕の場合、Rubyを勉強しているといくつかのフェーズに出くわします。
全く知らないことを覚える。（配列、ハッシュ、メソッド、クラス、インスタンス）
かろうじて知っていることを、うっすら理解する。（問題は解けたり間違えたりする。答えを見ればわかる）
間違えずにコーディングの問題を解ける。解答について自分で説明もできる。
理解したことを応用し、手足のように操る。（答えを見なくてもできる。それどころでなく、同じ機能をもつ別のコードを書ける）
僕はプログラミングを勉強して「自分で、自分の思い描いた通りの動きをするコードを書きたい」ので、目的地は上記4.のフェーズであると言えますね。
それぞれのフェーズで、僕はこう勉強しています。
各ステップの勉強法紹介
まったく知らないことを覚える時は、紙に書き出しながら1文字1文字をしっかりと認識しながら覚えていく。
（例：ハッシュのキーにはコロンが付く、メソッドはendで締める、クラスの名前は大文字で始まる、インスタンス変数には@が付く）かろうじて知っていることを理解するときは、自分のコードに対してコメントアウトで、誰かに教えるつもりで解説を加えていく。手が止まったところは理解が足りないので復習する。
（あとで知ったのですが、ファインマン・テクニックと言うらしいです）2を繰り返していると、自然に模範解答に近いコードが書けるようになる。
手足のように操るためには、実際にコードをじっくりと読み、「ここはこう書き換えても同じように動くのではないか？」という仮説を立てて、実際にコードを書いてみる。もし動かない場合は、なぜ動かなかったのか調べる。ちゃんと動いた場合は、自分に拍手を送る。
このように、自分の理解度に対して最適な勉強法は異なると思っています。
今やりたい勉強はインプットかアウトプットか？
上で紹介したプロセスは、以下のように抽象化できます。
「未知の概念や知識との邂逅」
「自分がどこまで理解したか確認」
「徹底的な2.の反復」
「自分がどこまで技術として取り込んだかテスト」
勉強の各段階を、上記のようなステップに言い換えてみました。
ここでポイントになるのは、徐々にインプットからアウトプットに重心移動していることです。
インプットから始めてアウトプットへ移る
知らないことを書いて覚える（インプット100％）
調べながら、自分なりに解説してみる（インプット30％：アウトプット70％）
（徐々にアウトプットに重心を移す）
自分で書いてみて、ダメなら調べる（インプット10％：アウトプット90％）
繰り返しますが、「エンジニアとしてコードを書けるようになる」は、抽象化して言い換えると「アウトプットできるようになる」です。
だから、徐々にアウトプットに重心を移していくのはごく自然な練習のプロセスであると言えます。
作業の損益分岐点を考える
最初のインプットの段階では、「紙のノートに書いてまとめる」が重要になります。
コードをコピペして読むだけでは、「ハッシュのキーにはコロンがついている」「defの後はendで締める」といった細かいことを見落としていても気づきにくいからです。
こういった細かい点に気づかないまま覚えると後々エラーまみれになり、苦労しそうです。
しかし、徐々にコードの量が増え、理解する対象が複雑になるにつれ、「ノートに書くことにより得られる効果」よりも、「ノートに書く時間がかかるデメリット」の方が大きくなる転換点が来ます。
ここで、「重要な点はノートにまとめて理解した方が良い」は、
「月収が1億円の方が良い」と同じ次元、単なる理想論に堕ちたと言えます。
つまり、これまで「紙のノートに書いて覚える」が最高の勉強法だったのに、あるときから「時間がかかるわりに効果が低い勉強法」になってしまいました。
このように、「効果」と「時間」の軸を要素として加えることで、「〇〇した方が良い」の評価は大きく変わるということです。
怠惰も上手く使えば役にたつ
ここまで見てきたように、勉強するときに「〇〇した方が良い」という思考はあまり汎用性がありません。
その時々のインプット・アウトプットの比率や自分の理解状況によって最適な学習方法を切り替えていくことが重要です。
その「切り替え」の考え方として外せないのが「した方が良い」を捨てるということです。損益分岐もしっかり考えて「〇〇だけしておけばOK」という思考停止をやめることです。
僕は現状プログラミングの学習を開始して6週間程度のところにいますが、
学習させていただいているスクールにおける3ヶ月分のカリキュラムを5週間ほどで終えることができています。
僕は基本的に面倒くさがりで、無駄な勉強や作業はできるだけやりたくありません。（プログラマの三大美徳のひとつ、”怠惰”ですね）
その結果、本記事のような効率重視指向が生まれ、結果的に学習進捗に効いていると思います。
これからも一生勉強していく身ではありますが、以前の記事でも書いたように「勉強の醍醐味の一つは、勉強自体が上手くなること」でもあるので
現時点で考えていることをまとめてみました。
参考になれば幸いです。
おしまい。
この記事が気に入ったらサポートをしてみませんか？