図形やブロックを組み合わせてプログラミングすることを一般にビジュアルプログラミングと呼びます。

　近年、コンピュータの処理能力が十分発達してきたので、ビジュアルプログラミングというものが再び見直されつつあります。

　たとえば音楽の分野ではシンセサイザーの配線をビジュアル的に配置して独自の音を創り出します。MacOSXにもQuartz Composerというビジュアルプログラミング環境があり、スクリーンセーバーなどを作ることが出来ます。

　ビジュアルプログラミングという研究分野の歴史は意外と古くからあります。

　RANDコーポレーションのGRaIL(グレイル;Graphical Input Language)はそのひとつです。

　アラン・ケイによる説明動画がこちらにあります。

　RANDコーポレーションはアメリカ陸軍航空軍の研究所としてスタートしましたが、現在は独立したNPOになっています。しかし実態は半数の研究がアメリカの国家安全保障に関わる研究を行うなど、軍事色の強い研究所です。

　GRaILは、そんな研究所で産まれたビジュアルプログラミング言語です。

　1960年代に開発されたシステムで、ペンによって操作し、画面上で図形を構成していくことでプログラミングができるようになっていました。

　おおまかな設計からマシン語など細部に渡る実装まで全てこのシステムで実現できるようになっていました。
　動画を見ると、なんと文字認識までもが当時実現されていたことに驚くと思います。

　GRaILがなぜ主流にならなかったのかというと、もとが軍事用の研究であったためと、膨大な費用がかかったからと言われています。

　その後、ビジュアルプログラミング言語に関する研究は一旦ペンディングとなり、キーボードを使って簡易なプログラミング言語を作るという方向に動き始めます。当時の汎用コンピュータにはグラフィックス処理はまだ荷が重かったのです。

　シーモア・パパートはLOGOという言語を作りました。
　LOGOはキーボードを使うものの、それ以前に発明された言語に比べると格段にわかりやすく、またすぐにグラフィックスが出せるので教育用に適していると考えられたものです。

　しかし残念ながらLOGOは本当の意味での教育用言語としての地位を確立することはできませんでした。

　かわりに流行したのはBASICです。

　BASICも歴史は古いのですが、それを完成させ、一般の人々が使うレベルまで広めたのはビル・ゲイツと古川享の功績です。

　なぜLOGOはダメで、BASICは普及したのでしょう?

　LOGOを動作させるには高度なコンピュータが必要だった、とか、いろいろ考えることはできます。
　特にLOGOは、再帰呼出しを行うため、当時のメモリが少ないマイコンで動かすのは難しかったでしょう。

　しかしやがてマイコンがパソコンと呼ばれるようになり、メモリやCPU速度にも一切考慮しなくてよくなってもLOGOは決して初心者に使われることはなかったのです。

　それはなぜか。

　これはあくまで私の個人的な見解ですが、LOGOは教育を専ら目的としていたのに対し、BASICはまがりなりにも実用を目的としていた点が決定的に違うのではないかと思うのです。

　LOGOは再帰呼出しやプロシージャなど、BASICに比べて明らかにプログラミング言語として進化していました。
　やろうと思えばなんでもできる、というのもその通りです。

　しかし、BASICは、いい意味でも悪い意味でもシンプルで、そして自由でした。
　プログラミングをするために覚えるルールは最小限になっており、新しいルールを覚えるとそのワザがすぐに使えるようになっていました。

　だから結果として子ども達はBASICに夢中になったのではないかと思います。

　自分の頭で考えていることをBASICにするのはLOGOで同じことをするよりも遥かに簡単です。
　LOGOはあくまでも言語開発者がイメージする「正しいプログラミング」の作法に乗っ取らなければなりませんが、BASICはいくらでも汚い書き方が出来ます。

　さらに、とにかくBASIC、特にMicrosoftのBASICは解りやすかったのです。

　「PRINT "こんにちは"」と書けば画面に「こんにちは」と表示される。
　それに比べると、LOGOはどうすれば同じことができるのかパッと思い出せません。

　ただし、絵を描く、特に数学的な絵を描くことはBASICはLOGOほど得意ではありません。
　かなりまどろっこしい書き方になってしまいます。

　しかしそれはBASIC全体の簡単さに比べたら、些細なことだったのです。
　工場勤めだった私の父はBASICでボイラーの燃焼効率をグラフ化したり、集めたデータを分析したりといったプログラムを書いていました。ほんのわずかな訓練で、高卒のエンジニアにも使いこなせたのがBASICのメリットです。

　さて、当時の少年少女が使っていたBASICにしろ、コンピュータのプロ中のプロが使っていたFORTRANやCOBOLにしろ、プログラミングを始める時には、特に大規模なプログラミングを始める時には、フローチャートを書くのが大切、と言われていました。

　フローチャートとは、下図のようなものです。

