ビスケットのあれこれ

ブログを移したのですが，こちらにもリンクだけ貼っておきます．

デバッグを小１に教えた話

自動車は人間の足の拡張，ラジオは耳の拡張，テレビやカメラは目の拡張と言われています．同じような意味でコンピュータは脳の拡張であると言ってもよいでしょう．たとえば，電子辞書やWikipediaその他インターネット検索というのは脳の記憶の能力をはるかに越えて補ってくれています．それ自体はとてもすごいことですが，元々あった本や百科事典をコンピュータに載せただけとも言えますから，紙や印刷技術の発明のインパクトの強さにかすんでしまいます．

同様に，コンピュータの日本語は計算機と言いますが，高速で計算する機械の視点でみても，そろばんや手回し計算機という発明が既にあったわけですから，それが高速で正確になったというすごさ以上のものでもありません．

本当の意味で「コンピュータは脳の拡張」と言ってよいのは，コンピュータシミュレーションのことではないでしょうか．コンピュータシミュレーションというのは，実際に実験をやるかわりにコンピュータの中で計算で実験をしてみようというものです．条件を変えて何度でも実験できますから，その効果は絶大です．そのときどうやって計算する方法をコンピュータに教えるかというと，それがまさにプログラムなわけです．

ビスケットでも，単純なシミュレーションであれば実に簡単にプログラムできます．たとえば，風邪の感染のシミュレーションはたった4つのメガネだけで，感染の広がり方や治り方を色々な条件を変えて試すことができます．このシミュレーションは実際の病気の予測などにはまったく役には立ちませんが，感染という計算が持っている性質を直感的に理解するには非常に強力です．


感染の次にやるのが，ジャンケンのシミュレーションです．3つの絵が3すくみのルールによってお互いにバランスをとるように作られています．ところが，このシミュレーションは「バランスを保ち続ける」という大方の予想に反して，どれか一つの絵に収束してしまいます．このジャンケンのシミュレーションを色々な大人に見せて予想をしてもらったところ，正しく予想できた人は人工知能研究者だけでした．僕も間違えました．しかし，この結果を元にして，もう一度3すくみのルールを考えてみると，しごく当たり前の結果であることがわかります．3つの種があるうちはバランスがよいけれども，もし1つの種が滅んでしまって，世の中には2つの種だけになってしまうと，勝ち負けは一方的になり，一方は滅んでしまいます．たとえば，パーが頑張ってグーを滅ぼしてしまうと，チョキとパーだけになるので，パーも滅んでしまいます．最初に勝ってしまった種が次に滅んでしまうというのは皮肉なことですね．

人間の先入観というのはまったく当てにならないものです．ところがこうやってシミュレーションで結果を見せられると，考えを変えざるを得ません．人間は理解を切り替えられるくらいな柔軟性も持っているんですね．

我々の生活において先入観で失敗することは多々あります．たった数円安い買い物のために交通費と時間を無駄にしてしまう話．宝くじの共同購入に騙される人．住宅ローンや生命保険の計算も直感的ではないので，判断を間違えやすいですね．これらはシミュレーションをやってより懸命な判断ができるようになりましょう．何度もシミュレーションをすることで，その領域への直感も鍛えられ，先入観があてにできるようになるでしょう．

コンピュータによるシミュレーションのもう一つの良さは，難しい数学を使わなくてよいということです．これまで数学が発展したのはコンピュータが無かったからです．年利2パーセントのローンを10年借りると，利息はいくらになるかといった計算は，指数関数で計算できます．一方で，コンピュータシミュレーションでこの計算をすると，かけ算と足し算を沢山繰り返す，ということでもできます．力学の運動だって，コンピュータを使わなければ微分方程式を解かなければなりませんが，コンピュータシミュレーションでは足し算とかけ算を繰り返すだけです．この意味は，プログラムは実はすごく簡単だということです．

プログラムを自分で書くということも重要です．自分で書くから，意外な結果にも納得できるのです．観光バスに乗って観光スポットに勝手に連れて行ってくれることよりも，レンタカーを借りて自分で運転して観光をした方が，自動車は人間の足の拡張っぽいですよね．同じように，自分でプログラムを書いて，その動きに納得して，そして意外な結果を受け入れる，これが「コンピュータは人間の脳の拡張」なのです．

個人に対するプログラミング教育のモチベーションは，他人よりも人生において優位にたちたい・幸せになりたいということでしょうから，それはそれでどんな理由でもよいと思います．大事なことです．

それに対して，義務教育でのプログラミング教育の意味はまったく違ってます．義務教育のきちんとした定義はあるんでしょうが，僕が一番大事だと思っているのは，社会全体での共通理解を底上げする，ということです．ついでに，僕自身ずっと言っているのは，これは子供の教育だけの話ではないですよ．大人もちゃんと理解しておいてほしいことですよ，ということです．社会全体での共通理解の底上げが大事です．

たとえば，先日起きた人工衛星の「ひとみ」の事故の話です．

http://jbpress.ismedia.jp/articles/-/46999

この記事では，もはやものづくりそのものの考え方が古くなっているということが書かれています．この人工衛星の製作にあたった方々はみなさん理工系でコンピュータを普段から活用されていらっしゃるのでしょう．そんな方々でも，コンピュータのさらに専門的なことに関しては認識を誤ってしまうのです．彼ら自身が新しいコンピュータ（たとえば，100万台で一部が壊れても動くといった）に対する理解を深めなければいろいろと立ち行かなくなってきているのです．これは拡張すると，社会全体が古いコンピュータへの認識のままだと，日本の将来は本当にやばい．子供達の未来を考えるなんてこと自体が無意味になってしまうかもしれません．

いま，プログラミング教育というと，コンピュータを自分で動かす経験という点に重点を置いています．導入はそれでもいいですが，最終的に社会全体にどんな共通認識を持ってもらいたいか．これはいろんな意見があると思います．僕もその一部しか思いつきませんが，書いてみます．

１）分量が半端ないこと．

