先日、コンセプターの坂井直樹先生のご紹介をいただき、物学研究会という集まりに呼ばれ、デザインとプログラミングについて講演させていただくことになりました。

　会場は西麻布の交差点からほど近い、パロマプラザです。

　非常に気軽に引き受けたものの、いざ会場に行ってみるとデザイン界・産業界の重鎮ばかりで緊張しました。あまり心の準備をせずにこういうところに行くと冷や汗ものです。

　冒頭、坂井先生からご紹介を受けた後、さて、何を話そうか全く準備のできてなかった自分に慌てるのです。

　というのも、この日はちょうど体調が悪く、打ち合わせも全て以前この連載で紹介したテレイグジスタンス・ロボットのDoubleで済ませるほどの熱で寝込んでいたからです。

　とはいえ、講演の仕事を多少の熱があるくらいで休んではならないと、夕方まで頑張って体調を回復させるのに精一杯で、いざ会場にたどり着くと、はて、何を話したものか、少し途方に暮れてしまったのです。

　また、最近の筆者は、講演のときにいわゆるスライド、Keynote(Windowとユーザは無批判にそれをパワポと呼びますが)の資料を作らないようにしています。

　というのも、スライド主体のプレゼンテーションは目を引きやすく、事前の準備もラクなら実際のプレゼンもラクなので多用されがちですが、それではそもそも講演を生で聞きに来たライブ感がなくなってしまい、印象に残りにくくなってしまうからです。

　極端な話、スライドを使ったプレゼンテーションでは、客席に一瞥もくれることなく、淡々とスライドを進めていけばどうにかこうにか時間を終えることが出来ます。

　でもこれでは、わざわざ生身で説明しなくても、ビデオを作って配布するのと変わりません。

　あくまでも聴衆の感心や目線にあわせてストーリーを展開するべきで、あまり周到に用意されたスライドがあると、どうしても度々話の論点をスライドに戻さなければならなくなります。それではつまらないじゃないですか。

　もちろんスライドなしのプレゼンテーションを行うには、スライドを用意するよりも遥かに多くの事前準備が必要です。

　まずは聴衆の反応を見ながら、その日のメニューを語ります。と言っても、それがメニューであるとあからさまにわかってしまってはつまらないのです。

　たとえばこんな感じです。

　「本日は皆さんどんなお話を聞きたいと思っていらしていただいたんでしょうか。プログラミングをやってみたい?プログラミングを理解したい?プログラマーと会話できるようになりたい?それとも内容なんかどうでもよくて、とりあえず惰性で参加しに来てると考えてよろしいでしょうか」

　ここでは4つの選択肢を提示しています。(1)プログラミングの方法を知りたい (2)プログラミングとは何か理解したい (3)プログラマーとコミュニケーションがとりたい (4)それ以外。

　話しながら聴衆の反応を伺うのです。
　聞いている人が大きくうなずいたり、身を乗り出してきたりしたら、それが彼らの選択です。壇上から話していると面白いようにわかります。

　それをマクロな段階からミクロな段階まで繰り返し、プレゼンターが一方的に講義を組み立てるのではなく、聴衆と一緒に講義を組み立てていくのです。

　この日は年配の方が多かったので、解りやすい話からすることにしました。

　「みなさんは、企業の英語公用語化についてどう思いますか?」

　必要か、不要か、はこの際どちらでもいいのです。
　プログラミングの話なのに、なぜ英語公用語化の話を持ちだしたのか。

　実は英語を含む外国語を学ぶこととプログラミングを学ぶことには共通点があるからです。

　企業によっては、入社時にTOEICが何点以上でなければならないという要求をする場合があります。それはそれでひとつの基準と言えるでしょう。例えば客室乗務員には600点以上のスコアが入社時に求められるそうです。

　ところが私は、英語力が十分以上あるはずの人が、いざ海外に出ると萎縮してしまって何も話せなくなってしまうのを何度も見ています。

　なぜでしょうか。

　当然ながら、言語はコミュニケーションのための道具(ツール)でしかありません。
　コミュニケーションの本質は、道具ではなく、それを発する内なる心、相手の心と響き合おうとする意志にあるのです。

　仮に言葉(たとえば英語)というツールだけの技能を磨いたとしても、言いたいことがなければ返答に詰まってしまいます。