　こんな感じのものをひたすら書くのです。

　なぜこれを書くのかというと、フローチャートを書くことによってプログラムの構造を見やすくすることができると信じられていたからです。

　これによってバグを未然に防ぎ、プログラムを引き継いだ人も安心、というわけです。

　ところがいつのまにかこの「フローチャートを書きましょう」という文化は死滅してしまいました。
　いま、どこのどんなプログラミング入門書を見ても、「フローチャートを書け」と初心者に進めているものはないはずです。

　
　それはフローチャートにするには複雑過ぎるか、逆に単純すぎるプログラムばかりになってしまったからです。
　BASICくらいの時代は、プログラムがどんどん複雑化してしまい、ソースコードの見通しが悪く、「スパゲッティプログラム」などと自虐的なジョークが囁かれていました。

　だからかなり簡単な処理でも、フローチャートを書く必要があったのです。
　しかし、その後、構造化プログラミング、オブジェクト指向プログラミングとプログラミングに関するさまざまな叡智が蓄積され、大規模開発においてはフレームワークとミドルウェアを用いた差分プログラミングが一般化するに従ってプログラムの個別の構造そのものはどんどん単純化していきました。

　そうすることでプログラミングにおいてフローチャートは必ずしも必要ではなくなっていったのです。

　言い換えれば、かつてのプログラマーはまずフローチャートをプログラミングし、それをプログラミング言語に変換する作業をやっていました。

　しかし一方で、現在でもフローチャートを書く仕事はまだ残っています。

　それは仕様書の作成という仕事です。

　画面遷移図とも言います。
　これは今や専門のプログラマーの仕事ではなく、文科系の企画マンたちや営業マンたちの仕事になっています。

　かつてはプログラマーの仕事だったフローチャートの作成というものが、いつのまにか専門職以外の人たちの仕事になっていたのです。

　つまりプログラマーはより専門性の高い仕事に集中できるようになっているわけです。

　さらに、プログラマーは現在の高度なフレームワークや複雑な処理を記述するために、UMLというビジュアル言語を使います。

　UML(ユーエムエル;Unified Modeling Language)は、国際標準化委員会(ISO)で規定されているプログラム設計のためのビジュアル言語です。

　プログラムの構造や複雑な動きを記述するための国際的な標準規格になっているのです。

　UMLをデザインするための専用のツールもいくつもありますし、UMLによって設計されたプログラムの骨組みを吐き出すツールもあります。

　ここまで出来るにもかかわらず、UMLによって完全なプログラムを記述することはできません。
　ちょうどフローチャートが完全なプログラムを記述していないのと同じです。
　

　ここにひとつミッシングリンクがあります。

　つまり、実際のWebサービスやアプリは、フローチャートや画面遷移図が含まれた仕様書という形でビジュアル的に設計(プログラミング)され、それを渡されたプログラマーはUMLという形で設計図を起こしているにも関わらず、そのままではプログラムとして動作させることができないということです。

　これはなんとも勿体ないことです。

　私がビジュアルプログラミング言語の、特に実用的な可能性について研究しようと思ったのはこのギャップがあるからです。

　このギャップを埋めることが出来れば、それがすなわち、一億総プログラマー時代の到来です。

　たとえば、Microsoftが開発したVisualBasicというものがあります。

　名前には「ビジュアル」とついているのですが、実際のプログラミングは全てキーボードで行います。

　ではなにがビジュアルなのかというと、ウィンドウに配置されるボタンなどの部品(ウィジェットと呼ばれます)をビジュアル的に配置できるようになっているのです。

　これは厳密にはビジュアルプログラミング言語ではありませんが、ビジュアルプログラミングに求められるある種の本質を示していると言えます。

　つまり既にプロの世界では、UIの設計そのものはビジュアル的に行われるのが当たり前になっているのです。

　これはiOSやAndroidのアプリなどでも同様です。

　上の画面はインターフェースビルダーのものですが、画面上に配置されたウィジェットと、プログラムの対応関係をビジュアル的に定義することができます。

　ここまでできるのならば、キーボードで入力されるロジックの側もビジュアルにすることはできないのでしょうか。

　そして現在、広く一般に受け入れられているビジュアル言語にはScratchというものがあります。

　しかし、Scratchはもともとプログラミング学習用という特徴があり、これをプロのプログラマーが仕事として習得すると言う話にはなかなかなりません。

　私たちが開発を進めているMOONBlockは、Scratchとは全く異なるアプローチで、むしろUMLやフローチャートに近い考え方でプロが行うプログラミングをもっと簡単にできないかを検討しています。

　ビジュアル言語の利点は、複雑になりがちな処理を見通しやすくすることの他に、根本的に簡単である、というものがあると思います。

　しかし、限界もあります。
　
　むしろ簡単な処理を書こうとするときのほうがビジュアル言語では冗長になりがちなのです。