コンピュータが高速で，大容量ということは知識としては知っていますが，それが本当にどれくらいすごい高速で，どれくらい大容量かということを数字じゃなくて体で知ってほしい．数字だとゼロが１０個増えただけで実感できません．僕は昔，自分のパソコンのメモリーが16kBだったのを32kBに拡張したとき，メモリーを順番に画面に流して見ててすごい時間がかかったのを今でも覚えています．たった32kBですよ．メモリーってすごい広いんだと思ってました．これが年々増えていて，いまはその時の１００万倍ですよね．物としてあればある種の恐怖を感じられたりしますが，コンピュータは見えないので何も感じられらないのです．

２）脆弱なこと．

人間だと，同じ作業を繰り返された時途中で気づいて，なにか反応します．手順をまとめたり入れ替えたり，その作業をより効率よくする方法を考えたりします．人間はそういうメタ的な視点を持っているので，計算能力や記憶能力が貧弱でもすごいことができるのです．コンピュータは真逆で，言われた通りどんなことでも疑問を感じずに黙々とやります．それが利点でもありますが，アクシデントに全く対応できません．もちろんソフトウェアですからあらかじめ想定できるアクシデントがわかっていれば，そう動くように作れば動くのですが．未知のアクシデントには対応できません．そして本当に頭の悪い動きを繰り返して自分が壊れちゃうのです．

この１）と２）を合わせて「コンピュータはバカだけどすごい」ということになります．

こんなことは，専門家だけがやればよいではないし，知識として知っていれば良いのでもダメです．たとえば，横幅５０cmの板の上をまっすぐ３m歩くというのを考えましょう．こんなの楽勝ですよね．ところが，この板が地上50mにあったらどうでしょうか．いまは無風なので，地面に板を置いたのと同じくらい安全に渡れます．でもこの板を渡れと言われて渡れますか？10万円あげるからと言われたらやる人がいるかもしれませんね．なぜ，この板の上を渡るのは怖いのでしょうか？それは高さに対する直感があって，落ちたら死ぬというのが，感覚としてしみ込んでいるからでしょう．遺伝子なのか経験なのか．これからのコンピュータとうまく付き合って行くのは，この「落ちたら死ぬ」的な感覚をコンピュータに対しても持たなければならないのだと思います．

３）情報の複製の怖さ．
ある情報を二つに複製するプログラムがあったとします．一度動かすと情報が二つになります．これをたくさんのコンピュータで動かした時，その情報は一気に広がります．ビスケットの「感染」のデモで説明していることですね．最初はゆっくり増えますが，途中からすごい勢いで増えてゆきます．このような指数関数的な現象は自然界にもあるのですが，人間にはその直感はありません．これがコンピュータウィルスの拡散の速さでもあるし，バズることの広がりの原理でもあります．

４）コンピュータの上にコンピュータを作れる
プログラミング言語を新しく作るというのは，コンピュータの上に新しい（ある種の理想の）コンピュータを作るということでもあります．たとえば，機械語とかC言語ではポインタが大活躍します．メモリーには数字による番地が付けられていて，メモリーに格納されているいろんな大きさのデータをその先頭の番地で代表して参照するという仕組みです．この素晴らしい仕組みのおかげで複雑なデータを扱うことができるようになりました．その番地によるメモリーとポインタというのはコンピュータハードウェアの動作そのものですから動く効率はすごく高いのですが，一方でプログラムの上でのミスもやまのようにありました．それに対して，LISPからスタートした言語ではメモリーとポインタをプログラムから見えなくして，ポインタ操作の間違えの元が起きないようにしたわけですね．こんな感じで，よりよい「計算する機械」を作るためにプログラミング言語はどんどん進化してます．それは，理想のコンピュータとはなにか，ということを追求する行為でもあります．僕はこんな細かい話まで，社会全体での共通理解を求めてはいませんが，その大元の考えである「コンピュータの上にコンピュータを作れる」ということだけは知ってほしいと思っています．シリコンチップの発明がコンピュータをここまで凄くしてきた片方の理由だとすると，このコンピュータの上にコンピュータを作れる，別の言い方をするとプログラミング言語の階層，という発明が，膨大で複雑なプログラミングを可能にした理由です．たとえば「核分裂」というのをどれくらいの人が知っているかわかりませんが，それと同じくらい重要な考え方だと思います．

プログラミング教育の先というのは，こういったコンピュータを中心とした社会の原理を知識としてではなく，体験として，体で怖さと凄さを感じられるようにすべきということです．

オブジェクト指向プログラミングを神格化するような記事が流れてきたので，僕が知っている問題点について書いてみたいと思います．僕がまだ学生だったころは，オブジェクト指向の評価もまだそれほど定まっていなくて，オブジェクト指向の次はどんなパラダイムが出てくるかとか普通に学生レベルで議論していたものですが，ここまで強大になってしまうとそれを打ち負かそうなんて気にはならないのでしょうか．僕にはオブジェクト指向が普遍的な真理という感じは全然しなくて，ここまで使われてる理由は，現実的なテクノロジーで大きなシステムを作らなければならない必要性のほうを優先した結果であると認識しています．オブジェクト指向がその後の25年ほどもずっと安定してその地位を保てるほど素晴らしいものとは思えないのです．

以下で上げる問題点は，個別に解決している研究はあったりしますし，僕も論文を書いたりしましたけど，実際の言語に導入されていなければあまり意味がないので，問題点として指摘させていただきました．論文じゃないので，軽い気持ちで読んでいただければと思います．

１）メッセージの流れが見えない
　オブジェクト指向においてメッセージのやり取りほど重要なものはないのに，そのやり取りの様子がプログラム上で表現できていません．メッセージの送信は，繰り返しや条件分岐などの制御文によって作られた関数呼び出しの副作用として間接的に表現されます．一方受信の方はもっと見えなくて，例えばその時のオブジェクトの内部状態によって受信できるメッセージの種類が変わるはずなのに，そういった制御や抽象化ができません．最初に初期化のメッセージを受信した後，処理のメッセージをいくつか受信して，終了のメッセージを受信する，といったプロトコル的な記述もできません．

