これはすごく同意。
最近のプロジェクトを見ていると、奥出研で言うコンセプトができ上がって、粘土こねてなんとなーく、作るモノが見えてくると、途端にみんな手を動かすのをやめて（Craftingをやめて）、電子回路とソフトウエアを洗練することに集中します。まるで暗黙の了解があるかのように、モノの形や人々がふれる部分・場所のデザインがスライドの中だけで語られていること、よくあります。なんか、まずいなあ、といつも思います。
出展はちょっと前のうちの研究室のメーリングリスト。
さて、同意なんだが、コレ読んでからちょっとモヤモヤしていたんだけど、最近まとまってきたので書く。
結論からいうと、みんなの言う「実装」は実は「設計」の事だ。ソフトウェアやハードウェアの実装を、工場の製造のメタファーで見ているから間違える。
手を動かしながら、時には寸劇をしてみたりして、こんなものが欲しいなあというのを考えて、いきなり「実装」しますとか言い出すんだ。これがおかしい。
もちろん俺自身も動くモノを作る＝「実装」は割と得意で、好きだ。でも作って終わりじゃない。
Teleshadowは、動くプロトタイプができるまで、「これは一方がこっちを見ていて、でもこっちが他の人を見ていたら、覗かれているみたいでちょっと気持ち悪いんじゃないか？」とか気づかなかった。
あるいはPileusの地図も、動くプロトタイプができて自分で使ってみて初めて、これがあるとどういう風に都市とのインタラクションが変わるのかわかった。
まず、世の中に今存在しないものを頭の中で作るのではなく、それに近いプロトタイプを作って、それの存在する世界を感じ取らないといけない。そうすると、いかに自分が最初に考えていた「理想のモノ」が想像力不足だったかに驚く。動いているモノが目の前にあると、考慮しきれなかった部分が見えてくる。
で、「実装」の話。「ソフトウェア工学」とかでぐぐるといっぱい出てくるけど、コンピュータのソフトウェアをプログラミングするのは「製造工程」ではなく「設計」です。
コンピュータは、設計図がそのまま動いてしまう、という不思議なものだ。これを工場の製造のメタファーで見るから間違える。
プログラムを書くのは、きちんとした設計図を書いているのと完全に同じだ。もし動かなかったら設計が悪い。
コンセプトとかUMLとか口と頭で言って設計して、あとは実装、と考えるのはおかしい。
工場生産で言う設計図を書く ＝ コンセプトとか形を作るまでの部分
工場で言う生産行程 ＝ プログラムを書く
というのが間違い。
ここで音が鳴って、とかこの順番にデータ取ってきて、というインタラクションのディテールはむしろプログラム書いている時に思いつく。
プログラムを書くのは試行錯誤の繰り返しで、とても創造的な作業だと思う。
俺たちの普段使っている日常言語では、インタラクションのディテールやコンピュータの動きの詳細までを記述する為には粒度が荒すぎる。「こっちを押したらこっちが動いて」程度なら問題なく人間語からコンピュータ言語に翻訳できるが、例えば同時に複数の時間軸が動いている場合や、もっと緻密な論理的条件は記述できない。言語モードをもっと、日常語からプログラム言語まで下げないと記述しきれない。
モノの形を考える時に、言葉ではなくスケッチで、スケッチよりディテールに踏み込みたかったら粘土や彫刻や色々やったりするのと同じように。音の事を考えるときに音符や波形や実際に楽器鳴らしてみたりするのと同じように。インタラクションのディテールを語る時にはプログラム言語までちゃんと踏み込み、モノをデザインする時にはもちろん、そのモノを使った寸劇とプログラムとの間を行ったり来たりしなければならない。
そして、なによりプログラムで設計すれば、その論理や時間の流れが正しいかどうかすぐ確かめる事ができる。
みんなの言う「実装」は既にある設計図＝「デザイン」をそのまま動くように実現、生産する事の様だけど、そうではなく、最初に頭の中で考えていたモノを超えるような作り込みをする創造的な作業であるべきだ。
なので、コンセプトを作って機能設計をするまでを「設計」とか「デザイン」とか呼んで、プログラムを書く部分を「実装」と呼ぶのはおかしい。いや実装なんだけど、なんか「製造」とかいうルビが振ってるように聞こえる。
まとめ：プログラムを書いて動かす所までちゃんとやって、意図したとおりにモノが働いたら、はじめてデザインがちゃんとできたと言える。そうでなければ、実現できないモノを描いたデザインが間違っている。
（いやいや、正しいデザインというのは現代の技術で工場で生産できるようにパーツ分割まできっちり考えられたものですよ、というのもある？）
だから、今よりもっとちゃんとプログラムを書かないといけないですよ俺は。