年金番号の流出の話

プログラミングから脱線すると色々と言いたくなるという．

年金番号がウイルスにかかって流出してしまって，想定される被害は年金番号の成り済ましが怖いので，流出してしまった人たちに番号を再発行して郵送するとかニュースで言ってました．

実は，僕の学位論文の一部で，オープンシステムにおける名前付けの問題について議論しています．ちゃんと論文にもなっています．そのときの議論の延長線上に今回の年金番号流出もからんでいるので，その話をしましょう．

当時の話題の中心は，インターネットでした．世界のコンピュータにそれぞれ一意の番号をつけて（つまり，全部のコンピュータが違う番号をもっている），その上で，ある番号のコンピュータにメッセージを送りたければ，どうやってそのコンピュータを探すか（ルーティング）という問題を解けば良い，ということにしていました．その後に出てきたIPv6も色々と修正してますが同じです．

ルーティングはきちんとアルゴリズムを作ることができましたが，このシステムの最大の問題は，世界のコンピュータがそれぞれに一意の番号をつける，ということです．同じ番号を名乗るコンピュータが２つ以上あるとシステムはちゃんと動きません．アルゴリズムではそこは保証できていません．社会がそれを保証するしかないのです．つまり，インターネットに接続しようとする人は，団体から与えられたIPアドレスの範囲で名前をつけて，それで接続する．そのルールを破った人はつないではいけない．

当たり前だと思うかもしれませんが，これはオープンシステムではありません．集中的な組織があって（それが木構造で分散管理されていたとしても，最終的にルートが１つなら同じことです）そこからの管理に従わなければちゃんと動かない．その中で決めた社会のルールに従ったものだけが通信ができる，というシステムです．

オープンシステムというのは，こういう集中的なルール・組織を一切仮定しないで成立するシステムのことです．局所的な，つまり隣り合ったもの同士の約束を守るだけで，全体の整合性がちゃんと取れているというシステムです．そして，それは作れるのですよ．

僕が提案した解は，相対アドレスだけを使ってすべての計算を行うというものです．相対アドレスというのはまず，そのアドレスの起点があります．起点が変わると相対アドレスの中身が変わります．何を起点にしてそのアドレスを言っているか，というのがすべてです．

「居酒屋の隣に座った親父問題」というので説明します．あるおじさんと居酒屋で，偶然隣りに座って，話が盛り上がったとします．その時点で，2015年6月1日の「ゆかり」という居酒屋に20:00-21:00の間にカウンターの3番目の席に座っていたおじさん，という名前がつきます．自分の中では飲み屋であった美空ひばりの話をしていたおもしろいおじさん，という言い方でその人のことを思い出せるならば，それでもよいです．けっして，おじさんのDNA番号といった世界の人間を明確に区別できる番号でその人を指し示してはいません．その人のDNA番号を必要もありません．

話が進んでいるうちに，実は同郷だということがわかりました．さらに年齢を言い合うと，なんと僕の中学の同級生，中村君のお父さんだったということがわかりました．この瞬間に，このおじさんの名前はおもしろいおじさんから，中村君のお父さんという言い方にかわります．どっちの言い方も，相対的なものです．僕の言う「中村君のお父さん」という言葉は，「中村君」で同じ人間を思い出せる僕の中学の同級生の間でしか使えません．それ以外の人には「原田の中学の同級生の中村君」と言い換えないとダメです．

相対的な名前は，周囲の情報によって変わる可能性があり，伝えた相手にとっても相対的な名前でなければなりません．名前の変換が主の計算になります．

相対的な名前でも，インターネットで実現できているどんな相手とも通信ができる，ということは作れます．それを示したのが僕の論文です．名前の変換を全員がちゃんとやれば繋がるよということです．

話が大幅にそれましたが，年金番号が秘密の番号である，という社会のルール自体が脆弱すぎます．そんなのに頼らなければ上手く行かないシステムはいずれ破綻します．これは，この後導入されるマイナンバーでも同じです．

僕らコンピュータ屋が考えているのは，どんなにダメな人たちが管理しても絶対大丈夫というシステムを作ることです．そして，それは作れます．とっくに出来ているものもあります．

ところが，コンピュータの本当の意味の専門家じゃない人たちが色々と勝手に決めちゃうので，彼らはそういうことができることも知らないし，社会のルールとか法律でそれを守ればよいという極めて脆弱な解決方法しか知らないので．こんな風に社会が動いているうちは，こういう事件が多発します．

