どういった学習プロセスを辿ると技術力が身につくのか
この疑問は、以前から興味がありました。過去の記事でも少し触れています。
今回は、今までの自分の経験と、この疑問を考え続けた結果から、あるひとつのプロセスが浮かび上がってきたのでまとめます。
目次
学習したのに身についていない現実
自分はこんな経験があります。
- あの本を読んだのに、実際の仕事に活かせていない
- 手を動かしてモノを作ったけど、何を学んだか説明できない
- 自己学習をしているが、成長を実感できていない
これは、学習が目的になっている典型的なパターンです。「本を読めば技術力が身につく」「コードを書きまくれば技術力が身につく」と思いがちですが、単に本を読んだりコードを書いたりしただけでは身につかない場合があります。今回浮かび上がってきた学習プロセスでは、この空回りを極力なくし、効率的に知識を身につけることができると考えています。
「身につく」とは
本記事では、「身につく」を以下のように定義します。
「学習して得た知識を使い、より多くの問題を解決できること」
エンジニアは自分の知識・技術力を用いて、問題を解決することがお仕事です。ある技術を知っていても、それを用いて問題を解決できなければ、知らないも同然です。学習をする際、目指す状態はこの定義です。
より多くの問題を解決するには
より多くの問題を解決するためには何が必要でしょうか。それは、汎用性の高い「抽象的な知識」が必要です。
世の中に存在する問題は「具体的な問題」です。これに対して、その問題しか解決できない「具体的な知識」しか持っていない場合は、他に応用が効きません。
たくさんの具体的な知識を覚えようとしても、脳が追いつきません。
そこで、「抽象的な知識」を持ちましょう。脳のリソース消費は少なく、多くの問題を解決できます。
しかし、ただ抽象的な知識を持てば良いかというとそうではありません。もう一つ大切なのは「抽象的な知識を具体的な問題解決に結びつける」という力です。例えば「単一責任の原則（これは抽象的な知識）」を知っているだけでは問題を解決できません。「単一責任の原則」を具体的なコードに適用できなければ、問題は解決されないのです。
まとめると、より多くの問題を解決するには、以下の２つが必要です。
- 汎用性のある「抽象的な知識」を持つ
- 抽象的な知識と具体的な問題解決を結び付ける
では、どのような学習プロセスを辿れば、この２つを身につけることができるのでしょうか。
学習プロセス
いろいろと考えた結果、以下の学習プロセスが浮かび上がってきました。
- 抽象的な知識の「種」を定義する
- 具体的な問題解決にトライする
- 結果から、抽象的な知識を微修正する
- 再度、具体的な問題解決にトライする
- これらのフィードバックループを回して、知識を育てる
順を追って説明します。
抽象的な知識の「種」を定義する
これから、学習プロセスを経て抽象的な知識を育てていくのですが、まずは育てるものがないと始まりません。初めの一歩として、抽象的な知識の「種」を定義しましょう。現在の自分の知識を言葉にするのです。例えば「単一責任の原則とは、ひとつのクラスにひとつの責務だ」というように定義します。抽象レベルはわからなくても構いません。これからこの知識を育てていくのです。
具体的な問題解決にトライしてみる
抽象的な知識を定義したら、実際の問題解決にトライしてみます。例えば「クラスが神クラスになっている」というような問題に取り組みます。先程定義した自分の抽象的な知識を用いて解決を試みます。
結果は以下の３パターンに分かれます。
A. うまく問題解決できた場合
自分の定義した抽象的な知識を用いて、うまく問題を解決できましたか？解決できたのなら、その知識はある程度汎用性があり、具体的な問題に結び付ける力もありそうです。他の問題に取り組みましょう。他の問題も解決できた場合、より多くの問題を解決でき、技術が身についていることになります。
B. 汎用性がなく、解決できなかった場合
あるクラスAの神クラス問題は解決できても、他のクラスBの問題は解決できない場合です。例えば「（クラスAにしかない）◯◯メソッドを✕✕に書き換える」という知識で解決を試みた場合です。クラスAのパターンに特化した具体的な知識となっており、他の問題に応用できません。
これは、知識の抽象レベルが低いことを意味します。一段階抽象レベルを上げて再度トライしましょう。クラスAにもクラスBにも適用できる知識に微修正します。ここはなかなか難しいところですが、頑張って捻り出した知識はあなたをレベルアップさせます。
このように、トライ→フィードバック→トライを繰り返して、適切な抽象レベルを見つけます。より抽象レベルの高い知識を使いこなせれば、解決できる問題も多くなります。知識が育つ瞬間です。
C. 具体的な問題解決に結び付けられず、解決できなかった場合
例えば、抽象的な知識を「単一責任の原則とは、ひとつのクラスにひとつの責務だ」と定義したとき、この言葉だけでは具体的なコードが書けない場合です。これは、知識の抽象レベルが高すぎて、具体的な問題と距離があることを意味しています。
この場合は、一段階抽象レベルを下げてトライします。「目の前の具体的なコードをどう修正するか」を言葉に表しましょう。汎用性は気にしなくても良いです。心配しなくても、次のフィードバックループでまた微修正できます。今は、目の前の問題を解決できる知識まで、抽象レベルを落としましょう。
フィードバックループを回す
上記のようなフィードバックループをぐるぐる回します。ある時は抽象レベルを上げ、ある時は抽象レベルを下げます。抽象的な知識のレベルを１ループ毎に見直し、より多くの問題を解決できる知識になるまでブラッシュアップをします。ある程度まで知識が育てば、より多くの問題を解決できるでしょう。
以上の学習プロセスを１枚の図に表します。
フィードバックループを回して知識を育て、適切な抽象レベルを探します。
学習に対する姿勢が変わる
「知識を育てる」という意識を持つだけで、学習に対する姿勢が変わります。学習全てが、知識のフィードバックループにおける仮説検証に変わります。育てる対象の知識を意識すると、「今から書くコードは◯◯という知識の検証だ」「◯◯の知識が正しいかを確かめるために、この本を読む」となります。この姿勢で学習に取り組むと、既存知識との差分がわかったり、知りたい箇所ではない部分を読み飛ばしたりできます。このような学習は、冒頭で述べた「空回り」を極力無くすことができます。
まとめ
「技術力が身につく」とは「学習して得た知識を用いて、より多くの問題を解決できること」です。そして、より多くの問題を解決するためには、以下の２つが必要です。
- 汎用性のある「抽象的な知識」を手に入れる
- 抽象的な知識と具体的な問題解決を結び付ける
これらをトレーニングする学習プロセスは以下です。
- 抽象的な知識の「種」を定義する
- 具体的な問題解決にトライする
- 結果から、抽象的な知識を微修正する
- 再度、具体的な問題解決にトライする
- これらのフィードバックループを回して、知識を育てる
最終的に「より多くの問題を解決できるように知識を育てていく」というシンプルな方法が浮かび上がってきました。知識が育っていくと、自分でできることが増えていくので自信に繋がります。めちゃくちゃ伸びる人、というのは、このようなフィードバックループを無意識に回しているんじゃないかと思います（これも仮説ですが）。もし何かご意見等あれば、twitterなどでつぶやいていただくとうれしいです。
実はこのプロセスも、自分の仮説検証の最中です。様々な学習に適用できるかを検証しています。一旦整理する意図でブログにまとめました。今後、何らかの気付きがあった場合は、また記事に書くかもしれません。
