2015年7月5日日曜日

プラットフォームの構築

書名：「ザ・プラットフォームーIT企業はなぜ世界を変えるのか？」
著者：尾原 和啓
発行日：2015/6/10
発行：株式会社PLANETS

都立中央図書館に遊びに行った時に、新刊書の棚に見つけてめくってみたところ、思いのほか面白かったのでKindleで買った。プラットフォームという言葉に、どういう意味が託されているか、が良くわかる本だった。

発見はあまり多くなかった。しばらく前に報告書で書いたこと、考えていたことを再確認する内容だった。ただ収穫は多かった。特に具体例、彼が所属した内部から書かれている具体例が大変参考になった。iモード、リクルート、楽天などである。

プラットホームとはなんだろう。この本では以下のように定義されている。

「プラットフォームとは、個人や企業などのプレイヤーが参加することではじめて価値を持ち、また参加者が増えれば増えるほど価値が増幅する、主にIT企業が展開するインターネットサービスを指します。」

また、最近の特徴として
・参加のしやすさが格段に上がった
・範囲が拡大し、生活や社会に大きな影響を与えはじめた
があるとしている。

また、彼はプラットフォームと密接な関係にあることとして、プラットホームの運営者たちの共有価値観（Shared Value）があると言っている（私はビジョンと呼んでいた）。この本も彼の共有価値観（「ふむふむ」や「ワクワク」を生む「なぜ？」の共鳴）の一つの実現として書かれている。

私は今まで、プラットフォームとは実用的なものであって、多くの人に役立つアダプタのようなものだと考えていた。実際多くの人にとってプラットフォームの見え方はそういうものだろう。ただそれは中で紹介されていたTEDの講演（サイモン・シネック「優れたリーダーはどうやって行動を促すか」）におけるWhatの見方、皮相的な見方である。

プラットフォームにとって重要なのはその設計思想である。設計思想は製作者の共有価値観をコアとしている。

アップルの共有価値観はアップルの製品の設計思想のコアである。Googleの共有価値観はGoogleの各アプリやサービスの設計思想のコアである。

プラットフォームには一貫性が大事だ。プラットフォームを作る人、利用する人々はその一貫性を体得し、一貫性に基づく予測をして、手を加える、自分の目的に活用する。

一貫性が見失われた参考にすべき事例としてmixiが挙げられていた。（mixi側からの反論が聞きたいところだ）

共有価値観と設計との間には大きなギャップが存在する。戦略と戦術と言い換えてもいいかもしれない。たとえばmixiでは足あと機能は戦術の一つである。公開日記という日本独特の文化をベースに心理的なバリアを小さくして、ユーザをアクティブにステップアップさせていく仕組みが戦術である。twitterに影響を受け、その一貫性にほころびが生じた、という解説には説得力がある。

この本ではそういった様々な戦術について、具体的に書かれているのが興味深い。各社の共有価値観や戦略についてはある程度はネット調べれば出てくる。また非常に印象的に表出されるので我々の記憶にも残る。一方で共有価値観と、それぞれのアプリやサービスや製品の設計との間の関連性は中々表には出ない。

例えば、この今手元にあるiPod touchと言う製品も、たくさんの人が関わって作られている。私には、いかにもティム・クックの共有価値観が体現されているエッジの立った製品だなと思う。ジョブズのころのiPod touchのテイスト（丸いフレンドリーな、それでいて個性の強い。私は個人的にはジョブズ派）との違いが印象的だった。制作に携わる多くの人に、うまく共有価値観が伝わらないと、ティム・クックのiPod touchのような完成度の高い製品はできない。完成度と言うのは共有価値観の再現度という意味である。

サイモン・シネックのTEDの講演で、スペックをいくら謳っても人の心には何も届かない、という話が出てきた。Whyを伝えることが肝心である。そしてそれができる人は極めて数少ない。まぁそうだよなぁ。

この年齢の私にとって何が大事かというと、どれほど私にとって魅力的な、さらに多くの人の共感を得られる共有価値観を語れるかということだ。共有価値観に関しては、いろんな人に何度も何度も伝え、反芻して改善を繰り返していく必要がある、本当にその内容・表現で良いのかよくよく考える。再考する。共有価値観を言葉にするのもとても大事だ。

以下は私の共有価値観についての話だ。

私たちの毎日の生活の中には、不便な隙間がいっぱいある。みんなそんなもんだろうと思って生活している。例えば今消したこのエアコンも、まるで使い勝手は良くない。その他にも照明や寝具や場所の使い方や、とにかくいろいろな不便がたくさんある。それらの小さな、みんなが我慢している不便な点を補うところにバリューが生まれると考えている。

どれも小さいバリューなのでそんなにたくさんのお金は払えない。例えば私の家の中の片付けが多少まともになるからといって、月々3,000円のお金を払うだろうか。いや私は払わない。一個一個を取り出して見れば小さな不便であり、我慢すれば済むこと、または良くできる人ならば何とかしてしまっていることなのだ。

しかしみんなが片付けが上手でも、みんなが食材の使い方が上手でも、ゴミの出し方が上手なわけでもない。みんな何かしら苦手なことがあって、何かしら我慢をしている。それは匠に住宅改造してもらうような大掛かりなことをしなくても、多くの場合何とかなる。でも助けてくれる人はいないので、そのまま不便が不便のまま放置される。

その不便のいくつかを小さく解消して、私たちの生活のレベル、QOL（Quality of Life）を向上するところにこそ、新しいプラットフォームの存在価値がある。