２）オブジェクトのつながり具合が手続きでしか表現できない
　次に大事なのがオブジェクトのつながり具合です．たとえばＭＶＣという３つのオブジェクトの集まりで一つの部品を作るような場合があります．プログラムは，Ｍ，Ｖ，Ｃそれぞれが同じ相手とつながっていることが前提でつくられます（たとえば，Ｍが知っているＶと，Ｃが知っているＶは同じものである，といったことです）．しかし，このつながり具合が正しいかどうかを保証する方法がありません．木構造をオブジェクトで作るとき，自分の子供は全員自分を親として見ているか．こういったつながりを手続きで頑張って作るので，間違えが入る可能性があります．間違えをできるだけ入らないようにするために，オブジェクトの外側からは内側を触れないようにカプセル化しますが，そういう制約はオブジェクト指向自身が自由度が高すぎる，逆に言うと何も保証しない貧弱であるから必要なのです．


３）ユーザレベルでの部品化再利用に全然なっていない
　僕が素晴らしいプログラムの部品化再利用の例だと思っているのがＵＮＩＸのパイプラインです．これが通じる人はどれくらいいるのかな．コマンドの出力が次のコマンドの入力になるようにパイプでつないで表現するものです．パイプが人間にとってすごく使いやすい理由は，そこを流れるデータが人間に見える形式だったからです．見えるから次のコマンドにどんな処理をさせればよいか考えやすくなります．何か動きがおかしければ，途中に流れている文字列を見ればわかります．典型的な入力データをエディタで作ってもよいですし，途中の処理が特殊すぎてわざわざプログラムで処理しなくてもよいような場合，人間がエディタ上で手作業で編集してもよいわけです．テキストデータという共通のデータ形式の上で人間とコンピュータが協調して問題を解いていたという感覚がありました．

こんな素晴らしい仕掛けが使われた時代はそんなにコンピュータが速かったわけではありません．それでもバイナリーではなくテキストの10進表記で数を表すという，実に無駄な方法が人間の利便性を優先して使われていたということに敬意を表します．

1次元にコマンドを並べて処理を順に行うような単純な処理だけですむ時代は終わりました．パイプに代わるもっと複雑なコマンドの組み合わせ方を発明しなければなりません．パイプは一方向の情報の流れでしたが，情報は双方向の流れを許すべきです．

僕はUNIXにX-Windowというウインドウシステムが入ってきたとき，次世代のパイプが発明されるのかとワクワクしてましたが，結局まだ誰もそれを発明できていません（僕が知らないだけであるのかもしれません）．部品化はオブジェクト指向にとってかわられ，プログラムの中は閉ざされ，人間は遠ざけられました．

北大の田中先生のIntelligentPadにその可能性を感じましたが，結局はオブジェクトの合成という非常に難しい問題がその前に立ちはだかりました．

そうこうしているうちに，WWWの大爆発が起こって全部吹っ飛びました．


４）知識表現が手続き側に偏っている
　プログラミングという処理っぽい呼び方ではなく，もう少し広い意味を込めて知識表現と呼ぶことにします．プログラムはもちろん知識表現の一部です．たとえば，EXCELの表も知識表現ですし，構造をもったデータは知識表現です．オブジェクト指向の何が悲しいかというと，構造をもったデータを直接作り出すことはできないということです．手続きを使って変換するしかありません．たとえばLISPではコンピュータが処理するデータ構造を人間が直接入力することができます．そういう人間とコンピュータの仲の良い関係がオブジェクト指向では消えてしまってます．

５）オブジェクト指向は人間をだましている
　オブジェクト指向で作られた典型的なグラフィカルなプログラムを考えましょう．オブジェクトには内部状態があります．その内部状態を更新させることが唯一の計算です．その内部状態を人間にみせるためのプログラムと，人間が見ているもの（画面）に対するマウスやタッチの操作を解釈して内部状態を更新するためのプログラムがあります．これは上の例ででてきたＭＶＣということなんですが．だましているといったのは，Ｍは内部に存在しますけれども，Ｖがどう作られたかで見え方が違ってきます．同じ見え方でもＭの中身が違っていたり，同じ中身でも見え方が違っていたり，ということが平気で起きます．真逆はLISPです．LISPはコンピュータが見ているメモリーの構造と人間が見ているＳ式とが1対1の関係になるので，つまり人間とコンピュータが同じものを見ているという安心感があります．オブジェクト指向はコンピュータと人間が同じものを見ている感がしません．コンピュータがすごく頑張って人間にすごいものを見せている（もしくはだましている）という感じです．

　こうなっちゃった理由は，コンピュータに課せられた役割が，これまでプログラムを作る人と使う人とが一体となっていた時代から，作る人と使う人とが明確に分かれた時代に変わってきたということなのかもしれません．UNIXのテキストは人間にわかりやすいといっても，ビットマップのテキストよりは見栄えがしないわけで，作る人と使う人が一緒なら我慢もできましょうが．逆に，使うだけの人にとっては，上手にだましてもらったほうがいいわけですし，よりかっこよくだました方がお金が儲かるという事情もあったのでしょう．


６）オブジェクト指向は貧乏
　オブジェクト指向が活躍した時代はメモリーが非常に少なくどう節約するかが重要でした．なのでよく使われていた例は，列というものがあって，その列をどのように扱いたいかによって実行の効率が変わるので，使用法に適した実装を選んで効率をよくすることができる．しかしアルゴリズムはそのデータ構造の影響を受けないように計算方法だけ書けばよい．そんなことが言われていた時代でした．つまり，一度書いたアルゴリズムはいろんなデータ構造に対して，効率の良い実行ができるというものです．

しかし今は，メモリーもふんだんにあって実行速度の差もそれほど重要ではなくなってきたので，そんな実装方法に依存しないアルゴリズムという貧乏なことを言わなくてもよくなりました．万能なデータ構造を一つ決めて，アルゴリズムは全部その構造に対して作ってしまえばよいのです．LISPみたいなものです．ただし，LISPの時代から何が変わったかというと，扱うデータが木構造のように単純ではなく，グラフ構造になったこと．一つのスレッドではなくマルチスレッドでかつ分散になったこと．オブジェクトが複雑に参照しあっているようなグラフ構造をLISPのS式のようなシンプルで汎用性のある記法で記述しなければならないということです．なのでS式的な今風の拡張が求められています．

