テストで点を取る学び方だけではプログラムは書けるようにならない

自分の経験やOJTトレーニングの一環で人に教える機会を経て、タイトルのようなことを感じたためまとめておく。

伸び悩む人の特徴

プログラム(でも技術的なことでも他のことでもいいけど)が書けない!焦って学習時間を投下しているが、いざ書く場面になると何もできない。そんな人は、以下のような特徴がある。

  • 学ぶ = 正解を取りにいくになっている
  • パターン学習をしているため、新しいことに対応できない

学ぶ = 正解を取りにいくになっている

「正解を取りにいく」とはテストで100点を取ろうとするようなイメージである。よくあるFizzBuzz問題であれば、「どうやったらFizzBuzzが書けるか」しか考えておらず、「FizzBuzzの書き方」自体を検索や質問で見つけようとする。方法が見つかればそれを書き写して終わる。動かない場合は「自分の書き方が間違っている」と考えてしまう。このような具合である。

見つけることができればまだ良い。しかし、仕事で求められるアプリケーション実装はドメイン知識や設計が必要になる。ドメイン知識 = 事業や専門的な内容は検索できない。事業の内容はその会社ごとに異なるため。1自力で仕事ができるようになるため学習するのであれば、正解を覚えてなんとかしようとするやり方では到底太刀打ちできない。

パターン学習をしているため、新しいことに対応できない

「パターン学習」とは、問題を解くためのパターンを覚えていく学習方法である。例えばFizzBuzz問題であれば、以下のような内容が含まれている。

  • 引数が3の倍数のときはFizzを返す

この「解き方」を覚えておき、「似たような文章を見たらFizzBuzz」の解き方を当てはめて解こうとする。「引数の値がnullのときはエラーをthrowして処理を終える」という内容を見ると「〜のときは」の部分を「nullのときは」に置き換えてFizzBuzzの解き方を当てはめてしまう。エラーのthrow方法と処理の終え方がわからないので聞きにくる。このような具合である。

「引数の値がnullであればエラーをthrowして処理を終える」のように、内容は一緒なのに文面が異なる場面がある。この場合は対応できない。なぜか?文章が一言一句同じでないと同じパターンとして認識されないからである。

実際はFizzBuzzもエラーハンドリングも「引数を判定してその後の処理を決める」点は一緒である。パターン化するなら「特定の条件で分岐したいときは条件分岐の方法を使う」として欲しいが、そうはならない。なぜなら文字の字面だけ見てパターン化しているからである。

  • 引数が3の倍数のとき(条件)はFizzを返す(処理内容)
  • 引数の値がnullのとき(条件)はエラーをthrowして処理を終える(処理内容)

じゃあどうする?

まずは「思考停止のパターン化」をしているかどうか?をよく観察して見極める。正解を取りに行く=テストで100点を取るために解き方をパターン化してしまう、という学び方になっている。ここを早めに指摘してやめさせないと酷くなる。やめさせ方はまた別途まとめたいが、まずは上から下まで説明させるのが手っ取り早い。わかっていないことは人には説明できない。

正解を取りにいくタイプかを見分けるポイントは次の通り。

〇〇で合ってますか?と聞いてくる

正解を知ってその通りに次からは解こうとする。よって詰まっていることが出てくると「正解を教えてください」的な聞き方になる。Aをやりたいが調べ方がわからない、とかではない。方法そのものを聞きにくる。自分の意見はないことが多い。

内容が一緒でも文面が異なると対応できない

先に述べた通りで、与えられた内容について吟味すれば一緒とわかるにも関わらず、別物扱いして詰まってしまうとかなり怪しい。 逆もあり得る。内容が異なっていても文面が一緒なら同じと認識してしまう。文意や指示が理解できていないと思考停止のパターン化率はかなり上がる。

内容を説明させると詰まってしまう

正解を覚えているだけなので、「他のやり方は検討しなかったの」「なぜこのAPI(処理方法)にしたの」と聞くと回答できない。当然である。正解を書き写しただけなのだから。繰り返し処理のように方法が複数ある場合で顕著になる。

まとめ

  • テストで100点をとる勉強法は資格試験以外では通用しない
  • 字面だけ見てパターン化していると新しいことに対応できない
  • パターン化しているようでただ単に思考停止しているだけなので伸び悩む
  • まずは上から下まで説明させることで思考停止を止めさせる

大学の卒業論文とかでこの辺は脱しているのかと思いたいが、動く・動かないがはっきりするジャンルだと「動く = 正解」になってしまいがち。そうじゃなくて実装すべきものを整理して、それをどうやって実現するかを考えるのだという思考回路になりたい。


  1. 検索できてしまったら別の意味で問題がある…。