JavaScriptを使ったプログラミングの授業はここ5～6年行ってきており、昨年(2015年)までは、1から100の中から好きな数字を指定して、「もっと大きい」とか「もっと小さい」とヒントを出しながら当てていく数当てゲームを作ってきました。これは、10行くらいでプログラミングが書け、その中に順次・繰り返し・条件分岐の3つがバランスよく入っています。特に2015年度は、今回ご紹介するMonaca(※)を使った数当てゲームを作る活動を行いました。全部で4時間の構成です。

※https://ja.monaca.io/academic.html

こちらがプログラミング環境です。Monacaのすばらしいのは、クラウド上で作業ができることです。その他にも、スライドに挙げてあるようにいろいろ便利なところがあります。

最終的に全チームが完成しました。活動そのものは楽しかったですが、うまく動かないと「どこがおかしいんだ」と原因を探して、バグ取りを一生懸命やって、「よかった、動いた」というのがメインになってしまいました。

そこで、今年は、最低限の条件だけを与え、作るものを制限しないことに決めました。具体的には、基本的に2時間目まではほぼ同じで、3・4時間目で生徒に乱数を使った「何か」のプログラムを自由に作らせることにしました。2時間目に行う説明も、あまり事細かな説明に終始せず、基本的な情報のみ提示し、「こんなのがあるから、最悪コピペでもいいよ」ということにしました。

3時間目は、出席番号順に3人1組でグループを作って、「乱数(Math.random())の機能を使って何でもいいから役に立つものを作る」という活動をしました。

「何でもいい」とは言っても、わけのわからないものでなく、「役に立ちそうな」もの、あるいは、「楽しそうな」ものを自分たちで考えて作ってごらん、と指示し、作るものは生徒に任せてしまいます。3時間目の授業時間と、4時間目の時間の半分が作業時間になります。逆に言うと、その程度でできるものでいいかなと考えました。

最初のクラスは、何をしたらいいか困っている生徒が多かったので、何かサンプルが必要だろう、と思い、サイコロの代わりにするとか、1から10の中から数を当てるゲームを紹介しました。何を作ればいいのかということを、なんとなくイメージしてもらって、ハードルを下げるわけです。

一方、「好きなものを作っていい」とすると、生徒はサンプルと全く同じものは絶対作らないです。サンプルを上手に利用し、それを発展させる形で考えていきますから、生徒が作るものとして想定できる「おみくじ」とかをサンプルにしなかったのは、あまり見せすぎてしまうと彼らが作るものがなくなってしまうと思ったからです。

ちなみに、配布したサンプルプログラムがこちらです。最初は特に用意してはいなかったのですが、やはり何もないところから作るのはたいへんなので、こういうものを用意して全員に配布しました。

Monacaのいいところは、これらの「ひな形」を簡単に全員に配布できる点です。キーワードを入れ替えて改造してもいいし、全部消してやり直してもいい。アラートやドキュメントの使い方の復習もできます。また、スマホ対応であるので、完成したプログラムを自分のスマホで確認することができ、興味を持って取り組むことができます。

「何でもいいから作りましょう」と言うと、まず教科書を見始める生徒がいます。ですから、生徒たちに言うのです。「君たち自身が作りたいものはどこにも載っていないよ。自分たちで何を作りたいかを良く考えなければできないよ」と。彼らは、とにかくどこかに正しい答えがあって、それを持ってきて模範解答のような形になればいいんだ、という発想を持ってしまう場合があるのです。そのため、「好きなものを作っていい」と言われると、真面目な生徒ほど「先生、何すればいいの？」とフリーズしてしまう。「作りたいものを考えることも今回の課題のうちだよ」と言うと、ワヤワヤしているうちに、サンプルから「おみくじならできそうじゃない？」「おみくじにしよう」「セリフはこうしよう！」「そうか！」と、上手に誘導されていくことになります。

困っている生徒のためにサンプルはちょうどよい程度に準備してありますが、それを使わずに、教科書を見たりネットで「JavaScript」などと調べたりしている生徒たちは、多くが失敗してしまいます。教科書やネットのサンプルは、パワーユーザー向け、あるいは学習時間や製作時間をそれなりにとるものが多いからです。制作時間は1回半分しかないので、とにかく3人で相談しながらサンプルをあれこれいじっていく方が、形になっていくのですね。

2時間目の後半で発表をするのですが、ここではちょっとした工夫をしました。3人の中には、すごく頑張って作った生徒もいれば、なんとなくその場にいただけ、という生徒もいます。ですから、全員が自分たち自身の作品内容を十分に理解してもらうため、発表の時には、グループをシャッフルし、発表のための別の3人組を作ります。そして、その中で、自分たちのプログラムを残りの2人に、実際にプログラムを走らせながら1行1行解説してもらいました。ですから、実際は作っていない人も、自分たちのプログラムを説明しなければならなくなるので、必死に食いついていく。中心になって作った人の方も、「ここはこうだから、ちゃんと説明してね」といった形で、グループ内での学習が活性化します。

そして、発表が終わったら、他の2人、つまり自分たち以外のグループの2人からコメントもらいます。そして元のチームに戻って、他のチームの人から言われたことを伝え、改善すべき点を話し合います。このステップはとてもよかったと思います。先ほどおみくじを作った人が多かった、とお話ししましたが、先生用に「発表者を決めるためのくじ」を作ったグループもありました。これはおもしろかったですね。

こんな感じで、発表は大盛り上がりでした。完成できなかったグループも、他のグループにアドバイスをもらうことによって、完成へのちょっとしたコツや修正点を学ぶことになりますから、よくわかっている人が、できていないグループに積極的にアドバイスをしていました。授業後も、「もう帰りなさい」と言っても帰らないで粘っている。それだけおもしろかったんだな、と思いました。

楽しかったかどうかと、難しかったかということのクロス集計がこちらです。「とても難しかった」「まあ難しかった」と言っている人は多いですが、それでも「まあ難しかった」であれば、「難しいけど楽しかった」と答えている人はけっこういます。また、「とても難しい」と思ってしまうと、「あまり楽しくなかった」と思う人が増えてしまうようです。「ほどよい難しさ」が大切なのかもしれません。

最後に、難易度(どのくらい難しいと感じたか)と難しかった内容について調べました。「とても難しかった」という人が一番多いですが、彼らの中で、3の「コンピュータの操作方法が難しかった」と言っているケースが思っていたよりも多かったことが意外でした。操作できないので、難しく感じてしまっている。ということは、プログラミングはある程度の機器の操作方法の習熟が必要であることも見えてきます。その他は傾向がほぼ同じで、JavaScriptでどのように手順を書いたらいいかということがわからなかった人が多かったです。

今回のアンケート結果で感じたことは、「どのような手順になるのか」と、「それをどのようにJavaScriptで表せばよいのか」という区別が難しかったのではないかということです。これも踏まえて、来年度またさらにブラッシュアップしていこうと考えています。