７）関係を記述できない
　メッセージは単項演算なので，複数のオブジェクト間の関係を表現するのが苦手です．ある一つのオブジェクトに，起きろ，歩け，といった命令をするだけなら簡単です．それに対して，二つのオブジェクトが関係する命令，たとえば二人に対して，ぶつかれ，ならべ，という命令が苦手です．通常のオブジェクト指向では，関係するオブジェクトのどれか一つを特別に選んで，それに対するメッセージとして表現します．他のオブジェクトはそのメッセージの引数として渡されます．２）で言ったようなつながり具合を表現したければ，メッセージの受信側に選ばれたオブジェクトが責任をもって引数で渡されたほかのオブジェクトどうしをつながなければなりません．

Prologは関係を表現できます．というか関係しか表現できません．たとえば，Ａ＋Ｂ＝Ｃという式があったとします．普通の言語ではＡ＋Ｂの計算をして，Ｃのメモリーにその値を書き込むという解釈をします．ＡとＢの値が決まっていてＣは未定義だったり，Ｃの新しい値としてこういう計算をしました．それに対して，ここで表現した式は計算の方法ではなくあくまでも式というか変数同士の数学的な関係を表していると解釈できます，たとえばこの式があったとき，Prologでは「Ｂが２０，Ｃが５０のときＡは何でしょう」という聞き方にもこたえることができるのです．

計算の方向まであとで決められるくらいの自由度はともかく，オブジェクト指向がメッセージのやりとりにこだわっていると，関係を表現するのがすごく大変ということはわかっていただけたでしょうか．


オブジェクト指向の問題点のうち，ごく一部はビスケットの設計方針に影響を与えています．たとえば，コンピュータが裏で人間のために頑張るというのではなく，コンピュータと人間が同じものを見ている感というのを大事にしている部分などですが．人間とコンピュータの関係がどうあってほしいかといった思いも込められています．

Twitterで住井さんと山口さんがプログラミングの興味深い議論をしてまして．その議論をきちんと追えてはいないんですが，ビスケットについても語られていた部分があったので，ちょっと考えてみました．

もともとは，数学とプログラミングの違いからはじまり，プログラミングの本質はどこにあるのかから，逐次実行，分岐，反復は基本だよね，といった流れのようです．

「右に動き続ける」と「「右に少し動く」を繰り返す」の間には認知的にはギャップがあるはずで、Scratchを使うと「「「右に少し動く」を繰り返す」→「右に動き続ける」」が学べるように思えるけれど、Viscuitで学べるかはよく分からない。

— Ryusei Yamaguchi (@mandel59) 2016å¹´5月7æ—¥

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>


Scratchを始め，ほとんどのプログラミング言語には，明確に逐次実行，分岐，反復が言語の構成要素として現れています．これらを組み合わせることでプログラムを作りますから，当然これらの構成要素を強く意識します．ビスケットとはいろいろと違うのですが，一番大きな違いは「いまどの命令を実行しているのか」という概念がそれらの言語にはあるということです．この「どの命令を実行しているのか」はCPUのレベルではプログラムカウンタという言い方をしてます．命令がメモリーに順番に並んでいて，その順番通り実行すればよいので，基本的には数が１つずつ繰り上がることから，「カウンタ」という呼び名になっています．もっと上の言語になると命令の列をメモリーとして意識しないのでカウンタと呼ぶのは変ですが．なんというんでしょうね．明確な呼び名がすぐに思いつかないのは，その概念が（ブロックのような）プログラムの構成要素としては出てこないからでしょうか．そのプログラムカウンタのようなものが，現在実行しているブロックを指し示していて，指し示すブロックが変わってゆくことが逐次実行，分岐，反復を表現しているわけです．

それに対して，ビスケットにはどの命令を実行しているのかという概念がそもそも存在しません．存在していないので，逐次実行，分岐，反復といった概念も明確に理解することには繋がらないですし．ではどんなことを学んでいるのでしょうか？

ビスケットの教え方を順を追って見てみましょう．この過程で，子供達のコンピュータの理解はどのように変化しているのかを推測してみます．

１）メガネの左右に同じ絵を入れて，その絵を動かす．メガネの中の絵の動き方で方向と速度を調整できる．この時点では自分で絵を動かすツールという理解になるでしょう．同じ絵は同じ動きをする．メガネの中を変えると，同じ絵は一斉に動きを変えます．メガネが壊れると一斉に動きがとまります．瞬時に変化が全員に伝わるすごさと，一斉に壊れるというコンピュータの脆さも伝わります．ときどき，システムのデザインをやっている大人からは，ここまでの理解だけではメガネに丸が左右にあることは無駄で，方向と速度を示すだけの一つの丸でよいのではないかという質問をもらいます．

２）同じ絵を使ったメガネを二つ用意する．たとえば上に進むメガネと下に進むメガネ．これは新しいビスケットに追加された機能で，２つのメガネがランダムに選ばれて実行します．その結果その絵はゆらゆらと動くことになります．普通のプログラム言語ではランダムな実行というのはかなり上位な概念で作られますが，ビスケットではそれが組み込みの機能として入っています．このとき，子供達には，メガネは命令というよりは，その絵が持っている性質を表しているという印象に変わると思います．我々は「おばけは上に行ったり，下に行ったりする」という言い方をしています．命令ではなく，あるべき性質の一つを定義すると感じです．だいぶ宣言型言語らしくなってきました．

これでもメガネのまるは，まだ一つで十分ですね．

３）２つの絵で，パクパクするアニメーションを作る．このとき初めて，メガネの左側の意味がでてきます．メガネはある絵をある絵に変える（位置関係も含めて）という説明をします．いままではたまたまメガネの左右に同じ絵が入っていたから動いて見えているだけでした．絵を変えるということができるとわかると，たとえば絵を１０個書いて，１０個のメガネで順に変化させるといった実験もできるようになります．２コマから１０コマに変わるという理解で，逐次実行が理解できたと思ってもよいかもしれません．途中で同じ絵から始まるメガネを複数つくると，「赤いボールは，青くなったり，黄色くなったりする」といったことにもなります．これは状態遷移図につながります．ある絵で動きが止まってしまうことがありますが，それはその絵から始まるメガネを作っていないからです．これで反復が明確に見えてきます．それから最初にある絵を置いたとしても，そのあとその絵が出てくることがないということがある場合は，その絵が右側（結果）にはいっているようなメガネを作っていないということです．これらを通じて，プログラムが止まらずに動き続けるにはどうしたらよいか，という重要な概念を学ぶことができると思います．