ウィルスに感染したメールを開いてしまったのが原因ではないです．人間はミスをします．そのミスによる損害は，そのミスと同じレベルの損害で抑えられるようなシステムでなければなりません．誰でもついクリックするじゃないですか．そのミスはそんなレベルですよ．ウィルスチェックをしなかったなんて大した問題じゃないんですよ．

一番の問題は，脆弱なシステムの上に大事なシステムを構築したことなんです．どんなにダメな人間が関わっていても大丈夫なシステムを作ってそれに乗ればいいんですよ．

ーー追記
最後の文章はちょっと筆が滑りました．半分眠りながら書いていたものですから．すみません．


今月末にこういうイベントをやります．この相対アドレスの話はしませんけれど，ぜひ．
コンピュータの本質を新規開発に活かす

文字の入力の問題

今回はプログラミングの話題からちょっとズレて，コンピュータへの文字の入力の問題について書いてみます．

日本の小学校の教育では手書きが中心ですが，海外では手書きはマイナーで，普通にコンピュータで作文やレポートを書かせているのだそうです．どうしてここまで差がついたのか．これは日本の教育界が古き良き伝統を重んじるとか（そういう傾向はあるのかもしれませんが）それだけではないと思います．

アルファベットを言語としてもつ国はアジア以外はほとんどだと思いますが，彼らにとってのキーボードというのは入力したい文字とキーが1対1に対応している，直接入力デバイスです．彼らが手書きを捨てて，キーボードを選ぶというのは，本が活字を使っているというのと同じくらい自然なテクノロジーへの対応です．

日本語でそれに対応しているのが漢字タイプライターというものです．すべての漢字がずらーっと2000個くらい並んでいて，それを選んでガシガシと打って行きます．コンピュータがまだ漢字を使えなかった時代にはよく使われていました．僕の父は国語の教師でしたが，漢字タイプライターは得意だと言ってました．これをそのままコンピュータの入力とする方向性もあったと思いますが，コストとか入力効率とかの問題で消えて行きました．

そこで出てきた技術が「かな漢字変換」というものです．かなを入力してそれを読みから漢字に変換する．でもそもそも漢字というのは見た目に意味・情報が詰まっている文字であるにも関わらず，その特徴を捨てて，音で入力します．漢字はいろんな読み方ができますからそこはさらに複雑になります．同じ音でもいろんな種類の漢字がありますし．

でも，さらにまずいのが，英語教育やプログラミングとの親和性を考えるようになると，かなキーボードではなく英字キーボードを直接覚えるということが主流になって，「ローマ字かな変換」というこれまた変な方法が使われるようになりました．

予測変換とか，全文変換とか，いろんな技術でこれらを支えて，現在では相当ストレスがなく使えています．でも，2段階の変換「ローマ字→かな→漢字」というのが入っているのはどうしようもありません．そもそも日本語というリッチな文字体系に対して，キーボードという非常にプアな入力装置で対応するというのは根本的に難しい問題なんですね．

僕が期待を寄せているのは，タブレットのペン入力です．これも研究の歴史はとても長く，少しずつではありますが進化しています．最近で素晴らしいのはiPadでのmazecという手書き入力ですね．キーボード入力はどうしても1次元的な操作になってしまいますが，mazecでは2次元を非常に上手く使っています．候補と確定が2次元的にそれぞれに書いた文字の上に出てくる．

僕はタブレットやスマホでの日本語入力は手書きを愛用しているのですが，こうしてPCでローマ字入力している速度にはかないませんが，スマホのキーボード入力と比べると，心地よさは断然手書きです．

でもまだまだ改良の余地があって，たとえば，手書きで予測入力というのが出来ていません．今の予測入力は文字として確定してからの，単語の予測ですとか．あとなんと平仮名で書いたら漢字にしてくれるという，「ローマ字→かな」の部分のを手書きにすることですか．

ところが，手書きで予測入力ができるようになると，たとえば手偏を書いたら，手偏で始まる漢字がずらっと出てくるということになります．それらを選択してもいいし，無視して書いて行くと候補が狭まって行く．このやりかたの良さは，漢字をちゃんと覚えていなくても書けるようになるということですかね．予測だけじゃなくて，曖昧入力も入れて，手偏で書いて行ったけど実は木偏だったみたいなのが候補で出てくるというのもありですね．当然，前の文や過去の頻度なども学習しますし，これが学校でつかわれる入力法なら，その学年で覚える漢字に限定した辞書を使うようにすればよいですね．

