勉強法(4) 教える側に回ると、穴が見える

プログラミングを教えていると、質問が2種類に分かれます。

片方は調べれば答えが出ます。もう片方は、自分が何を根拠に答えているのか分からなくなります。

答えられない質問は、いつも同じ形だった#

3つめで詰まります。「そっちでいいと思います」とは言える。ただ、なぜそう思うのかを説明しようとすると、経験からそう思う、としか言えませんでした。

教えやすいことと、実務で差が出ることがずれている#

教材にしやすいのは、正解のあるものです。文法、関数の使い方、エラーの読み方。手順が決まっていて、できたかどうかも判定できます。

ところが、仕事で差が出るのはそこではありませんでした。

右の列は、教科書の形になりにくい。正解が状況によって変わるので、「こうしなさい」と言えないからです。

結論ではなく、後で起きることを渡す#

説明の仕方を変えました。それまでは「こう書くといい」と結論だけを渡していました。いまは「こうすると後で何が起きるか」を先に話します。

たとえば、同じ設定値を2か所に書いた場合。その場では動きます。問題が出るのは、片方だけ変えたときです。

「重複は避けましょう」だと、禁止として覚えて終わります。「今は動くが、変えるときに壊れる」だと、理由として残ります。次に似た場面が来たとき、自分で判断できる形になります。

自分の側にも効いた#

説明のために言葉にしたことが、自分の作業にも戻ってきました。

このサイトのコードには、処理の説明ではなく「なぜその選択をしたか」を書いています。1か所にまとめた理由、別のファイルに切り出した理由、選ばなかった案。

これは人に説明するときに必要だった形と同じです。半年後の自分は、今の自分が何に困っていたかを覚えていません。困りごとごと残しておかないと、また同じ場所で悩みます。

教える相手が、自分の穴を教えてくれる#

答えられなかった質問は、そのまま自分が言葉にできていない部分でした。

1人で書いているかぎり、そこは表に出てきません。動いているからです。聞かれて初めて、説明できないことに気づきます。

本を読んで穴を埋めたこともありますが、穴の場所を教えてくれたのは、いつも質問のほうでした。

今回の学び#

まず、選べることと、選び方を説明できることは別だということ。手が勝手に選んでいるうちは、使えてはいても分かってはいませんでした。

次に、結論より、後で起きることを渡すこと。「こう書きなさい」は覚えて終わりますが、「こうしないと何が起きるか」は判断の材料になります。渡す形を変えただけで、返ってくる質問が変わりました。

そして、自分の穴は、自分では見つけにくいこと。1人で書いていると、動いている場所は疑いません。答えに詰まった質問の一覧が、そのまま埋めるべき場所の一覧でした。