10月半ばごろに、適当に飲みながら？話した事を郡山さんがテープ起こししてくれたので
コピペしてみる。
ただし、ほんのちょっとだけ（暴言とか）編集した。
あと、俺は普段語尾は「である」調ではないんだけど、郡山さんが文字起こしするとそうなる。
—————-
情報世界と物理世界を同じもののように、タコの足のようにくっつけて、ひとつのものとして作る必要がある。そのための考え方であり技術の選び方を考えなければならない。「ウェブのサービス」などのように分けて考えるものではなくて、全てが一つのものである。「ウェブサービスを作りたい」と言うのではなくて、何か作りたいものの中の部品としてウェブサービスがある。
プログラムを書いている時に試行錯誤している。プログラミングは実装ではなくて、プログラムを書くことが設計である。書いてすぐ試して、というスケッチしているような中でデザインをしていく。
Pileusをつくっている時に、いきなり「こういうもの」として頭で描こうとしても、詳細に踏み込めない。作った後の今だったら、こういう傘があってこっちに振ったらこうなって歩くのにあわせて地図が動いて読んで、表示が変わって、撮影したものがアップロードされた時に自動的にタグがついて、などは分かる。
それらは、つくってみるまで具体化してなかった。「flickrの写真が出る」とかまでは言っていて、それがどう出るかとかどういう時に出ないのかとか、そういう条件を叩き出さないといけなかった。しかし、作らないとそれができない。
なぜ作らないとできないか。それは、人間の言葉は表現力に限界があるからである。普通の人間の言葉は、同時に並列にものごとが起こっていることとか、凄く複雑な論理構造（それとこれ、かつ、そうでない、など）を表現することができない。
この２つができないから、最初からPileusの完全な設計図を書くことができない。そのため、簡単にユースケースを書いた段階からどんどん作る必要がある。作ることが設計図を書くことになる。
作らないとインタラクションの詳細が分からない。むしろ、例えば影電話の場合、作ってすぐコンパイルして実機で影の行灯の表示やぼかしをかけたほうがいいなとか、ゆらぎを入れた方がいいなとか、やってみたら無い方がいいなとか、そういうことが分かる。そういったことは絶対に試しながらじゃないと分からない。設計する時には、人間の言語では表現することができない。設計はコンピュータの言語で行う。
コンピュータの言語じゃないと設計できないという問題があるから、たくさんスケッチしたあとにスケッチしたり、最後に彫刻したりする。素材を細かくしながらしていく。
音楽の人だったら、楽譜だったり楽器だったり、最初口笛で口ずさんでメロディを考えたりとか、道具を使い分けながら詳細に入っていく。
それと同じように、詳細なデザイン・設計を決めるための「思考するための道具」なのがプログラム言語である。
といった観点でいろいろ選んだ結果、最近言っている４つ、すなわち（１）インターフェースのGUIの部分、（２）タンジブルコンピューティングを行うためのフィジカルコンピューティングの部分、（３）ウェブのサービスを作るためのMVCフレームワーク、（４）その３つをつなぐタコ本体の部分のC#の部分。それが必要である。
ここで、３つの足だけにしないで、真ん中のタコ本体も入れないと、両側からくるデータの流れをさばききれなくなる。それは、僕が経験上知っているだけだが、するとC#じゃなくても微妙に弊害があって、重い処理をするところが真ん中にないといけないのかなと思っている部分もあるが、そこはまだ分からない。
というのも、Pileusと同じ思想で影電話を設計したらうまくいかない箇所があった。何を表示するかをC#が決めて、Flashはどう表示するかを決めることに専念させようとしたら、Flash側で画像処理してるから何を表示するかFlashが自分で作っていたりしている。ここのポリシーが崩れてきたので、すこし考え直す必要性を感じている。それはむしろ設計方法論の完成度を上げるためのいいことだと思う。
それで、僕らが何回も書いたり書き直したり設計していくことのためにこういう言語を選んでいるということがあるが、FlashとかProcessingといった言語は、エンタープライズの世界とは全く対極にある。ソフトウェア工学とかで博士号を取るような凄い人の記事とかを見ると、「大規模ソフトウェア10万行」などと書かれている。
10万行という異世界の話である。しかし、僕らは3000行くらいで既に大規模である。1万行あったら超凄い。パイレウスは全部併せても3、4千行しかやっていない。
なぜそういった違いが起こるか。ひとつは、プログラム言語の選び方に違いがある。10万行の世界はひとつの言語で作られている。JAVAだけとかC++だけ、といった風に。
それに対し、こちらの行数の少ない世界では複数の言語で作られていて、それぞれの用途に特化している。そのため行数が少ない。
用途に特化した言語を使うと、行数というか記述の数が少なくなる。例として人間の世界で言うと、「シュートしろ」と言った時に、目の前にボール一個とゴール一個だけあったらシュートしてくれる。「うて！」と言うだけでサッカーだったらシュートしてくれる。
でもゴールが5個とか複数あったり、敵が30人とか目の前にいる場合、そしてボールが7個とかあったら、「右から二番目のボールを敵をこういう風にかわしながらこっちのゴールに打て」と言わないといけない。
つまり、言葉とは状況が複雑になると長くなる傾向にある。状況が複雑な所で使える言語すなわち「何でも作れる言語」では、長くなって結局何も作れなくなる。何でも書けるけど、長くなって仕方がない。
何でもかける言語とは、10万行を設計図の通りに、仕様書の通りに書いていく。それと違うことは書かない。多分。しかし、僕らは設計図に従ってプログラムを書くのでなくプログラムを書くことで設計したい。3000行を何回も書くことで設計したい。その過程で10倍くらい書いてるので3万行くらい書いてる気もする。向こうは、書いたら書き直さない。こちらは、書いたら書き直す。それによって、インタラクションを考えるためのプログラム言語として使っている。そのため軽い言語を使わないといけない。何回も書き直すためのプログラム言語である。
何回も書き直すためにいろいろなプログラム言語を使うわけであり、それは大変そうという印象を与えるかもしれないが、実はうちの研究室の人は既に3つのプログラム言語が使える。
学部の情報処理の授業で習ったJavaと、奥出研に入ってから習ったFlashとArduino。実は全く違う領域で使う３つの言語が使えている。プログラムとか言語とかは、３つめからは学習コストが下がる。英語を苦労して勉強してた通り、第二外国語は簡単に勉強できたと思う。英語の時の学習の流れが分かっていたりしているから。
それと同じようにプログラム言語を新しいものを学ぶ時は全て差分で学んでいく。ひとつの言語を深くやるよりも、広く浅く勉強した方が早い。そんなに差がない。上から書いた通りに実行されるだけである。
では、プログラム言語をどれぐらい勉強するか。その言語が何に向いてるかとかができないかとかが明らかになったら、それ以上は勉強する必要がない。必要な時にそれをまた引っ張りだして使えばいい。つまりArduinoで何ができるかというと、モーターの制御とか赤外線とか、時間にクリティカルな操作は自動化して行ってくれる。その分逆に、時間にクリティカルな部分は隠蔽されているからタイマーとかスレッドなどが使えなくなっている。そのため複数の処理を同時に一個のArduinoマイコンで行うことができない。
そのことさえ知っていれば、それ以上やる必要はない。基本的な文法が分かって2、3回書いたことがあればもうやる必要はない。あとはプロトタイピングの中で学んでいけばいい。
「開拓する」というのは達人になるということでなくて、それを使ったら何ができるか、何ができないかが分かり、なんとなくプロジェクトの中で「これを使ったら1週間くらいかかるな」とか「このセンサを使うんだったら3日くらいかな」とか「このライブラリは、よく分かってないけど顔の位置を認識できるんだな」とか、1行くらいで設計できるんだなとか10行くらいで動くんだなとか、それが分かっていたらそれでいい。プロジェクトの中で日数の見積もりまで出せる所まで理解したらそれ以上はやる必要はない。あとは、横に広がっていった方がいい。「タコの足の候補」を増やせばいい。
そういったことを勉強した後は、メッセとかで1対1で人に伝えるよりは、ブログに書いた方があとあと逆に情報が集まるようになるので有益である。30人の中で29人に1対1で教えて、それかける29回教えるよりは、どっかに書いて読みたい人だけ読んでもらった方が楽である。そうでないと追いつかない。また、それにより何回もラピッドなプロトタイピングを繰り返すことができる、
それが奥出研の方法論を支える根幹にもなっている。それの複雑なインタラクションを支えることができるのがこれのポイントである。
こっちを押したらあっちのFlashが光るとか、Flashのこっちのボタンを押したらマイコンのここのモータが動くとか、そいうった直結した簡単な論理構造で並列に時間が走ってないようなインタラクションでは、次元が上がっていかない。1アクションでもたくさん豊かなことが起こっていかないといけなくて、その点で、いろいろな方向からくるメッセージをさばくことが必要になる。インタラクションの言語性。
傘を持って、歩きながら傘のインターフェースを見て、ここの地図と見比べて、その後に「この辺か」と思ってスイッチを切り替えて写真モードに変えてくるくると回して、写真をブラウズしてこの場所行きたいなと思って地図に戻して、歩きながら写真を撮りながら向かっていく。
その流れをラピッドにプロトタイピングできるようにしないといけない。Pileusは本当に作りながら考えた。実は1stプロトは夏休み中に3回ほど作り替えた。最初の2回は思った通り動かなかった。というところを、作りながらシナリオを作る、みたいなところが必要である。
…アーキテクチャイノベーションから話し始めると、それ単体では説明できるがタコ理論までつなげるのがなかなか難しい。
こちら側から説明すると、破壊的イノベーションを起こせるデザイナになりたいというビジョンがある。飛行機の部品を作れるようなはんぱなく凄い技術を持ってる人が東大とか東工大にはたくさんいるのだが、飛行機そのものを作れる人はいない。そういった、最後にインテグする人材を作った方が日本のためにいい。
それは、全体の必要なパーツと機能を抜き出すこともできるが、全体の絵がかけて、いろんな人に話し掛けながら頑張って一個のものにしていくこと。実際、ただ設計図を書く人という意味ではない。ただ設計図を書くだけじゃなくて、設計図とは、最初から書くことができない。作りながら書くことしかできない。人間の言語はそういう風にできていない。なので、それをやりたい。
破壊的イノベーションができるとどういうことが可能になるか。それは、パソコンの規格品の部品等とは違い、簡単に手に入る部品はいろいろある。そういうものを集めて、既存のものを集めて違う価値のものが作れる。そのため部品調達コストが低いのに、豊かなものが作れる。またお金ももうかる。
最後にそれをインテグする人は、設計図を書くことだけでは設計図を書くことができなくて、合体・インテグさせながら設計図を書かないと設計にならない。
という感じで、破壊的イノベーションを行うには、何回もプロトタイピングできるように技術のレベルを調節しながらやっていくしかない。下を作っては上を作っていく、といった具合に。
コアの技術とは、各部品から来るメッセージをさばく部分のことであり、ただの設定ファイルのようなものではない。スイッチAがこうだったらスイッチBがこう動くとか、そういうものでない。
もっと、20ミリ秒止まるとか、そういう所まで来ると、設定ファイルみたいな書き方では実現できなくなる。ほんとにプログラム言語じゃないと書けない。同時に、並列的にイベントが起こるため。処理80％くらいのときに向こうから指令がきたらどうなるか、とかまで踏み込まないといけない。
フィールドワークは実はこの場合にすごく重要で、常にフィールドにいてプログラムを書かないといけない。何故かというと、作ってすぐコンパイルしてすぐ動く状態にして試すのがいい、重要だと主張しているわけだが、試した結果が正しいとかこうした方がいいとかう基準になるのは、ユーザーである。あるいは自分が使ってみて使いやすいかとか嬉しいかでもいいのだが。
どっちの方に持っていきたいかとか、文化的なコンテキストとかユーザー的なコンテキストに沿ってそちらに寄せていかないといけない。なので、使ってみた結果僕のターゲットにしてるおじいちゃんには使えないなとか、それが分かるためには最初からフィールドワークが必要である。そのユーザーのコンテキストを自分に取り込んでいないと、いくらラピッドに試せるとしても、反映できない。
フィールドワークができてなかったら、それがいいかどうか分かる筈がない。ポストプロダクションではないが、プロダクションしている途中なのだが、最初のアイデアを得る段階でフィールドワークが必要だということもあるが、その出来た物が良いか悪いかということはフィールドの中じゃないと分からない。
スモールチームについて。これらのことは、小さなチームで意思決定しながらじゃないとできない手法で、たぶん20人とかいたら月あたりの人件費が600万円とかいくものである。でも学生4人だったらもっと低くて、リスク度外視で動ける。
どんどん冒険しないといけないし、そもそもこの開発手法だとあまり金がかからない。破壊的イノベーションだから、出来合いの既製品を集めてきてやってるわけで、かかったとしても200万とか。それだと、全然企業のデザインプロジェクトよりもお金はかかってない。
スモールチームで、Web側から、タンジブルインターフェースでみんなをカバーできるようにしないといけなかったから、軽い言語を使わないと、スモールチームではカバーしきれない。
大きい30人とかの組織でそれら全部をカバーすることはできるのだが、そうすると今度は意思決定が遅くなる。意思決定を早くしようとすると、ヘッドの3人くらいのデザイナーとその下の27人くらいの構造になるが、そうするとウォーターフォールモデルの開発になる。
デザイナと開発者に分かれていて、しかしデザインすることと開発することは同じである。手を動かす人と考える人とリスクを背負う人と頭を動かす人は全部同じ人じゃないといけない。その3、4、5人くらいのチームでデザイン領域の技術全部と、フィールドワーク先のコンテキストを取ってくる技能、本読んで勉強したりする技能、それら全てをもってないといけない。
ちょっとちゃちいけど動くプロトタイプを、少人数で2週間に1個とかのペースで作れるからこそできる種類のものがある。それと一番相性が合うのが破壊的イノベーションである。
個々の部品は性能が上がるものであり、実際、携帯電話に入るプロジェクタを作ってたりする人とかいて、つまり後から性能は上がるものである。ユースをあげれば性能を上げる人は他にいるから、俺らががんばると科学者の人もうれしい。
身体的なインタラクションを考察したドーリッシュの話があるが、実はオペレーションのところじゃなく、アクションでもユビキタスコンピューティングは動くよねという話。操作しなくても自動的に動くのだが、しかしぎりぎり操作になる。歩くとか、毎日寝起きしてるだけでもベッドが勝手に体調管理してくれるとか。
使わされてるわけではなく、使っているのだが、オペレーションではないのにEmbodiedなインタラクションがある。具体的なオペレーションではなく、生活しているアクションで使うことができる種類の、「大きい」Embodied Interactionはwebのサービスと相性がいい。
それのアクションをトリガーにして、ベッドで寝起きするだけとか、トイレを使うだけとか、傘をさしてただ歩くだけとか、行灯の前でただ生活するだけとか、カメラとかを埋め込まれたセンサーが認識してくれて、それでウェブのサービスが動くようになる。それがEmbodied Web。ウェブのサービスがウェブだけにあるのではなく、身体化される。
言語に粒度がある、ということについて。
基本的には、先ほどの何でも書ける言語は何も作れないということ。また、いろいろな言語をいじっていると分かることがある。PerlとPHPとRubyは全く違うもので、今では同じ用途のものとして扱われることもあるが、まず最初の頃にC言語があった。そして、スクリプトでC言語が書けるようになって、ハッシュと正規表現があるのがPerlである。PerlにCGIがついて、HTTPの機能がついたんだけど、そのHTTPの機能を中心にPerl側の正規表現とかに伸ばしていったのがPHP。Rubyは、それとPythonというDelphiっぽい変態言語から長所短所を整理し直してオブジェクト指向を中心にして作った。Rubyで完成された、ちょっと傲慢な思考のオブジェクト指向の考え方をもういっかいPerlに戻したのがPerl6.0、らしい。知らんけど。もちろん、JavaScriptみたいな変なのもあって、クラスが存在しないオブジェクト指向もある。
オブジェクト指向が何故いいか。それは、プログラム言語が僕らの生きている世界とfamiliarityを持ったところにある。書き方が似ている。主語.動詞(目的語, 目的語, 目的語)、という書き方ができる。それがオブジェクト指向の一番いい所である。
今まで、主語無しで動詞だけとか、いきなり目的語＝目的語とか繋げたりしていた。それに対し、わりと人間の言葉に近いのにコンピュータのロジックにコメントできるギリギリの境界を作ったのがオブジェクト指向の考え方の一番凄いところである。
メモリアドレスに現実世界に似せた自由な名前を付けられることと、それに関数を関連づけること、それだけで主語.動詞()、の書き方のように人間の言葉に似た書き方ができるようになってよかったねということである。
もちろんフォーカスが違うということもある。CPUの中のことをそのままやりたければアセンブラが一番いい。現実世界のものごとをコンピュータに移したくなったらオブジェクト指向。
図の右上の言語学・記号論について。
以上の話が、言語学とか記号論とか文法とかの面で、そして今のオブジェクト指向とかプログラム言語の見方で、さっき言った言語学と同じように文法と記号の並び方の文法でできているわけなので、3つ目以降のプログラム言語は早く勉強できる。それはそのまま成立するし、言語で思考しているし、言語によって思考の詳細化ができるレベルが違うとか、逆に詳細になりすぎて全体が書けなくなる言語があるとか、そういうところは多分言語学とかと通じる。
図の左下のオートメーション、人工知能について。
オートメーションと対になる言語性のあるインタラクションというもの、それは複雑さを縮減する方法をどうするかという話でもあるが、現実世界で起こっていることをセンサーで入力して電圧とかになってコンピュータに入り、記号処理されてデータベースに問い合わせてそれが戻ってきて、その記号から電圧からアクチュエータに戻って人間に戻ってくる。
そこで、情報が変換されたり減ったり増えたりしている。それをやるときの方針が、オートメーションか言語的なインタラクションか、という話になってくる。僕はそれはミックスでいいと思っている。白鳥さん的なベイジアンネットワークにmastabaとかcara clockみたいな面白いインタラクションを重ねる。
現実世界にある情報は扱いきれないものだが、それを一回センサーが変える。例えば樹がやってたような「笑ったセンサー」というものがあって、笑ったセンサーがついてる机のまわりでみんなでDSでゲームをやっているとする。盛り上がったらその人の所だけ画面がでかくなってハイライトされたりする。それでゲームがより面白くなったりするとする。
もしかしたら「笑った」というのは「大声を出した」とか足をバタバタさせたとか、そういう箇所で取ればいいのかもしれない。もう少し複雑なセンサで取ってもいいのかもしれない。そういう風にして、複雑な・曖昧なところをコンピュータで計算可能な状態に変えていく。それを計算して、出力結果を人間に理解可能な状態に戻して、渡してあげないといけない。
さっきのEmbodied Webの話の様な事をやる時は、その変換が凄く重要になる。なんでかというとwebでやりとりされる情報は、XMLとか生テキストとか地図とかビデオみたいなすごくリッチな情報だけど、人間とインタラクションする部分をGUIだけじゃなくてTUIでもやろうとするとモータをこう動かす、LEDをこう光らせるというチープなただの「物理現象」に変換しないといけない。翻訳が重要。
人間に理解可能なものをコンピュータで計算可能にして、そしてまた戻すこと。Computationalな部分とUnderstandableな部分それの行き来をさせるのが、おそらくコンピュータを使ったメディアを作る醍醐味である。それが、「こっちを押したら向こうが動く」とかではなく、何かの変換が行われて違うものが出てくることの面白さである。
インタラクションのデザインなんだけど、それはある面ではその変換のデザインである。その変換することの方針が、オートメーション型で情報を縮減していって計算して出していくことか、言語的なインタラクションでより多い情報や可能性を記述できるようにしてコンピュータに伝えることか、ということ。人間が発することができる言語なんだけど、コンピュータに十分状況が伝わるようにインタラクションを設計するか、という違いである。それら両方を使うと、たくさんまとめると大量に伝えて、それを一気に表示して記号処理してまた戻してきてくれたら凄く面白いものになる。
入力装置、ではなく、変換装置である。意味が減ったりしている。人間の言語は絵みたいなものであり、ハエが頭の上で飛んでいて、みたいな感じで状態や物と物の関係は記述できる。しかし、同時にとか複雑なこととかが自明なことになっていて伝えきれていない。それがないとコンピュータは動かない。
インタラクションの言語性という話について。
オートメーションするのはコンピュータ側で複雑な情報を全部計算可能な状態にするような人工知能というアプローチもある。コンピュータで計算可能かつ人間で理解可能なこと、という点について、実際問題、Webでやりとりされているコンテンツは全部それしかない。
テキストと地図と写真とビデオと音声しかない。5種類しかない。それらは、地図はもちろんなのだが、人間がそれ自体をそのまんま見てコンテンツとして楽しめて、かつそれの中身のデータを解析してコンテンツ間の関連性を計量したり計算したりとか課金したりとかできる性質のものしか記述していない。
なので、そのまんま写真、とか、そのまんま音声、とか、そのまんまビデオ、など。Web2.0で発達したのは、そこのお金のやり取りとインタラクションのコストが下がったこととくらいしかなくて、コンピュータで計算してお金のことを考えたりとか、コンテンツ間のリンクを生成したりとか、人間がそのままそれを楽しめることが同時に満たされているものしか、ウェブではコンテンツとして流れていない。
でも、この言語的なインタラクションのこととかを考えたりしていると、もうちょっと変わってくるのではないかと思う。コンテンツとはバイナリのデータファイルのことを言うのではなくて、tumblrのdashboardを流していく事がコンテンツなのではないかと思う。一枚一枚の写真に意味があるのではなくて、キーボードの jボタンを連打しながら流していて、頭がシャワーに流されているような、上流から凄い勢いで桃を流してる人がいる事件みたいなのが起こったりするのがコンテンツ。
それが、これから作るものの指針になってくるんじゃないかと思う。インタラクションに価値が出てくる。このときのポイントは、現実世界の多過ぎる情報をどうやってコンピュータで計算可能な状態に縮減していくか。