山中俊治さんの義足の話

EARTHLING2011というシンポジウムを見てきた。全体を通して非常に充実した一日だった。なかでも山中俊治さんの義足プロジェクトがすごく印象的だったのでメモ

* プロジェクトをはじめた頃は「義足にデザインなんて」と懐疑的な見方をされた。
* 多くの義足は人間の脚に似せようとしている。ただしスポーツ用の義足はそうではない。美しい義足の形とはどういうものか?果たして人間の脚に似せるのが正解なのだろうか、と考えるようになった。
* ある日、グラウンドで義足のアスリートを見ながらスケッチを描いていると、そのアスリートに「絵を描く人なのですか?」と話しかけられた。自分はデザイナーで義足をデザインしたいと思ってスケッチしている、と伝えると「僕も実はこの脚ってかっこいいんじゃないかって思ってたんです。そういう見方をしてくれる人がいて嬉しいです」と言われた。その時にデザインの可能性を感じた。
* 日本には現在8000人の義足の人がいる。多くの人はズボンに隠しているので分らない。逆に、スポーツ用の義足をつけることによってはじめて義足で人前にたつことになる。
* ある女性のアスリートは自分の義足を花の模様で飾っていた。美的側面も求められていると確信した。

そのようにして何枚ものスケッチを描き、何体ものプロトタイプを経て現在のモデルにたどりつくのだそうだ。望まない理由で使うことになった道具が逆にアイデンティティとなっていく人間の強さ、そしてそれを後押しするデザインの力を感じるエピソードだ。

現在は一人一人にあわせて作っているので商業的にはまわらないだろう、と認めていた。ただそれは大量生産を前提にしたものづくりができないことで、それを分った上でやらなければならいと思ってやっている、と言っていた。

最後にモデレーターから「なぜこのプロジェクトをはじめたのですか?」と質問されて山中さんはこんな風に答えていた。「最初は単に好奇心です。でもそれでいいと思うんです。最初は好奇心で、この形って何だろう、と近づいて行くので。それでもやって行くと、後から、人助けになるとか役に立つとかそうものが見えてくるんです」

広告

エビデンスは証拠か?デザインは設計か?

とあるユーザーグループによる翻訳プロジェクトに参加している。


Lost In Translation より (特に本文と関係なし)

翻訳しているのは、UXデザインに関するごく短い文書なのだけれど、それでも、レビューしていると迷うところがチラホラとでてくる。例えば「evidence」。本文中には「実際のユーザーによるevidenceを集めてデザインを評価しましょう」のように出てくる。普通に日本語を当てるならば「証拠」なのだけれど、なんだかしっくりこない。証拠という日本語にはどうしてもネガティブな響き、あるいは説得材料に使うような攻撃的な響きがともなう、ような気がする。最近のビジネスで使われるエビデンスというカタカナにはもうちょっとフラットな、単なる「記録」や「データ」に近い響きを感じる。迷った末に、僕のレビュー担当分では「エビデンス」とカタカナで置いた。ある程度の専門的な読者を想定するならばその方がいいのではないか、という判断だ。最終的にどうなるかは分らないけれどまずはそれで。

そういう意味ではdesignも大変難しい。この場合は逆にカタカナでデザインと書くと逆に意匠に重きをおきすぎているような感じがある。ただ「設計」と訳してしまうと工学によりすぎているような感じがする。UXの議論の場合はどちらも含めたい。どうするべきか?

evidenceの例では今日の打ち合わせで、最初の一回目は「エビデンス(証拠)」と書くのはどうか、という案もでていた。それはなかなかいい手に思える。

パウル・クレー展は7/31(日)まで

すこし前のことになるが東京国立近代美術館にパウル・クレー展を見に行ってきた。

この展示、IA的観点からも面白かった。かなり大量に作品が展示されているのだが、それを単に年代別に並べていくのではなく、技法の観点から整理して空間を壁でゾーンにくぎるようにして展示していた。鉛筆で書いた絵を油彩でトレースするという油彩転写を使ったもの、描いたキャンバスを切断し、回転させたり組み合わせを変えたりしたもの、等々。パウル・クレーという作家の描くプロセスそのものまでに至る試行錯誤の流れを感じることができるように配置されていた。動線として興味深い。