もともと電気というものが、そういうものではなかったか。コンセントにプラグを差し込めば、どんな電気製品でも動くなんて、ものすごいプラットフォームだと思う。停電もしないし、電圧や周波数も安定しているので、メーカーも利用者も、ほとんど水道水のように意識せずに使えるプラットフォームである。

私がいま考えている共有価値観は
「生活のクオリティを共有し、その中で見出される隙間を丁寧に埋め、バリューが生まれる場を作る」
である。

新しいプラットフォームの構築に貢献したいと思う。かすかでも。


投稿者 時刻: 0 件のコメント:

2015年7月2日木曜日

「忙しい」という言葉は私にとって主観的な意味を持たない

100kw氏の以下の設問が面白いので、私も考えてみた。
授業で、「時間を長く／短く感じる時について」「忙しいとはなにか」「テクノロジーは忙しさを軽減するか？」についてミニレポート出した。「忙しさとは何か。いつ忙しいと感じるのか、いつから忙しいと感じるようになったか？忙しいの対義語はなにか」ということについての考察してもらった。
— (@100kw) 2015, 7月 2

「忙しい」という言葉は私にとって主観的な意味をあまり持たない。

美味しいとか、悲しいとか、痛い、といった言葉が、それぞれに対応する私の主観、もしくは実感を思い出させるのに対して、「忙しい」には対応する実感が無い。この言葉は私にとって、むしろ他人とのコミュニケーションのための共通の符号として意味を持つ。であるにも関わらず、実は「忙しい」と伝えた相手に対して、これまた私の具体的な状態をあまり伝えない言葉でもある。ただ「不問」とか「ちょっと待ってくれ」という程度の、コミュニケーションの遮断・遅延を意味する言葉である。

さらに、この「忙しい」という言葉の面白いのは、そのように実感が薄いにも関わらず、私の状態を表す言葉として使われているという点だ。

似ているがちょっと違う言葉に「焦っている」というのがある。ただし、焦りには対応する主観や経験がある。焦ることはある。ただ焦っている時には、ほとんどの場合気づいておらず、後から振り返って、焦っていたことに気づく。そのため「焦った」と過去形で口から出ることが一般である。「いま私は焦っている」と言える人は焦っていない。

同じような言葉に「怒り」がある。怒っていることはあるが、その時に自分が怒っていると気づくことはほとんどなく、むしろ気づいたことによって、怒りが収まる場合が多い。収まった後には、諦めとか、むなしさといった別の状態に変わる。恐らく私は、抑えようのない怒り、といった本物に出会わずに済んでいる幸せ者だということだろう。

さて、もとに戻って、「忙しい」の正体について考察してみよう。

私が忙しい、と言っている時、もしくは言い訳している時には、処理速度の不足を通知している時だ。目の前にこなすべき（と感じている）タスクがあり、いずれも遅延を許されない（ように感じてしまっている）時に、私という人間の処理がオーバーフローになっていることを、周りの人物に通知する意味合いで言っている。

しかし上述したように、その時私は「忙しい」と感じているわけではない。こなすべき処理を継続している。一つ一つ書類の山を崩している。興味の湧くタスクであれば、やりがいを感じている場合もある。また、イヤイヤながら機械となって処理をしている場合もある。少なくとも、処理速度が落ちて停滞していたり、放置している状態ではない。

処理速度が落ちていたり、放置している時に「忙しい」とは言わない。「ちょっと無理」「すいません」「勘弁して」「限界です」「やーめた」というのだ、そういう時には。

忙しいという状態は、自分にとってのタスクの価値や、こなしている時の自分の主観とは関係ない。それぞれのタスクには誰かしらクライアントがいて、そのクライアントが要求している期限に対して、私の処理速度ではキツキツであるということを意味する。であるから、他人とのコミュニケーション用の言葉、ということになる。

つまり、クライアントに対して、さらには、処理を分担してもらうべき同僚に対して、さらには、私の健康状態や家事の分担に関して配慮してもらうべく、家族に対して、私の状態を伝える言葉である。

もちろん、私は自分の肉体的、また精神的なリソースを考慮して言っている。毎晩徹夜すれば、または休憩時間を減らせば、短期的にはこなせるかもしれないが、そうするとその後に大きなパフォーマンス低下が生じるため、結果的に平均的な処理速度は低下する。なので、適宜休憩や適切な睡眠をとって、自分のパフォーマンスを一定以下に落とさないようにしても、期限的に厳しいという場合に「忙しい」と言う。

このように考えているため、私の眼からは誤用に思える使い方をする人がいる。例えば、自分の趣味や楽しみを夢中になってこなしている時に、「忙しい」という人だ。それ、忙しいっていうのかな、と思う。あれは大人のジョークなのだろうか。

忙しいという言葉を使い始めたのは、クライアントから期限のあるタスクを多数与えられるようになってからである。学生時代にもクライアントはいたが、社会人になってから明らかにクライアントは増えて、期限に対する厳しさも増した。

上述したように、忙しさは処理速度と期限との関係なので、期限が緩ければ、忙しい状態にはなりづらい。期限が厳しく、処理速度の限界に近ければ近いほど、忙しいになりやすい。

こういった考え方は私が工学系、それも計算機科学を専門とするからだろうか？　多くの人は「忙しさ」を実感としてもっているのだろうか？

忙しさの対義語は、忙しくない、である。暇な時もそうだろうし、余裕がある時もそうだろう。単に私の抱えているタスクと、処理との関係を表している。

時間の経過を短く、また長く感じることはある。これは主観である。私の世界の話だ。これと忙しさとは、私にとっては関係が無い。忙しさは、私の世界の話では無いからだ。これは、いわゆる「現実」、他人と共有する約束事の世界の状態である。