つぎにやっと条件が分岐が入ってきます．

４）メガネの左側に２つの絵をいれます．この絵とこの絵がぶつかったら，という言い方をします．いままでは絵の単独の性質を記述していましたが，二つの絵の衝突を導入することで，その絵の位置関係を使ってある条件を表すことができるわけです．一番単純なのは「尺取り虫がボールにぶつかったらボールをける」というメガネですね．絵の配置だけを変化させています．もう少し複雑になると，「健康な人と風邪をひいた人がぶつかったら，風邪がうつる」というメガネで，２つの絵がぶつかると，片方の絵の種類が変化する，ということが表現できます．これを動かすと絵の数が変化する様子が見れるので，一つの箱庭のシステムとしてものをみることができるようになります．ここから，指数関数的な広がりの理解などに繋げられます．

こうしてみると，ビスケットでは逐次実行，分岐，反復にだけ特化しているというよりは，もっといろいろなシステム全体の動きを総合的に理解して，その中の一つに，逐次実行，分岐，反復が現れている，と考えることができるように思います．実際にはその３つだけが自然界で重要であるとは思えないですよね．たまたま，コンピュータのハードウェアが採用していたというだけであって．

それよりも，ビスケットが重視しているのは，「一つの命令は小さい変化しか起こせない」ということです．逐次実行，分岐，反復も小さい変化を組み合わせて作られてますし，それ以外にも小さい変化で作れるものはたくさんあります．つまり，プログラミングのもっとも基本的な考えは「小さい変化を組み合わせて複雑なことを実現している」ということであって，そこから上位の概念を教えるのがよいだろうと思います．

何度も繰り返して言ってますが，プログラミングを全員が学ぶ必要があるのはコンピュータとは何かを知るためです．何度も質問をされますが「プログラミングを学ぶとどんな能力がつくでしょうか」に対して僕は一切答えるつもりはありません．というか，我々（コンピュータの専門家）は答えるべきではないと思っています．

本心からいうと，たとえば佐藤さんのブログで

自己研鑽力，ルール適応力，根回し力，といったことが言われていて，僕も共感できますし．神谷さんの本「子どもにプログラミングを学ばせるべき６つの理由」の内容も同意です．うすうす感じています．きっと正しいと思います．

ただ，こういった力がつきそうということは，プログラミングを教えて普通に観察していると気がつくことなので，できれば外部からではなく，内部つまり学校の先生たちに気がついて欲しい．だって子供にいろんな力をつけさせるというのは先生たちの本業であって，重要な能力であればあるほど，先生たちはそういった子供たちの変化に敏感であるはずですから．

ある小学校に授業に行ったときなんですが，終わって校長先生の部屋でお茶をご馳走になっていたら，担任の先生がその次の授業の合間をぬって，僕たちに授業の感想を言いに来てくださいました．

「子供たちの普段とは違う側面を見ることができて本当に良かったです．あの子がこんなことができるなんてまったく知りませんでした」

それだけ言って，すぐに教室に戻られたのですが．いや本当先生はお忙しい．

僕らは毎回いろんなクラスで普段通りやっているだけで，その中にはバンバンやる子もいれば，友達に教えられながらやる子もいれば．まあいろいろです．普段がどうということはまったくわかりませんから，教え方としては，一番遅い子に合わせて，でもはやい子も退屈しないように気をつけてやっているだけです．何がどう変わったのか，たとえば普段，絵をまったく描かない子が描いた，とか，普段まったく発言しなかった子が自分から質問したとか．そういったことは，我々にはわかりません．

しかし，子供たちの変化に敏感な先生であればあるほど，たった１回の授業でも，いろんなことに気づくはずです．繰り返してやるうちに，これは何々力をつけるのにつかえるツールだ．ということがしっかりした証拠で言えるはずです．

逆に，事前の打ち合わせでいつも言われるのが，やんちゃだとか，理解が遅いとか，発達障害の子供がいるんですといった，ちょっと飛び出た子がいるので気をつけてくださいということですが．ところが，僕らも終わってから，どの子が心配な子だったのか気がつかないほどで，僕らも特別なケアはしていません．でも，いろんな先生からいつも言われるということは，先生方にとって，普通の授業をする上ではそういう子の存在を知っておくことが重要なんだとということなのでしょうが．僕らはそんなに重要ではないわけです．

外部講師の役割の一つに，担任の先生とは違う視点を教室に持ってくる，ということがあると思います．それは先生にとってももちろん，クラス全体にとっても重要なことでしょう．担任の先生ができることをわざわざやる必要はないですし，そこで担任の先生と奪いあっても仕方がない．

絵が描けない子が，絵が描けるようになりました．というのを担任の先生に言われるのは我々も嬉しいのですが，逆に，こちらから「絵が描けない子でも絵が描けるようになりますよ」と言ってしまったら，「いやいや，うちでは他の方法で絵を描けるような教え方をしてますから」になっちゃいますよね．それはすべての「何々力」に言えることです．

唯一，我々にしか言えないことというのが「プログラミングって楽しいよ」「コンピュータはこういうことなんだよ」ということであって．まあ，それだけを愚直に言っていくのがだれも敵に回さない方法だと思うのです．

先日書いたブログが拡散して，某新聞記者から取材を受けました．意見を持っている人にとって，それがちゃんと伝えられるいい時代になりましたね．そんなわけで，自分の中ではとっくに解決している問題ですがあらためてブログに書いておくことにします．

プログラミング教育が小学校でという話で，誰が教えるんだ．どの教科を削るんだなど，よく言われている課題がありますが，僕は実現はそんなに難しいとは思っていませんので，それを書きます．


