今週が成蹊大学における今年最後の授業となりました。

　年が明けるとあと二回の講義があるので、先週からこれまでに教えたことを活かして実際にチームに分かれて作品を制作する、ハッカソン的なスタイルを採用することにしました。

　プログラミングは特にそうなのですが、知識だけ習ったとしてもそれを実際に使ってみなければ、自分たちの手で動かしてみなければ、本当に使えるようになったとは言えません。

　そのためには、一人ひとりが独立して課題をこなすのではなく、互いにアイデアを出しあいながら作品性を高めていくことが大事です。

　この連載では何度も主張しているように、私は教育の現場に携わるようになって、プログラミングは表現手段の一つなのであるということを強く意識するようになりました。

　こうした場合に生徒に与えるべき課題とは、具体的なイメージが湧くものと全く具体的なイメージが湧かないもの、両方が必要になります。

　具体的なイメージが湧くとは、例えば「ゲームを作る」という目標を与えることです。

　「これから三週間かけて、チームに分かれてゲームを作ってもらいます」と言えば、かなり具体的なイメージが湧きます。自分たちが何をするべきか、何が求められていて、何を提出するか、その評価指標は何か、といったことがいっぺんに説明できます。

　ゲームの評価指標とは、「面白さ」です。
　それは企画の面白さかもしれないし、絵の面白さかもしれない、もしかしたら、操作の面白さかもしれません。ゲームバランスやプログラミングテクニックによる面白さの差もあります。

　ゲームを題材に選ぶとき、これが人々を駆り立てるのは、「面白さとは何か」「自分はどんなものを面白いと思うか」「自分が面白いと思うものをプログラミングとして表現可能か」ということを強く意識しなければなりません。これがまた、学習意欲につながります。

　今回、非常に面白いと思ったのは、私はこれまでの三年間の授業で初めて、ハッカソン形式を採用したこと、そしてハッカソン形式を採用したことで思わぬ化学反応が産まれたことです。

　それは、生徒たちがこれまでよりもずっと能動的になったということです。

　これまでの授業でも生徒たちがランダムに発言できるように匿名性のチャットシステムを導入していました。

　普段、一方通行の授業をしているとなかなか得ることの出来無いリアルタイムの反応を得ることが出来て、これはこれで授業としての幅が広がったという感覚がありました。

　しかし、ハッカソン形式、しかもチーム形式のハッカソンを導入すると、生徒たちは単なる感想やジョークをチャットに書き込むのではなく、具体的に自分たちが表現したい内容を表現するにはどうすればいいのか、という質問を書き込むようになったのです。

　これは教える側もハリがあります。
　それぞれの質問は非常にシンプルなものなので回答するためのプログラムを書くのはものの数分で済みます。

　しかしひとつのソースコードは無限のメッセージを伝えることが出来ます。

　たとえば、「ゲームに制限時間をつけたい」という質問に対しては、以下のようなプログラムで答えます。

enchant();

window.onload = function(){
var game = new Core(320, 320);
game.fps = 30; //一秒間に30フレーム
game.onload = function(){

la = new Label("");
la.on('enterframe',function(){
this.text=this.age; //これまでに経過したフレーム
if(this.age > 30*10){ //30フレーム✕10秒　
this.text = "終了"
game.end()
}
})

game.rootScene.addChild(la)
};
game.start();
};

http://code.9leap.net/codes/show/106167

　このプログラムを日本語で説明するとこうなります。

これまでに経過したフレーム数を表示するラベルを作って、ラベルは1/30秒毎に呼ばれるフレームごとにそれまでの経過時間ageと比較して、10秒に相当する30*10=300フレーム以上の時間が経過していたら、終了として、ゲームを終了させる

　どちらが解りやすいか、という問いは難しいでしょう。
　前者のソースコードによる説明は、JavaScriptの知識が全くない人には読むことが出来ません。

　後者の日本語は、前提となる予備知識や語彙を理解していないと一度に飲み込めません。
　情報量としては日本語による説明の方が簡潔に見えますが、JavaScriptの素養が少しでもあれば、ソースコードによる説明の方が明快です。