指かペンかという議論ですが，これは断然ペンです．指で文字を書くということは，腕の筋肉を使うということですが，ペンで文字を書くのは指先の繊細な筋肉を使えることになるので，小さいストロークを正確に書けるようになると思います．それと画面を指で邪魔しないという利点もありますし．なんせタブレット上のボタンの大きさを小さく出来ますから，画面設計上の制約もすくないです．

iOSは最近やっとIMEを開放したとかそういう不幸なことが続いていたわけですが，制約もなくなりましたから，ちゃんとした入力法を子供用に（大人用にも）作ってあげて，小1の作文教育からストレスのない環境を提供して上げたいですよねぇ．

十進法の計算

ビスケットで二進法の計算をさせるのプログラムはこれまでにもご紹介してきました．

２進数のカウンター（その１）

で，十進法の計算を作ってみました．つくるのに2時間くらいかかりましたよ．



まず，数字の部品を10個つくります．0から9までですね．数字を重ねるとそれを足したということにします．3＋2＝5という計算は3と2を重ねておくと，5に変わるというものです．数字の場所がズレないように置くのがミソです．結果が二桁になる計算の場合は1の位10の位を考えて置かなければなりません．たとえば，7＋8＝15の場合はメガネの左側に7と8を重ねて置いて，右側には7と8があった場所に5を，その左となりに1を置きます．

1を生成するパクパクと，3を生成するパクパクがあります．本当は残りの数を生成するパクパクも作った方がよいですが，ここでは2つだけ作りました．

で，それらを横に並べておいてるので，13ずつ足すプログラムになっています．ここで表示されているのは13の倍数です．


二進法の計算は，0+0, 0+1, 1+1 の3つのメガネがあればよいですが（0+0はめったに使わないので省略できます），十進法の計算では，50個以上のメガネが必要です．足し算の九九の表ですね．

これがどういう説明になるかってことですけれど．

うまく動かない１つに，メガネの中の数字の置き方が上手くない場合があります．桁というのをきちんと考えなければならないということです．計算ということを改めて考えさせられます．桁の発明というのは偉大です．桁を発明できたので，どんな大きな数の計算でも，たった50個程度のメガネでできるのです．

簡単とはいえ二進法と比べたら十進法は複雑な計算ですね．

コンピュータは0と1で動いています．これは知識として広く知られています．ところがなぜ0と1で動いているのかはそれほど知られていません．なぜかというと0と1の計算は簡単だからです．コンピュータは電子回路で動いていますが，簡単な計算ということは回路が簡単ということです．ただそれだけのことです．

知識でしか知られていないと間違った解釈が広まります．たとえば0と1で動いていると言えば，正しいか間違っているかしか無い，なんとも柔軟じゃない印象がありますね．デジタルかアナログかという議論の元も，0と1の印象の悪さから来ているのではないでしょうか．もし，コンピュータも人間と同じように十進法で計算していたらデジタルがこれほど悪く言われなかったかもしれません．

デジタルとアナログの違いと言っても，人間でもデジタルとアナログを使い分けていますよね．身長や体重はアナログですけれど，お金や人数はデジタルです．0と1だからデジタルではありません．

こんなことは，知っている人には知っているけれど，知らない人には知らないという，いつものことなんですけれどもね．

小学校の義務教育にプログラミングを入れる作戦

賛否両論ありますが，僕は教えるべきという立場です．反対意見の人って，たとえばプログラミングを狭く考えているとか，ビスケットのことを知らないとか，そういうことなのであまり気にしていません．

プログラミングを学校に入れるよくある作戦として，Scratchのわくプロ本の作戦があります．コンピュータはいろんな教科の学習に使えるのだから，最初に使い方を覚えて，その後は各教科の中の時間でやればいいんじゃないか．というものです．そんなに難しくないから，やりかたを覚えた担任の先生がその先はやっていきます．学習指導要領の隙間をつく作戦でもありますね．僕も昔はその作戦を考えていたのですが，これですと，現状の学校の状況とその理想的な状態との間にギャップがありすぎて，たぶん無理です．やれても，ものすごいお金と労力をかけてやっと実現出来るって感じ．全国の小学生は７００万人いるわけですが，担任の先生は大雑把に２０万人はいるわけですよ．２０万人もそんなことができるようになるとは思えない．