会期は今週末(7/31)まで。
http://klee.exhn.jp/

プロトタイピングとアジャイル開発

アジャイル開発とプロトタイピング、割と近い文脈ででてくる用語なのだけれど、それぞれ別のものなんじゃないかと考えている。別、というよりもフェイズが違うというべきか。アジャイル開発はあくまで開発であり、プロダクションレベルのものをよりスマートに作り上げるための手法であるのに対し、プロトタイピングはアイデアを出す、またはぼんやりとしたアイデアの形を作るためのものなのだと思う。(ちなみにアジャイルといってもアジャイルUCDという用語もあるけれど、とりあえずここで触れているアジャイルはアジャイル・デベロップメントのことです)

先日のPivotal LabsのIan McFarlandさんと伊藤 穰一の対談(詳しくは安藤日記へ)にてIanが「プロトタイプのコードは絶対に捨てる」と言ったのを聞いた時はハッとさせられる思いだった。曰く、プロトタイプはユーザーストーリーを決めるものでコードはその発展系としてプロダクションに進んではいけない。ユーザーストーリーが決まったらテストを書いてTDD(テスト駆動開発)で作り直す、のだそうだ。確かに納得である。

burndown-chart
Photo by kakutani
バーンダウンチャート: そのチームがどのくらいの速度でストリーポイント(工数見積もりの単位)をこなしているかを可視化するチャート

アジャイル開発のフェーズでは、ソフトウェアに限ったことかもしれないけれど、テスト駆動開発であることがすごく重要だと思っている。テストがあることで、今日やるべきことが決まる。なのでチームの状態が見えるようになる。チームのヴェロシティ(開発速度)を見る上では、一つの実装に区切りができないといけない。なので、ここまでできればこのユーザースートリーは完成、ということをコードレベルで先に定義してしまうことはとても有効なプラクティスだ。そして、結果的に、テストがあることで、その後に変更を加えても丈夫なコードになる。

Paper prototype
Photo by cesarastudillo
ペーパープロトタイプの例

逆にいうとアジャイル開発に入った時点では(それほど)ユーザー視点を持つ必要はなくて、あくまで既にイメージが共有されているユーザーストリーを効率的に消化することに注力することになる。プロトタイピングは、そのユーザーストリーをチームで共有するために作る。なので、捨てることが前提で素早く作ることが最も重要となる。多くの人が紙ではじめるのもそのためだ。もちろん、本物に近い動くプロトタイプが一番イメージがはっきりするし、インタラクションの気持ちよさなんかは動かしてみないと分らないところが多いので、実際にコーディングするのは大変よいことなのだけれど、それはクオリティは度外視したものとなりがちである(クオリティにとらわれるべきではない)。例えば、データベースに無駄なスキーマが増えたり、使われないアクションや、ネーミングとして適切でない変数が偏在することとなる。なので「プロトタイプのコードは絶対に捨てる」というモットーは大変いさぎよい。そこからツジツマを合わせつつプロダクションに持って行くよりも効率はよいのかもしれない。

[アジャイル開発のおすすめ本]

Flow / ミハイ・チクセントミハイ (2)

Flowの続き:

3章途中。至上の経験(Optimal experience)を得た人の話を聞いて行くと、どんな文化圏の人に聞いても共通の表現が頻繁にでてくるそうだ。一例としては、時間の感覚が変わる。一時間が数分に感じられるし、数分が数時間に感じられる時がある、と言ったものがあげられる。そして、そういう経験は自己の成長を促す原動力となっている。この本では、そういう経験をFlowとよぶわけだけれど、それを得るためには『あるスキルを使ってチャレンジングな行動をすること』が最も有効らしい。アスリートが語る至上の経験などは典型的なそのパターンになるようだ。

