来年から小学校でプログラミングの要素を取り入れた授業が始まります。
しかし多くの現場では、何をすれば良いのか、はたまた教員が対応できるのかについてもこれから検討する、ということも多いようです。
私はプログラマーではないとはいえ、少しはその世界に触れてきた立場なので、その良さはよく知っているつもりですし、子どもが学ぶべきスキルとしては英語よりも大事ではないかとすら思っています。
そんなこともあり、ちょうど小学3年の息子がいますので、近所で月一で開催されている子どもプログラミングサークルのようなものにもたまに参加しています。
そこで使っている教材としては、この界隈では世界標準的に有名な「Scratch（スクラッチ）」というガジェットというか、ゲームのようなものです。
これがとてもよくできていまして、条件分岐や繰り返し分、変数からメッセージ通信まで、理解しやすくビジュアライズされたブロックを組み上げることで「スプライト」と呼ぶオブジェクトの動きを定義することができます。自分専用のアカウントを作ればクラウド上にデータも保存でき、他人に公開できます。とても無料とは思えません。
とはいえ、細かことを言えば、私はScratchを見て、かつてのFlashのようだなと思いました。オブジェクトそのものに命令を書いて行くスタイルで、複雑になってくるとどれがどんな命令を誰に出してどういう順番で動くのかがとてもわかりづらいのです。
さて、Scratch自体については本題から逸れるのでそのくらいにして、これを息子にやらせたところ、楽しそうにどんどん教えてもいない命令を組み上げて何かを作ろうとするわけです。
プログラムサークルに参加している同年代以上の子どもたちも、自由な発想で面白いアニメーションを組み立てたりします。
私の住む地方では情報系の大学があることもあり、プログラミングに関するイベントもたまに開かれたりするのですが、このたび小学生によるScratchの作品コンテストが開催されます。それに合わせて、息子にも少ししっかりとした形の作品を作らせることにしました。
その過程で気づいたことがありました。
プログラムとは発想は自由。しかしコーディングは原理原則がある。これが子どもには厳しい。
作品のテーマや素材を何にするかや、どんな絵意を書くか、動きをつけるか、などといった発想的な要素については、こどもの頭の柔らかさをもってして、大人が思うだにしない面白いものが発現したりします。
しかし、いざそれをプログラムとして組み上げるとなると、これを「効率よく」「手戻り少なく」「バグ少なく」「再現性よく」「デバッグ性高く」進めるためには、プログラマーとしては当たり前の「設計作業」をこなさないといけないのです。
- UIレイアウトの決定
- ブロック図・フローチャート・スレッド設計等、処理の流れの設計
- 変数、メッセージの定義
- デバッグ用オブジェクト・変数の仕込み
こういったものがそれに当たります。これらの要素は、「順番に計画立てて効率よく事を進める」ためにプログラムとは切っても切れないものなのです。いわばプログラムの掟ともいえます。
しかしこれが、子どもにはとても厳しい作業になります。
子どもとは自由・好奇心旺盛。みちくさこそが子どもの専売特許
子どもというのは、とにかく無駄なことが好きです。
大人から見たら意味不明な言動の数々。大人的には無駄と思えるものに異常な好奇心を示し、意味不明な試行錯誤を長時間繰り返したりします。
なにせ子供が肩が凝らない理由は、無駄な動きが多いからという話もあるくらいです。
小学生よりもさらに下の、幼児・赤ちゃんクラスになるとよりそれが顕著となり、単純なおもちゃに楽しそうに同じ所作を繰り返す彼らに、大人はほっこりさせられるものです。
なのにどうしたことか、少し言葉をおぼえてできることが増えただけで、我々は大人と同じレベルの「しっかり感」を求めるようになってしまいます。
やれ、早寝早起きろ、忘れ物をするな、宿題はちゃんとやれ、こぼさないで食べろ・・・
大人になるべく社会に適応する過程というのは、自分の行動を制限し自由を縛る過程ともいえるのではないでしょうか。
プログラム的な思考というのは社会において身につけていれば大きなアドバンテージにはなりますが、ときに大人が尊ぶ「子どもらしさ」との相性は良いとは言えないようです。
結局、プログラムで何を身につけさせたいのか？を熟考すべし。方法論は二の次でよい
息子が大作に挑むことになり、上で列挙したような「プログラムの掟」に踏みこまざるを得なくなったとき、楽しかったプログラミングからなんだかまったく別の荒野の世界に連れて行かれたような気持ちをもったであろうことが彼の表情から読み取れました。
これこそがプログラムの本質だ！と慈悲なく叩き込んでいくべきかどうか、教える立場としてそれに躊躇する気持ちもあります。あまりそれをやると、プログラムを嫌いになってしまうのではないかと。
しかしそれを教えていかずに、絵をいじってブロック積み上げて、はい命令通りに動きました絵が変わりました音がなりました、というところに留まっていては、プログラム思考が教育に取り入れられる真意には近づけないと思うのです。
いったん、我が家では、プログラム教育の意義を次のように見定め、これを原則に進んでいきたいと考えました。
何かをやりたいと思った時には、それをなるべく短い時間で手間も少なく、将来に役立つようにできる方法を考えてみよう。
そのときの考え方を身につけること。また、うまくいかないときは自分で原因をみつけ、もっと良いやりかたがあれば改善する態度を身につけること。
それがプログラム教育の本意。
数学が論理的思考の礎となっていることを教えられずに、定理や公式の暗記で嫌になってしまうようなことがプログラムでもあってはいけません。根底すべき部分をしっかり大人たちでもシェアして、おかしな方向に進まないようにあってほしいですね。