まずやるからには，国民的なコンセンサスが必須です．「ああ，こういうことならやってもいいんじゃない」とみんなが思うようなものでなければだめです．で，ポイントは二つ，内容と時間です．どんなに内容がよくても１０時間もかかるのだったら，それなりに慎重になりますよね．逆に年間で２時間くらいでよければ，「ああそれなら．．．」になりそうですよね．総合の時間をやりくりすればどこだってできる．学習指導要領がどーたらとか考えなくてもいいです．

時間数を増やすのは，本当に国民的なコンセンサスが得られてからです．

なので，まずは最小時間で考えます．ざっくりと，小１小２は年間１時間くらい．小３～小６は年間２時間．小学校６年間で合計１０時間です．これでどんなことを教えられるでしょうか．

実はビスケットは，本当に覚えることが少ないので，２時間（実質９０分）もあると，本当にいろんなことができます．僕らが毎年夏にお手伝いしているNTTのドリームキッズでは，たった２５分で「プログラミングというのは単純な命令を組み合わせるから複雑なことができるんだよ」ということまで教えてますからね．

まず，ビスケットを教える専門家を養成します．この人たちは，１０時間の授業ができればよいだけです．同じ授業を何十回もいろんな子供達を相手にやるので，教え方はどんどん上手になって行きます．一人の人は１日３クラス，２００日で６００クラスの授業ができます．全国に２０万くらいクラスがあるとすると４００人くらいの先生で，全児童に毎年２時間ずつ授業ができるわけです．先生を一人５００万円くらいで雇うとすれば２０億円くらいです．各自治体にICT支援員とかいますから，その人たちが研修を受けて授業ができるようになってもいいですね．そしたらすでに払っている予算の範囲内です．

で，何を教えるかというと，コンピュータサイエンスです．コンピュータはエンジニアリングの視点で捉えられることがすごく多いですが，そっちではありません．エンジニアリングは他の教科，たとえば図工とか音楽とか理科とか，すでに実施している教科と重なることがすごく多いんですね．エンジニアリングは普通の先生がすでに教えていることでもあるということです．

別の言い方をすると，他の教科では絶対に教わらないことで，普通の担任の先生も知らないこと，です．まったく重ならない内容を専門家が１０時間教える．これだったらありじゃないですか？

具体的にはこんな内容です．

コンピュータが得意なことと人間が得意なこと．

情報の基本的な性質．複製で劣化しない．指数関数．

シミュレーション

０と１で計算すること．十進法で計算すること．

アルゴリズムというのは，いったいなんなのか．

プログラミング言語の面白さと奥深さ．

一切ほかの教科とはかぶりませんね．コンピュータそのものをどう教えるかということだけです．
これらを２時間の枠のなかに，埋め込むのは，基本的にはビスケットの体験をやらせてから，その体験に関係する講義を５分くらいやる，という流れです．



こういうことを３年くらいやります．そのうち自分でも教えらえる担任の先生が現れてくると思います．それから，ここからが本当の応用なんですが，タブレットも一人１台持っていることだし，図工の時間を少し使って，もっとクリエイティブなプログラミングをやってみようという先生が現れてくると思います．そうなると，いろんな教科で使えるようになって行きます．そこが「プログラミングで学ぶ」です．さらに１０年くらいたてば，完全に学校のなかだけで教えられるようになって，専門家の集団を派遣するということもやらなくてよくなります．

ビスケットのポインタについて

ビスケットでソートとかカウンターとか基本的な仕組みが作れることはわかったのですが，それらを組み合わせて大きなシステムが作れるのかというと，どうもそんな気がしませんね．何かが決定的に足りないのです．その１つがポインタです．今のビスケットにはポインタはありません．将来，導入が予定されています．

ポインタというのは何かというと，コンピュータの原始的な段階で，単なる自動的に計算する機械から，１つ上のレベルで考えることが出来るようになったという極めて画期的な発明です．まずはその解説から．

40名のクラスがあって，その中のある二人を選んだら，その二人から別なもう一人を決める方法を考えます．同じ二人のペアでは毎回同じ人が決められます．変な問題ですみません．生徒には出生番号というのがあって，1番から40番まで決められています．二人の出席番号をX番とY番，そこから決められる人はZ番だとすると．
Z = f(X, Y)
というXとYで何か計算をしてZが決まる関数fを作ればよい，ということになります．fはいろんな形があると思いますが，これは数学のブログではないのでこれ以上は触れません．

