TEDなどでも紹介されている有名なプロジェクトですが、LED Tileやこのプロジェクトのモジュール的なアプローチは面白いですね。
モーションセンサー、近くにある端末の識別が可能でワイヤレス通信を行っているとのこと。Shiftablesは特に、積みかさねたり、グループわけしたりといった自然なものの扱いに従って操作できるのが、素敵ですね。
http://sifteo.com/
inspiration コメント (0)
Yusuke Okamura @ 3月 11, 2010
先日、Make:japanで紹介されていたDesign for Disassemblyに関する記事はデザイン、オープンソース、サスティナビリティを考える上で示唆的だった。
これまでもプロダクト・デザイナーは、１つの製品の拡張性や製品ライフサイクルのことを当然考えてデザインをしてきている。しかし、これらの要件はどちらかというと、審美的な側面からいえば邪魔ものでコンセプトモデルでは美しかったデザインが、これらの要件を満たそうとして審美的な価値を失ってしまったり、造形としての美しさを優先させて、ユーザーにはバッテリー交換を出来ないようなデザインになってしまうこともある。
造形としての美しさとオープンな構造というのはなかなか両立しないのだろうか…。本質的には、このあたりのことを追う必要がありそうだが、最近の傾向としては、オープンな構造の方が価値として重要視され始めているように思う。これは、環境面だけの話ではなく、消費？のあり方の問題として。今日は、そんなことを考え始めるための事例をいくつかあげてみようと思う。
10秒で簡単に分解できるデンタル・フロスの容器の例
「分解できるデザイン」（Design fo Disassembly: DfD）は、将来、修理や改造やリサイクルができるように分解しやすく作るというデザイン手法だ。
DfDの利点は、 分解しやすさは製造しやすく製造に関するコストを低減する。それから、素材を減らしていくことにつながるので原料のコスト面でも有利に働く。また、このような企業の考え方が広まれば、環境意識が高い層の評価が高まり、新しいマーケットを創りだすことができる、とのことだ。それから、修理可能なパーツの販売も推奨されている。もちろん、危険が伴なうものは分解できないようにする必要があるが、特に作るプロセスや製品そのものが危険を伴わないものは、半完成品で提供してもよいと思う。完成品は完成品で良いが、「自分で作る」というプロセスや時間にもっと価値を感じられるようなものもあるはずだ。
こちらもMake:経由で知ったプロジェクトで、
製品の開発者や建築家に、たとえば流しや自転車などの部品を使って別の製品が作れるような、ハック可能な製品を作ってもらうための基準をまとめたものだ。このシステムの基本は4×4センチの方眼。あらゆる部品をこの規格に合わせて作ることになる。（中略）このシステムの核心は、製品を簡単に分解できて、簡単に再構築できるようにするという提案にある。
このプロジェクトがユニークなのは、「グリッド」=細胞、「パーツ」=組織（細胞のあつまり）、「コンポーネント」=心臓などの器官（組織のあつまり）、「ストラクチャー」=消化器官システムとして、階層化してデータベースを作ろうとしているところだ（該当ページへのリンク）。 すべてフラットなマテリアルではないために、用途に応じて必要なものを探し、「コンポーネント」の組み合わせでものを作ったり、「パーツ」レベルからものを作ることを可能にしている。
いわゆるメーカーの既製品でも、DfDやオープンな構造が採用されていれば、製品は単純に消費されるだけ、つまり予め規定された操作体系にしたがって操作するだけという、部分的で限定的な関与だけでなく、より能動的な製品への関わりを生み出すことができるのではないだろうか。
こちらは、ちょっと前のAdaptive Path社のプロジェクトで、インドの農村部でのフィールドワークからモバイルデバイスがどうあるべきか、というデザインコンセプトを導いたものだ。インドに限らず、アジアの途上国では携帯電話の（合法なものも非合法なものも）改造、修理の強烈な文化があるという[1]。この市場では、”hack-able”なデザインが重要で、視覚デザインのヒントをスチームパンクから採用し、カスタマイズがしやすいように見えるデザインを提案している。視覚デザインとしてこのようなデザインが効果的ななのかどうかはおいておくとして、途上国には分解可能であることや、修理可能であることは先進国とは少し異なる側面で大切な要件でありそうだ。
このようにいくつかの事例をみると、インタラクションデザイナーも画面のなかだけでなく、プロダクトデザイナーと協調し、ものとして製品ライフサイクル全体を視野にいれた、製品の扱い方をデザイン領域として捉えれば、製品とユーザーの新しい関係を構築し、新しいイノベーションに寄与する機会が増えそうだ。
[1]http://www.janchipchase.com/repaircultures
Opensource, Untitled コメント (0)
Yusuke Okamura @ 3月 8, 2010
以前に、「デザインとオープンソースハードウェア」というタイトルで、オープンソースハードウェアがサスティナブルな社会に貢献するのではないか、というようなことを書きました。今回は、このエントリーに続いてもう少しこのあたりを掘り下げて、ものづくりの分散化について考えてみようと思います。
※オープンソースハードウェアの簡単な説明はこちらをどうぞ。
住宅のオープンソース
既にご存知の方も多いかも知れないが、住宅のオープンソース化の試みに、建築家の秋山東一氏による「Be-h@us」という住宅システムがある。「Be-h@use」は、日本の風土にあった「木の家の作り方」をネットワーク上で共有化し、オープンソースのような存在にしようとするプロジェクトだ。ネット上に公開された部材のマニュアルや設計支援ツールでセルフビルドすることも可能だ。
秋山氏がセルフビルドを推し進める理由は、現在の日本の住宅への問題意識から始まっている。その問題意識は単純にハードが良くないという問題ではなく、生産と消費の構造への問題意識による。
―現代の住宅の問題は、生産者と消費者とが分断している、ということにあるのではないかと考えています。本来、住宅の作り方は伝統的、地域的な「共有知」に基づいたものであったはずですが、それを支えていた伝統的地域共同体の崩壊とともに、ハウスメーカーや工務店、設計者というような、生産組織の経済行為としての住宅の作り方に取り変わってしまったのです。
「Be-h@use」では、サスティナビリティや環境問題はどのように捉えられているのだろうか？
―Be-h@us のシステムは、その高性能をもって環境に負荷をかけない住宅を作りだします。その徹底ぶりは、その住宅が遠い将来、廃棄されるゴミになる時まで配慮されて います。また、Be-h@us にオプションとして附加される機能、Be-air という「夏涼しい家」を作る換気システム、Be-solar という壁面、屋根面を集熱面とするソーラーシステムは、そこでの生活を十分エコロジカルなものにします。それも、しっかりとした Be-h@us の躯体・箱があっての仕掛けなのです。
さらに、秋山氏はこう続けている。
―自分で作った家こそ、自らの責任で維持し発展させることができます。時間の中で、家は変化していきます。また、変化させていかねばなりません。
オープンソース、サスティナブル、デザインが重なる領域で、Be-h@useが示す、可能性の一つ目は、環境負荷が低いものづくりの方法をオープンソースで共有していく、というあり方。（このあたりは、Designers Accordに通ずるところがある。）特徴的なのは、完成形のソースが提供されるのではなく、自由度を持ったシステムとして、住宅を作るための環境として、提供されているところだろう。もちろん、ある完成形のソースを公開していくということにも大きな意味があるが、準備された仕組みを活用しモジュールを組み合わせるように、新しいものを生み出せるという環境は、創造力を刺激するのに程よい制約として機能する…。恐らく、今後ものづくりが本当に分散化すれば、一定の審美性や専門的な知恵が活用された「ものを作りのための環境やシステム」が求められ、デザイナーはこんな形でユーザーが作ることを支援するということが多くなるのではないだろうか。
可能性の二つ目は、現在の消費と生産の構造を問い直すというところにある。これまで生産者に委ねられてきた生産プロセスを、個人が取り戻すということは、生産と廃棄に関する環境問題に対し、個人がより大きな自由と責任を持つということを意味している。ポジティブに捉えれば、大量生産で余って廃棄されていたようなものが減ったり、「自らの責任で維持し発展する」意識が生まれて一つ一つの物の寿命が延びることなども想像できる。あるいは、地域共同体に根づいたものづくりであれば流通時の環境負荷を低減することも可能かもしれない。一方で、大量生産型の効率の高い生産システムではないために資源を有効に使えずに無駄が多くなる可能性や、産廃の管理などが企業単位以上に分散化することで社会全体での統制が難しくなるなどの反対意見もあるだろう。
生産と消費の話や社会の仕組については、まだまだ知識が乏しく結論めいた事は言いにくいのだけれど、現在、とても大切な問題として浮上しているように思う。今は、このあたりのヒントを求めて、イヴァン・イリイチの「コンヴィヴィアリティのための道具」を読み進めているところだ…
Opensource コメント (1)
Yusuke Okamura @ 1月 29, 2010