　たとえば変数xに0〜10までのランダムな数字を入れたい場合、MOONBlockでは次のようになります。

　しかし、テキストでプログラミングすれば「x= Math.random()*11」で済みます。

　ところが普通の人は「なぜ0から10までの値がほしいのに11を乗じているのか」がわかりません。
　ここがプログラミングのとっつきにくいところです。

　もちろんこれは、別の関数を定義して「x=rand(0,10)」のようにすることもできます。

　しかしこういう改善をひとつひとつ行って行っても、まず普通は「関数とはなにか」「英語のfunctionと日本語の関数の関係性(あまり関係がないという関係性)」の説明が必要になってきます。

　これが特に非英語話者には難しいと感じられるのです。

　しかし一方、英語圏であっても、「私の知ってるfunctionと違う」とか、「(繰り返しを意味する)forってどういう意味?」という、むしろ母語が英語だからこそぶちあたる言葉の壁というものがあります。

　繰り返しならrepeatがいいだろうとか、いや、whileのほうが解りやすいだろう、とか、いろいろな流儀はありますが、これはテキスト言語の持っている根源的な宿命です。

　むしろ我々日本人は英語を客観視できることで、下手をすれば英語自身に詳しくないがために、むしろ容易にプログラミング用語としてのwhileやforに馴染めるという有利な点さえあると思うのです。

　テキストによるプログラミングは、習得や理解に多数の困難が伴うにも関わらず、その軽量性を武器に発達して来ました。

　しかし私たちが会話に用いる自然言語は、本来、非論理的なものですし、非プログラミング的なものです。

　プログラミング言語として言葉を用いるとき、結局のところ、熟練者には見えない「型(テンプレート)」がそこに見えています。

　forがあれば、続くのは条件式で、その先には処理ブロックがある、というプログラミングの世界の「お約束」が身体に染み込んでいれば、なんの不都合もなく読み解くことが出来るのです。

　しかしそれを全ての人に習得させるのはとても困難です。

　特別に訓練された一部のエリートだけがプログラミングできればいい、という考え方もあるかもしれませんが、それは一部のエリートだけが数学を知っていればいい、という考え方、愚民を見下した考え方だと私は思います。昔は文字を読めるのはごく一部の貴族だけでした。書ける人はさらに限られました。人類の進歩は、叡智を共有することにょって初めて成し遂げられて来たのです。

　プログラミングは有用なものです。それが有用であることは誰もが認めているわけですから、我々プログラマーは、その地位に驕ることなく、それを誰もが使えるレベルまで落とし込んでいくべきです。

　そのなかで、私はビジュアル言語を考える際に、とても重要だと思っているのは、プロでさえもビジュアル言語を選択する時代を目指すということです。

　初心者のための「プログラミング玩具」ではなく、プロが使う本物の道具としてのビジュアルプログラミング言語があれば、潜在的なプログラマーの数は爆発的に増大します。

　かつてはバリバリの理系プログラマーしか書けなかったフローチャートを、今では誰でも書けるようになっています。もちろん訓練は必要ですし、今のところ、彼らが書いたフローチャートをチェックし、プログラミング的に正しい文法に直すのはプログラマーの仕事です。

　しかしそんなことは、インタラクティブ環境があれば機械が半自動的に正しいフローチャートを書くよう導けるようになるはずです。

　そしてビジュアル言語は、内部的にいかなる言語にも変換可能だからです。
　たとえば英語と日本語で語順が違うようなところでも、ビジュアル言語ならば統一的に表現することができます。
　ビジュアルとは身体感覚に基づくものだからです。

　インドにアウトソーシングするためにUMLを英語で書くというのも馬鹿馬鹿しいものです。
　もし真に実用的なビジュアル言語があれば、日本人が日本語で書かれたブロックを適切に並べさえすれば、インド人はタミル語やヒンドゥー語で書かれたブロックとして見ることが出来ます。ビジュアル言語は、世界中の言語のコミュニケーションさえ超えることが出来るのです。

　ビジュアル言語で複雑なプログラムを書くことが出来ないというのは幻想です。
　それは扱うべき問題が定義がまだ適切に定義されていないというだけです。

　充分な粒度のソフトウェアコンポーネントにまで分解できれば、ビジュアル言語の方にむしろ未来があると私は強く感じます。

　そして益々プログラマーは、その母数を増やし、そのアイデアと実装力でもって人類を力強く前進させていくでしょう。全ての人々がプログラミングという武器を手に入れるということは、全ての人が文字を読み書きできるようになるのと同じくらいに大きなインパクトを引き起こすと思います。

　そのためにも、ビジュアル言語をもっと研究しなければならないと強く思います。
　道はそこにしかないからです。

　それが私の想い描く人類の未来の姿です。