昨日、電車で帰る時に吉田さんと話しててやっと言語化されたのをdirtyにメモっておく。
「処理系よりもライブラリ」という視点から技術を選び、3つのデザインルールを使い分けるからこそ、ラピッドなプロトタイピングが可能になっている、という仮説。
奥出研究室ではユビキタスコンピューティングという領域で、色々なモノ（サービスやプロダクトなど）が開発されて、発表されている。その成果物を人に見せ理解してもらったり、自分でこりゃ違うよなと思い直して洗練していくために「デモ」を作る。
その、ラピッドにプロトタイピングしている時、自分が何を考えているか、設計思想・デザインルールを省みてみた。
デモプロトだから、最初から商品レベルで工場動かして…となる筈はない。見せて説得し理解させるのが目標で、部分によってはクオリティを気にしない部分もある（筐体から線が大量に出ていたり）
■デザインルール
俺達は多分3つ意識している。
１．疎結合
２．モジュール化
３．密結合
この3つは、名前を見ても気付く通り並び立たない。だが、並び立たせる為により上位のデザインルールがある。
それは「処理系よりもライブラリ」というルールだ。
もはや、
「新しい処理系（プログラミング言語や装置など）を習得するコスト増」＜「強力なライブラリを使える事によるコスト減」
になっている。そもそもモノ（サービスやプロダクト）を創造する研究室なわけだから、基礎から技術開発する必要は無い。（以前その一部をまとめたので参照）
だいたい文法なんて覚えるの大して時間かからないし、プログラミング言語なんてどれも考え方は似たような物なんだから、目的にあったのを選べばいいじゃないか、という事だ。全部Javaで作るよりも絶対そっちの方が早く完成する。
じゃあ戻って、意識している3つのルールとは何か。
これは全部今あるものづくりのルールだ。ここを土台にせずに、俺達はプロトを作る事はできない。基礎から技術開発する余裕はないし、使うライブラリもこのどれかの思想で設計されているから。
１．疎結合
webのシステム作りで、ベンチャーな／オープンソースな人達が結構意識してる概念。
例えば
「サーバを増設するだけで対応できるようにシステムを組んでおくのが重要」とか「新しいシステムを素早く追加できて、しかも古い方に影響がでない様にするには？」とか考えている人達が実践している。
web2.0とかSOA（サービスオリエンテッドアーキテクチャ）とかBionicSoftware色々な言葉が乱発されていて、とても活発な人達がいる。
これ詳しく書いてると終わらなくなるし俺もまだ良くわからないのでパス。
まあようするに、ソフトの部分が多いから柔軟性の部分に贅沢に投資できるわけで、いくらでもXMLで抽象化させて、プロトコルをスタックさせてスケーラビリティを持たせられる。
例えばこういう話 → naoyaのはてなダイアリー – 疎結合のための Web API
街の中で生活する人間と、ネットワークと、それを扱う手元のデバイスと、インタラクションのデザインを考える上では、webが無い世界を前提に作るのはありえないだろう。むしろAPIがガンガン公開されているんだから利用するべきだ。
２．モジュール化
車など、デジタル部品とメカニカルな部品が合わさって、しかも製造スピード・コスト競争にさらされた時、摺り合わせのアーキテクチャで製品の部品を作っていく。
デジタル部品はインターフェイスを統一すれば接続性が確保されるが、物理的なデバイスの場合は接続出来てもガワに納まり切らなくなる事が多い。インタフェイス自体がサイズを持つわけだから、インタフェイスなんて標準化しない方がいいかもしれない。でも流石にネジは標準化した方がいいかもしれない……どこまでやればいいんだ。隣の部品の担当部署と相談すればいいんだろうか？上からの指示を待とうか？
という、無茶な状況をクリアする。
かなり組織のマネジメントと、事前の組織構造自体の設計が重要になってくる世界。
大学の研究室が海外で生産するかっていうのは冗談だけど（たまにブルガリアで基盤を製造したりはあるが）、我々の生活している複雑な世界の中の人間の使う道具をデザインするわけだから、当然複雑なモノになる。物理的な機構とコンピュータとネットワークを同時に考えるのに、モジュール化という考え方は学ぶ点も多い。というか一応頭に入れてないと、作った物は現実に生産されて消費者に届かないモノになるかもな。
この辺の本とか。
モジュール化—新しい産業アーキテクチャの本質
デザイン・ルール—モジュール化パワー
３．密結合
疎結合の逆。普通に考えて、疎結合で作る必要が無い部分は、密結合で作ってしまった方が速く作れる。
疎結合で作る必要の無い所とはどこか？それは、現実の世界で言えば、スーパーのレジや、駐車場のシステムや、エスカレータとかだ。何がwebシステムと違うかというと、拡張する予定が無い事だ。もしくは拡張するとしても拡張箇所が違う。
疎結合で作る一番重要な部分はデータベースの抽象化で、データベースを利用するビューワが複数あっても動くようにしている事だ。バーコードリーダや駐車場というのは物理的な物で、ビューを増設したら最初に付いていたビューもどうせ変更を加えなければならない訳で、最初から考えていないのだ。
部品が少ない方が壊れにくいし、安いから売れるというのもある。
ここではCPUが大抵8bitだったり資源が少ないので、疎結合みたいにウェブサービスの概要を記述するサービスなんてのを設定するのはキチガイ沙汰になる。
デモ実装で言えば、わざわざXMLSocketで全部接続するよりも、C#にActiveXでFlash.ocx埋め込んで、C#を起点にしてネットワーク、シリアル通信を制御した方が楽だ、というような設計。
自分にとって拡張する予定が無ければ、他の人が疎結合にしている場所でも密結合にしても良い。見せて説得し理解させるのが目標だから。
今製造されているセンサ・アクチュエータは密結合でコストを落として作っていて、環境コンピューティングであるユビキタスコンピューティングはその産業構造までひっくり返すわけにはいかないんだから、この動けばokな世界も知ってなければおかしい。
だらだらと書いたけどこんなもんだろうか。
色んなWindowsやMacやLinuxなんかを使って、色んなマイコンを使って、色んなコンパイラを使って色々やってみるのがベストかなと思ってる。その為に3つ（細かく分けようと思えばいくらでも分けれるだろうけどさ）踏まえた上で、「処理系よりもライブラリ」ができる状態になりながら、デモプロトを作っていけばいいんじゃないかと。
＊＊＊＊＊＊＊＊
あーSFCの授業でいえばデータ構造とプログラミングとかシステムプログラミングあたりが、プログラミングの基礎を身につけるのに役立った。両方ともアルゴリズムとデータ構造をJavaとCで自作させられる。リストとかハッシュテーブルとかを両方で、オブジェクト指向の考え方と構造化の考え方両方で実装させられたからかなり為になった。しかも次の週になったら前の課題の無限長の電卓を分数電卓にしなさい、とか拡張する課題も出たりしたから、嫌でもそういう「無茶な要求」に即対応できるような設計にするようになるし。