さて，1から40までの数の計算をすることですが，元々は人間の話でした．田中さんと吉田君が選ばれたら，そこから決められる人は佐藤さん，という話でした．元々は人間の話だったのに，出席番号というのを使ったおかげで，数の計算にすることができた．ここが画期的なんです．

コンピュータにはメモリーというのがあって，その中に数字がずらっと入っているわけですが，メモリーの１つ１つにも番地という出席番号のようなものが付けられています．コンピュータは数字の計算ができますけれど，その計算結果をメモリーの番地とみなして，その番地に入っている別の数字を取り出して，次の計算に使います．別のたとえで言うと，脳外科のお医者さんが自分の脳の手術をやっている感じです．数字が名前になるというのがそういうことなんですね．これでOSが作れるようになったし，新しいプログラミング言語も作れるようになった．極めて重要な仕掛けです．

ビスケットの場合メモリーというのは画面そのもので，番地は画面の位置になります．なのでポインタに相当する機能は画面上の離れた場所を指し示す方法ということになります．

たとえば，トラックの荷台に箱を積んで走る．というプログラムを考えます．トラックの絵と，箱の絵があります．このとき，箱の中に何が入っているか．いろんなものを入れたいですが，それらの中身をトラックと一緒に絵の動きで動かすのは大変ですね．すべてのパターンを作るわけにも行かないし，他のトラックとぶつかって，荷物を落としてしまったりしそうです．箱の中はトラックの動きとは別の場所に置いておきたいです．

ビスケットに導入される予定のポインタは2つの絵が組になってます．始点と終点の絵です．始点は箱の形をしていて，終点は箱の中身を示す形をしています．終点の絵の上に箱に入れたい荷物を重ねて置きます．トラックには始点の絵を積んで走ってもらいます．それで，たとえばどこかのステーションに付いたら，トラックに積まれている荷物を降ろして，ステーションでカウントするとか．箱を4つ作って，この箱には何をいれて，こっちの箱には何をいれて．それでそれぞれの箱を4台のトラックに積んで，この荷物をいれた箱は上に向かって走る．こっちの箱は斜め右上に向かって走る．そんな風にも使えます．

メモリー（画面）が一枚の平坦なものだったのが，トラックが走る世界と，箱の中の世界の２つに分かれたということもお気づきでしょうか．トラックが走っているうちに，別のトラックの荷物の中に入ってしまうこともあるかもしれません．落語の頭山の世界です．そういうレイヤーの違う世界が混ざってしまうのを面白がるのもありますけれど，一方で画面を複数枚用意して，それぞれの動きは混ざらないようにして，ポインタは別の画面間に置くという方法もあると思います．これでかなり複雑なプログラムを作って行けますね．1枚の画面の方は昔のCPUの直接触っていたのと同じ，複数の画面でやる方は高級言語で作っているという違いもわかると思います．

ポインタがあると，スタックが作れるので，再帰的な動きをさせることもできるようになると思います．いろいろなアルゴリズムのアニメーションも作れるようになります．

柔らかい書き換え（Fuzzy Rewriting）について

知恵袋で柔らかい書き換え（Fuzzy Rewriting）について質問を受けました．ちょっと嬉しいので，ここに回答を書いておきます．

どんな発明もそうですが，ビスケットにもそれが発明される以前のものがあって，その欠点を補うということで作られてます．

Stagecastというもので，これは元々はアップルリサーチで作られた KidSim の商品版です．KidSimは古いマックの上で動いてまして，僕も学生の頃に触って感動しましたけれど．まさか自分が子供向けの言語を作るなんて思っていなかった時代です．

KidSimの論文はこれですが，英語を読まないでもここで使われている絵を見ればビスケットに似ていることがわかります．94年ですから20年以上前ですね．

たとえば，

です．ゴリラが岩の前にいたら岩を飛び越えて反対側に行く，という命令ですね．

KidSimは当時のコンピュータの限界もあったと思いますが，格子状に配置されたアイコンの位置関係を規則に従って書き換えて行く，という言語です．ビスケットと違ってアイコンには内部状態をもたせることができて，例えば自動車だったら燃料という状態があって，1つ前に進むごとに燃料を1つずつ減らして行くとか，燃料が空になったら止まるとか，そういったプログラムが書けるようになってます．Simというのはシミュレーションのことですが，値を使ったシミュレーションがちゃんと作れるようになっています．