テクノロジーは忙しさを軽減するか、という設問に対して、処理効率化という観点からは私は無関係、と考える。まず、忙しさは単にタスクと処理能力の関係であり、これは例えばコンピュータのCPUが速くなったからといって、コンピュータが暇になるわけではないのと同じである。

忙しさを減ずるには、タスク量をコントロールするしかない。あまりに忙しいと、上述した私のリソースは限界に達するため、たとえ多くのクライアントに感謝されても、多額の収入を得ても、私の人生にとって意味をなさなくなるため、タスク量をコントロールするしかない。

では、さらに未来を想定して、タスクを減らすのに、コントロールするのに、テクノロジーは役立つだろうか。

例えば企業にとって、職員が忙しすぎて身体や精神を損傷したのでは、企業全体としてのパフォーマンスは下がってしまう。喩えれば、右手に働かせすぎて、右手が壊れてしまう人体、といった状態が現在の企業である。いまの企業は上手にコントロールできずにいる。この状態の改善のため、センサーを職員全員に付けてもらい、職員や所属部署の状態を可視化することで、「忙しさ」そのものを制御しようという取り組みが始まっている。

おそらく、そのジョージ・オーウェル的未来では、朝、職場に入ろうとすると、忙しさが限界を超えたため、IDカードが無効になっていて、仕事が自動的に同僚に割り振られている、といったことになっているだろう。強制的に家や、病院に送られて休憩することになるだろう。

もしくは、忙しさ予測エンジンが動いていて、新しいタスクを割り振れる量が、職員それぞれに決まっていて、それを超えてメールを送ることすらできない、といったことになるかもしれない。

ただ、そこまで行ってしまうと、私は次のステップが待っているように思う。入社から退社までの職員のパフォーマンスを予測し、いかに当該企業にとって最適に活用すべきか、といった最適化プログラムが走り始める可能性があるということだ。３年間の期間雇用であるとすれば、その後、その本人がどうなろうと、期限内に企業にとって最大の貢献を与えるように使い切る、といった発想は決して悪夢ではない。

おそらく、自分自身の人生を守るために、私達自身もテクノロジーの力に頼って、それら使い捨てへの対策を講じることになるだろう。やはりイタチごっこということだ。

さて、ここまで考えてきて思うのは、クライアントからの要請の無い人生というのも味気ないものだ、ということだ。顧客であれ、生徒であれ、上司であれ、親であれ、妻であれ、娘であれ、見ず知らずの他人であれ、誰かが必要としていることを、自分の力でなんとかする、手助けをする、というのは社会的動物である我々にとって、とても大きな生きがいである。

それは、QOL（人生のクオリティ）の主要因である。つまり、忙しさというのは、私達が求めているものでもある、ということだ。そのバランスを決めるのは、テクノロジーではなく、私達自身である。






投稿者 時刻: 0 件のコメント:

2015年2月18日水曜日

Processing で Philips hue を制御

Processingからhueを制御しようとして、PUTがうまくできずに困った。
結局、以下のように直接 Java で書けば問題なく動いた。

以下の 192.168.11.20 はhueブリッジのアドレス
newdeveloperは登録したユーザ名とする。
ユーザ名の登録の仕方は、hue api等で検索すれば出てくる。
例えば以下のサイトを参照。
http://blog.udcp.net/2013/10/09/philips-hue-api/

import processing.net.*;
import java.net.URL;
import java.net.HttpURLConnection;
import java.io.*;

Client c;
String data;
JSONObject json;
Boolean onoff;

void setup() {
  size(300, 300);
  onoff = true;

}

void draw() {
  if (onoff) {
    background(255);
    textSize(32); textAlign(CENTER); fill(0); text("ON", width/2, height/2);
  } else {
    background(0);
    textSize(32); textAlign(CENTER); fill(255); text("OFF", width/2, height/2);  
  }
};

void mouseReleased() {
  onoff = !onoff;
  lightSwitch(1, onoff);
  lightSwitch(2, onoff);
  lightSwitch(3, onoff);
};

void lightSwitch(int lightnum, Boolean onoff) {
  json = new JSONObject();
  json.setBoolean("on", onoff);
  sendPUT(lightnum, json);
};

void sendPUT(int num, JSONObject json) {
  try {
    URL url = new URL("http://192.168.11.20/api/newdeveloper/lights/"+num+"/state");
    HttpURLConnection httpCon = (HttpURLConnection) url.openConnection();
    httpCon.setDoOutput(true);
    httpCon.setRequestMethod("PUT");
    OutputStreamWriter out = new OutputStreamWriter(
      httpCon.getOutputStream());
    out.write(json.toString()+"\r\n");
    out.close();
    httpCon.getInputStream();
  } catch (Exception e) {
  }
};
投稿者 時刻: 0 件のコメント:

2015年2月5日木曜日

「融けるデザイン」を読了

「融けるデザイン」（渡邊恵太）を読み終えた。面白かった。
http://www.bnn.co.jp/books/7305/

内容の８割ぐらいは既知、１割ほど新味、１割ほど懐疑・不明、という印象だ。だから、かなりレベルが高い。最近私は、読書では、この２割ぐらいの新味＆懐疑・不明が、いい塩梅ではないか、と思っている。全部既知、というかスルスルと中に入ってくるようだと面白くない。新鮮さが無いし、刺激的でもない。一方で、新しいこと、不明点が多すぎると、ちっとも読めずに、苦労する。まだ、自分がそのレベルに到達していない、とか、そもそも変なこと、もしくは時代を先取りしすぎたことが書かれている、ということで、時が熟していない。それを難読するのもまた面白くはあるが。知的トレーニングとしては、この２割ぐらいのノベルティがいい。