面白いな、と思ったのはそういう経験の一例として「読書」をあげていたところ。「スキル」というとどうしてもフィジカルな、あるいは知識量的なものを競う例を考えるけれど、この本が言うには、読書というのは、目的を持ち、集中力を要する活動であり、それはFlowを得やすいパターンに値するようだ。ではスキルは?という疑問がうかぶわけだけれども、スキルと一口に言ってもフィジカルなスキルを指す訳ではないので、読書に必要となる、言葉をイメージにする力、架空のキャラクターを具現化し文脈を自分の中で構築し直す力は立派なスキルと言える、とのこと。確かに納得。松岡正剛も「読書は自分の考えと本に書かれている考えが混じること」と定義していた。そのスタンスをとるならば、単なるシニフィアンの読解力だけでは読書はなりたたない。「広い意味では、記号を扱うことは総じてスキルと呼べるのだ」と本文になる。確かにそうかもしれない。「それは音楽家が音符を音楽にするようなものなのだ」。ふむ、なるほど。

Flow / ミハイ・チクセントミハイ (1)


ミハイ・チクセントミハイの「Flow」を読んでいる。直接にデザインやエンジニアリングに関わる本ではないもののUX関係のいろいろな本で言及されているので一度ちゃんと読んでこうと思ったのです。とうことで読書中のメモを書いて行こうかと思う。

中心となる問題意識は「人の幸せとはなんなのか?満足している状態とはなんなのか?過去の時代から較べると物質的には何十倍も豊かになっているし、社会的にも最も洗練された状態にあるのになぜ幸せ感はそれほどにも上がっていないように感じられるのか?」というもの。社会的に、というのは、民主主義的なシステムが長い歴史的な苦労の上にやっとのこと築かれた現在であるにもかかわらず、という意味。よく聞く議論ではあるが確かにそうだ。そのあたりを科学の視点から検証して行こう、という本らしい。

ちなみに、幸せ度を測る試験として、ランダムに一日8回鳴るようにしたページャー(ポケベルみたいもの?)を色々な人にもってもらい、それが鳴った時の気分やしている事をメモする、という調査を1週間やったそうだ。日記調査としてなかなか面白い。携帯電話の利用実態などもこの手法で調査すると面白いかもしれない。

以下メモ
* 人々はリッチになりたい、痩せたいなどと願うものだが本当に満足できるものはそれではない。
* 根本的には世界は予測不可能なものであり、それを無理矢理に理解しようとして様々な社会的ツール(文化や宗教など)が作られてきた。それは「カオスから人々を守るシールド」である
* 私たちはもっとも重要なのは未来に起こることだと信じるように育てられてきている。今の苦労は未来のため、未来のため、と常に現在ではなく未来のために現在を生きているところがある。「それは常に明日のパンとジャムであり、今日のパンとジャムではない。」
* 私たちは動物的な欲求(肉体的な快楽をものめるもの)と社会的な欲求(まわりの人の評価をもとめるもの)に内側と外側からコントロールされている。そこから意識を使って自由になるのが満足いく毎日を送るための道である。

#現在1章を読み終わったところ

ペーパープロトタイピングならぬペーパービデオ

某本で知った”Twitter in plain english”というビデオが面白い。ペーパープロトタイピングならぬ紙とマジックのみで作った紹介ビデオ。

この会社Common Craftはこういった紙芝居型の紹介ビデオを作るサービスをしているらしい。Twitterだけでなく、例えば電球型蛍光灯の効果(とリスク)を説明したビデオもある。

あえてミニマムな手法でこなしているところがクールだし。これをビジネスにしてるのがすごいね。I like it.

nine hours

噂のカプセルホテル「nine hours」に泊まってきた。

女性用、男性用とフロアが別れていてエレベーターからして別。

左はロッカーとシャワーのフロア、右はカプセルの並ぶ部屋。

カプセルの中はこんな感じ。

