繰り返し構文は，作業をサボるだけなのか

先日のプログラミング教育系の研究会で面白い問題提起がありました．プログラミングを教えててこういう生徒がよくいるよねー．という話です．僕はその日に小学生の活動を見学したのですが，ある子は，ドリトルで知っている構文（線を引く）ということだけを使って複雑な絵を描かせました．全部で２００行近くあって，いわゆる制御文というのは一切使っていません．制御文と変数をうまく使うとそれらのプログラムは１０行くらい（つまり1/20）に短くなるのですが．ただひたすら似たような文を入力していました．そういったプログラムを書いた子にはどう反応すべきかという問題提起です．

ある意見．「難しい構文を知る前に作った作品なんだから，そういう苦労は褒めるべきであろう」まあ，僕もこの意見には賛成です．概ねみなさんそうでしょう．問題は次の段階．「プログラミングの本質は作業をサボることなんだから，こういうのは良くない．ちゃんと制御文を教えるべき」さあ，ここです．「プログラミングの本質は作業をサボること」という部分です．これは確かにプログラミングが得意とする部分でありますが，それをどれだけ重要だと思うのかという点ですね．

ここに，今度は教育側の人の意見が絡んできます「学校は漢字の書き取りのように繰り返し作業をよしとする文化がある．プログラミングはズルをすること，という捉え方をする先生がでるかも」．プログラミングを教えるという部分がこの先一人歩きして行く時に，いろんな解釈から，本質を見失って伝わっていく可能性があるという点を指摘しています．

僕は，ツールを自分で作る人間ですから，何か問題があればツールを直せば良いという立場です．何か問題があるならその問題が生じないようにツールを直してしまえばよい，ということです．ここでは何が問題かというと，「プログラミングの本質は作業をサボること」という解釈の部分です．

いろいろな作品作りの世界では「手数の多い仕事」というのはほとんどいい方に向かいます．油絵でも音楽の打ち込みでも，どこか手を抜いて作ったものはそれはすぐにバレてしまうというか．何も考えないで「手数」だけ多ければいいってことでは全くないのですが，少なくともサボると大抵ばれます．ではなぜ，プログラミングではここがねじれているのでしょうか．

これがデジタルの表現としての貧相な部分だと思っています．つまり，制御構文を使ってサボったプログラムとダラダラと書いたプログラムとで，実行の結果が全く同じだという点です．人間側の揺らぎが一切現れない．逆の面として，正確さが重要であるということも言えるのですが．

実はビスケットでも同じようにダラダラと作られる場合があります．これは幼稚園児くらいの子供が作った作品を僕が思い出して作りました．

彼は魚を３匹泳がせたかったのだと思いますが，ステージには絵を一つずつしか入れられないと思ってしまったのでしょうね．小さい子供にとって，コンピュータの特徴である「複製が簡単にできる」ということは全く自明ではなく，一つは一つと発想するのは自然なことでしょう．それで，一匹泳がせた後，もっと増やしたくなって，また絵を描いてメガネを作ったと．ビスケットの場合，こういうズルをしない繰り返しの作業は全て「手数の多い仕事」として作品のあじになります．デジタルであるけれどこういうアナログ的な性質を積極的に取り入れているわけです．

ではどういうときにプログラミング的な性質が現れるかというと，プログラムを修正するときです．たとえば，魚の動きを全部速くしたいと考えた場合．ダラダラと作る方法では一つ一つのメガネを修正しなければなりません．一斉に変えるためには，最初から一つのメガネで作っておくべきだったと．文字の言語でも同じで，繰り返しの内側を修正すると，その修正は全てに反映されます．ダラダラ書いていた方は毎回１行ずつ修正しなければないのですが．繰り返しは単に作業をサボる以上の効果があるということですよね．

プログラムを１回作ってそれを作品とする，という視点では「サボれる」ことしか利点ではありません．プログラムを修正して次の作品を作る．これを何度も繰り返して作品の質を上げて行く，というもう一つの上の視点から全体をみると「サボれる」以上のすごい効果があるということがわかります．

こういったことも，プログラミングをやっている人にとっては全くの自明なのですが，知らない人たちとの議論では，変な勘違いをされないように細かく言語化して行かなければいけないのでしょうね．

（実は，その見学した子供は自分の作ったダラダラとしたプログラムから規則性を抽出して，このプログラムにはこういうパターンがあり，この数はこういう変化している，という発表をしていました．すごい小学生ですね．ここから制御構文と変数を教えてあげると，飛びついてくるでしょうね．手続き型言語を教える理想的な手順のように思います）

プログラミングを学ぶ理由を万人に説得する方法

「プログラミングを学ぶ」「プログラミングで学ぶ」この言い方は，最初見たとき中々うまい言葉を使うなぁと思いました．プログラミング教育の本では，国語とか音楽とか他の教科の授業でも使えるんだという例がいろいろと乗ってますし，僕らもビスケットを活用して生き物の動き方を観察する学習に使ったりと，プログラミングを直接の目的としない学びに使っています．これが「プログラミングで学ぶ」ということですね．