渡邊氏の仕事はずっとウォッチしてきたので、最後のLiveSurface以外は知っていた。また背後にある考えも、それなりに理解してきたので、新味がない。全体としては、そういうことになるんだろうな、と理解した。またノーマン、ギブソン、ワイザーらの話や、Macintosh、iPhoneについても、ずっと読み、体験し、考えてきたことなので、その通りだな、という印象である。もしくは多少の異論はあるにしても、HCI研究者としては常識的な内容を、見通しの良い日本語で的確に整理した、と捉えるべきかもしれない。

新味を感じて面白かったのは、４章と５章で、情報の道具化、環境化を論じている箇所だ。ちょうど今、コネクテッドホーム、家庭向けIoTの可能性について、いろいろ作ったり、実験したり、調査したりしていて、それと呼応する内容だったので、膝を打った。何度も。そうそう、という感じだ。叩きすぎて膝が痛いほど。

インターネットに接続されることで、私たちの身の回りの道具や環境が、全て繋がった、融け合った状態になりつつある。そこには、つながりの悪い「モッサリ」した部分も当然含んで、しかし、ある部分は「サクサク」と、一切の抵抗無く世界の裏側まで貫いてしまうような接続性が担保されつつある。

そのため旧来の、無駄に完成度が高くなっていたジョイントの一部は、不要になる可能性が出てきている。それは特にエンジニアリング、工学の分野で多い。一種のルール無用が生じている。単位が消えてしまう、というのもその話だ。もっと身体に近いところで、別の言語化がなされるようになり、それが、そのまま適切にコピー＆ペーストできるようになる。

例えば、暑さ・寒さとか、湿度とかいった概念も、もっと情緒に近いレベルで、より細やかに表現できるようになるのではないか、と思う。15度といっても、それは人間にとってのクオリティを適切に表せていない。もっと使える表現、使える記憶方式、が実現できる。「あの時の南軽井沢の朝」というような。

６章、７章の、デザインの現象学、メディア設計からインターフェイスへ、は、まだ始まったばかり、という印象である。書いてある内容はわかるが、設計論としては具体性というか、リアリティが不足している。これからの活動に期待したい。

一方で、注意深く書かれてはいるが、タンジブル関連の記述に、若干いじわるさを感じた。TUI自体を攻撃しているわけではなく、「モノ」や「物理的な対象」に考えが縛られることを警戒しているのだが。私の理解では、人間にとって、生まれた時から制約・束縛として付き合い続けた、さらには進化の過程で大昔から馴染んできた、身体と物理的な環境とのインタラクションにおけるインバリアントは、何を考える上でも極めて重要な制約条件なのだ、ということだと思う。さらに、その強固な持続性、一貫性は、たとえ多くが錯覚であっても、強い「安心感」「やすらぎ」の根拠となっている、というのも重要な点だと思う。

今後、テクノロジーはどんどん進化するだろうが、この安心感、やすらぎがどのように生まれるのか、は十分に理解し、活用すべきだろう。触覚も視覚と同じく、そのエッジに様々な見えが集約されている。聴覚や嗅覚もしかりだ。それら全てを包含して、新しいデザインの現象学が生まれるのだろうと考える。

いずれにしろ、IoTを単に、センサネットワークのようなものと思っている、日本のエンジニア・デザイナには、ぜひ本書を通読して、次のステップへ進んでいただきたい。これを読まずにIoTを語るエンジニアを私は信じない。



投稿者 時刻: 0 件のコメント:

2015年2月2日月曜日

第2回 おうちハック発表会 参加報告

会議名：第2回　おうちハック発表会
日時：2015年2月1日（日）14:00-17:00
会場：GARAGE秋葉原　　（http://garage-working.com/）

第1回は技術評論社のサイトに記事あり。

概要：

SONY CSLの大和田氏と、NISTの湯村氏が中心となって活動している「おうちハック発表会」の第2回に参加した。最初の凹氏の講演が「おうちハック」の典型例を代表している、と言って良いだろう。自分の部屋・家をガジェットや自作の装置でハックした人たちの発表会である。発表者はインターネットでのハンドル名（ニックネーム）で紹介されたので、多くの発表者の本名は不明である（名刺交換した人以外）。

感想：

・密度の濃い2時間であった。大変参考になった。
・「実際の生活に用いている」というのが最高に良いポイントだ。素晴らしい。
・特に、最初の凹氏の講演は深みもあった。
・なおデザインという点からすると、もう一歩と感じた。多摩美大情報デザインコースとかとコラボしたら面白いだろう。

基調講演

(1) 基調講演「ハッピーおうちハッキング」 

最初に基調講演として凹（へこみ）氏による「ハッピーおうちハッキング」が30分枠で紹介された。
紹介された内容の多くは既に以下のサイトでブログとして公開されている。

