はじめに
自分にとってBetterな学習プロセスについて記述します。
学習効率とは、理解の広さx深さ/時間 のことで、これを最大化する上で最も実行しやすいやり方について、Betterという表現を使わせてもらいました。
Bestな学習は必要以上に学習に負担を与え、必ずしも学習効率を上げるとは限らないという考えからです。
学習プロセス
アウトラインをざっくり読む
- できるだけ公式のドキュメントを参照する
- 公式のドキュメントにアウトラインやチュートリアルがない場合は必ずしも、公式ドキュメントを追わなくても良く、最も理解しやすいと感じたドキュメントを参照する
- アウトラインはできるだけ理解しながら読むのが良いが、理解が難しい場合は一旦飛ばして、学習を後回しにする
- その際、TODOとして何かしらのチェックは入れておく
- アウトラインからの参照は必要以上に多くしないようにする
- ５分以上脱線する事柄は学習を後回しにする
手を動かす（モノを作る)
- ざっくりと手を動かす
- プログラミングならチュートリアルを行ったり、簡易な実装を行う。数学なら問題演習を解く。
- 理解している事柄と理解していない事柄について明確に分けておく
- 理解せずに動いたものについては、忘れないようにTODOとしてチェックを入れておく
- 必要以上に作り込みすぎない
- あくまでも理解する上でのアウトプットなので、必要以上にこらない
アウトラインを精読する
- 実装や問題演習が終わったら、再度ドキュメントを読み直す。
- 今度は理解していない箇所が無いように精読する。
- わからない箇所はわかるまで読み直すか人に聞く。
理解した事柄についてまとめて、ドキュメントとして公開する
- 理解した事柄について、qiitaや hatena blogなどで、ドキュメントを公開する
- 公開するドキュメントはできるだけ齟齬や間違いなどは無いように意識する
- あまり間違いを気にしすぎるのも良くないので、公開する上で気をつけること、と意識する
さいごに
人によっては、最初のドキュメントを読む段階ですべて理解することを意識したり、とりあえず実装する過程を省略するかもしれないが、自分の場合モチベーション維持の観点で失敗しやすかった。
上記はあくまで自分のBetterな学習プロセスであり、Bestな学習プロセスではないことを留意する必要がある。
