1ヶ月あるはてなインターンの前半2週間が終わった。前半は基本的にWeb周りの講義を毎日行い、それぞれ課題をこなすというものなのだけれど、僕は前半はインターン生のうちの二人のサポートというポジションだった。
僕は人と話したり、教えたり、というのが好きなので、この二週間かなり楽しんで仕事ができた。その中で、教えるということについて結構勉強ができたと思ったので、軽くまとめてみる。
答えを示さない
場合にもよるのだけれど、教えるときには答えを教えない、ということは大切だと思った。
プログラミングの場合、何かしらのエラーでハマっている時、「何故か動かない」と聞かれる時が多い。自分がその言語に結構精通していれば、エラーを見た瞬間にだいたい何がおかしいか分かる。しかしここですぐに修正方法を教えてしまうと、違うエラーが出た時にまた対処が出来なくなって、そのたびに教える必要がある。
答えを教えるのではなく、原因の見つけ方を１つずつ教えて行くほうが良いと思った。具体的にはエラーメッセージをどう見るか、printでデバッグする時にどのへんに辺りをつけていくと良いか、など。こうしておくと次からは自分でエラーを探せるようになる。
当たり前かもしれないけど、答えを教えるのではなくて、手順を教えるというほうがよさそうに思った。
人によって教え方を変える必要がある
一番勉強になったのは、人によって教え方を変えたほうが良いということ。
ある概念を教えるときに、その人の知っている知識に合わせて説明の仕方を変える。人によって現状理解している概念が異なるので、それに合わせて教えるほうが早く理解してもらえた。例えばはてなにおけるORM(というかDBIのラッパなのだけど)を説明するときに、
- RubyでWebアプリを作ったことのある人には、RubyのこのORMをちょっとだけ変えたものだよと教える
- PerlのTengを知っているなら、Tengの概念からここを引き算したものだよ、のように教える
- あまりプログラムからDBを触ったことが無ければ、それを使った小さい機能を一緒に作ってみる
などと、その人の知っている概念との差分で説明する。そうするとその人にとっては新しい概念ではなくて、既に知っていることの差分になるので、理解しやすくなるのではないかと思う。
また教える方法の参考として、その人の得意な開発の仕方も役に立った。例えば、見えるところから作るのが好きか、下のレイヤーから積み上げていくのが好きかによってWAFの概念の教え方を変える。
- 見えるところから作るのが好きな人には、Controllerはどういう風に作るのか、下のレイヤーを無視して作るにはどうしたらいいのかを教える
- ダミーデータをとりあえずControllerで作っておいて、まず見えるようにしたらいいよとか
- 下から積み上げるのが好きな人には、途中段階での動作確認のやり方を教える
- 作ったメソッドを適当にControllerに書いてprintデバッグを細かくしていくと良いよとか
- テストの書き方を多めに教えて、テストで検証する方法を教えるとか
つまり、教えるときに自分がよくやる手法をそのまま教えるとかでなくて、その人の好きなやり方での良いやり方を教える。こうするとその人のいつもどおりの考え方で勉強ができるので、良いような気がした。
まとめ
インターン中に教えることで勉強になったことをちょっとだけ書いてみた。こうやって書いてみると、教えるのには人をよく見るのが必要なのだなーと感じた。
その人の知っている概念とか得意分野とかを知るのだったら、その人が楽しそうに話している内容を聞いていると少しずつ分かってくる。どういう開発の仕方が好きかとかは、commitの順序とか、後ろからコードを書いている様子を見ていると少しずつ見えてくる。質問している時に何がわからないかを知るには、教えてる時の反応とか、わからないところを説明している時のカーソルの動きとかを追っていると、少しずつ見えてくる。そうしてその人に合わせた教え方をする。
教えることは難しいのだけれど一つ勉強になった。