以下にメモを記す。
・おうちハック＝住まいを面白く、便利にするものを作ること、考える事
・最初は勉強と趣味を兼ねて始めた。やってみると便利になった。モティベーションが維持された。
・なんといっても、他人に自慢できる、他人にもわかりやすい、というのがモティベーション維持に大きい
・個人として本当に便利になったか、という視点で、ビジネスは無視してやってきた。
・照明（hue）を、動体センサ（WeMo）で制御している
・Netatmo（環境センサ）やiRemoconがある
・Bluetoothマイクで玄関でも声が拾える。音声認識のため。
・宅内にnode.jsが走っているサーバを置いている。サーバでコマンド解釈・発行を行っている。
・node.jsはけっこうゴリゴリハードコーディングしている。
・ネット対応の家電、赤外線リモコン対応、タップなどで家電制御
・プロジェクタもリモコンで制御
・HDMI切替器もリモコンで制御
・「プロジェクタつけて」というと、「プロジェクタをつけます」と復唱してオンにしてくれる。
・「プレステでトルネをつけて」というと、「トルネを起動します」と復唱して付けてくれる。
・トルネは、リモコンの右を3回、○を1回、スタートボタン、といった操作を順番にコマンド発行している。
・Pebble（腕時計型装置）からも制御できる
・IFTTTでサービス連携している。アクション側はメールを送って、メールのサブジェクトを解釈している。
・GitHubにソースを上げているので、参照
・実際に生活に使ってみると、便利な面もあるけど、面倒も多い
・○決まった流れ、ルーチンは楽に出来る
・○ベッドでも、どこでも操作できるのは便利
・○自動通知は面白い
・×（A)自動制御には誤動作がつきもの。勝手に電気が消えたり、夜中に何かを人感センサが検知したりする
・×（B)オンになるまでに時間がかかる制御があって不便。例えば、トイレは人感センサを使っているが、反応が遅い。
・×（C)メンテが面倒くさい。システム更新や、機器追加など。
・改善方法：
・（A) 半自動化（後述）
・（B）トリガの最適化（人間は許容できる時間に限界がある）
・（C) 色んな家があるので統一化は無理、UIの工夫でも限界あり。
・A:半自動化：トリガに対して、候補を表示して、選択させる。
・例えば、温度低下を検知したら、エアコンONなどのアクションカードを表示し、選ばせる。
・また帰ってきたら、ゲームとか照明とかを表示
・出勤時も同様
・要するにGoogle Nowのパクリ
・Moto 360上にAndroid Wearで実装してみた
・B：トリガの見直し
・動体検知は遅いので、リードスイッチでドア開閉で検知させた
・ドア開閉センサにはTWE-Liteを使った。
・おうちハックAdvent Calendarが役に立った。
・ボタン電池で3年ほど持つので十分
・「賢いスイッチ」をばらまくのが良い。
・同じ機構でどこでもリモコンを作った。ぶっちゃけ一番便利
・C：メンテ面倒に対して、自動化を検討
・今はプログラムでやっている。最も柔軟。
・IFTTTはシンプルでわかりやすい。しかし複雑なルール記述は難しい。
・ビジュアルプログラミングはいいとこ取りで良いようにも思うが、メンテはやはり大変では。
・そこで「日々の暮らしから自動でルール作り」をすることを考えた
・例えば、寒く感じたら→暖房、とか、家を出る→電気を消す、とか、布団に入るまでに電気を消す、といったアクションはセンサとトリガーに対して、自動化が可能
・自動化候補が出たら、システムからユーザに問合せて、OKだったら、ルール化する
・これもGoogle Nowのパクリ（笑）
・まとめ：
・考えるのも作るのも楽しい。わかりやすく、面白い。モティベーション維持しやすい。
・趣味なので、もうからなくていいというのが良い。

QA：
Q　暖房（熱）・モーターの類を制御しているか？
A　やっていない。もしやるとしても、メーカーのインタフェースを使う。特に、ヒーターとかは危険だ。ハックしない。
Q　音声認識では、TVの声などで誤認識がある。どうやっているのか？
A　誤認識は多い。良いマイク、例えばKinectの指向性マイクを使う、といった手しか思いつかない。
Q　お客さんが来た時はどうしているのか？
A　お客さんモードを用意している。デモモードのようなもの。
Q　電気代に変化は？
A　おうちハック前後で電気代は変わらなかった。
Q　SONY　MESHの利用は考えているか？
A　すでにindiegogoで投資した。納品されたら使う予定。
C　しかしMESHはLED、ボタン、加速度センサしかデフォルトは無いので、GPIOが多数必要だろう
A　たしかに
Q　おうちハック後に、人間観察みたいなことは変わったか？
A　実家に帰った時に、家電がたくさんでハックできるな、と思った。ただしレガシー機器が多く、難しい。
Q　音声認識は何を使っているのか？
A　juliusとwebスピーチAPIである。webスピーチAPIが楽だ。
Q　モノが増えていくと管理が面倒では？
A　まだラック一杯程度で溢れていない。
Q　賃貸だと、釘が打てないなどの改造上の制約があるが
A　気をつけている。Kinectは一脚上に乗せるなどしている。
Q　センサなどの配線、固定が面倒では
A　壁美人というホッチキスで重たいものを固定できる治具があり、便利。痕が残らない。
Q　赤外線制御の課題として、フィードバックが無く、誤制御の結果が分からない問題へは何か対策しているか？
A　1秒おきにコマンドを送るなど、確実に制御できるプロセスを試行錯誤で決めている。音を出すといったフィードバックを考えた方が良いだろう。

ライトニングトーク


その後、ライトニングトークとして、「IoF（Internet of Furo)」「おうちで野菜」「ルンバを制御」「mbed+Felica+RasPiで消し忘れチェック」「やまびこ」「未来のティッシュ箱」「BUTABAKO」「Energy Design Competition」「おうちハックAdvent Calendar」が8分づつ発表された。
各発表について概要を記す。

(2) IoF（Internet of Furo) 