ビスケットはそういった内部状態の部分は全部切り捨ててますね．機能を削るのは研究としては主張しにくいですが，言語の方向性を明確にするという意味では尖らせてます．

ビスケットが新たに導入したのは，アイコンは格子状ではなく自由な位置に置けて，しかも回転させることができる，ということです．それだけが違いです．だからビスケットで回転させないタイプの例題（たとえば二進法のプログラムとか前回のソートのプログラムとか）はそのままKidSim (Stagecast)で走らせることができると思います．感染が広がるやつもできると思う（内部状態はあまり入れたくなかったですが，いま考えると感染の強さとか治りかけとか，そういう表現のためには入れてみてもいいかもしれませんね）．

で，そうやって書き換え対象と規則（めがね）を柔軟にしたときに，課題なのはどうやって動かすのかです．格子状のアイコンの場合はアイコンの配置がピッタリ決まっているので，それと同じ配置を探すというのは全然難しくありません．それに対してビスケットでは厳密に同じ配置で探すのではなくて，似ている配置であればOKにしようという方針にしました．つまり書き換え規則を曖昧に柔軟に解釈しようということですね．

めがねの中に部品がそれぞれ１つだけのときは曖昧性はないのですが，部品が２つずつ入ったとき．たとえば感染が広がる例の「ぶつかったら」の部分です．正確にこの配置でぶつかるのだけでなく，大体こんな感じでぶつかったら，という解釈をしよう，ということです．そのときめがねに入っている配置に対して，どれくらずれているかという計算をします．ピッタリ同じ場合もあるし，少しだけズレた場合もあるし，ギリギリぶつかった場合もあるし．そのズレは，書き換えの結果，つまり「風邪がうつる」の部分に反映されます．風邪がうつるの場合も正確にこの配置で風邪の人が出現するのではなくて，ピッタリ同じの場合は同じ配置になるけれど，ズレていたらそのズレに応じて出現する位置も変わる，という計算をしています．こういう部分が，ビスケットを動かしていて飽きないアニメーションになっている理由だと思います．曖昧なマッチングをしても生成が厳密のままだったら生成されるアニメーションはどんどん単調になっていくはずです．

でこの方法をFuzzy Rewriting（柔らかい書き換え）と名付けました．

実はこの柔らかい書き換えは，アイコンの配置の書き換えにしか使えないわけではありません．一般化することができます．何かの対象をベクトルで表現して，それの時系列変化を発生させる．書き換え規則は，変数を使って定義する代わりに，書き換えの代表的な例を示して定義する，という解釈になります．説明がどんどん難しくなりますが，もっと広い応用があるんですよってことですね．

例えばピアノにしてみると
「ドレミ」→「ミレド」
ドレミと弾いたら，ミレドというのが返ってくるという鍵盤のメガネを作りました．それに対して
「ドレファ」
と弾いたら，何が返ってくるのかということです．で柔らかい書き換えで動くピアノの場合は
「ファレド」
というのが返ってきます．メガネを沢山いれてあげて，勝手に演奏するシステムができて行きますね．

具体的な計算方法ですが，バージョンが変わってまして，初期の計算は論文にもなっているのですが，最新のはコードだけです．初期の計算方法に関しては

https://github.com/viscuit/viscuit6

で密かに公開していたりします．これだけではビスケットは動きません．

未来のプログラミング言語（ビスケットによるソート）

ビスケットは変わっているプログラミング言語ですから，ビスケットでどういうプログラムが作れるのかというのはまだ完全にはわかっていません．発明されてから１２年で，中身も全然進化していないのに，最近になっても，これまで思いつかなかったプログラムが見つかったりします．

これはビスケットによるソートのプログラムです．

ソートというのは，数の小さい順に並べ替えるというもので，例えばWebの画面で表が出てきたとき，項目の横に三角が表示されていてそれを押すと，金額の安い順とか，駅に近い順に表を並べ替えてくれる，その中で動いている仕掛けです．

