プログラミング教育という研究テーマのまとめ書きみたいなもの

ちょっと自分の研究についてまとめ書きしておきます。

先ずは問題提起から。
最早プログラミング教育の定説となりつつある (既になっている?) 問題です。

レジナルド・ブレイスウェイトが書いていることを読んだとき、私はそんなわけないだろうと思っていた。

私と同様、この著者は、プログラミングの仕事への応募者200人中199人はコードがまったく書けないということで苦労している。繰り返すが、彼らはどんなコードも書けないのだ。
どうしてプログラマに・・・プログラムが書けないのか?

引用元で言われている通り、プログラマ志望の人達でもこれだけ書けないらしいです。
実際大学での状況を鑑みると多いにあり得ると思いました。


そこでプログラミング教育を発展させる為の研究をテーマに据えたわけです。
先行研究では様々な手法、教育方法がありました。
ゲームを使って学生の自習を促す、アニメーションによる理解の促し、アナログな手法によるアルゴリズムの実体験等々。

それらを踏まえて自分がプログラミング出来なかった時代にはどんな事が躓く要因であったのかを考えてみました。

  1. エラーが意味不明
  2. 構文が意味不明
  3. バグの発生
  4. プログラミング時の考え方が分からない

ざっと上記の理由が挙げられました。
講義の中でこれだけの問題を抱えたままプログラミングを理解しろと言う方がどだい無理な話だと思います。

プログラミングは論理的にソースコードを記述する必要があり、初めての人間には中々難しいものだと考え、 1 年程研究してきました。その中で学習者には抽象的に物事を考えさせる練習をさせるべきだと感じました。

論理的に記述しなければいけないのに何故抽象的に考えるのか。
そもそも論理的な物が必要なのはコンピュータであって人間ではないと思います。
いきなり論理的に記述しようとするから無理だと考えました。
そう思っている矢先にこんなまとめを見つけました。

プログラミングにおいて必要なのは絵を書くと言う行為じゃ無いのか? と言われています。
絵と言うのはこの場合アートとかではなく、プログラムの動作が簡潔に分かる全体図のことです。
この方法も物事を抽象的に考えることと同じ事をしています。

設計図が無くてもプラモデルを作れる人はそうそういないのと同じですね。

考える時はシンプルに考え、問題解決に必要な部分を抽出する。
そして全体図を作る。
プログラミングにおいて、この部分が重要な気がします。

残りの 1 年 (おそらくですが...) この部分に注力して研究を進めていきたいと思います。