１）誰が教えるの？
　前に書いたとおり，小学校の各学年で２時間程度ですから，専任講師が教えます．２時間の授業６学年分のやり方を覚えた人が講師になります．担任の先生は，同じ子供に毎回違うことを教えるのに対して，この講師は同じことを毎回違う子供たちに教えますので，その内容に関してすぐに上手に教えられるようになります．売れない芸人が毎回同じタイミングでお客さんを笑わせているのと同じ感じです．どの説明がわかりにくいか，どこはもっと短くてもよいか，２－３回授業をやるとすぐに改善されます．

　これらの講師はそれほど専門的な質問には答える必要はありません．まずは「今度ハカセに聞いておくね」で十分です．講師がわからない質問をしたということで，子供も鼻が高いでしょうし．中途半端な知識で知った風に答えてしまう方がやっかいです．中途半端な専門家よりも，子供の目線に立てる人の方が重要です．

２）機材はどうするの？
　専任講師がタブレットを人数分持っていきます．無線やサーバなどの機材も持ち込みます．いまだとタブレットは１台2.5万円くらいで，児童の人数にもよりますが３０人として全部で150万円くらいで揃えられるでしょう．

３）全国に展開するには，講師は何人くらい必要で，お金はどれくらいかかるの？
　日本には小学生は各学年で１２０万人くらいいます．クラス数にすると，小さいクラス大きいクラスいろいろとあるでしょうが，平均２０人として（人数の少ないクラスだったら，２学年同時にやってもいいですし），６万クラスです．６学年で３６万クラスですか．各クラス２時間ずつできっちりとつめると，１日３クラスの授業ができます．１２万人日必要です．１年に２００日くらい授業ができるとすると，６００人の講師がいればすべての学校に行き渡ることになります．各県で１０人くらいと考えると，一人でどれくらいのエリアを担当するか想像できると思います．つまり，６００人の年間の人件費と，各人150万円くらいの機材費ですね．人件費はどういう人材を講師にするかという考え方にもよりますが，わかりやすく，350万くらいとすると，合わせて500万円です．最初の年は３０億円，翌年からは機材日がかかりませんから２０億くらいずつです．そんなにバカみたいな金額ではないとおもいます．

実際には，人件費は各自治体がどういう人を雇うのかで，決まって行くとおもいます．たとえば，ICT支援員さんを雇っている自治体もあるので，その人数を増やして講師として派遣するというのもいいですね．

４）何を教えるの？
　前のブログの記事では全部ビスケットを教える風に書きましたが，高学年は違うことをやってもよいとおもいます．ただし，これが成立するのは，各クラスで２時間に収めるというのが前提です．ITに力を入れている自治体はもっと予算をかけてやればよいと思います．前のブログではあえて「ものづくり」の視点は外してあります．その視点は大事ですが，そこまで広げると話が散漫になってしまいます．図工などを中心としたカリキュラムの再編成で解決すべきで，もちろんプログラミングは最重要にですけど，設計とかコンピュータとは無関係に重要な話もいろいろとあるので．

５）なんの時間で教えるの？
　２時間だけの時間をもらえればよいので，学校がどの授業の枠でやるかを決めればよいと思います．僕は総合の時間でよいと思います．総合の時間はそもそもそういう使われ方をするために生まれたと思っています．

６）対象は子供だけ？
　本当は大人も受けるべきです．PTAや，もちろん学校の先生にも．大人を相手ですから，子供よりは短い時間で６学年分をやってしまうことができるように思います．そもそも，いまの大人は成長の過程で習ってこなかったことですから，どこかのタイミングで習う必要があると思います．

７）何年間続けるの？
　これを３年くらい続けたときに，学校でも自前のタブレットを揃えるというところが増えてくるのと，自分でも教えられるという先生が増えてくることが予想されます．自分のクラスで自由に使えるタブレットがあったときに，先生は他の教科の中でもプログラミングを導入してみたくなるでしょう．それらは，いま盛んに実証実験されている，国語，図工，音楽などの教科の中で実施していることとも繋げられます．

まずは，子供の教育に携わっている大人全員が，この授業の重要性を知ってもらうことが大事です．理解された後は，自動的に話が進むはずです．いま進まない理由は，単なる無知や誤解からですから，それを解くということが最も重要な課題です．

　
８）これをやるとどんな人に育つのか
　教育の評価は非常に難しいと思います．それを教えるか教えないかで，その人の将来がどう違ってくるのか，というのを何年も待たなければないわけですから．しかもあることを教えなかったといっても，その人は授業とは別に本で読んで知っちゃったかもしれないと考えると，正確な実験なんてできっこありません．

教育の別の見方として，子供に新しい視点を与えるというのがあります．コンピュータの中身を少し知るということです．これはほぼ無条件でプラスです．知らない方が幸せな人生を送れたということは考えにくい．年間３０億の予算と，各自２時間の時間と引き換えに，新しい視点を与えるという選択になります．

それも早ければ早いほど良いでしょう．たとえば，子供はタブレットでゲームをやったとき，自分でゲームを作れて，それは意外と簡単だけど意外と難しいというのがわかるかわからないか．ゲームをやり始める頃には，中身についてもやりたいですね．

９）この先どうするのか
　本当のプログラミング言語はもっと色々とあるし，それを学ぶ方法も沢山あります．僕自身，プログラミングを覚えたのは３０年以上前で独学でしたから，インターネットの時代に，環境さえ用意してあげれば大人がとやかくいうことはないと思います．それを支える見守る大人が増えればよいだけです．

そして，上に述べたことは，知らない大人にどう知ってもらうのか，ということを遠回しに言っているのことなのでした．

コンピュータとは何かということを言い続けてますが，それ自身ぼんやりした話ですよね．知っている人はなんとなく知っていて，知らない人はまったく知らない．一体何と言われてもぼんやりしたことしか言えない．

ということなので，僕が考えていることを，少しずつ説明してみます．

まず，みんなに知ってもらいたいのは，「コンピュータはバカだけどすごい」という話です．コンピュータの動きってときどき，信じられないくらいバカな動きをしますよね．一方でむちゃくちゃ賢い動きもする．どうしてそうなっちゃうのかということです．

