子ども向けプログラミングワークショップでScratchを選択する理由

　何年か前から、ど田舎の図書館で子ども向けプログラミングのワークショップを開催しています。
　子どもたちの最初の一歩として、どんな教材を使うか検討した結果、Scratchを選ぶことにしました。

　その理由を挙げてみます。

目次

マウスだけでほとんどの操作が可能（なんならタッチパネルでも）

　Scratchがブロックプログラミングであることに由来する利点ですが、パソコンが初めての子どもでも、マウス操作ならすぐに慣れることができます。
　一方、多くのプログラミング開発環境で必須となるキーボードは、習熟している子と不慣れな子の差が激しく、不慣れな子どもを待っている間に習熟している子どもの集中力が途切れてしまいます。

　プログラミングのワークショップを検討しはじめた時期に言われていたのは、2013年の調査によると小学生の打鍵平均速度は5.9文字/分しかないということです。これは平均ですから、習熟している子どもはそれなりに速いでしょうし、そうでない子どもはずっと遅いということになります。これでは、写経すら終わる前にイベント時間が終了してしまいます。
　また、アルファベット（特に小文字）は小学生には分からない、というのが図書館での経験則です。そもそも、キーボードには大文字しか刻印されていません。

　「キーボードやアルファベットなど、興味のある子どもならすぐに覚える」という反論もありましょうが、単発あるいは月1回程度のワークショップでは、覚えるのを待っている暇はありません。逆に言えば、例えば学童保育などで毎日のようにキーボードに触れる機会を持てるのなら、何でもありです。

　今回の記事では扱いませんが、IchigoJam BASICは大文字でコーディングしますし、命令が短いので、子ども向けワークショップに向いていると思います。

命令語が日本語であること

　Scratchそのものは海外のマサチューセッツ工科大学生まれではありますが、日本語化がほんとうに丁寧になされています。
　これもScratchがブロックプログラミングであることに由来する利点ですが、他のブロックプログラミング環境では、必須の命令群が日本語化されていなかったり、フォントが微妙（読めない）だったり、ブロックに対して文字がズレているなどは当たり前のような状況です。*1

　また、Scratchで日本語でコードを書き終わってから、表示言語を切り替えるだけで自分が書いたコードが外国語で表示されるのは、子どもたちにとって興味深いでしょう。*2

文法エラーの排除

　これもまた、Scratchがブロックプログラミングであることに由来する利点です。
　テキストプログラミング言語では、タイプミスによる文法エラーが起こりやすいのですが、Scratchでは命令語はブロックなので、単純なスペルミスが排除できます。
　また、条件分岐の「もし」(if)や、ループの「〇回繰り返す」(for)なども、コードブロックの始まりと終わりが視覚的に囲まれますので、コードブロックの閉じ間違いによる文法エラーが排除できます。
　これらは、テキストプログラミング環境で言えば、コード補完などの入力支援機能が有効に働いている状態に当たります。

　初心者のうちは、ロジックエラーと文法エラーの区別がつきません。排除できるエラーは排除しておくことで、途中で投げ出す可能性を排除することにつながるでしょう。

子ども向けのテキストが豊富

　自宅でプログラミングを継続する際にも、関連書籍など情報の入手が容易です。
　むしろ、Scratchに関して言えば、本が多すぎて選択に迷いかねない状況ではあります。しかし、選択肢が多いことは、一般的には好ましいことです。

高い知名度

　こんなど田舎でプログラミングワークショップに参加するようなアーリーアダプターは、すでにNHKの番組などでScratchの存在を知っていることが期待できます。

　実際、開催後には、複数の保護者の方から「もともと、NHKのプログラミングの番組を観てて興味を持っていた」と伺いました。

実はストイックなプログラミング言語である

　一般的なテキストプログラミング言語とScratchとの差は、命令語をキーボードで打ち込むか、マウス操作でブロックをドラッグ＆ドロップするか、という手間の違いだけです。
　命令を組み合わせてロジックを構築するという部分は共通しているので、他の言語を覚える必要が生じた際にも、有利であることが期待できます。