　ありがちなのが、英語だけは一所懸命に勉強したけれども、アメリカ合衆国や英国の歴史など、欧米人なら誰でも知っているような基礎的な知識や教養がないケースです。

　結局、伝達手段は伝達手段に過ぎず、大事なのは「何を伝達するか」「何を聞き取るか」ということです。目的のないコミュニケーションは、とても浅い付き合いかとても深い付き合いのどちからでなければ発生しません。

　逆に言えば、「何を伝えるか」ということがはっきりしていれば、伝達手段はなんでもいいのです。むしろお互いにとって最適な伝達手段を選択する方が効率的でしょう。

　また別の話になってしまいますが、先日、某国の大使夫妻との食事会に呼ばれた際、同席した日本のNPO団体の幹部氏があまりにもデタラメなことを言うので腹がたったことがありました。

　彼は国内大手メーカーを定年まで務め上げたあと、その国との親善交流を担うNPO法人に招聘されたそうなのですが、彼がほろ酔い加減で語る日本像があまりにもデタラメすぎて、逆にさきほどまで彼に聞かされていたその国の美徳や歴史的文化的背景までもがデタラメなのではないかと疑ってしまう程です。

　この嘘というのも、「日本人の先祖もユダヤ人だからヨーロッパ諸国とは他人じゃない」とか、「キリストの墓が青森県にある」とか「月の内側は空洞になってて、そこから水が地球に落ちてきたのがノアの大洪水」とかいう荒唐無稽なもので、「お前はネオパラダイムASKAか!」とツッコミを入れるしかないんですが、当の大使夫妻がカッバーラ使いであるわけもなく、仕方なく筆者が知らないおっさんのブレーキ役に回るという有様でした。

　このように特に伝えたいことがないとツールは暴走してしまいます。
　しかも聞いてる方も何が面白いんだかわからないような状態になってしまって、本当にマヌケです。

　同じことは、実はプログラミングを学ぶときにも言えます。

　プログラミングを学ぶ、と一口にいっても、それは「スポーツを学ぶ」くらいの定義の幅があります。そう、プログラミングと一口にいっても、どれかひとつに絞ることはできないのです。

　大昔は、BASICというその名も基礎っぽい名前の言語があったため、入門者はこれを学べば良いとされてきましたが、21世紀にBASICはいくらなんでも時代錯誤です。

　今は普通に使われている言語だけでも数百はあり、そのうちどこから手を付けて良いのかわからない、というのが入門者の第一の悩みです。

　そこでたいがいのプログラマーは入門者から「プログラミングをやってみたいんだけどどれからやればいい?」と聞かれた時にこう聞き返します。

　「プログラミングで何をしたいの?」

　「えーと、いや、なんでもいいんだけど」

　「たとえばアプリを作りたいとか、ゲームを作りたいとか、Webサービスを作りたいとか・・・もっとぶっ飛んで、OS作りたいとか」

　「それ一度に全部できる言語ないの?」

　「アセンブリ言語かな」

　入門者はとにかくラクをしたがります。
　近道を教えてくれ、と聞きに来るわけです。

　でも、実はプログラミングのゴールはひとつではありません。
　ゴールがひとつではないから、近道も目的によって変わるのです。

　プログラマー自身が用意した目的別の近道が、それぞれのプログラミング言語だったり、フレームワークだったりするのです。

　Webサービスを作るためにはPHPやRuby、Windowsアプリケーションを作るにはC#と.NET Framework、iOSアプリケーションを作るにはSwift、HTML5アプリケーションを作るにはjQuery、enchant.jsなどなど。

　それらはみんな、それぞれ別の目的地のための近道として作られているのです。いわばディズニーランドのファストパスのようなものです。確かに速いけど、ひとつのファストパスではひとつのアトラクション(目的地)にしかいけないのです。

　プログラミングは、人間から機械と意志を伝達するための手段です。
　逆に言うと機械は自ら主張する心を持ちませんから、これは一方通行です。つまり人間らか機械への一方的な命令があるだけです。だからここでも心がおろそかにされがちですが、それは違います。

　本来、重要なのはプログラミングという伝達手段そのものを学ぶことではなく、プログラミングという伝達手段を使って何をやりたいのか、という人間の意志、心です。