ここでは，１から４までの数字を小さい順に並べ替えています．右の方が数が大きくなります．ビスケットは数を知りませんからまずは１から４までの絵を書きます．数字じゃなくてもよくて，何か順番がついているものならどんな絵でも構いません．たとえば，ネズミ，ネコ，ライオン，ゾウという強いもの順（大きいもの順）というのでもよいです．ただしジャンケンのように強さが１周してしまうものはダメです．なので，ゾウはネズミに弱いという童話的なルールは無しです．

ここでのメガネは非常に面白いのですが，「間違っている場合を直す」という方針で作られています．一番上のメガネは，２の右に１があれば，１と２を入れ替える．となっています．残りもメガネも全て，間違った置き方をしていたら，絵を入れ替えてます．

たったこれだけですが，動きはこのようになります．

動画

説明らしい説明もないのですが，ビスケットは絵の並びの中から，間違った並びを見つけては，その順序を入れ替える，ということをひたすら続けてます．どこから入れ替わるかはビスケットがどのように動いているかで決まるのでわかりません．

さて，これはプログラムと呼んでよいのでしょうか．何か普通のプログラムと違いますよね．ソートというといろんなアルゴリズムがあって，そのアルゴリズムを表現したのがプログラムで，というのが普通に習うのかもしれませんが，アルゴリズムっぽいものはまったくありません．でも，ビスケットはちゃんと数を並べ替えてくれてます．

これって，プログラムの仕様を書いてあるだけですよね．数の大小の定義と言ってもいいです．仕様を書いたらそのまま動いてしまったということです．

実はここに，プログラミング言語の未来というか，僕がプログラミング言語の研究を始めた２０数年前に見ていた研究者の夢「未来のプログラミング言語」がチラッと見えています．

当時の夢というのは，こういうものです．

もう，アルゴリズムのようなプログラムを人間が記述するのは止めよう．人間は，コンピュータにどう動いて欲しいかを考えるのではなくて，コンピュータに何をやって欲しいかだけを考えよう．動き方はコンピュータが勝手に考えてくれる．未来のプログラミング言語は，何をやって欲しいかを伝えれば動いてくれるようなものになるだろう．

そういう未来のプログラミング言語を作るのが僕らの夢だったわけですが，世の中のプログラミング言語の進化というのは，あまりそっちの方には進まなくて，人間が巨大なプログラムをエラーが少なく書きやすくなる，という方向になってしまいましたね．それでも，少しずつですが進化してきていると思いますよ．たとえば，江木君の Egison がとても嬉しい発明です．

ちなみに，専門的な話をすると，ビスケットの動作は，配列の隣り合った数を比較して入れ替える，というのをランダムに全部の要素で実行しているだけですから，見方によってはとても仕様を書いて実行しているとは言えません．これらのメガネから自動的にクイックソートを誕生させれば嬉しいですが，そこまですごい話ではないです．つまり，仕様を記述してバカな効率でよければ動かすのはなんとかなる．すごい効率にはならない．そんなレベルです．

進化は遅いとは言え，さすがに今の子供達が大人になる頃には，この夢は叶っているんじゃないのかとは思うのです．

今のプログラミング教育のブームとか，中学の技術でやっているプログラミングとか，「どう動かす」を訓練することにフォーカスが当たっていますが，それは実に古い「プログラミング言語観」に囚われていると言えます．

「どう動かす」というスキルは，すごいプロフェッショナルであれば生き残ると思いますが，ほとんどはコンピュータに置き換わってしまうのではないでしょうか．並みのプログラマーは不要になってしまう．だって，未来には仕様を入れれば動いてしまうプログラム言語ができるんですよ．

しかし「何をやって欲しい」の部分はコンピュータには置き換えられない．そういう人を育てるべきではないでしょうか．

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

先日のプログラミング教育系の研究会で面白い問題提起がありました．プログラミングを教えててこういう生徒がよくいるよねー．という話です．僕はその日に小学生の活動を見学したのですが，ある子は，ドリトルで知っている構文（線を引く）ということだけを使って複雑な絵を描かせました．全部で２００行近くあって，いわゆる制御文というのは一切使っていません．制御文と変数をうまく使うとそれらのプログラムは１０行くらい（つまり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でもまったく同じです．動かしたい実体とは切り離して，式の世界で動きを構築するということが必要になるのです．それに対してビスケットでは，そういった抽象的な世界の記述はなく，具体的な動きの例を沢山与えて，それらを参考にして実際の動きをつくりだす，という動きをします．動きの実例を増やすと式の精度が上がるということになります．


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

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

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