・ギークハウス品川というシェアハウスに住んでいる。
・プログラマなどIT系の人が集まったシェアハウスである。
・共用ということで、トイレや食堂は問題ないが、風呂が1つしか無いのが問題
・風呂までの廊下や階段が寒いので、見に行って空いていないと、往復が無駄になる
・誰かが入っていることを確認できるシステムを作った。
・各自のスマホでのBluetoothを検出して、Raspberry Piでfrobeeconというソフトでslackに投稿するシステムだ。
・風呂場と脱衣所に、BLE対応のBlueetoothアダプタを備えた、Raspberry Piを設置。
・スマホ（iPhone）持参で風呂に行き、装置の上に置くと、「○○さんが風呂にいると思う」と投稿がなされる。
・取り外すと「脱衣所にいると思う」と投稿がなされる。
・シェアハウスはハックすべき課題が多い。
・シェアハウスだと、課題にみんなで立ち向かう、という感じが良い。
・Raspberry Piは濡れると困るので防水容器に入れているが、発熱が心配。Edisonの方が発熱少ないというフロアコメント

(3) おうちで野菜 

・ここ3年で8kg太った。野菜が必要。近所のファミレスで「らりるレタス」が食べられる。おいしい。
・自分でも作ろうと思い、LED栽培キット（9800円）を購入。40日でサラダが食べられる、というふれこみ。
・監視システムを自作した。openCV + rubyでカメラを起動し撮影する。カメラ起動後3秒間は撮影できない
という問題があり、タイマーを入れている。
・40日たったが未だに収穫できない。原因は温度。エアコンが無い寒い部屋なので。
・温度管理システムが必要か。

(4) ルンバを改造

・GOMIHIROIDO氏
・ルンバは誰でも改造できる。APIが公開されている。
・センサもモータも、スピーカも制御可能
・ルンバにキーボードをつないでみた。演奏が可能。
・MIDIは演奏できないので、MIDIを単音に変換して、音信号として出している。
・ケーブル（シリアル接続）が邪魔なので、Androidで制御できるようにした。
・もともとARをやっていたので、ルンバの上の模様をマーカーとして、初音ミクが踊れるようにした。
・Javaの制御ライブラリを公開中

(5) mbed+Felica+RasPiで消し忘れチェック 

・消し忘れ、は、消したことを覚えていないのが問題である。自動で消してくれなくてもいい。
・チェックシステムを作成
・チェックすべきところに、Felicaをはりつけて、Felicaリーダーとmbedで自作した装置で、チェックするようにした。
・WIFIを使っているので、充電が頻繁という課題あり。Androidではどうか？、との声がフロアからあった。
・ガスは電磁センサでチェック

(6) やまびこ 

・ユカイ工学の岡田です
・Apple HomeKitとECHONETをつなぐYamabikoというアダプタを作った
・小さなボード型装置で、相互変換をする
・神奈川工科大学からSDKを近日リリース予定
・変換ボードはAppleの認証が必要だが、特定のチップを搭載する義務など、なかなか大変。しかし、達成するつもり。
・HomeKit側はすべてカバー、ECHONET側は実際に機器が販売されているもののみ対応

(7) 未来のティッシュ箱 

・jojonokiです。UIエンジニアです。
・光るティッシュ箱を作った。3Dプリンタで外形等を製作、ArduinoとLED、サーボモータで動作
・ティッシュを一枚取りだすとキラキラと光り、取ってがふさがって、すぐには2枚目が取りだせないようになる。
・ティッシュの取りだしは、加速度センサで検知
・3Dプリンタ便利、従来は、アイデアから100円ショップ、加工、モノ、という流れだったが、3Dプリンタがあれば、アイデアからモノに直結できる。
・品質は実のところ、100円ショップに負けるが、ドンピシャで欲しいものが見つかるというのがうれしい。
・どんどん「ワタシ」と「イエ」と「ソト」がつながる世界が来ている。
・肩書にこだわらず、いろんなこと、スキルの幅が広がる。一方で学習コストが下がっている。

(8) ヨメ召喚

・スマホアクセサリを作って売っている。ウインクルという会社。
・家のサービスを考えた。結論として、家はアニメを見る場所である、ということになった。
・テレブーというエージェントを作った。テレブーという豚のぬいぐるみと会話して好きなテレビが見れる。
・IoTの未来として、ロボットと生活する、というようなのが謳われることが多い
・しかし、私はロボットとなんか暮らしたくない。
・欲しいのはヨメである。
・だからヨメを召喚する。
・フォグスクリーンにプロジェクションする
・フォグスクリーンは加湿機を改造した。
・風呂の湯気を使う装置も開発した。
・ポリッドスクリーンでも作った。アクリルケースで覆うと、すごくかっこいい。
・将来は、ご飯も作ってくれるようにしたい。
・DMM.akibaで活動中。デモ可能

(9) Energy Design Competition 

・SONY CSL　大和田です。
・スマートメータのBルートの見える化コンテストをやっている
・明日、発表予定。（以下のサイトに企画と結果がまとめられている）
・ハッカソンをたくさんやってきたが、おもちゃの域を脱しないのが課題
・この、おうちハックは、実際に自分で使っているので、うまくいっている
・今後、ハッカソンとデザインソンを融合するのが必要

(10) おうちハックAdvent Calendar 

・NICT　湯村です
・Advent Calendarというのは、クリスマス前の1か月を楽しみながら過ごすための、カレンダーである
・最近、これをもとに、ハッカーが各自ブログをリレーして、カレンダー形式にまとめるのが流行っている。
・おうちハックでもやってみた。
・25日全部埋まった。すばらしい。
・すべて紹介する。


