きのう、五反田のゲンロンカフェで定期的に開催している特別講座「ノンプログラマー・プログラミング入門」の中で、コンピュータとコンピュータでないものの解説をしました。

　たとえば録音機を出して、「これはコンピュータですか?」と問いかけると、会場の方々はほとんど手を挙げませんでした。

　それから、プロジェクターを指差し、「これはコンピュータですか?」と問うても同じでした。

　最後に携帯電話を取り出し、「これはコンピュータですか?」と聞くと、ほとんどの人が手を挙げました。

　興味深いのは、録音機にせよ、プロジェクターにせよ、そして携帯電話にせよ、ハードウェア的にはどこかしらにCPU、つまりコンピュータが積まれているということです。

　現代の情報機器にはCPUが欠かせません。
　たかがプロジェクターのメニューを表示したり、SDカードに録音したデータをファイルとして出力したりといったことにもCPUが使われます。そのほうがずっと便利で、気の利いたものができるからです。

　にもかかわらず、なぜ人々はプロジェクターや録音機をコンピュータと看做さず、携帯電話だけをコンピュータであると認識したのでしょうか。

　ひとつの手がかりは、「アプリケーションが動作すること」「自分でアプリケーションがインストールできること」が、現代の携帯電話をコンピュータのようなものだと認識しているのかもしれません。

　しかしそうだとすれば、iPod classicとiPod touchを比較してみたらどうでしょうか。
　どちらも音楽やビデオというソフトをインストールすることができます。

　しかしiPod touchはMacを使えばアプリケーションを自分で作ることが出来ます。
　iPod classicでは自分でプログラミングしたアプリケーションを動かすことはできませんが、自分で作曲して唄った曲をインストールすることができます。

　このふたつのことは、とても似ていますが、決定的な違いです。

　つまり本質的な「コンピュータらしさ」とは、「プラットフォームの提供側以外の第三者がプログラミングが可能かどうか」に大きく影響を受けているのかもしれません。

　プログラミングをしない人であっても、その微妙な空気の差を感じ取ることができるということのひとつの例なのかもしれません。

　ではもうひとつの疑問が産まれます。

　なぜ自分で作曲して唄った曲は、プログラムとは感じられないのか。

　私が掲げる定義に基づけば、楽曲は立派なプログラムの一種です。
　しかしコンピュータプログラムと行った場合に人々が期待するものとは明らかに違います。

　そのひとつは実行時の対話性です。
　コンピュータプログラムは、使い手に自由度を提供します。

　一般消費者むけに書かれたコンピュータプログラムが動く時、ずっと決められた手順で動き続けることは滅多にありません。
　　

　むしろユーザからの入力を待ち、その反応を返す双方向性、インタラクティビティ(Interactivity)にこそコンピュータプログラムの醍醐味があります。

　そもそもインタラクティブという言葉は、inter(互いに)とactivity(活動)の合成語です。相互に活動しあうということがコンピュータに期待されることなのでしょう。

　また一方で、コンピュータプログラムとプログラムでないものの境界線というものもあります。
　たとえば、Webページそのものはプログラムではありません。

　Webページを作る作業をプログラミングとは呼ばないのです。
　それはオーサリング(著述)と呼ばれます。

　Webページを作るということは、ハイパーテキストを作るということを意味します。
　きのうの講義では、受講生の方々に貸し出したenchantMOONで、それぞれがさまざまなハイパーテキストコンテンツを作成して発表するという趣向になっていました。この時点ではenchantMOONのプログラミング機能は使わない、というルールです。

　どれも力作揃いで、それぞれの説明を聞いているだけで聞き入ってしまいました。
　
　しかしこれらは全て、コンピュータプログラムらしいものではありません。
　なぜプログラムと呼べないか、何度も遊ぶとわかると思いますが、ひとつには偶然性がないからです。
　

　しりとりの結果はいつも同じ、モグラ叩きもクイズもそうです。
　もちろんこれをもっと大量に作れば、コンピュータプログラムのような振る舞いをさせることも可能です。

　しかし、それにはあまりにも手間が掛かりすぎます。
　コンピュータプログラムとは、もっとずっとエレガントなものなのです。

　ハイパーテキストのオーサリングだけでは、コンピュータの能力を充分引き出すことはできません。
　つまり、プログラミングを全くせずに結果を得ようとすることの限界値が、まさにこれなのです。

　最小の手間で無数とも思えるバリエーションの結果を産み出す。これが本質的にプログラミングが持っている大きな力であると言えます。

　ExcelでVBAマクロを組んだ経験がある方ならば、オーサリングとは表をつくることで、プログラミングとは表を自動的に操作させることだ、と言えば解っていただけるでしょうか。

　或いは、オーサリングとは紙で行える作業をただ電子的に置換えたものであり、プログラミングとは紙にはできないことをやらせることだ、という言い方でもいいかもしれません。

　オーサリングで作られるものはコンテンツそのものであり、プログラミングで作られるものはコンテンツを産み出す手順です。だからプログラミングされたもののほうが、より豊かな双方向性を獲得することができるわけです。

　経営をプログラミングに例えるとすれば、経営におけるプログラミングとは、組織やマニュアルを作ること。経営におけるオーサリングとは、自ら陣頭指揮をとって営業なり開発なりに専念すること、と言い換えることもできるでしょうか。

　オーサリングがどのようなものか理解していないと良いプログラミングができません。
　これは現場を理解していないと経営が勤まらないということととても似ていると思います。

　最近、現場に降りてソースコードを見たり弄ったりする機会があったのですが、大局的なものの見方も大事ですが、細部まで理解していないと方針を誤ることがあります。

　ときどき現場の目線でものを考えるのも必要なことなのだ、とあらためて感じました。