昨日の続きで、プログラミング教育について。
私はプログラマーではなかったが、コードを書くのは好きだったし、もしもプログラムを職にしたなら、超とまではいかないにしても、一流のプログラマーにはなっていただろうなと思う。
超のつく一流というのはイノベーティブなプログラマーであって、例えばGoogleの分散ストレージのコードを２週間くらいで書くような天才的な人間である。
論理的思考を身に付けるという目的で、プログラムを通して見につけて欲しいことは２つある。
一つ目は変数の領域の概念。
ローカル変数とグローバル変数で、その変数が有効となる領域の範囲。
領域の思考法は実社会でも非情に役に立つが、周囲の人間（プログラミング経験あり）で変数の領域をきちんと意識していたと思える人間は少ない。それはコードを見て言うのではなく、会話や仕事ぶりやその他の振る舞いを見て感じたもの。仕事の責務や境界線とか、ルールをどの範囲に適用するかと言ったような、基本的な考え方である。
この考え方ができていない人間はプログラムの変数領域の問題も真剣に取り組んでいないことがわかる。
スクリプト言語のような変数の型や領域を曖昧にするような言語では身に付かない。
二つ目は構造化。
これはいい具合の機能単位を局所（関数）にまとめ、それを誰の目にも明らかにわかりやすい形で呼び出すという構造化。
構造化できずにダラダラとロジックを書いても「論理的な思考」を養ったことにはならない。
実はこの２を実現するということは、別の側面から見れば「保守性の高いコード」を書くということになる。
保守を意識するのは、例えば人の書いたコードを自分がメンテしなくてはらない時に、「どうしてこんなわかりにくコードを書くんだ」と呪ったり、うっかりとバグを踏んだりするような時に学習できる。
だから新しいプログラムを書いて、はい、あなたの書いた命令でロボットが動きましたね！おめでとう！！
みたいな教育では何も論理的な思考は身に付かない。
それよりは数学の証明問題を解く方がよっぽど論理的な思考が身に付く。
（その時間を削って、子供にプログラムをやらせようというのですか！？）
保守性の高いコードのアナロジー。
自分が同じ職場や同じクライアントの下で永続的に働くわけではない。
でも自分がいなくなっても仕事の影響力が長く残るような仕事をするべきである。
もちろん正しい仕事であることが条件。
その場しのぎの仕事ではなく、自分の影響力が残るためには、単純なアウトプットではなく、なぜそのようなアウトプットを出したのか？どういうプロセスの下で出力したのかというルールを定義する必要がある。それが抽象化の能力。
抽象度が高まれば汎用性が高まり永続度も高まる。
保守性の高いコードを書く人は、仕事においても同じことをしようとするはずである。
もしもこの２つの行為に相関性が無いのであれば、学校教育にプログラミングを取り入れる意味は全くない。
ただ、本当に相関性があるかどうかはわからない。
文科省の人間がそれをわかってプログラミングを導入しているのかもわからない。
ただ、IT化＝プログラミングだと思ってるだけなのかもしれない。哀しいことに。
