エンジニアにとって技術スキルを磨くために「勉強する」ことは必要な要素かと思いますが、
この「勉強する」とはどういうことなのか？ということを言語化した本が[科学的根拠に基づく最高の勉強法]という本です。
そもそも勉強するとは何か？
「勉強した」を表現する際に、「〇時間勉強した」「〇〇ページ勉強した」「〇問解いた」などの指標に変換されることが多いが、ある集団が同じ勉強範囲を同じ期間勉強した後に試験を行い、誰かの点数が高ければ「頭が良い」、点数が低ければ「頭が悪い」と評価してしまうことがあるが、そうではないです。
大事なのは「〇時間勉強した」「〇〇ページ勉強した」「〇問解いた」という指標ではなく、「どのように勉強した」のプロセスです。
科学的に効果の高くない勉強法
効果の高い勉強法を知る前に、今まさに勉強に取り組んでいる人に気づいてもらうには"効果の高くない勉強法"を知り、それをすぐにやめることです。
ではその"効果の高くない勉強法"とはどんな方法なのかをご紹介していきます。
繰り返し読む(再読)
何度か読書することで、同じ文章を読むのですらすらと読めてしまうことから「わかった気になってしまう」ようですが、これは「流暢性の錯覚(幻想)」と言われ、深く理解していないにもかかわらず、覚えた気になってしまう心理的な現象に陥ってしまうようです。
コロラド大学の大学生を対象とした約1,500～1,700語の文章を再読するグループと、再読しないグループに分け、2日後に試験を受けてもらったところ、文章を続けて2回読んだ学生と、1回読んだ学生では試験の成績に差はないという結果が出ています。
このことから、再読には学習効果はあまりないことがわかります。
何回も読むことで「流動性の錯覚」に陥り、学習した気にならないように気を付けなければなりません。
エンジニアにおいて技術書は勉強する上で必要なアイテムかと思いますが、何度も読むこと自体に効果はないことを把握しておきましょう。
ノートに書き写す・まとめる
技術書などで学んだ内容を「ノートに綺麗に書き写す」「まとめる」などをした経験がある方、そのノートに書き写した内容、誰かに説明することができますか？
おそらくほとんどの方はできないのではないでしょうか。
アメリカの研究結果で高校生180人を対象に以下のグループに分け、アフリカ部族に関する文章2000語の文章を読んでもらい学習効果を研究した内容です。
方法
- Aグループ: 各ページを読んだ後に短く3行に要約する
- Bグループ: 読んでいるときに重要だと思う文章が出てきたら自分の言葉でノートに書く
- Cグループ: 重要だと思う文章を3行そのまま書き写す
- Dグループ: 文章を読むだけ
勉強直後と1週間後に試験を受けたところ、結果はCとDグループの結果は変わらず、AとBグループの点数は同等で、ただ書き写した場合や読んだだけの学生よりも高得点だったという結果が出たそうです。
書かれた文章をそのまま書き写す作業は文章を記憶したり理解したりしなくてもできることから、脳にかかる処理がほぼ行われないため効果が薄いようです。
ここまで読んでエンジニアの学習においても技術書を読んでとりあえず意味不明な状態で最後まで読んで終わって読了！よりも、わからない点は調べながら深堀りしていき、かつNotionなどにわからない内容を自分の言葉に置き換えて読み進めたり、ブログへアウトプットすることで記憶への定着率が高い勉強法であることがわかります。
「休日に10時間勉強した」と時間に着目するのではなく、たとえ3時間の学習だったとしても、それを人に説明できるレベルまでになっているのかどうか？に着目し、学習することで時間を無駄にすることもなくなるでしょう。
科学的に効果の高くない勉強法まとめ
- 繰り返し読む(再読)
- ノートに書き写す・まとめる
ここまで「科学的に効果の高くない勉強法」を紹介してきましたが、では「科学的に効果の高い勉強法」とはどんな勉強法なのでしょうか？
次の章からは"科学的に効果の高い勉強法"についてご紹介します。
科学的に効果の高い勉強法
精緻的質問
精緻的質問とは学習した内容に対して「なぜそうなっているのか(Why)?」「どうしてそうなっているのか(How)?」を自分自身に問いかける勉強法です。
生物学を履修した大学生294人を対象とした研究で、人間の消化についての文章を読んでもらい、
半分の学生には「なぜそうなっているのか」という質問に答えながら読んでもらい、
残りの半分には「ただ再読」してもらった結果、精緻的質問を用いた学生の平均点は76点で、再読だけを行った学生の平均点は69点という結果がでています。
エンジニアの学習においてもエラーに遭遇した、これをエラー内容でググってとりあえず解決した人と、「なぜこのエラーになったのか？」「どうしてこうすると解決するのか？」を自分自身に問いかけて解決できた人では後者の方が理解力の高いエンジニアであることがわかるかと思います。
Linuxのコマンド一つとっても、そのコマンドにはなぜこのコマンドなのかという理由がわかります。
lsコマンドはファイルやディレクトリを表示するコマンドですが、lsはlistを略しています。
cdコマンドはディレクトリを移動するコマンドですが、cdはchange directoryを略しています。
上記は非常に簡単な例ですが、このように一つ一つの内容をなんでこのコマンドはこういう動きをするのだろうか？と問いかけてみると合点がいくかと思います。
昔、私がエンジニアになりたての頃、当時の開発部長に「なぜこうなのか？」という質問をしたところ、マウントを取られた経験があります。
「そんなものはこういうルールで決まっているから考えても無意味」だと。
私は今でもこの言葉を忘れることはないです。
「ルールで決められているから無意味」なんてことはないはずです。
必ずそうなるには理由があるはずです。それを追求するのがエンジニアだろう、と今でも思います。
自己説明
これは資格学習において活用できる内容かと思いますが、「自分はここがはっきりわかっていない」「ここはだいぶ理解できた」を客観的に評価し、把握することが重要です。
例えばAWSの認定資格を取得するために問題集を使って学習するかと思いますが、その際
- 問題の内容を理解して解くことができ、正解できた場合 -> 青いマーカーを塗る
- 問題の内容理解はなんとくだが、正解できた場合 -> 黄色いマーカーを塗る
- 問題の内容も理解できず、間違っていた場合 -> 赤いマーカーを塗る
などとして自分の理解度を可視化し、復習の際には黄色いマーカーと赤いマーカーで塗ったものを重点的にやることで学習効率を大幅に上げることができるでしょう。
私は実際に上記のように理解度を可視化して学習に取り組むことでAWS Certified Solutions Architect Professional(SAP)の試験に合格することができました。
勉強のモチベーション
勉強をするうえでモチベーションを保ち続けることが難しいことがあるかと思います。
難しいと感じない方はこのセクションを読む必要はありません。
自己効力感
モチベーションを保つための重要な概念に自己効力感というものがあります。
ある目的を達成するために、必要な行動を自分がどの程度うまく行うことができるかという個人の確信の程度で「自分にはこれができる」という感覚のことを指します。
自己効力感には次のようなものがあります。
- 成功体験: 自分自身で課題に取り組み、成功する経験を積むこと
- 言語的・社会的説得: 上司や親から「君ならうまくできる」「このプロジェクトは大変だけど君ならうまくいく」などと期待されること
小さなことでも良いから成功体験を得るとモチベーションに繋がりますよね。
ここで大事なことは「こんなちょっとしたことを成功しても」と思わないことかと思います。
「上には上がいる」という言葉があるかもしれませんが、「上にいる人」も小さな成功体験を積み重ねていって自分よりも上にいるのです。
小さいことの積み重ねがいずれ自分が上に立つ日がくるので、ちょっとしたことで成功を喜びましょう。
自己決定理論
自己決定理論では次のような3つの心理的欲求があり、これらが満たされるとモチベーションが推進されるようです。
- 自律性: 他人に強制されたり、圧力を感じたりせずに自分の行動を自分で選択・決定すること
- 有能感: 自分が何を上手にできるという実感や、特定のタスクや挑戦を成功させる能力
- 関係性: 他人とのつながりや帰属意識をもつこと
本書の中で上記の欲求がなぜモチベーションにつながるのかをわかりやすく例えた内容が以下です。
「ファイナルファンタジー」や「ドラゴンクエスト」などのゲームは多くの方がプレイしたことがあるでしょう。
まず、ゲームをやるということは、誰かに強制されるのではなく自分がやりたいからやる、という自発的なものです。
ゲームの中ではたくさんの選択肢が用意されていて、自分が行動を決めることができるので自律性の欲求が満たされます。また、敵を倒す達成感やレベルが上がることによって成長していく感覚があり、有用性の欲求が満たされます。そしてゲームの中の仲間とつながる感覚もあります。
私自身もファイナルファンタジーやドラゴンクエストをプレイしたことがあります、一番楽しいと思ったのはレベルをコツコツ上げることでした。
なぜならレベルをあげるとどんどん攻撃力が高くなって、相手に与えるダメージが増えるからです。
これを現実世界に置き換えたときに、エンジニアとしてレベルをコツコツ上げることで書けるコードの知識が増えたり、エラーに遭遇しても、このエラーはこうすれば解決できるだろう、などと解決能力が高くなることに欲求を感じ、モチベーションを保つことができています。
まとめ
ここまで"科学的に効果の高くない勉強法"と"科学的に効果の高い勉強法"についてご紹介してきました。
私がこの本を読んで一つ確信したことはブログを書くことは最強の勉強法であることだと思ったことです。
本文中では詳細にご紹介しませんでしたが、ブログを書くということは
- ブログのテーマについてまず自分が知らなければならない
- 知らなければならないということは調べてインプットしなければならない
- インプットした内容を自分以外の人間が読んでもわかるようにアウトプットしなければならない
このプロセスは3行で表すと簡単なことのように見えますが、非常に時間のかかる作業です。
そして、あるテーマについて書こうと思ったときに必ず「ぁ、この内容ってなんだっけ？」にぶち当たります。
そうです。自分が意外にわかってない内容を把握できます。
これは自己説明の章でも解説しましたが、自分がはっきりわかっていないことを把握するためにも必要なプロセスを勝手に踏んでいるのです。
また、ブログというのは誰かに説明するように書く必要があるので1プロテジェ効果があります。
エンジニアは"よくわからないことはググれば良い"などと聞いたことがあるかと思いますが、たしかにわからないことはググりますが、ググる時間を短縮することができればその分設計を考える時間に充てることができたりと、別の本質的な部分に時間を割くことができます。
ブログを書くことで、知識の定着率がぐんと上がり、"ググる"という行為を減らすことにもつながります。
私はよくクラスメソッドさんの2DevelopersIOを参考にすることがあります。
DevelopersIOの技術記事を執筆する理由は知識や経験のナレッジをシェアすることはもちろんかと思いますが、あの目的は"もう二度とググらない"ために書いているということも目的の一つなのだと思います。
私も個人的にググる時間を減らすために技術記事を書いています。
ググる時間を減らすために技術記事を書いていると、実は自然と楽しくなっていきます。
技術記事を書くのが楽しくなって、記事を書くことが習慣化されます。
ぜひ、この記事を読んで技術記事を書いてみようかな？と思った方は何でも良いからまずは"書いてみること"に行動を移してみてはいかがでしょうか？
ここまで読んでいただきありがとうございました。