　そしてソースコードによる説明の重要な点は、たとえこのソースコードを理解していなかったとしても、コピー&ペーストすることで自由に利用することができるという点です。

　例えば英語の手紙を書くとき。
　英語がニガテな人は、今ならGoogle翻訳を使うかもしれません。

　しかしGoogle翻訳による訳もいまいち信用出来ないということはよくあります。
　そういうときはどうするでしょうか。

　普通は、慣用句をそのまま使います。
　たとえばJohn Smithに出す手紙の出だしは、Dear Mr. Smith〜であり、手紙の終わりはBest regardsで終わるとしましょう。

　さて、Dearが「親愛なる」と訳されることが多いのはよく知られていますが、これは本来はどういう時に使われるべき挨拶なのでしょうか。

　私はDearを使う時はほとんどありません。
　これはかなり形式張った言葉であり、まさに「親愛なる〜」と送るようなシチュエーションにピッタリだからです。

　だからこれが頭についているというのはよほどの時です。

　私が普段使うのは、アメリカ英語風に、Hi, Johnまたは Hello, John、もしくはいきなりJohn, How are you?かもしれません。

　ただ、本当のところは何が正しいのかわからないのです。
　そういうとき、普通は辞書を引いて慣用句をコピペします。

　プログラムも言語である以上、そうであっていけない理由はありません。

　そしてプログラムの面白いところは、意味を理解せずにコピペすると、運が良ければそのまま使えるけれども、運が悪いとそれがバグのもとになるということです。

　そのバグを修正しそうとあれこれ工夫しているうちに、プログラムの本当の意味が理解できるようになることはよくあります。

　だからまずコピペ。これが大事なのです。

　初心者が犯すプログラムのミスの大半は、勘違いや不注意によるものです。
　カッコの対応がとれていなかったり、大文字と小文字を間違えたり、不必要な全角スペースがあったりとかです。

　これは初心者をとても苛立たせます。
　失望させ、プログラミングを嫌いにさせてしまいます。

　それならば、確実に動くコードを示してあげて、とりあえず混乱したらコピペからやりなおせるというのは安心感につながります。

　
　最初は必要と思われる部分をコピペするので十分なのです。
　使いながら次第にわかっていくわけです。

　それとチームにして競わせるというのも非常に重要だと思いました。
　個々人を競わせると、あまりに僅差の場合、非常にもやもやとした感情の対立を産みます。

　チームだと多少はそれが緩和され、そして意地悪な話ですが、ツッコミどころ、差別化要因の見つけどころも出てきます。

　そうすると負けても、「次は頑張ろう」とお互いを励まし会うきっかけになります。

　また、やはり人によって進みの早い人、遅い人がいます。チームにすることで教え合うきっかけになります。

　生徒たちが力を合わせてお互いのスキルを補い合い、プロジェクトを前に進めるときにとても前向きな力が産まれます。

　先週はチーム分けを発表して、今週はチームごとに考えたアイデアをプレゼンしてもらったのですが、どのチームもかなり頭を使っていて驚きました。

　この手のハッカソンで重要なのは、具体的なイメージが全く湧かないものをテーマにすることです。

　例えばテーマを「吉祥寺」とか「冬」など、漠然とした、どうとでも切り取れるものにしてしまうことです。こうなった瞬間に生徒は混乱します。この混乱こそが、クリエイティビティの源泉です。

　今回は「吉祥寺ゲーム」をテーマとしました。
　吉祥寺は成蹊大学のある土地でもあり、学生たちにとって親しみやすい題材です。

　しかし、多分彼らはこれまでの大学生活で一度も「吉祥寺をゲーム化しよう」とは思ったことがなかったはずです。情報工学科ならともかく、経済学部の子たちなわけですから。

　このテーマを発表した瞬間、教室はザワツキました。これぞ、狙い通りです。
　

　そしてこういう無理難題を課された時、最初は「絶対に無理だ」と思うのですが、不思議と、「なんとかなるかもしれない」と思う瞬間があります。それこそがまさに、生徒たちがプログラミングを自らの道具として意識し、単なる知識が実態を伴った知恵へと相転移する瞬間なのです。

　年が明けて12日には作品発表があります。
　今から楽しみです。