以上
投稿者 時刻: 0 件のコメント:

2014年12月22日月曜日

工学の終焉と再生

ある研究会での質疑の話を聞いた。フロアから、なぜそのアルゴリズムを使ったのか、と質問があったところ、発表者が
「OpenCVにあったから」
と答えた。OpenCVは有名な画像処理のライブラリである。この話は、ツールに依存して基礎を疎かにしている発表者を戒めるための逸話として語られている。しかし最近私は、もう少し大きな流れ、工学の民主化、もしくはコモディティ化、極端に言えば工学の終焉を表す一つの事例と考えるようになった。

デザイナーの奥山清行氏が自著[1]でトヨタのヴィッツと、BMWのニュー・ミニの話をしている。曰く「工業製品として優れているのは間違いなくヴィッツの方である。その差は圧倒的」だ。しかし、氏が選ぶのはミニである。性能が低くて、価格が倍以上するミニを選ぶのは何故か、また氏以外にも選ぶ人が相当数いるのはどういうことか。それはヴィッツがニーズ（Needs）であり、ミニがワンツ（Wants）であるからだ。他でも手に入るが仕方なく必要なものに、人は徹底的に財布の紐を絞る。対して、喜びのためであれば何倍もの金を、人によっては何十倍、何百倍の金を注ぐ。
私はこれを工学の敗北と読んだ。もちろん、高品質で低価格な製品が世の中にあふれることで、社会が得ている利益は莫大である。ただ、コモディティと化した製品は低価格競争に陥り、利益を得ることが難しくなり、やがては開発費用や維持費用を負担できなくなる。
この話を読みながら私は、電気が徹底してコモディティとなっている現状を重ねていた。電気事業の一翼で禄を食む物として、電気の普及による社会的利益の大きさと、それに比して極めて低い、電気に対する人々の価値意識を思っている。あってあたり前のものに高い金を出そうと思う人はいない。

もうかれこれ10年以上前に、渋谷で田中さんという研究者と会った。彼は写真をうまく使った興味深いアプリケーションを作っており、それを手伝えないかという話だった。結局私の技術では支援できないことがわかり、話はそれきりになった。ただ、その時に感じた、良いと感じたものに体ごと飛び込んでいく彼の姿勢は印象的だった。それから数年後、あるワークショップの昼飯時に彼が今どうしているのか、と話に出したら、彼はFabの伝道師になっているよ、その道では有名だ、と聞いた。慶応大学の田中浩也准教授である。彼の武勇伝は「FabLife」に詳しい[2]。
Fabは、パーソナルファブリケーションの意味であり、ものづくりをパーソナルに行うことを意味する。この場合、ワンツは自分の中にある。例えば、MITのFabLabに来た芸術系の女性ケリーが、自分で部品を組み立てて作り上げた「スクリームボディ」は、前に抱くバッグの形をしている。これは町中で急に叫びたくなった時に、口をあてて思いっきり叫んでも周囲に迷惑がかからない道具である。さらに後から誰もいない場所で再生できる機能まである(注1)。彼女は大勢人がいる場所で急に大声を上げたくなる衝動の持ち主で、その衝動のためずいぶん苦労してきた。しかし彼女のために製品を作ってくれるメーカーは無い。だから作った。
FabLab利用者が物を作れるのは、レーザーカッターや、3Dプリンタ、Python、またそれこそOpenCVなどの、各種装置、部品、ライブラリが普及したことによる。さらに、彼女にとって電子工学やプログラミング、工具の使用方法は、自分自身のワンツを叶えるために必要性の明らかなハードルである。だから乗り越えられる。
パーソナルファブリケーションに関してMITのガーシェンフェルドが書いた「Fab」という本[3]には、自分の必要のために、また楽しみのために、障害を乗り越えてものづくりをする人々が描かれている。例えば、ニコラ・テスラが1913年に発明した、薄い板が重なった低速回転用タービンと太陽熱を使って、動力源を作ろうとしているガーナの人たちが紹介されている。
こういった話はブルーエコノミー[4]や、適正技術[5]という文脈で様々に語られている。現地で手に入る材料や道具を使って、安価かつ簡易に「たどん」を作れる技術の有用性と、取り組みへの現地の人々の熱狂について。どこまでもシンプルに工夫された灌漑用ポンプの、コストパフォーマンスの高さ、また作っている人々の自活力、創造力の高さ。

さらに別の側面から。従来のマーケティングの無力さ、大量のアンケートに基づくデータ分析をしても、また、たくさんのユーザにニーズ調査をしても、なぜ魅力的な新製品を作り出せないのか、という課題に対して色々な提案がなされている。その中に「仮説生成型」とでも言うべき開発方法群がある。
例えば、「デザイン・ドリブン・イノベーション」[6]では、市場自体を変えた複数の製品開発に関して、ヒアリングをもとに議論している。そういった新製品、例えばアレッシーのワインオープナーや、任天堂のWiiを作り出すには、ユーザへの耽溺ではなく、デザインディスコースへの耽溺が必須である。デザインディスコースとは、隠された新しい意味、まだ気付かれていない新しい価値を探り当てようと日々取り組む人々（解釈者）のネットワーク（コミュニティ）である。解釈者の、まだ確信のない仮説、つぶやきに耳を傾けることが最も重要と彼らは主張する。
また、takram design engineeringは「ストーリー・ウィーヴィング」を提案している[7]。これは開発に先駆けて、使われるシーンをイメージした短いストーリーをグループで作るという方法論である。そのストーリーには、調査やプロトタイピング、ユーザビリティテストなどを通じて、常に立ち返って改訂を繰り返していく。モノ主導でも、ユーザ主導でもなく、魅力的なストーリー主導としている点が独特である。例えば、重なった所に虹ができる透明な傘「虹の傘」、雨粒がそのままストッキングの美しい模様になる「Stockings of Splashes」など、斬新な発想のプロトタイプが作られている(注2)。
三品らは「リ・インベンション」こそが必要と主張している[8]。この言葉はスティーブ・ジョブズが言った、
“Today, Apple is going to reinvent the phone, and here it is.”
で記憶に残っている方も多いだろう。イノベーションが旧来の価値基準で圧倒的に優れた技術を作ろうとする活動なのに対し、リ・インベンションは評価軸自体を作り替え、誰に・何を・どのように提供するかまで遡って再発明することを意味する。そのためには測定可能な客観指標を捨て、感覚的な理想を明確にイメージし、その理想に至るインテグリティ（一貫性）を貫くことが、容易な追随を許さない製品を生み出す、とする。