コンピュータはプログラムで動いています．そのプログラムの中身はというと，小さな命令があってそれを組み合わせて一つのプログラムになっています．どれくらい小さな命令かというと，これが人間が考えるよりもずっとずっと簡単な・単純なことしかできません．数を読む，数を書く，数を引く，数を足す，数を比べる．本当にこんなことしかできません（本当にそうです）．コンピュータがいろんなことができるのは，いろんなことを数に置き換えているからですけれど，もう一つ重要なことは，単純な命令しか使っていないけれど，それはそれはものすごい数の命令の組み合わせでプログラムにしているからです．１０個や１００個ではないです．１万個や１００万個くらいの命令の組み合わせで動かしています．それがものすごい速さで動いて命令の多さが見えてこないので誤解されるわけです．

コンピュータがバカというのは，単純な命令しか実行できない，ということです．コンピュータがすごいのは，むちゃくちゃ多い命令を高速に実行するからです．コンピュータがバカだというのはプログラムを書く人だけの秘密ですね．

僕が，大人向けの講座でやっているトランプの遊びをご紹介しましょう．これはコンピュータの命令を組み合わせることがどれくらい難しいことなのかということを体験するものです．

２人ペアになって，トランプを５枚配ります．わかりやすいように，５枚のマークは同じものにするとよいです．

トランプを伏せておいて，それを数の小さい順に並べるという課題を，二人で解決します．

一人は命令を出す役，もう一人はコンピュータ役です．

命令出す役の人はカードの数を見てはいけません．コンピュータ役の人にやって欲しいことを言うだけです．

コンピュータ役の人にお願いできることは次のことです．
　カードを動かしてもらう．
　２枚のカードのどちらが大きいかを聞く．


こんな感じですすみます．

a「このカードとこのカード，どっちが大きですか」
b「こっちです」
a「では小さい方のカードをこっちへ，大きい方のカードをこっちへ動かしてください」
b「はい」

a「このカードとこのカード，どっちが大きいですか」

これを繰り返します．

まずは，最短で並び替えるということは考えなくて良いです．というのは，最初にカードがどのように並んでいるかで手数が変わるからです．それよりも，間違わないように慎重にやるようにしましょう．終わったと思ったら，ひっくり返して確認します．コンピュータ役の人はどこで間違ったかを知っているので（でもゲームの途中では言えない）教えてもらいましょう．たった一回のミスが最後まで尾をひきます．コンピュータ側の人からみると「その操作はさっきもやったのに」と思うような無駄なことも，命令する人にはわからないですよね．

何度か役を交代して，間違わないように命令をだすということがどれくらい難しいのかを身を以て体験しましょう．人間とコンピュータの違いがすごくよくわかるとおもいます．

（ぜひ身近な人ととやってみてください．プログラムを知っているからと言って，簡単にできるわけでは無いようですよ）

よく，コンピュータのアルゴリズム的な考え方が重要だ，といった言い方を聞きますけど，そもそもアルゴリズムというのはどういうものでしょう．

実は，この遊びではまだアルゴリズムにまでは到達できていません．命令を出す役の人は，カードがどのように動いたかを観察して，その都度次の手を考えているからです．でも，何度か交代してやっているうちに，必勝法というのがわかってきます．こういう考え方で，こういうときにはこうすればよい，といったことですけど．必勝法が思いつくと，その方法を文章に書くことができます．その文章を読んだ人もまったく同じやりかたで一発で成功できるようになります．この必勝法のことがアルゴリズムなのです．

必勝法ができると，ゲームの間はそのやり方に従って命令を出せばよいだけなので，ほとんど頭を使いません．必勝法を知らない頃はすごく考えていたのに，考えなくても，できるようになります．道具をつかったり（カードを並べた位置に印をつけるとか），カードの並べ方，重ね方などを工夫して，より手順が少なく，頭を使わない必勝法がよい必勝法です．

一方で人間がトランプの数を小さい順に並べる作業を考えてみましょう．人間の場合は，カードが全部表を向いています．なのでパッと見たら一番小さいカード，大きいカードがすぐにわかります．あとは両手を使ってささっと並べ変えれば終わりです．カードの枚数が１００枚くらいになったらさすがにそんな簡単にはできませんが，５枚くらいだと本当に簡単です．人間がどれくらい高度で複雑な命令を実行できるかよくわかるとおもいます．

トランプを相手にしてますから一番小さい数が１で，一番大きい数が１３ということを知ってますけれど，本当の問題は，数の範囲もわかりませんし，どっちに偏っているかもわかりません．

本当のコンピュータも，ここでやったように２つの数の大小を比べる，数を書く，数を読む，という命令しかできません．それらを組み合わせて，膨大な数を小さい順に並び替えているのです．並び替えるというだけで命令数は１０００くらいは必要でしょう．

コンピュータでいろんなことをさせてますね．最近は写真に写っている顔を交換するという面白いアプリが流行っていますが，写真は１点１点の色を数で表してその計算だけで，こういうすごいことをやらせているんですから．

「コンピュータとは何か」の一つとして，コンピュータはどこがバカで，どうしてすごいのか．なんとなくわかりました？


では，次の疑問，何万，何百万という命令を間違わないように組み合わせなきゃないわけですが，それはどうやってやるのでしょう．そういう感じで，コンピュータ入門講座は進んで行きます．

プログラミングを小学校からやるという方針がやっとでましたね．僕も以前から主張していましたが，政府の後押しが出たのは喜ばしいことです．ところが，やはりというか「そんなことは小学生のうちからやる必要はない」という意見もチラホラでています．コンピュータが嫌いな人から出ているのならまだしも，コンピュータの専門家の中からも聞こえてきます．こんなのいつひっくり返るかわからない危うい決定なんですから，せめて専門家の間では足並みを揃えたいところですが．

こうなる理由は「プログラミングを教える」ということがちゃんと定義されないで，それぞれが思ったことを言っているからですね．ということなので，僕が考えている小学生向けの授業をざっとご紹介しようと思います．

僕は，各学年で４５分の授業を２回ずつで，６年間で１２回（毎週２コマではなくて年間で２コマです）というのを考えています．プログラミングを教えると色々な効果があると言われていますが，それらは全部後回しで，この１２回では子供達に「コンピュータとは何か」ということを少しずつ教えてゆきます．

