「技術」は「課題」とセットで学ぶ
当たり前のことかもしれませんが、ふと忘れがちになってしまうので自戒も込めて記します。
TL;DR
- 技術の仕組みだけを勉強するのではなく、その技術が解決しようとしている「課題」も意識すると身につきやすい
身についた技術と身につかない技術がある
ふと思い返してみると、気づいたことがありました。日頃勉強をしているのに、身についた技術と身につかない技術があるのです。
今回は、「これはなぜだろう？」と疑問に思ったのが発端です。単純に勉強時間と相関があるわけではなさそうです。
身についた技術に対して何をしたか
どんなことをしたらその技術が身についたのかを、ざっくり振り返ってみます。
- 身についた
- 自作ライブラリを作った
- 業務で使用した
- 身につかない
- 書籍をパラパラと読んだ
- 仕組みだけを勉強した
- 惰性で勉強会に参加した
身についた技術には何か共通項があるのでしょうか。
共通項は？
軽く共通項を考えてみると「実際に手を動かしたもの」が身についていそうです。よく「うだうだ言ってねーでコード書け！」と耳にしますが、それは間違いではなさそうです。しかし自分の場合、「手を動かした技術は本当に身についているんだっけ？」と疑問に思いました。手を動かせば100%身についているか、と問われると、首を縦には振れません。
ということは、もっと他に「身につく要因」があるはずです。
「身につく」を紐解く
ゴールから辿ってみます。「技術が身につく」とはどういうことでしょうか。
自分の考える定義は、「その技術を使って課題を解決できる」ということです。ある課題があり、それに立ち向かい、適切な技術を選択し、その課題を解決する、ということです。さらに言い換えると「課題に適した技術を選択できる」ということです。その技術が身についていないと、適切な選択はできません。
「技術と課題の結びつき」を知る
適切な技術を選択するには、どの技術がどの課題を解決するのか、という「技術と課題の結びつき」を知る必要があります。この知識が間違っていると、適切な選択はできません。技術の勉強は、この「結びつき」を知ることだと思います。
単に「仕組みを理解すること」ではないのです。仕組みを知っていても、使い所がわからないと価値は生み出せません。
TDDのやり方を知っていても、TDDがどのような課題を解決するのかを知らないと、不適切な場面でも適用してしまいます。dockerはどんな課題を解決しようとしていますか？reactはどんな課題を解決する技術なのでしょうか。これらの知識を増やすことこそが、エンジニアの勉強だと思います。
まとめ
もう一度「身についた技術に対して何をしたか」を考えてみると、「その技術を使って課題を解決した」と言えます。課題を解決した経験から、技術と課題の結びつきが頭にインプットされたのです。自分の技術で解決できる課題が増えた瞬間です。
そもそも技術とは、何らかの課題を解決するために生まれてくるものです。それを忘れて「技術学ぶぜー」と意気込むだけで、何を解決しようとしているのかを考えないのは危険です。ただチュートリアルをこなして仕組みを理解するだけでは、自分の技術力はどこで発揮できるのかがわかりません。価値を生み出すことは難しいでしょう。
今後は、ある技術を学ぶ時は、
- その技術は「どのような課題」を解決するのか
- 課題の具体例を挙げてみる
- その課題を「どうやって」解決するのか
- 実際にその課題を解決してみる
という２点を重視して勉強していこうと思います。