この100年、工学が急速に発展し、高度に専門化し、大きな社会的成功を達成した背景には、工学が「クオリティ」を無視したことが大きい、と私は考えている。工学は人間が「すてき」とか「うれしい」と感じるクオリティそのものは無視し、その代わりに精度や、効率、解像度、安定性、再現性などの客観指標を、クオリティに置き換えて追求してきた。それがヴィッツを、また停電のしない電力系統を実現させた。
しかし、そのことが今、工学を苦しめている。技術的に素晴らしい製品をいくら作っても高く買ってくれる人がいない。何故か。それは前述の奥山氏が書いているように、
「身もだえするほどほしい」
と思えないからだ。これを目的関数とする最適化アルゴリズムは無い。その意味で工学はすでに終焉している。
一方で、Fabや適正技術、また仮説生成型の製品開発といった流れが、新しい工学の再生を示唆している。世に無くどうしても自分が必要な、また売れるかどうか自信は無いが腹の底から欲しいと思うものを、自分で作れる環境が、まさに工学の発展のおかげで手に入りつつある。昔は椅子も家も、近所の職人が、また多くは自分で作っていた。一周してそこに戻っていくのだと考えることもできる。
私は、上述した本やウェブサイトで紹介されている、世界中でものづくりをしている子供から老人まで、多数の人々の写真や映像を見ながら、彼らの楽しそうな顔、自信に満ちた顔、ドヤ顔に、工学の新しい未来、再生を感じている。

参考文献：
[1]       奥山 清行「100年の価値をデザインする: 『本物のクリエイティブ力』をどう磨くか」 PHP研究所，2013．
[2]       田中 浩也「FabLife ―デジタルファブリケーションから生まれる『つくりかたの未来』」オライリージャパン，2012．
[3]       ニール・ガーシェンフェルド「Fab ―パーソナルコンピュータからパーソナルファブリケーションへ」オライリージャパン，2012．
[4]       グンター・パウリ「ブルーエコノミーに変えよう」ダイヤモンド社，2012．
[5]       シンシア・スミス「世界を変えるデザイン――ものづくりには夢がある」英治出版，2009．
[6]       ロベルト・ベルガンティ「デザイン・ドリブン・イノベーション」同友館，2012．
[7]       渡邉 康太郎「ストーリー・ウィーヴィング」ダイヤモンド社，2011．
[8]       三品 和広, 三品ゼミ「リ・インベンション: 概念のブレークスルーをどう生み出すか」東洋経済新報社, 2013．



注2： このURLにプロトタイプが多数紹介されている。
　
投稿者 時刻: 0 件のコメント:

2014年12月21日日曜日

Processing で ポップアップスレッド (Pop up dialog thread for Processing sketch)



Processing で drawの中の状態に応じてポップアップダイアログを出す方法。
普通にdraw内に記述すると、drawが止まってしまう。だからスレッドを使う

If you want to use dialog pop up in your draw function,
you should use a thread for the dialog.

-------------
float   percent;    // progress bar
boolean isRunning;  // flag for thread running
Thread thread1; // thread for pop up dialog
boolean answer; // answer of user

void setup() {
  size(400, 300);
  isRunning = false;
  percent = 0;
  answer = false;
}

void draw() {
  background(255);
  if (answer) stroke(#AA0000);
  else stroke(#0000AA);
  line(10, 10, percent++, 10);

  if (percent == 300) {
    percent = 0;
    if (!isRunning) {
      thread1 = new Thread(new popupThread());
      thread1.start();
    }
  }
}

// pop up thread
class popupThread implements Runnable {
  public synchronized void run() {
    isRunning = true;
    popUpJPanel();
    isRunning = false;
  }
}


import java.awt.*;
import javax.swing.*;

// pop up dialog
int popUpJPanel() {
  JPanel panel = new JPanel();
  BoxLayout layout = new BoxLayout(panel, BoxLayout.Y_AXIS);
  panel.setLayout(layout);
  panel.setPreferredSize(new Dimension(400, 50));

  panel.add(new JLabel("Feel Good?"));
  //checkComment = new JTextField();
  //panel.add(checkComment);

  int r = JOptionPane.showConfirmDialog(
  null,
  panel, "Feel Good", // title of dialog
  JOptionPane.YES_NO_OPTION, // option
  JOptionPane.QUESTION_MESSAGE);  // message type

  if (r == 0) answer = true;
  else answer = false;

  return r;
};

投稿者 時刻: 0 件のコメント:
登録: 投稿 (Atom)