ところが，これらは分類には向かない言葉でもあります．たとえば，プログラミングを学ぶ理由の１つに「論理的思考力」がつく，と言われていますがそれはどっちに属するのでしょうか．いつも真っ先に出てくる理由なので「プログラミングを学ぶ」に分類される感じもしますね．国語や音楽と比べればずっと前者よりです．しかし，論理的思考力は，プログラミングじゃなくても学べます．むしろビスケットのような，あまり深く考えないでさらっとやったらすぐに動いてしまうツールだと，論理的思考力をあまり使わないで作れたりするし（これはこれで，利点でもあり欠点でもありますが），パズルや将棋といったじっくり考えるゲームの方がずっと論理的思考力は付きます．ビスケットはプログラミングからパズル的な要素を排除したとも言えます．世の中のイメージではプログラミングがパズルっぽく扱われているけれど，僕はプログラミングの本質はパズルではないと考えているので，僕の考えでは「論理的思考力」は「プログラミングで学ぶ」に分類したいです．ようするに説明がごちゃごちゃ必要なのは，何かに問題があるってことですね．

プログラミングを学ぶ理由を分類するとしたら．

a)プログラミングでしか学べないこと

b)プログラミングじゃなくても学べるけど，ついでに学べる・楽しい・効率が良いといった効果があること

がよいでしょう．これだと定義が明確です．「論理的思考力」はついでに学べるので当然b)です．

b)については，それこそ本当に沢山あると思います．いま思いつかないだけで，コンピュータがいろんなことに応用されているのと同じくらい，人間の脳の訓練（学習）に関係するものであればほぼすべて，プログラミングで訓練を加速させることができるでしょう．たとえば，自分の理解を深めるために，他人に対して教えて上げる，ということをよくやります．他人に教えることで自分の理解を整理し，理解の足りない部分を見つけられるからです．その他人に相当するのがコンピュータになります．コンピュータがわかるように教えるということはプログラミングそのものですから．ビスケットで10進法の計算をプログラムするという課題がありますが，それは算数での計算というものを見直すことそのものです．昔の人工知能の課題は，人間の脳の働きを理解するために人間と同じ動きをするプログラムを作る，ということでした．

たとえば，プログラミングはモノづくりの基本であるとか，創造性教育によい，といったのは全部b)です．モノづくりということを言うなら，手を動かして工作をすることと比較してどっちが良いかという話になりますし，創造性教育だって美大を出た先生たちの工夫のレベルは相当高いので，太刀打ちできないです．もちろん工作とくらべて，プログラミングは試行錯誤のサイクルが圧倒的に早いとか，ビスケットのお絵描きのカラーパレットは水彩絵の具よりも色のことをよく考えて作られているとか，そういう議論をして説得できる可能性もありますけど．でもやっぱり五分五分だと思います．アナログの奥深さを全部捨ててまでそれが重要かって話になりますからね．

b)ばかり強調しすぎるのは危険です．「プログラミングを学ばなくてもよい」と考えている人たちの格好の反論材料になります．優秀な教師は教え方の工夫がすばらしいわけですが，そんなところにまで得体の知れないツールを強制されるのは我慢がならないはずです．いろんなものはいろんな教え方があっていいのです．

もう，b)を言うのはやめましょう．議論が収束しないと思います．言いたければ，こんな可能性もあるんだというヒントとして与えるにとどめるのがよいでしょう．控えめにです．

プログラミングを学ぶ理由を万人に説得するには，a)の部分「プログラミングでしか学べないこと」という点を追求するしかないと思います．

長くなったので，a)を掘り下げることはまた次回にしますが，要約すると．

コンピュータを何らかの形で使う人（つまりほぼ全員）は，コンピュータとは何かを学ぶ必要がある．何かを知らないで使うのは危険．

コンピュータは類似するものが無いので，なにかに例えて説明することは非常に難しい．座学ではコンピュータとは何かは学べない．ところが，この「難しい」ということを知らない人に説明することも難しい．つまり堂々巡り．

これは，体験を通じてしか学べない．すなわちプログラミングをするしかない．

補足
　実はプログラミングだけではなく，他にも似たような分野がある．たとえば演劇とか．逆に座学で学べるものはどんどん学校に入って行った．座学では学べない重要なものが沢山取り残されている．

ビスケットに乱数を入れる

新しいビスケットに乱数を導入しようと思います．どのように導入するかを考えて行く過程が面白いので書いてみます．


昔のビスケット（パソコン版で，ダウンロード・インストールして動く．ファイルはローカルに保存）にはサイコロというのがありました．現在，このビスケットの公開は停止してますから動かすことはできません．


この図では，車が上に動くメガネと下に動くメガネがあって，それぞれにサイコロが入っているので，どちらのメガネが選択されるかは乱数で決まります．つまり，上に行ったり下に行ったりします．こういうのが乱数です．