　以上の点から、受講者に希望がある場合は別として、「プログラミングを始めたいけど、何からすればいいか分からない」と言われたら、Scratchを勧めるのは充分に合理的でしょう。

　とはいえ、これには反論も存在します。

「Scratchはテキストプログラミングじゃないからいやだ」という反論

　「子どもにはScratchよりもテキストプログラミングに触れさせるべきだ」という意見を、時折耳にします。
　例えば、次のような意見です。

1. 「Scratchに慣れた結果、テキストプログラミングへの移行を面倒がってプログラミングをやめてしまった子どもを何人も見てきた。だから、最初からテキストプログラミングをするべきだ」
2. 「Scratchでは、例えばデータベースの操作などの本格的で実用的なシステム構築はできない。だから、最初からテキストプログラミングをするべきだ」
3. 「なんか思ってるのと違う。自分が好きなのは、真っ黒な画面にプログラムを苦労して打ち込んで、アスタリスクを左から右に移動させたりするのに成功した、あのワクワク感だ」

　そもそも論として、子どもにプログラミングに触れてもらう目的を「子どもにプログラマーになってほしい」という明確だが狭い範囲に置くのか、それとも「子どもに、これからの社会を生きるための基礎知識のひとつをつけてほしい」という曖昧だが広い範囲に置くのか、そこを明確にしないと、捉え方が変わります。

　1.の意見は、昔から初心者向けのプログラミング教本を多く出しているある著者が強く主張していました。
　この手の話はたまに耳にするのですが、Scratchからの移行でプログラミングをやめてしまう子どもが、なぜ最初からテキストプログラミングだと継続できると思えるのかについて、納得いく解説を聞いたことがありません。
　子どもにとっては、自分がやってみたいことと移行先のプログラミング言語でできることが乖離していたとか、移行先にScratch程の魅力を感じなかったからとか、そのような事情があったのでしょう。
　その齟齬を埋められない責は、育成する側が負うものです。

　2.の意見については、そもそもプログラミング言語には向き不向きがあるので、万能なプログラミング言語などありません*3。本格的にプログラミングを始めると、いくつかの言語を使い分ける必要が出てくるものです。それはScratchなどのビジュアルプログラミングでも、テキストプログラミングでも、変わりません。

　3.の意見は、半分冗談で書きましたが、1.や2.だと主張するからよく聞いてみたら、実は3.みたいなことを言っていた、ということもあるようです。だったら最初からそう言ってくれ、って話ですが。

　余談ですが、昔は、Scratchのスプライトのような画像を高速に動かすのはとても大変か、もしくはそもそも不可能でした。
　今のようなネットなどない中、パソコン付属のマニュアルと月1回しか発行されない専門誌という限られた情報源を手垢まみれにして、やっとBASICを一通り覚えても、画像を思い通りに動かすなんて到底無理だとわかり、当時の子どもは、泣きながら機械語の使い方を覚えたものです。
　Scratchであればそれが簡単にできてしまうのですから、やっかむのも無理はありません。*4
　そういう人には、今ではSmileBASICみたいに大容量で高速な優れたBASIC開発環境がありますので、ぜひ触れてもらえればと思います。
　それに、今の子どものほうが、画像処理まわりなんかは覚えることが多すぎて大変だと思います。昔は大したことはできなかったので、覚えることも少なかったわけですし。

　子どもに強制しないのであれば、個人的な好き嫌いの話でしかないので、好きにすればいいのではないでしょうか。そういうのが好きな小学生は、たまにいます。

　ただ、30年前のパソコン少年の知識だけでScratchに挑むと、メッセージやマルチスレッドあたりで初っ端からつまづくことになるので、あまりバカにしないほうがいいと思います。*5

「Scratchは素晴らしいノーコード環境だ」という誤解

