子供に Scratch を遊ばせている。
長男(10歳)は素晴らしい吸収力で、弾幕シューティングみたいな動きを作って「動きが美しい」と喜んでいた。
画面中央から自分を正確に狙った弾が飛んでくるので、ひたすら避けるだけのゲームだけど。
こういうものを簡単に作れてしまう、というのは Scratch の柔軟性の高さだと思う。
プログラムを勉強する、というと、とりあえずリファレンスマニュアルを読み始めようとする人がいる。
英語だったら、ある程度英単語を知らないと作文はできない。
リファレンスを読むのは「どんな単語があるか」を知ることになるので、まぁ、間違っているとは言わない。
でも、まずは何か目標を立てたほうがいい。
英語の学習でもそうだけど、明確な目標が無いと上達しにくい。
で、目標を立てるというと、思い描くソフトの「完成系」を夢想してしまい、そこにむかって邁進しようとする人が多いようだ。
目標が細かすぎると頓挫する。
最初に細かな「仕様」を決めると、どうしてもそのものを作りたくなって、持っている技術で「回避しよう」とか考えられなくなっちゃうから。
目標は、一言で言い表せる程度にしておくのが良い。緩い目標設定だ。
「ゼビウスみたいなシューティングを作る」とか、「綺麗な模様を描けるソフトを作る」とか、その程度。
そして、自分の知識で出来そうなことから作ってみるのがいい。
その途中で新たな知識を得たら「これで何か面白いことできないかな」って考えて機能を追加してみる。
自分の出来ることばかりやってたら上達しないよ、っていう意見ももっともだけど、プログラムってそんな単純なもんじゃない。
「これならできるだろう」と思って始めたことでも、思わぬところでつまづいて、苦労するもんだ。
それで十分勉強になるし、上達できる。
先に書いた弾幕シューティングは、非常に簡単な仕組みだ。
Scratch 2.0 には「クローン」という機能がある。
プログラムは１つしかないのに、複数の物を動かせる便利機能だ。
ちなみに、１つのプログラムで複数の物を動かす、という概念は混乱しがちなので、Scratch 1.x 系列にはこの機能は用意されていなかった。
でも、この機能無いとゲームが非常に作りにくい。
ものすごく重要な機能で、使い方を理解してしまえば非常に便利だ。
で、長男は画面の中央に適当なキャラクターを置き、常に「自機」の方を向くようにプログラムを組んだ。
Scratch では、キャラクターに「向き」がある。キャラクターの移動を「前へ」「後ろへ」「右へ」「左へ」などで指示するためだ。
そして、他のキャラクターの方に向ける、という命令があるので、「自機」に向かせるのはたった１命令で出来る。
で、一定時間ごとに「クローン」を作るようにした。
クローンは元のキャラクターと同じ位置に生み出されるが、特に指示しない限り生み出されるだけで、プログラムは動かない。
そこで「クローンされたとき」に動き始めるプログラムを組んだ。
このプログラムは、ひたすら「前へ」を繰り返すだけ。生み出されたときの方向に、ずっと動き続ける。
以上。これでおしまい。
自機はマウスで動かせるようになっているのだけど、その自機をめがけて多数の弾が飛び続ける。
まるで弾幕シューティングのような画面になる。
ちなみに、長男は弾幕シューティングなんて全く知らない。
「この命令、何かに使えないかな」と適当に組み合わせている間に面白い動きになり「みてみて、面白い」と見せに来ただけだ。
この無目的さがいい。
プログラムの「お勉強」だと、なかなかこういうことができないけど、何かに使えないかな、って考えて使ってみた機能は、確実に自分の知識となる。
独習書を買ってきて、本で原理を学んで、サンプルプログラムを真似して作ってみても、その知識は案外活用しづらい。
思えば、僕も BASIC のリファレンスマニュアルを読んでは「へー、こんな機能あるんだ」って実験しながらプログラムを覚えていったと思う。
BASIC は、プログラムを組まないでもその場で「命令の実行」が可能だった。
いわゆるダイレクトモード。命令を入力すれば、すぐに結果が返る。
これがあるから、リファレンスを見ても命令の動作詳細がわからないとか、そもそも手元にリファレンスが無いけど命令自体は記憶しているとか、そんなときに命令の動作を簡単に調べられた。
簡単な組み合わせで、狙っている目的が実行できることを確認してからプログラムに組み込んだりね。
実は、いまも Javascript や PHP のプログラムを作るときに、同じようなことをすることがある。
Scratch では、リファレンスすらいらない。
だって、使える命令は全部画面上に「ブロック」として置かれているのだもの。
それ以外の命令は使えない。
この、「命令が見えるものだけに限られている」ことに拒否反応を示す人がいる。
大抵はプログラマーだ。
本物のプログラムは、もっと多くの命令を自由に駆使することで無限の可能性が広がっているものだ、という。
この意見はわからないではない。
僕も、Scratch で仕事のプログラムを作れ、と言われたら断乎として拒否する。
出来ることが非常に限られているから、苦労することが目に見えているんだ。
でも、それは「本物のプログラマは Pascal を使わない」というのと同じことだ。
今までの自分のやり方と違うからと言って拒否しているだけ。
僕はアセンブラで低レベルなプログラムを書いて、ハードウェアの隅々までしゃぶりつくすのが好きだ。
それを仕事にしていたこともある。
でも、Scratch の非常に簡単にプログラムが書けるのも大好きだ。
多くのプログラム言語を見てきて、それぞれに違う得意分野があることを知っている。
そして、そのどれもが、本物のプログラム環境だと思う。
Scratch では、先に書いたように全命令が非常に少なくて、画面上に置かれているのでリファレンスがいらない。
BASIC と同じように、ちょっと書いて（組み合わせて）動かすことも簡単だ。
だから、リファレンスが無くても動作詳細はすぐにわかる。
そして、非常に少ない命令は、よく考えられている。
ゲームを作る、キャラクターが動き回る紙芝居を作る、タートルグラフィックで遊ぶ…など、いくつかの「子どもが興味を持ちそうな」分野において、目的を１命令、もしくは数命令の組み合わせで実現できるように練り込まれている。
でも、もし Scratch でいわゆるお勉強…基本のソートアルゴリズムとか、文字列検索のプログラムとか、モンテカルロ法で円周率を求めるプログラムを作ろうとしたら、非常に苦労するかもしれない。
Scratch は得意分野が狭い。
その代わりに、その得意分野では非常に簡単にプログラムが組めるし、その範囲内では命令の組み合わせもしやすいように工夫されている。
でも、それでいいと思う。万能の言語なんて存在しない。
汎用性が高い、と言われるＣ言語すら、プログラムの需要が高まった現代では、不得手な分野が非常に多いと言われる。
子供向けの学習用言語である Scratch がＣよりできないことが多いからって、「そんなのダメだ」と言い出す理由は、全くない。
何か興味のあることを見つけて、その興味に従って自由に遊んでみる、ということが勉強には必要だと思う。
実は、これはプログラムに限らず、すべての勉強に言えること。
疑問を持ったら、それが知識の範疇であるならば図書館に行って調べてみる。
物理なり、幾何学なりで計算してみれば導ける問題なら計算してみる。
台所に行って実験できるものなら実験してみる。
空き箱で工作して解決出来そうなら工作してみる。
方法は問わないけど、「プログラム」もそれらと大きく変わるものでもない。
ただ、プログラムは「正解」かどうかがわかりやすい、というのが違う。
言い方を変えると、他の方法では、自分のやったことを直接的にしか知りえない。
調べたことをノートにまとめたとして、そこには自分の書いた字が残るだけ。
計算して数値を出しても、その数値が正しいかどうかはわからない。
プログラムは、自分が書くのは「プログラム」なのだけど、動かして出てくる「結果」は違うものだ。
結果が間接的に返ってくる。
ここで、エラーになったり誤動作したり、目的通りに動かないのであれば、明らかに違っているとわかる。
プログラムは他の学習方法と大きく変わるものではないけど、ただ一つ、目線を強制的に変えてくれる作用があるのだ。
そして、目線を変えることこそが、考えるときには重要だと思う。
先に書いたプログラム以外の「興味で遊ぶ」方法、自分一人で正しいかどうか判断する方法が一つあって、それは全く違う目線で確認することだ。
でも、違う目線を持つのは非常に難しい。大人になってもできない人が多いし、子供にはまず無理。
それが簡単にできる、というのがプログラムを学ぶメリットの一つだと思う。
遊びから得られるのは、知識ではなく「考える力」だ。
知識は教えることもできる。でも、考える力は教えることはできない。
「良く学び、良く遊べ」と言われるものこのためだと思う。
遊ぶというのが「元気に遊べ」ということではなくて、学んだ知識を使った遊びを考案せよ、ということね。
遊びを考案するってのは、応用できるようになるってことだからね。
これは知識を頭に入れただけでなく、己の血肉としなくてはできないこと。
そして、逆説的だけど血肉にするためには遊んでみないといけない。
長男が Scratch を楽しそうにやっているからこの日記を書き始めたのだけど、時間が来たので妹たちに交代した。
長女（７歳）はまだ自分でプログラムはできない。
でも、先日スクラッチで表示できるキャラクターの中から「魚がかわいいからこれで何か作って」というので、僕が簡単な金魚すくいゲームを作ってみせた。
「もっと魚の数増やせない？」とか、「すくい網が破けにくいようにできない？」とか言ってくるので、ヒントだけ与えて自分でやってごらん、と対応している。
まだプログラムは組めないが、どこのパラメータをどう変更すれば何が起こるのか、いろいろ試してみて喜んでいる。
「最高点を記録しておきたい」というのはなかなか難題だが、長男がヒントを出しながら一緒にプログラムを組んでいた。
我が家の実感では、７歳はまだプログラムを自由に作るのは難しいな、という感じ。
１０歳なら十分だ。
実際のところ、１０歳は自分でものを考えられるようになる年齢だとされている。
子供にプログラムをやらせてみたい、という人はその年齢を一つの目安にするといいだろう。
＃上に書いた通り、７歳でもパラメータを改造して遊ぶくらいはできる。
次女は５歳だが、５歳はゲームのルールを理解できる年齢。
これ以前は、ジャンケン程度の簡単なものでも難しい場合がある。
＃ジャンケン程度なら３歳くらいから遊べる子もいます。
ちなみに、次女のお気に入りはキッドピクス。
長男・次女のプログラムは横から見て楽しんでいるし、実は書き変えるパラメーターの位置なども、長女より早く「ココじゃない」と指摘することがある。
でも、まだプログラムにはあまり興味がないようだ。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |