勉強しただけで満足してしまう問題
技術書を読んだり、動画を見たり、記事を読んだりすると、勉強した気持ちになります。
自分もよくあります。
新しい概念を知った瞬間は気持ちがよいですし、「なるほど、分かったかもしれない」と思えます。ですが、いざ誰かに説明しようとすると、急に言葉が出てこないことがあります。
あれって何が大事だったんだっけ。
どこが既存のやり方と違うんだっけ。
実務ではどう使うんだっけ。
この状態になると、インプットしたつもりでも、まだ自分の中では整理しきれていなかったのだと分かります。
そこで大事になるのが、発表やアウトプットです。
発表は、理解の甘さを見えるようにしてくれる
発表すると、理解の甘さが分かりやすく出ます。
自分だけで読んでいるときは、分からないところをふわっと飛ばせます。ですが、人に話すとなると、そうはいきません。
- 何の話なのか
- なぜそれが必要なのか
- どんな場面で使うのか
- 何に注意すればよいのか
- 自分はどう解釈したのか
このあたりを順番に言葉にする必要があります。
たとえば、Rubyの簡単なメソッドでも、自分だけが分かればよいならこのくらいで済ませてしまうかもしれません。
def greet(name)
puts "Hello, #{name}!"
end
でも、人に説明するなら、
-
nameは何を受け取るのか -
putsは何をしているのか - 戻り値は何なのか
- 実務で使うならどこに置くのか
まで考えることになります。
この「説明するために一段深く見る」作業が、理解を育ててくれるのだと思います。
発表は、自分の言葉に変換する作業でもある
インプットした内容をそのまま話しても、あまり残りません。
資料や本に書いてある言葉を借りるだけだと、自分の理解になりにくいからです。
発表の準備をしていると、
- 自分ならどう例えるか
- どこでつまずいたか
- 何が分かると楽になったか
- 仕事ではどう使えそうか
を考えるようになります。
この過程で、借り物の知識が少しずつ自分の言葉に変わっていきます。
考えるために、まず書く。設計が進まないときの思考整理 と同じで、頭の中だけで考えているものは形があいまいです。外に出して初めて、足りない部分が見えます。
発表資料は、未来の自分を助ける
発表の良いところは、その場の説明だけで終わらないことです。
発表資料を残しておくと、あとから自分が見返せます。
たとえば半年後に同じテーマで悩んだとき、
- 当時どこでつまずいたか
- どんな順番で理解したか
- どんな例が腹落ちしたか
- どの資料を参考にしたか
が残っていると助かります。
これはチームにとっても同じです。
誰かが発表した資料は、その人だけの学びではなく、チームの知識になります。
記録は未来の自分への申し送りである でも書いたように、記録は未来の判断材料です。発表もまた、未来に渡せる記録なのだと思います。
小さな発表で十分だと思う
発表というと、きれいなスライドを作って、長い時間話すものを想像しがちです。
ですが、最初から大きくやる必要はないと思っています。
たとえば、
- 読んだ記事を3分で共有する
- 学んだコマンドをSlackにメモする
- PRで判断理由を少し詳しく書く
- 勉強会で5分だけ話す
- ブログに学びを残す
これくらいでも十分です。
大事なのは、インプットしたものを一度自分の言葉にして外に出すことです。
発表すると、質問で理解が深まる
発表していると、質問をもらうことがあります。
この質問がありがたいです。
自分では見えていなかった前提や、説明が薄かったところを教えてくれるからです。
質問されたときに答えられなかったとしても、それは失敗ではなく、次に学ぶ場所が見つかったということだと思います。
間違っていても記録する。未来の自分に判断材料を残す にも近いですが、完璧な理解になってから出すのではなく、途中の理解を出すことにも価値があります。
明日からできること
まずは、小さくアウトプットするところからでよさそうです。
- 今日学んだことを3行で書く
- なぜそれが大事かを1文で書く
- 実務で使うならどこかを書く
- 分からなかったことも残す
- 可能なら誰かに話してみる
これだけでも、ただ読むより理解は残りやすくなると思います。
まとめ
インプットはもちろん必要です。
ですが、発表やアウトプットを挟むことで、理解は一段深くなります。
人に説明しようとすると、曖昧な部分が見えます。自分の言葉に変換しようとすると、知識が整理されます。そして残した資料は、未来の自分やチームを助けてくれます。
まずは小さく、学んだことを誰かに話せる形にしてみたいです。