現在のFlashで作られたWeb版では，このサイコロはありません．新たに導入するのは簡単ですが，これまでそんなに必要性がなかったので，入れてませんでした．

ここで，まったく別の問題が登場します．初心者が間違えやすいバグのことです．たとえば，このバグです．

最初に魚を1匹描いて，それをまっすぐ進ませます．次に，パクパクの技を教えてもらったので，口が開いた魚を描いて，パクパクするメガネを２つ追加しました．


正しいプログラムは，一番上にある口を閉じたまま前に進むというメガネを削除して，パクパクのメガネだけ２つだけにしなければなりません．ところが，最初のメガネが残ったままです．

この状態で，今のビスケットではどのように動くかというと，まっすぐ動くか，パクパクするかのどちらかです．どちらになるかは，非常に変な動きなんですが，まったく同じ条件の２つのメガネ（口の閉じた魚）に対しては，メガネを最近移動させたものの優先度が下がる，ということになっています．丁寧に教えられる場合は，こういうのはバグですよ，きちんと考えながら作らないと行けませんよ，という指導をしたりしているのですが．

もうちょっと親切なシステムだったら，条件がまったく同じメガネ同士は何か色が付いたりして，気がつくように（エラーメッセージと言ってもいいですが）すべきですね．そこは今のビスケットは全然親切じゃないです．

バグを，ただしい作り方を教えるきっかけにしよう．ということと，バグにはやく気付くにはどうしたらよいか，ということです．

で，ここに乱数をいれてしまおうか，という提案です．まったく同じ条件のメガネの場合，どのメガネが使われるかは（メガネの編集の順序に依存するのではなく）その都度サイコロを振って決める，としようかと，いま悩んでいるところです．

最初のバージョンのビスケットの例である，車とサイコロの場合は，サイコロを入れなくても同じ動きをするということになります．魚の動きは，まっすぐ進んだりときどきパクパクしたりします．

メガネの編集の順序に依存していた場合は，動いたり動かなかったりの理由が本人にはまずわかりません．それに対して，乱数で行う場合は，本当は本人は連続してパクパクさせたかったのに，ときどきしかパクパクしない，ということで，何か変なことに気がつきます．そこで，まっすぐ進むメガネを削除すれば，自分の欲しかった動きが得られます．つまり，バグをみつけやすく，バグから正しいプログラムを作りたくなるモチベーションを奪わないということになってます．


これも良くあるバグです．魚のしっぽを左右に振らせて泳ぐアニメーションを作りたいとします．で，まっすぐの魚，しっぽが右に曲がった魚，左に曲がった魚，の2つの絵を描きます．そして，それぞれ変化するメガネを4つ作りました．


これは，思ったようには動きません．まっすぐの魚が2度使われていて，それらがまったく同じ条件になっているので，さっきと同じでどちらかのメガネだけがずっと選択されます．つまり，しっぽを右しか曲げないか，左しか曲げないかのどちらかになります．

正しいアニメーションは，実は絵が4つ必要です．まっすぐの魚を２つ描く必要があります．今は，3つの絵で4状態の遷移を作ろうとしてて失敗しているのですが，4状態の遷移を作るなら4つの絵が必要ということです．

で，新しい乱数の仕様に変わるとどうなるかというと，このプログラムはしっぽをランダムに左右に振ります．右と左は交互になりません．これは求めていた動きとは明らかに違うので，ただしいプログラムを探すモチベーションになります．

しっぽだから左右交互じゃないと変ですが，他の種類のアニメーションだったら，それはそれでアリな動きかもしれませんね．

こういう利点もあります．これは，絵が右上，真上，左上に動くというメガネを3つ用意しました．もちろん，いまのビスケットではどれか１つのメガネしか動かないわけですが，今度のビスケットでは大体上の方にランダムに動くということになります．メガネを増やせばそれだけ複雑に動くはずです．


たとえば，シミュレーションで要素の動きをきっちりとた動きじゃなくて，ある分布にしたがった動きをさせたいということがあります．たとえば前方で左右30度の角度のどこか，といった．そういった分布を式で作るのはそれなりに面倒ですが，ビスケットの場合同じ条件のメガネをその分布に従って沢山作れば，どんどん精度よく欲しい分布に近づけることができます．


これはビスケットの原理とすごく相性がよいです．一般的なプログラムは計算したい関数を式を使ってコンピュータに教えます．これはScratchでもまったく同じです．動かしたい実体とは切り離して，式の世界で動きを構築するということが必要になるのです．それに対してビスケットでは，そういった抽象的な世界の記述はなく，具体的な動きの例を沢山与えて，それらを参考にして実際の動きをつくりだす，という動きをします．動きの実例を増やすと式の精度が上がるということになります．


別の考えとして，乱数は特別な計算だから，それにはアイコンを与えて明示的につかわせるようにすべきだ，というのがあります．実は僕も，一番最初はそういう考えだったのですね．だから最初のビスケットはそういう仕様だった．

で，いままったく違う視点で見ていて，それはそれで面白いなぁという．

乱数を使った面白い例は，また次に書きます．