スッキリとデザインされているので、カプセルホテル独特のみじめな感じはまったくしない、が、逆にカプセルホテルや健康ランドなどにあるユルい感じ(だらしなくてもゆるされる感じ)もない。ただしそれも、スターバックスでタバコが吸えないのと同じで、ある種のユルさを切り捨てて別の人に対しての快適な空間を作っているとも言える。なので、いままでカプセルホテルに独りで泊まるのは躊躇したような女性が、ここだったら利用したい、と思ったなら成功していると思う。

Webのエスノグラフィ? – ウェブは2重コンテキストモデル

先日のWeb-UX研究会ででた話で印象にのこった一言に「ウェブは2重コンテキストモデル」という安藤先生(@masaya21)のコメントがある。ウェブのサービスを考える上ではリアルのコンテキストとウェブの中のコンテキストを考えないといけない、という意味で、それを聞いて目からウロコが落ちた。(まぁわりと簡単に落ちるわけだけど)

図にするとこんな感じか

エスノグラフィはウェブにも有効か?

プロダクトデザインとウェブサービスのデザインの違いとして、エスノグラフィの有効性に違いがあるのではないか、と常々思っていた。現場に入って観察を主とする手法はプロダクトデザインのようなユーザーとモノが1対1の関係ならば見やすいが、ウェブサービスとなると、ちょっと難しいところがあるのではないか、と思っていた。それはウェブが身体性に欠けているからではないか、と思っていたのだが、それよりもこの「ウェブは2重コンテキスト」であるという考え方だと説明がつきやすい。たしかに一昔前のマスメディア型サイトやコーポレイトサイトのような情報の流れが一方向のものと違い、最近のウェブサービスはウェブの中にソーシャルグラフを持ち、ウェブの中でのユーザー同士のコミュニケーションというのが発生する。さらに難しいことにネットワーク外部性(あるネットワークのユーザーが増えれば増えるほと1ユーザーの得る利が上がる)の効果も強く作用する。なので、プロダクトデザインと同じ考えでエスノグラフィをやってしまうと、得られる情報は2重コンテキストモデルのリアル側のものだけになってしまう、ということなのだろう。となると、ウェブの中のコンテキストにおけるエスノグラフィ、またはそれに相当するような観察手法を考えないといけない。さて、どうすればよいだろうか?

UXD initiative 第一回研究会

UXD initiativeという研究会に参加してきた。千葉工大の山崎研究室に社会人/学生を問わず20人程度を集め、ゲストのプレゼンを聞いた後にディスカッションするというもの。少人数で行うので、よくある講演形式とは違った密度の濃い研究会だった。

今回のプレゼンターはKevin Clark氏。元IBMのブランドとエクスペリエンス担当のディレクターで現在はContent Evolutionというコンサルティングファームの代表をしているそうだ。この種の職能の人の共通した特徴でもあるが、Kevin氏もビジュアライズが非常にうまい。体験の価値やユーザーのメンタルな価値観など、なかなか表現しにくい要素を2軸のマトリックスだったり円を重ねるようにしたクラウド型の図形だったりと様々なビジュアライゼーションを駆使していて大変参考になった。よいビジュアライズには考え方のプロセスが見える。

Observation is better than asking?

途中「Observation is better than asking」という言葉がでてきたが、これは経験的にも同意できるところが多い。昨日も某システムにあがってきた「あったら便利な機能」のリストをチェックしていたのだけれど、どうも本当に現場とマッチしているとは思えないような項目が多々あった。それよりは実際にユーザーが使うシーンを観察した方が得るものが大きいのは想像に難くない。とはいえKevinさんのプレゼンでもいわゆるペルソナのようなユーザーの特徴やメンタルな価値観をビジュアライズしたシートがでてきていて、そのレベルとなると観察だけでは知り得ないだろうと思われた。なので、そういった調査にはインタビューを行うのか?行うとしたら単なるAskingとどう違うのか?と聞いてみた。

『単なる質問とエスノグラフィックな問いかけは違う。 例えばペンについて知りたいとする。ユーザーに「あなたはそのペンを好きですか?」と聞くのは単なる質問だが、「そのペンを手に持っている時に、あなたはどんなことをしていますか?」と尋ねてみる。そうするとユーザーはストーリーを語りだす』

なるほど。