　ちょっと前から、一部のノーコーダーによる「Scratchはノーコードの一種だ」みたいな主張を時々目にします（そう主張している人が、本当にScratchを使い込んでいるのかは疑わしいのですが）。
　Scratchで書くのはコードなんですけどね。ほら。*6

Scratchの「コード」エリア

　話がややこしくなる原因として「ノーコードには明確な定義が存在していない」ということがノーコーダーのコンセンサスとなっている点にあるかと思います。つまり、ノーコーダーが「ノーコードだ」と主張すれば、それは名誉ノーコードになってしまうのです。

　Scratchは、自分の判断でブロックをコードエリアにドロップし、コーディングすることでロジックを構築しないと何も作れないわけですが、するとブロックプログラミングでブロックをドロップすることとエディタのコード補完機能でコードを入力することやマウスやタッチパネルなどのポインティングデバイスで仮想キーボードを使い、テキストプログラミング行うことの本質的な違いが問題になってきます。

　また、Scratchは小学校低学年でも遊べる優れたUIを持っていますが、見た目よりもストイックで、ロジックの構築（＝コーディング）を手伝ってくれるものではありません。もしScratchがノーコードの仲間だとしたら、「ノーコードでシステムを構築するには、Scratchに匹敵する大変な修練とコーディングが必要だ」と暴露していることになるわけです。もし今のノーコードがその程度のものであるならば、これほど残念なことはありません。*7

　Scratch勢はお上品なので、誰もはっきりと書かないのですが、単純な話、子どもたちにコーディングに親しんでもらおうと思ってマサチューセッツ工科大学が何十年もかけて作り上げた結晶であるScratchに対して、「コーディングなんか覚える必要ないぞ」と言わんばかりの名前で呼ばれたら、関係者は大激怒でしょう。思想を無視して、存在意義を否定されているのですから。

　以上に挙げた反論にしても、誤解にしても、コーディングを楽しんでいる子ども達の耳に「君たちがやっているのは、本当のコーディングじゃないんだよ」と吹き込むような行為であって、個人的には大人がするような行為ではないと思いますが、人の口には戸が立てられません。

　育成側としては、それを目にした子どもたちが混乱しないよう、説明できる術を身につけておくべきでしょう。*8

結論

　子どもが興味あるものに触れるのが一番。

　今回はScratchについて書きましたが、プログラミングのワークショップでは、Scratch以外にも、様々な教材を手配しています。
　詳しくは、また後日に書こうと思います。

*1:MakeCode系のブロックプログラミングや、EV3 Classroomなど。

*2:逆に、外国語で書かれたコードがそのまま日本語で読めてしまう点は、指摘しないと気付いてもらえません。

*3:そんなものがあったのなら、バベルの塔の前の世界のように、言語はただ一つで統一されていたでしょう。

*4:僕もいまだにMSX BASICを触りますし、暇になったら30年前にやってたZ80のアセンブラを再開したいと思っているクチです。

*5:プログラミング経験のある大人ほど、Scratchで「旗が押されたとき」ブロックが複数置ける点につまづきます。

*6:しかも、以前[スクリプト]エリアと呼んでいた場所は、Scratch3.0から[コード]エリアに変わっています。

*7:ノーコードそのものは必要ですし、これからも進化し続けると思っています。また、ノーコードでのシステム構築の際に、Scratchでのコーディング経験は（他のプログラミング言語と全く同様に）役に立つと考えられます。 ここで問題としているのは、一部のノーコーダーによる「Scratch＝ノーコード」という決めつけです。

*8:私見ですが、「Scratchはテキストプログラミングじゃないからいやだ」と「Scratchは素晴らしいノーコードだ」は、昔あった「宇宙の真理がこんなに単純なわけがない。だからきっと相対性理論は間違っている」と「宇宙の真理がこんなに難解なわけがない。だからきっと相対性理論は間違っている」に近いような関係にあるんじゃないかと思っています。