１，２年生
　自分の書いた絵が動く．メガネを二つ以上つかってゆらゆらさせたり，２コマのアニメーションをさせたりする．

　伝えたいこと：コンピュータは自分たちのものだという感覚．作った通りに動く．間違うと間違った通りに動く．作品はネットで公開されるので，見られても恥ずかしくない作品を作ろう．


３年生
　身の回りにあるコンピュータが入っているものを探してみる
　尺取虫が動く．尺取虫がボールをける．

　伝えたいこと：ひとつひとつのメガネは単純な動きしかしない．メガネを組み合わせると複雑な動きになってゆく．身の回りのコンピュータとビスケットとは何が同じで何が違うか．同じなのは単純な命令（メガネ）しかないということ，違うのは命令（メガネ）の数が何万，何百万という途方もなく多い．多いから複雑．コンピュータには最初から複雑な動きが入っているわけではない．命令を組み合わせるから複雑になる．


４年生
　風邪が感染して広がってゆくシミュレーション．

　伝えたいこと：ものと情報の違い．ものは複製できない．情報は簡単に複製できるので，簡単に拡散する．一度広がってしまったものを消すのは難しい

５年生
　２進数のカウンタを作る

　伝えたいこと：計算するとはどういうことか．人間がする計算とコンピュータがする計算の違い．２進法は簡単な計算方法だからコンピュータに採用されている．

６年生
　矢印を並べて，それに従って動く絵．

　伝えたいこと：今までのビスケットの遊び方とはちょっと違う遊び．メガネを作るだけじゃなくて，絵をどのように並べるかで動き方が変わる．プログラムとデータの関係．データを解釈してうごくプログラムがあると，データの並びそのものがプログラムのように見えてきて，それがプログラミング言語になる．プログラミング言語の階層があって，ビスケットの上にもう一つ矢印言語を作ったということ．プログラミング言語という発明はコンピュータが発展した大きな理由である．１万個のメガネのプログラムを間違えないように作るのは大変だけど，プログラミング言語を間に入れると，メガネの数が人間が扱える範囲にまで減らせられる．
（この授業が一番伝えたいこと．コンピュータがどうしてすごいのか，ということを子供達に知ってほしい）


この他にも，ゲーム作りや絵本作りといった楽しい授業もいろいろとできるのですが，それらは図工とか国語の時間にやるべき内容ですよね．子供達のウケはすごく良いのでやりやすいとは思いますが，すべての子供たちがやるべきだとは思いません．そこで狙っている内容はプログラミングじゃなくても教えられるからです．

それに対して，コンピュータとは何かを教える授業は，プログラミングでしか教えられないので，それが必須にする理由なのです．

これらをやる理由は，小学校にある田んぼの話などこのブログにもいろいろと書いてますね．

桐蔭学園の幼稚部のアフタースクールでビスケットのワークショップが行われた内容をご紹介します．

【幼稚部】スペシャルプログラム「海のせかいを描いて動かそう！」

記事を読むと，みんな楽しそうに遊んでいます．これほど子供の表情がわかるくらい近くで見れるのも珍しいです．

この中の上から６枚目の写真でおばけのゆらゆらを作っている画面がはっきりと見えるので，そこの解説をしましょう．

いま，ひっそりとテスト的にリリースされているAndroid, AIR(windows/Mac)版には，メガネのランダムな選択という機能が入っています．これが初期のビスケットを非常に表現力の豊かなものにしています（古いビスケットでは動きません）．



このように，おばけの動きで，メガネが２つ使われています．上のメガネはおばけが上に進む．下のメガネはおばけが下に進むです．今までのビスケットでは，メガネの左側（条件部分）がまったく同じ場合はどれか一つのメガネが選ばれたらそのままずっと選ばれっぱなしになってました．古いプログラミング言語の考え方ではこれが真っ当な仕様です．

ところが，新しいビスケットではこのメガネの選択をランダムにしました．毎回どちらが選ばれるか変わります．交互でもないです．

その結果，このおばけはゆらゆらと上下する動きになるのです．



どういう教え方をするかというと，「メガネをこうすると，おばけは上に動きます」「メガネをこうすると，おばけは下に動きます」「では，上に動くメガネと下に動くメガネを２つにしたら，どうなるかというと，このようにゆらゆら動くようになります」

そうやって，自分たちで試してもらいます．

それで，先ほどの子供の写真に戻りますと，写真をよく見るとおばけの動きに，メガネが３つ使われています．例えば，こういうことです．




ここでは３つ目に，おばけは後ろに下がるというのを追加しました．これによって「おばけは上に行ったり，下に行ったり，後ろに下がったり」するようになります．

メガネを３つ４つと増やせば，どんどん動きが複雑になってゆく，というのを発見する子供は，幼稚園児対象でも毎回何人かいます．


この応用で，カニが進んだり止まったり，というのもあります．横に動くというメガネと，動かない（左右で絵が同じ位置に入っている）というメガネをつくると，じっとしてて時々動くというカニができます．動かないというメガネをいれるといろんなものがすごく生き物っぽくなるんですよね．





ここまでは，基本的な動き（上下左右，早い遅い止まる）とメガネがランダムに選ばれるということだけを教えましたが，それらを組み合わせると実にいろんな動きを作ることができます．これらの動きはこちらからは教えません．自分で発見してもらいます．メガネを増やせば増やしただけ動きが複雑になります．

僕が子供たちに伝えたいことは，コンピュータの複雑さはどこからくるのか，ということです．ゆらゆら動くとか，ときどき止まるといったことは，もともとコンピュータの機能には入っていません．コンピュータは基本的な動きだけしかできません．最初はその基本的な動きだけで遊びます．それらを組み合わせることで複雑な動きができるようになります．新しい組み合わせを発見すると，できることが一気に広がります．その広がって行く感じ，これこそが僕たちがコンピュータに感じている可能性です．

これを幼稚園児に体験を通じて伝えられるということは，なかなかすごいことですよね．


さて，２月２８日はビスケットの誕生日です．今年はちょっと特別なイベントビスケットバースディ～パーティーを企画しました．様々な方にビスケットの魅力についてお話しいただきます．

http://party.viscuit.com/

阿部さんとの対談が個人的には楽しみです．