　たとえばよく「目覚まし時計の設定はプログラミングである」という話をしますが、目覚まし時計を設定する時、人間には明確に「明日の朝この時間に起きたい、目を覚ましたい」という意志があります。

　そういう意志があるとき、多少の不便を乗り越えてでも人は目覚まし時計を設定するのです。

　最近、Siriが便利だなと思うのはこうした目覚まし時計やタイマーなどを設定する、いわば音声プログラミングとでも言うべき機能です。

　風邪で寝込んでますから、とりあえずカップラーメンにお湯を注ぎ、「Hey Siri, 4分後タイマー」と呼びかけると4分タイマーがスタートします。

　これなどはまさしく人間が自分にはできないこと(正確な時間計測)を機械に瞬間的にプログラミングする、人間拡張(ヒューマンエンハンスメント)の好例と言えるでしょう。

　今のところまだこの程度ですが、近い将来、もっと高度なことがこれくらい簡単にできるようになると楽しいと思いませんか?

　例えば直ぐにできそうなものとしては

　「Hey Siri, ゲスの極みとベッキーについての記事を集めておいて」

　「12件のニュース記事と、4件の有料記事が見つかりました。合計400円ですが購入しますか?」

　「うん」

　「ゲスの極みとベッキーについて有料記事とともにリーディングリストに追加しました」

　とか

　「Hey Siri, 今日はどうも寒そうだから、夕方くらいから暖房つけといてくれるかな」

　「暖房のタイマーを午後五時にセットしました」

　とかはすぐできます。

　さらに将来、家庭用お手伝いロボットが実用化されたとしましょう。
　こんなふうに使えるでしょう。

　「Hey Siri, 今から部屋に女の子連れてくんだけど、部屋を片付けといて」

　「計算中・・・部屋の片付け完了までにはあと4時間32分程度かかります」

　「ダメだよそんなに待てない。30分くらいでなんとかして」

　「優先順位を教えて下さい」

　「下着とか、食器、ゴミは捨てて・・・」

　「計算中・・・40分程度で完了の見込みです」

　「わかった。それくらいは時間潰すから」

　ここまでくるとなんかスターウォーズのC3POみたいで可愛げが出てきた気がします。

　こうした卑近すぎる例たと人間の「心」というのが単なる怠け、甘え、だらしない人間の堕落した心のように感じられたかもしれませんが、そもそもプログラマーというのは本来は怠惰な生き物なのです。

　同じことをひたすら繰り返すのがイヤで、それを機械にやらせようと考えるところからプログラマーのモチベーションというのは始まっています。

　作る喜びというのはその次にあるものです。

　さっきまで10ステップかかっていたことが、新しいプログラムによって3ステップまで短縮できた!バンザイ、というために1000ステップかけるのがプログラマーです。

　それでも、10ステップかかる仕事を100回繰り返すよりも遥かに有意義に思えるわけです。

　最近特にそう思うのは、深層学習(ディープラーニング)向けの学習データセットの作成作業です。

　たいがいのネット上にある記事では、学習データセットは誰かが作ったものを持って来いとか、ヘタすると学習済みモデルすら誰かが作ったものをそのまま頂戴しろとか書いてあるのですが、やはり人と同じデータで学習しているだけでは本質的に何が違うのかわからないので、結局学習データセットを自分で作ることになるのですが、これが恐るべき単純作業です。

　そこで、単体の画像や動画データからいかに多彩な学習データのバリエーションをひねり出すかということになるのですが、こういうときにこそプログラミングの出番がやってくるわけですね。

　実際、深層学習のサンプルでは、反転させたり歪ませたり、部分的に切り取ったりして多様性を確保しています。

　ただ、これもやり過ぎると本来学習させたいデータの意図とは異なる学習になってしまったりするので、トライ&エラーでいろいろな方法を試していくわけです。

　これはこれで面白いんですけどね。

　要するに最初に目的があれば、その仮定にあるプログラムがどれだけ単純なものでも面白くなるのです。でも、目的がないと、複雑なプログラムを組めるようになっても「だからなんなの?」という視点を脱することが出来ず、やっぱり気が付くとつまらなくなっているんですね。

　何事も大事なのはどこを目的地と決めるか、どこに旗を立てるか、その意志をまず発信者である自分が持つこと。そうすれば、その過程にある道具をどう使えばいいのかといったことも自ずと見えてくるのです。